Subject: [IPsec] Sorry, 5 more

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Feb 2010 11:00:08 +0200

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?

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2010 15:23:06 +0200

Yoav Nir writes:
> I have used "will" rather than "SHOULD" as we are not specifying any
> more of those when interoperability is not at issue.

The suggested paragraph is ok, and I agree on the using word will
instead of should. 

I also (still) agree on other issues you posted... 
-- 
[email-masked]