Dan McDonald writes:
> Am reading this right?
>
> On Fri, Feb 19, 2010 at 08:22:51AM -0800, Paul Hoffman wrote:
> > At 1:10 PM +0200 2/19/10, Tero Kivinen wrote:
> > >Yoav Nir writes:
> > >> Hi all.
> > >>
> > >> There are only three issues this time, because this is the last batch.
> > >>
> > > > Issue #173 - Trigger packets should not be required
> > >> ===================================================
> > >> In a few places in the new section 2.23.1 in IKEv2bis, it says that one
> > >> must have a trigger packet when starting negotiation. This assumption
> > >> should be removed so as not to cause new requirements in IKEv2bis:
> > >> there is no requirement for trigger packets in RFC 4306 or in the rest
> > >> of IKEv2bis.
> > >>
> > >> - "When the client starts creating the IKEv2 SA and Child SA for sending
> > >> traffic to the server, it has a triggering packet with source IP address
> > >> of IP1, and a destination IP address of IPN2" should be changed to
> > >> "...it may have a triggering packet...".
> > >
> > >This change is wrong.
>
> Tero -- why precisely is "may have a triggering packet" wrong?
Becahse it client starts sending traffic to the server, it has packet.
It is not necessarely wrong, but it sound funny to say "I have packet
I am sending from client to server, so I may have a packet..."
> The change is to say, "may have a triggering packet," right? If I understand
> that, then what Tero says:
>
> > >If client starts creating IKEv2 SA for sending traffic, it will have
> > >trigger packet. If it creates IKEv2 SA for some other reason (i.e not
> > >because of trigger packet, but because of autostart rule or similar),
> > >then it does not have triggering packet.
>
> AND what Paul says:
>
> > We disagree. If a client starts creating an IKEv2SA for sending traffic, it
> > may do that because it knows it will have packets in the future, but does
> > not have them when it sets up the SA. An autostart rule that is based on
> > *knowing* that something will come in the future is still creating IKEv2 SA
> > for sending traffic.
>
> are both true. If there's disagreement, it's only because you two are
> tassling over what constitutes "creating an IKEv2 SA for sending traffic."
I expect so. As this paragraph does not cover the other cases than
when you have triggering packet, I do not think it is good idea to
confuse the things to add text that looks like it could be applied in
other cases too.
> Sure an IKEv2 SA can be used for sending traffic, but creating one doesn't
> have to be the result of an outbound packet that needs AH or ESP protection.
Actually the text about "IKEv2 SA" is wrong, as IKEv2 SAs do not have
traffic selectors, it should only talk about Child SAs, i.e. perhaps
the better text would be:
When the client starts creating a Child SA for protecting packet to
be sent to the server, it has a triggering packet, it has a
triggering packet with source IP address of IP1, and destination IP
address of IPN2.
> Both of you acknowledge, I believe, that creating an IKEv2 SA can occur
> without a triggering packet (whether it's by some autostart rule, or
> some explicit administrator action).
Yes, but this paragraph does not talk about those cases, it only
applies when you have triggering packet, i.e. when you are creating
Child SA because of traffic you are sending.
> Am I missing something else? Ahh, I think I am. After reviewing Tero's
> note:
>
> > All of that paragraph is for the case where you do have packet. It
> > does not cover other cases.
> >
> > > - The same change is made in the third bullet of the client list near
> > > the end of the section.
> >
> > This is the one that needs to be changed, as that third bullet is not
> > only specific to triggering packet case, it is in the generic
> > processing section, i.e. that bullet should be changed to:
> >
> > - If SA is created because of the data packet, then the first TSi
> > and TSr traffic selectors SHOULD have very specific traffic
> > selectors including protocol and port numbers from the packet
> > triggering the request.
>
> So Tero --> you agree that an IKEv2 SA can be created w/o a triggering
> packet,
Yes.
> but the changes need to be localized to only certain portions of
> 4301bis, while the other portions of text only apply when we KNOW a
> triggering packet would be present?
Yes. There is text already covering the cases where you do not have
packet. There is also text where you do have a triggering packet.
This whole section we are talking here is very special case only
covering cases where following things are true:
- We are using NAT-T (i.e. there is NAT between).
- We are talking about transport mode
The example given generalizes this to cases where
- We have two NAT boxes between the client and server
and this paragraph covers the (most common case as we are talking
transport mode NAT-T here):
- We have packet we are going to protect, and need to create
Child SA for it, i.e. we do have triggering packet.
The first sentence could also be written in other way around:
When we do have a triggering packet with source IP address of IP1,
and a destination IP address of IPN2, i.e. when client starts
creating Child SA for sending that packet to the server, client
host's PAD and SPD needs to have configuration matching those
addresss (or wildcard entries covering them).
but this leads quite complex text.
Also as we are talking ONLY transport mode NAT-T here, the autostart
rules are not very common. Transport mode is used for host to host
traffic, and I do not really see that you have all your machines set
up to create Child SAs to all hosts they might be talking before
actually sending traffic to them.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
