[IPsec] Another round of IKEv2-bis issues

[Yoav Nir <[e-mail]>]

Hi all 

Following Sean's review, Paul has opened 7 issues, which we'd like to close.

I think issues #182, #183, #185 and #186 can be closed immediately. 

I think issues #181, #184 and #187 can also be closed, and I have included below my suggestions. Please take a look and respond if you object.

As before, silence is treated as consent.

Yoav


Issue #181 - Section 2.4 unclear on Child SA failing
====================================================
Section 2.4 says "If Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then they MUST be negotiated by separate IKE SAs". It is not clear what this means. Does it apply to implementations? If so, how can an implementation know whether or not the first clause is true? 

I propose removing the sentence, or greatly clarifying it.

Tero and Dave commented. Dave proposed alternative text, replacing "they" with "each set of Child SAs":

If sets of Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then each set of Child SAs MUST be negotiated by separate IKE SAs.

But I think this misses Sean's point, that while an implementation might be able to know whether child SAs fail independently in itself, it has no way of knowing this about the peer. So I propose we remove it entirely.



Issue #182 - Marking CP() as optional in early sections
=======================================================
Sean Turner asks: Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in Section 1.2?

Tero said that the basic exchange described in section 1.2 does not include many optional features like EAP, and NAT-T, so it can skip CP as well. 

I agree with Tero. It is fine as it is.



Issue #183 - Replace "X.509" with "PKIX" throughout?
====================================================
We use "X.509" when we probably mean "PKIX". That is, we only care about the PKIX profile of X.509, not just the base X.509 spec. However, X.509 appears in some of the protocol element names. Can we change it throughout to PKIX, or are we stuck with the old name?

Sean replied to this, saying "Sec 3.5 is where the references to [X.501] and [X.509] are.  You could just replace them with [PKIX], delete the two informative references, and be done."

So we will make that change.



Issue #184 - Interaction of rekeying of the IKE_SA and windows
==============================================================
s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25?

Tero responded that section 2.25 already deals with these issues. If anyone thinks differently, please say so NOW.



Issue #185 - What do to if you don't ignore INITIAL_CONTACT
===========================================================
s2.4, para 2: 
   The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH
   request or response, not as a separate exchange afterwards; receiving
   parties MAY ignore it in other messages. 
What should receiving parties do if they *do* receive it and *don't* ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a protocol error and should cause some response (like dropping the IKE_SA perhaps).

Both Yaron and Tero responded, that because RFC 4306 did not mandate that INITIAL_CONTACT be sent only in the IKE_AUTH exchange, older implementations may send it in other exchanges. Processing, in case they don't ignore it, should be similar to the regular processing of INITIAL_CONTACT which is specified in the next paragraph (conclude that the other IKE SAs have been erased, and silently discard them). So this text stays as it is.



Issue #186 - Generating and accepting which types?
==================================================
s3.5, para after ID Field types table: 'Implementations SHOULD be capable of generating and accepting all of these types.' Does 'all' here mean the four types in the previous sentence or 'all' the types in the full table?

Tero says: "Isn't this the same as issue #156 which was left as is."

We really mean the four types from the previous sentence, so let's change "accepting all of these types" to "accepting these all of these four types"



Issue #187 - EAP introduction wording
=====================================
The first paragraph of 3.16 now says: 

The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 <xref target='EAP'/> and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined elsewhere, but a short summary of RFC 3748 is included here to make this document stand alone in the common cases. 

Where is "defined elsewhere"? We should be specific. 

Also, we agreed to remove the short list of EAP methods, but we didn't fix the last phrase above. Suggested wording would be appreciated.  


Even Tero didn't reply to this, so here's my suggested wording (I just removed the offending sentence:
   The Extensible Authentication Protocol Payload, denoted EAP in this
   document, allows IKE SAs to be authenticated using the protocol
   defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
   A short summary of the EAP format is included here for clarity.