Subject: [IPsec] Another round of IKEv2-bis issues

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Apr 2010 08:30:14 +0300

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 08 Apr 2010 08:00:38 +0200

It's kind of weird to introduce EAP while avoiding any mention of EAP
methods. So I propose:

When using EAP, an appropriate EAP method needs to be selected. Many of these methods have been defined, specifying the protocol's use with various authentication mechanisms. They are listed in [EAP-IANA].

Thanks,
	Yaron
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Apr 2010 15:34:59 +0300

Yoav Nir writes:
> 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?  
> 
> 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.

Why should it know it about the peer? If the other end used same IKE
SA to negotiate the Child SAs, then those Child SAs cannot fail
independently.

This case is only for the local implementors, it does not have any
protocol implications, except that other end can assume that if Child
SA A, and Child SA B are negotiated using same IKE SA C, then if A
works, that means that B also works (or the Child SA is deleted using
IKE SA C).

The current text does not say anything what happens if the host Z
tries to create Child SA A and Child SA B using IKE SA C, and host X
notices that it cannot guarantee, that they cannot fail independently.
Most likely host X will then return error, but most likely it can also
make Child SA A and B so that they cannot fail independently, i.e.
allocate them from the same security processor.

I.e. if we make example where we have host A, having multiple security
processors F, G, and H. Each of those security processors is able to
run full IPsec, including multiple IKE SAs and Child SAs. Each of
those security processors is separate, i.e. SAs are not shared between
them, thus each IKE SA and Child SA is on only one of them. Also in
this example we assume that one of those security processors can fail
independently from others, i.e. even if one of them crashes, or looses
state, the others can stay up. The device itself will then of course
need some kind of internal "switch" inside, which will "route" IKE and
Child SA packets to corresponding security processor.

Now when host A is initiating negotiations it needs to make sure that
the Child SAs and the corrseponding IKE SA are on the same security
processor so if one of them fail, then all of them fail.

If this is not true, then host B reciving packets from host A using
child SA which happened to be on the other security processor than the
IKE SA of that child SA, still thinks the host A is up and running,
even when the IKE SA is already dead. This means that host B will
never start DPD, as it is seeing valid packets from host A coming in,
thus it will never notice that other Child SAs and the IKE SA on the
other security processor are dead, and will happily send data to them
without trying to recover.

As the crash recovery is done on the IKE SA bases, and the crash
recovery assumes that if any of the Child SAs on the IKE SA is alive,
then the IKE SA is also alive, it is important that Child SAs and IKE
SA cannot fail independently. 

> So I propose we remove it entirely.

I do not agree on that. In most cases this is implementation hint that
is not needed, as most environments do not have multiple independent
security processors, but on those environments where we have those, it
is important for correct behavior that implementors implement this
correctly. Those who are really working on implementations on systems
which have multiple independent security processors should understand
what is said in the current text. As those people who do work on such
implementaions is extremely small, I do not think there is need to
add lots of material explaining the situation (as I did here in this
email), but keeping the text in the specification is still needed.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 8 Apr 2010 11:27:10 -0400

>even when the IKE SA is already dead.

What is wrong with using a valid child SA?  If you are claiming
the child SA is not valid because it's IKE SA on host A no longer
exists then I'll agree.  When host A lost the IKE SA because the
security processor failed it should have cleaned up any SAs created
by the IKE SA.  That does not mean all SAs created by the IKE SA need
be on the same security processor.  That's just your rule and how you
decided to handle the situation.  You could have kept knowledge of
this relationship outside of the security processor.  I see no reason
to dictate how to handle this situation in the RFC.

>This means that host B will

Well if host A did not properly cleanup up all child SAs I agree this
could happen, but so what?  Everyone is happy.  Data is being
exchanged as per the child SA.  If host A did kill the child SA then
dead peer detection would kick in as desired.

It's probably more of an issue if the security processor
containing a child SA died while the IKE SA was
in another security processor, but I contend that in this scenario an
implementation could be smart enough to know what child SAs are
associated with each security processor and properly clean up.  In
this case it would even be able to send a delete.

>SA cannot fail independently.

It's all a matter of bookkeeping.  If they can fail separately you just
need to keep track of what needs to be cleaned up when a failure occurs.
The method you suggest is perhaps a good one and the easiest, but
it is not the only one.

>> So I propose we remove it entirely.

I'm fine with removing it.

>email), but keeping the text in the specification is still needed.

I do not agree.  The rule is simple.  If an IKE fails cleanup all Child
SAs created by it.  In the case of a security processor failure you are
guaranteed to have that happen if you keep the child SA on the same
security processor, but that does not means that is the only way to
do that.  You have some distribution logic in place to begin with.  That
logic can save enough state to perform the proper cleanup.  I see no
reason to address how this cleanup occurs in this RFC.

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Apr 2010 16:18:34 +0300

David Wierbowski writes:
> exists then I'll agree.

Yes. The Child SAs are tied up to the IKE SA and if IKE SA dies, all
Child SAs needs to be deleted also. 

> When host A lost the IKE SA because the
> by the IKE SA.

If the information that this Child SA belongs to that IKE SA was on
the same security processor which had IKE SA then it cannot, and if
this is the case, then the implementation is broken.

If the Child SA on separate security processor still knows how to tie
itself to the IKE SA, and can clean up the state, then the
implementation is correct.

The text there said that you should not create such implementation
where the Child SA does not get deleted when IKE SA is deleted.
Instead you needs to make sure that you can clean up all Child SAs
when the IKE SA disappears. 

> That does not mean all SAs created by the IKE SA need
> be on the same security processor.

True. The text does not require that. It does require that you can
maintain the connection between IKE SAs and Child SAs, and if you
cannot, because of the setup, then you need to use separate IKE SAs. 

> That's just your rule and how you

The RFC does not dicate solution, it dictates, that you need to solve
the problem and make sure that the IKE SA and Child SA connection
stays intact regardless of failures. And if you cannot ensure that
then you need to use separate IKE SAs. 

> dead peer detection would kick in as desired.

Data is exchanged over one SA, but there might be others on other
security processors, and from the Host B point of view those work too
(as IKEv2 assumes that either all Child SAs and IKE SA fail, or all of
them work). So Host B will send traffic to those SAs too, and that
will cause black hole, as those SAs did get destroyed when the failure
happened.

> need to keep track of what needs to be cleaned up when a failure

If you keep that bookkeeping, then they do not fail separately, so
this text does not apply. 

> reason to address how this cleanup occurs in this RFC.

I think we need to mandate that logic you explained there to the RFC.
The text there does that. It says that you need to keep Child SAs and
IKE SAs connected, and either all of them work, or none of them work
(or you might also get delete notifications for those which failed,
provided the IKE SA stays up).

What is not allowed that some of the Child SAs stay up, but the IKE SA
does not (i.e. no delete notifications). And this from the remote
point of view, i.e. if you maintain internal bookeeping and destroy
the Child SA when one security processor fails, that is fine, and from
the remote point of view all Child SAs and IKE SA got destroyed. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 22 Apr 2010 17:33:35 -0400

>the remote point of view all Child SAs and IKE SA got destroyed.

I don't think we need to mandate how a particular situation should be
handled.  That is up to the implementer.  The implementer just needs to
know that there is a rule that states the it is not for some child SAs
stay up when the IKE_SA disappears.  I think the existing text could be
deleted.

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Apr 2010 15:49:46 +0300

> stay up when the IKE_SA disappears.  I think the existing text could be

But the existing text is the text which gives this rule or at least
try to. I.e. it tries to say that if implementation cannot guarantee
that all Child SAs and IKE SAs stay up together, then you cannot
negotiate all those Child SAs using the same IKE SA.

This same can partially be seen from the:

  Receipt of a fresh cryptographically protected message on an IKE SA
  or any of its Child SAs ensures liveness of the IKE SA and all of
  its Child SAs.

text, but some people might be missing the point that ALL Child SAs
and corresponding IKE SAs must stay up together.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Fri, 23 Apr 2010 10:14:15 -0400

>and corresponding IKE SAs must stay up together.

What I do not like about the text is that it is a rule related to the
life of the Child SAs.  I think it would be clearer to tie the rule
to the termination of the IKE SA.  For example I think replacing the
text with some thing like the following is more straight forward:

If an IKE SA fails without being able to send a delete
message, then all Child SAs created by the IKE SA MUST be silently
deleted.

On the other hand I am not saying the existing text must be removed.
I'm just saying that I think it could be removed.

Dave Wierbowski

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Apr 2010 14:19:33 +0300

> message, then all Child SAs created by the IKE SA MUST be silently

Do you think it is legal to create a system where one Child SA can
fail in such way that IKE SA cannot send delete notification?

The current text says it is not legal, but your replacement text
allows it.

I do not think such setup should be allowed. I.e. if any of the Child
SAs or the associated IKE SA fail, in such way that delete
notification cannot be sent, then all the Child SAs AND the IKE SA
needs to be destroyed. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Mon, 26 Apr 2010 09:22:44 -0400

>fail in such way that IKE SA cannot send delete notification?

I do not think a robust IKE implementation would allow this.

>The current text says it is not legal, but your replacement text

The current bis text is:
   If a system creates Child SAs that can fail independently from one
   another without the associated IKE SA being able to send a delete
   message, then the system MUST negotiate such Child SAs using separate
   IKE SAs.

This text also does not prevent the above.  It just says how the
children can be created.  It says nothing about what happens when
they fail.

>notification cannot be sent, then all the Child SAs AND the IKE SA

Then say that.  Say if a Child SA fails and a delete notification
cannot be sent then the IKE SA must be deleted.  Personally I think
you change how you interpret the sentence each time you respond which
just echoes Paul's original point, that the text is not clear.

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Apr 2010 14:09:15 +0300

> I do not think a robust IKE implementation would allow this.

I agree, and the current text says you cannot do that (i.e. it says
taht if that is possible, you need to create Child SAs with separate
IKE SAs).

> children can be created.  It says nothing about what happens when

It says that you are not allowed to do that, you MUST create such
Child SAs on separate IKE SAs.

Meaning that if you follow that MUST, then the Child SAs cannot fail
independently from one another without the associated IKE SA being
able to send a delete notification. I.e you must group IKE SA and the
Child SAs in such way that they cannot fail independently. In worst
case you need to create one IKE SA for one Child SAs.

> just echoes Paul's original point, that the text is not clear.

I am not changing the way I interpret the sentence, I am trying to
explain to you that the current text provides solution for different
cases, and covers lots of cases.

I agree it might not be clear for some people, but I have not seen any
better way to say the same text which would cover all the cases behind
the original text. If you can provide such exact text, then we can
look at that. I have not yet seen such text, meaning the current text
is best we have now.

I do not want the current text to be removed just because some people
think it is not clear as for me it is clear enough and it is something
that needs to be mentioned, and I have not seen better text to replace
it.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 29 Apr 2010 11:01:48 -0400

>that needs to be mentioned, and I have not seen better text to replace

What about:

If any Child SA fails in such way that a delete notification cannot be
sent, then the corresponding IKE SA and all its associated Child SAs
MUST be deleted.  If the IKE SA fails without being able to send a
delete message, then all Child SAs created by the IKE SA MUST be silently
deleted.

Dave Wierbowski