Hi folks.
5 issues got lost in the system (they were tagged wrong). Hopefully these are
really the last 5.
Issue #132 - Should NO_ADDITIONAL_SAS cover rekeying IKE SAs?
=============================================================
In section 1.3 at the end there is text talking about the NO_ADDITIONAL_SAS.
The current text is in the generic CREATE_CHILD_SA section thus it covers all 3
use cases for CREATE_CHILD_SA (creating new IPsec SAs, rekeying old IPsec SAs
and rekeying IKE SA). The text there is written to cover only new IPsec SAs,
but I think it should also cover rekeying IKE SA cases (section 4 conformance
requirements makes it quite clear you can return NO_ADDITIONAL_SAS to any
CREATE_CHILD_SA exchange including IKE SA rekey).
This means the text should be changed from
The responder sends a NO_ADDITIONAL_SAS notification to indicate that a
CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. Some minimal
implementations may only accept a single Child SA setup in the context of
an initial IKE exchange and reject any subsequent attempts to add more.
To
The responder sends a NO_ADDITIONAL_SAS notification to indicate that a
CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. This notify can
also be used to reject IKE SA rekey. Some minimal implementations may
only accept a single Child SA setup in the context of an initial IKE
exchange and reject any subsequent attempts to add more.
I don't think anyone ever got confused about this, but I think this change is
fine. Anyone disagree?
Issue #133 - Adding more possible notifications when rekeying Child SAs
=======================================================================
1.3.3 section should say that other notifications explained in the 1.3.1 can
also be included in this exchange, i.e. if transport mode SA was rekeyed then
this CREATE_CHILD_SA rekeying that SA needs to include USE_TRANSPORT_MODE
notification. Some kind of reference back to the 1.3.1 should be enough.
(nice touch that issue #133 deals with section 1.3.3)
How about just adding the following paragraph:
The notifications described in [Section 1.3.1] may also be sent in a
rekeying exchange. Usually they will be the same notifications used
in the original exchange, for example, if we're rekeying a transport
mode SA, the USE_TRANSPORT_MODE notification will be used.
I have used "will" rather than "SHOULD" as we are not specifying any more of
those when interoperability is not at issue.
Issue #134 - SAi1 in cookies
============================
In section 2.6.1 it has text saying:
For instance, if the responder includes the SAi1 and KEi payloads in
cookie calculation, it will reject the request by sending a new cookie.
which is misleading, as even if SAi1 is included in the cookie, that should not
cause cookie to be rejected, as the retry behavior for INVALID_KE_PAYLOAD says
that SAi1 is going to be same (section 2.7 says: "The initiator MUST again
propose its full set of acceptable cryptographic suites ..."). IT would be
better to remove "SAi1 and" from the sentence and only talk about KEi:
For instance,
if the responder includes the KEi payload in cookie calculation, it will
reject the request by sending a new cookie.
So it's basically s/SAi1 and KEi/KEi/
I'm fine with that, anyone disagree?
Issue #135 - Which IKE SA inherits a Child SA?
==============================================
Section 2.8.2 seems to have quite fatal error:
The new IKE SA containing the lowest nonce inherits the Child SAs.
This is wrong. The one containing the lowest nonce, is the one that is going to
be deleted, not the one that survives. This needs to be changed to:
The new IKE SA containing the lowest nonce SHOULD be deleted by the node
that created it and the other suriving new IKE SA MUST inherit all the
Child SAs.
Note, that I used words MUST here as this is one of the few cases where the
correct behavior is really needed for interoperability reasons. It is not
needed for simultaneous Child SA cases, as traffic continues to flow, even if
they do not delete the loosing Child SA (we just have one extra Child SA). In
this case it is important for the interoprability that both ends AGREE on which
new IKE SA inherited the Child SAs from the old IKE SA. If they disagree then
all IKE SAs are messed up and future rekeys, deletes etc will fail. Deleting
the loosing IKE SA is not necessarely needed for interoperability so thats why
that is SHOULD (just like it is in the child SA case), but moving Child SAs to
correct IKE SA is MUST.
I agree with Tero. Anyone doesn't?
Issue #136 - NAT traversal and transport mode
=============================================
In section 2.23 the paragraph:
o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are
obtained from the Traffic Selectors associated with the exchange. In
the case of NAT traversal, the Traffic Selectors MUST contain exactly
one IP address, which is then used as the original IP address.
Says that In case of NAT traversal there MUST only be exactly one IP address,
but that actually only covers the transport mode NAT-Traversal (as said in the
beginning of paragraph) so the text should be changed to:
o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are
obtained from the Traffic Selectors associated with the exchange. In
the case of transport mode NAT traversal, the Traffic Selectors MUST
contain exactly one IP address, which is then used as the original IP
address.
I agree with Tero. Anyone doesn't?
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
