Subject: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Sep 2005 12:02:47 -0700

Hi all,

I have a question about rekeying CHILD SAs in IKEv2 and whether Delete 
messages MUST always be sent.

 From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA 
being rekeyed.  So, if both sides know that a given IPsec SA is being 
rekeyed, does it still need to be explicitly Deleted?  My thinking is that 
if we are going to delete an SA explicitly, then we don't need the notify 
payload and if we do use the N payload then there is no need to explicitly 
delete the SAs (of course this only applies to the special case of rekeying).

best regards,
Lakshminath

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Geoffrey Huang <[email-masked]>
Date: Mon, 12 Sep 2005 13:29:51 -0700

There should be no such assumption based on rekeying.  What I mean to
say is that any party can request a rekey at any time, and you shouldn't
make any assumptions on how the peer treats the old SA.  The peer might
continue to use the old SA to send traffic for some period of time.  If
you delete the old SA without explicitly notifying your peer, you can
create a black hole.

-g

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Sep 2005 14:46:35 -0700

Hi,

Thanks for your response.  I don't see that problem; let me try and run 
through a scenario (perhaps I am leaving something out that you are 
considering):

Let us assume that Alice sends a rekey CREATE_CHILD_SA message -- 
specifically, with the N payload from Alice to Bob identifying the SA being 
rekeyed, and that would be the SA from Alice to Bob, and that Bob sends a 
positive CREATE_CHILD_SA response with the SPI identifying the SA from Bob 
to Alice in the N payload, the following happens:

1. After Bob sends the response, he now knows that Alice wants to remove 
the SA from Alice to Bob and that he wants to remove the SA from Bob to 
Alice, so he can go ahead and delete both SAs.
2. When Alice receives the response, it can install the new SAs and delete 
both SAs.

If the response message from Bob is lost, Alice would repeat the request as 
per the IKEv2 spec.  If it cannot get a response from Bob, it needs to 
delete all the SAs with Bob anyway.

One might say that Alice may send IPsec traffic to Bob, encapsulated with 
the old SA between events 1 and 2 above, but I don't think that  applies to 
all cases. (i.e., this is an argument between MUST AND SHOULD).  I know of 
use cases, where parties know that they don't want to use the old IPsec at 
the time rekeying is initiated (and know of others, e.g., remote access, 
where seamless rekying is necessary).

So, I am not saying that the initiating party makes assumptions about how 
the peer treats the old SA.  In effect, I am saying that inclusion of the N 
payload in the CREATE_CHILD_SA exchange allows the parties to explicitly 
"replace" the old SA with the new SA.

Finally, what is the purpose of the N payload in the CREATE_CHILD_SA exchange?

regards,
Lakshminath

---

From: Geoffrey Huang <[email-masked]>
Date: Mon, 12 Sep 2005 15:12:47 -0700

> Alice, so he can go ahead and delete both SAs.

I disagree.  Bob only knows that Alice wants to rekey the SA with the
given SPI.  He doesn't know that Alice wants to delete the old SA.

> "replace" the old SA with the new SA.

I think the inclusion of the Notify merely says, "I'm rekeying SA with
SPI X in this CHILD exchange."  This is different than "I'm replacing SA
with SPI X with the new SA we're about to create."

> Finally, what is the purpose of the N payload in the CREATE_CHILD_SA exchange?

To indicate that the SA you're negotiating is a rekey, and not a
deliberate parallel SA.  See section 2.8:

   Note that IKEv2 deliberately allows parallel SAs with the same
   traffic selectors between common endpoints. One of the purposes of
   this is to support traffic QoS differences among the SAs (see section
   4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the
   endpoints and the traffic selectors may not uniquely identify an SA
   between those endpoints, so the IKEv1 rekeying heuristic of deleting
   SAs on the basis of duplicate traffic selectors SHOULD NOT be used.

-g

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Sep 2005 15:39:55 -0700

Hi,

Please see inline:

>given SPI.  He doesn't know that Alice wants to delete the old SA.

Sure it is saying rekey, but given the parallel SAs vs. rekey SAs 
differentiation, I am not sure what purpose the N payload serves.  Hence, I 
think that "indication of rekeying via N payload" is an explicit 
declaration of intent to replace.

>with SPI X with the new SA we're about to create."

I understand that.  However, I am not sure what actions might be taken 
based on that information.

>deliberate parallel SA.  See section 2.8:

Not sure why the peer needs to indicate that an SA as being rekeyed, if it 
is going to send an explicit "delete" anyway.  Other than an early warning 
:-),  I cannot think of other reasons.

regards,
Lakshminath

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 12 Sep 2005 15:40:22 -0700

> There should be no such assumption based on rekeying.  What I mean to

Yes, this is what is specified in section 2.8:
 
   Hence unlike IKEv1, the combination of the
   endpoints and the traffic selectors may not uniquely identify an SA
   between those endpoints, so the IKEv1 rekeying heuristic of deleting
   SAs on the basis of duplicate traffic selectors SHOULD NOT be used.
   The node that initiated the surviving rekeyed SA SHOULD delete the
   replaced SA after the new one is established.

But i wonder what the purpose of N(REKEY_SA) is ? What is the responder supposed
to do with REKEY_SA notification ? If it just ignores it, then it is the same as the
CREATE_CHILD_SA ? One can potentially use it to insert the new SA in front of the
old SA so that outbound traffic can use the new SA. But you can't do so for the reasons
given in the last paragraph of section 2.8.

-mohan

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 13 Sep 2005 10:34:07 +0300

This issue has come up before. The only reasonable interpretation we came up
with is that IPSec is usually done by a machine that is also a firewall.
Firewalls tend to be "stateful" in the sense that they follow connections.
A firewall-vpn device may expect a single connection to use the same IPSec
SA all the time, so the rekey notification serves as an early warning that
future packets using the rekeyed SA may come from the new SA.

I know this is a dagerous assumption to make, because there is no reason to
think that the packets from a single connection shouldn't use different
parallel SAs, but that's the only justification I can come up with for
explicitly saying that this SA replaces that SA. 

-----Original Message-----

 <snip>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Sep 2005 09:27:55 -0700

Hi Yoav,

Thanks.  I did some searching (a quick search) before I posted to the list, 
and did find detailed notes in ikev2-clarifications-00.  Pasi and Paul seem 
to have wondered about this too, but the text in the current version (05 
was posted yesterday) is the same as in ikev2-17 with some minor 
clarifications on which SPI to use in the N payload.  There was nothing on 
what purpose the N payload serves.

The notes you provide below are informative.  Based on your message and 
other responses so far, I'd conclude that there is currently no reasonable 
case for why N payloads MUST be sent.

thanks and regards,
Lakshminath

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 13 Sep 2005 09:35:54 -0700

Wouldn't the rekey notify payload also be useful for indicating that a
rekey timer should stop?

-g

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Sep 2005 09:37:52 -0700

>Wouldn't the rekey notify payload also be useful for indicating that a

I am not sure I understand.  Please elaborate.

thanks,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Sep 2005 13:03:11 +0300

Mohan Parthasarathy writes:
> But i wonder what the purpose of N(REKEY_SA) is ? What is the
> responder supposed to do with REKEY_SA notification ? If it just
> ignores it, then it is the same as the CREATE_CHILD_SA ? One can
> potentially use it to insert the new SA in front of the old SA so
> that outbound traffic can use the new SA. But you can't do so for
> the reasons given in the last paragraph of section 2.8.

There are several resons for the N(REKEY_SA). The basic idea is to get
rid of that heuristic that happened in IKEv1, where implementations
searched their SAs trying to find out if this is rekey or not. To
explicitly tell that is rekey get rid of that.

Then we end up the question why does the responder need to know this
is rekey. There are multiple reasons for that, and most of them depend
on the implementations.

Most commons ones (not in any particular order, and not all are
applicable in all implementations)

1) To keep statistics over SAs over rekeys they need to know from
   which SA the old statistics need to be copied to this new SA
   (i.e. they want to show that this SA has moved XX bytes, and the
   whole SA family including all rekeys have moved YY bytes over ZZ
   rekeys etc).

2) They want to optimize the rekeying operation, meaning that they
   know that the sending to both new and IPsec SA is is not needed at
   the same time, so they can for example allocate shared crypto
   context to the outgoing traffic. I.e. they keep the current old
   outbound SA in the crypto core and use it, until they receive
   packet for the new inbound SA, and then they exchange the contents
   of the outbound crypto core to use new SA. They can also do this
   for the inbound traffic, in a way that they keep the old inbound SA
   in the crypto core, and just store the new inbound SA in memory,
   and when they got SPI not found from the crypto core, they can do
   processing on the slowpath and check if the new SPI they have
   matches the packet, and if so swap the new and old inboud SAs. They
   still need to be able to process inbound traffic with the old SA,
   but that is not very common, so it might be even done on the
   slowpath.

3) They want to make sure the new SA shares the same narrowed traffic
   selectors than the old SA before rekey, so that some of the traffic
   isn't suddenly left outside of the tunnel because of the different
   narrowing happening. I.e. initiator SPD has 10.0.0.0/8 <->
   192.168.0.0/16 and he proposes that on the rekey too. The responder
   SPD has 10.0.0.0/8 <-> 192.168.1.0/24, 192.168.4.0/24. The old
   traffic selectors of the rekeyed SA was 10.0.0.0/8 <->
   192.168.4.0/24 as the first packet happened to go to that network,
   and responder decided to have separate SAs per net. When rekeying
   the responder can check from the old SA what was the traffic
   selectors there, and try to match them in the rekeyed SA also
   (otherwise it might happen that this rekeyed SA is not matching the
   traffic old SA had, thus it wasn't working rekey). Initiator and
   responder want to send full decorellated SPD entry selt when
   rekeying so they will catch policy changes.

4) There is also implementations that will keep track on TCP flows and
   so on, and keep them on the same SA all the time. They want to know
   the new SA for those flows, so they are sure they are matching the
   rules specified for the flow.

5) The responder might have extra traffic selectors like QoS
   parameters, and he might want to keep the same traffic on the same
   SA after rekey also. 

6) Responder might also want to keep track of SAs to support channel
   bindings or similars etc.

Because of that it was considered better not to do IKEv1 style
guessing on the responder, but explicitly mention what SA is rekeyed,
so that responder can easily do those implementation dependend things. 
-- 
[email-masked]

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Sep 2005 11:25:13 -0700

Hi Tero,

On your notes in item #3 of your email below:

Are you saying that when two peers rekey an IPsec SA, they ought to use the 
same selectors?  I think not.  ( I don't recall anything like that 
specified in the ikev2 spec)

Furthermore, are you saying that the Initiator must send the same TS 
payload as in the original IPsec SA proposal?  Why?  Even if we agree on 
the above statement of rekeyed SAs MUST use same selectors, I'd say that 
the Initiator then MUST propose the agreed upon (or narrowed) selectors 
(TSr) and expect that the responder would readily agree.

But, back to the original point.  I think that a CREATE_CHILD_SA exchange 
message, even in case of rekeying, can carry any TSi the initiator chooses 
and does not depend on the current selectors.

regards,
Lakshminath

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 15 Sep 2005 14:32:29 -0400

> specified in the ikev2 spec)

if the selectors change, when would you consider this a rekey rather
than a parallel SA?

						- Bill

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Sep 2005 14:30:14 -0700

>if the selectors change, when would you consider this a rekey rather

If two parties know explicitly that they definitely don't want more than 
one IPsec SA between them.

Lakshminath

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 15 Sep 2005 17:46:18 -0400

> one IPsec SA between them.

2401bis and IKEv2 require support for multiple IPsec SA's.

						- Bill

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Sep 2005 15:16:37 -0700

>2401bis and IKEv2 require support for multiple IPsec SA's.

I just checked the compliance requirements section (Sec 4) of ikev2-17, and 
the following are under "
There are a series
    of optional features that can easily be ignored by a particular
    implementation if it does not support that feature. Those features
    include:

...

       Ability to establish multiple ESP and/or AH SAs within a single
       IKE_SA.

       Ability to rekey SAs.
...
"
I would like to rekey an SA, but don't care about supporting multiple 
SAs.  My reading of the N payload was that I could actually do it.  I do 
understand the implications of changing selectors as well as rekeying while 
deleting the old SA (i.e., some dropped packets on the old SA), but if my 
application is tolerant to the implications (both parties understand the 
implications and therefore are willing to stop traffic while an SA is 
rekeyed), but wants to be as efficient as possible (just for argument 
sake), it should be able to do that.

As I make this case, I recall an old DARPA project, where the requirement 
was that when rekeying a group SA, the sender MUST stop transmission, rekey 
the GSA, and then start transmission via the new GSA.  The premise is that 
the old group keys are (may have been) compromised, but we know that long 
term keys are not and would like to rekey the SA.

Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Sep 2005 12:04:38 +0300

> specified in the ikev2 spec)

Depends what you mean by same selectors. The actual traffic selectors
in the IKE can and will be different, but the traffic selectors should
be derived from the same SPD rule than before (otherwise it would not
be rekey, right?). If the responder narrowed traffic selectors last
time, initiator should still use the full rules from SPD not the
narrowed traffic selectors, as the responders policy might have
changed.

If the SPD rules have changed since last time the traffic selectors
resulted by this rekey can be different than last time, but both ends
should make sure as much traffic as possible from the previous SA can
be fitted to this new SA. 

> payload as in the original IPsec SA proposal?

The traffic selectors proposed should be based on the SPD entries, and
they should be full set from SPD, not the narrowed set that was used
in the SA being rekeyed. 

> Why?

So that if either ends policy has changed, we actually take those
changes in to account and create widest possible SAs that can pass the
packets used by the old SA. It might even be wider than before.

Example would be that initiator has policy 10.0.0.0/8 <->
192.168.0.0/16 and responder had policy 10.0.0.0/8 <-> 192.168.2.0/24,
but then new network 192.168.5.0/24 is added to the responder side, so
after next rekey the SA will automatically have that network added to
traffic selectors.

> Even if we agree on 

He could do that, but in that case SA selectors cannot never be
expanded even when both end's policy has been changed. 

> and does not depend on the current selectors.

I disagree. I think they MUST depend on same SPD rule that was used to
create the current selectors. Otherwise it is not rekey, as it could
be possible that the traffic we are transferring wno on the SA would
not fit to that SA anymore.

Remember that in the rekey we do have traffic we are supposed to move
from that old SA to that new SA. If they have distincting set of
traffic selectors, you cannot move that traffic. 
-- 
[email-masked]

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Sep 2005 08:43:37 -0700

Hi Tero,

Many thanks for the clarifications.

>narrowed traffic selectors, as the responders policy might have

Your note about the Initiator using the full rules from SPD makes sense to 
me now.  Sorry I missed that before.

Let me explore a couple of cases:

Case 1:  There are multiple IPsec SAs between 2 peers and one of the peers 
seeks to "rekey" one of the SAs.  As you note, I think the initiator SHOULD 
start out with the same TS payloads as used in the original IPsec SA 
establishment (which in itself could have been the result of the initial 
IKE SA, or a CREATE-CHILD-SA exchange: rekey or a parallel SA).

Case 2: There is a single IPsec SA between 2 peers and one of the peers' 
local policy changes -- there are dramatic changes in its SPD and it is 
still interested in a single IPsec SA with the peer with the new traffic 
policy.

My take is that I'd use rekey -- since intent is still to replace that one 
IPsec SA -- with the new SPD information in the TS payloads.  The Responder 
of course is welcome to accept or deny the new proposal.

>be fitted to this new SA.

This makes sense to me in Case 2 above.

In Case 1, there are so many scenarios, including the following which makes 
me think that the above is just a rule of thumb.

For instance an Initiator proposes a range of IP addresses to the Responder 
which let's say narrows the range down drastically.  Let us further assume 
that the Initiator accepts the narrower range.  The Responder in the future 
might propose a new CREATE_CHILD_SA exchange with a wider range and the 
Initiator accepts.  Some implementations might choose to consolidate the 
SAs in a rekeying attempt and some might not.  If I were implementing (or 
continuing my old hack at IKEv2 code), I'd guess that another 
implementation might choose any combination and willing to work with it.

>they should be full set from SPD, not the narrowed set that was used

I agree here, with the understanding that sometimes the "full set" might 
have been narrowed due to local policy changes -- either by firewall rules 
or other apps.

>not fit to that SA anymore.

Tero, I think I can use some help here to understand the SPD rule.  If that 
SPD rule you refer to has changed dramatically (recall Case 2 above), is it 
okay still to use rekey semantics?

thanks and regards,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Sep 2005 03:45:08 +0300

> okay still to use rekey semantics?

If it is still same SPD rule, I think it should use the rekey. If
there is no overlapping traffic with the old and new SPD entries, then
it should probably simply destroy the old SA and create new SA (as
there is no traffic that could be moved from old SA to new SA).

The rekey do have an idea behind it that you move old traffic from the
SA to this newly created SA...
-- 
[email-masked]

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Sun, 18 Sep 2005 18:20:17 -0700

Thanks again Tero.

best wishes,
Lakshminath

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Sep 2005 13:49:41 -0400

At 3:16 PM -0700 9/15/05, Lakshminath Dondeti wrote:
>I just checked the compliance requirements section (Sec 4) of 
>ikev2-17, and the following are under "
>There are a series
>I would like to rekey an SA, but don't care about supporting multiple SAs.

In section 4.1 of 2401bis (page 13) the text says: To permit this, the
    IPsec implementation MUST permit establishment and maintenance of
    multiple SAs between a given sender and receiver, with the same
    selectors.

This is unambiguous, so if you don't support multiple SAs, you will 
be non-compliant.

Steve

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Sep 2005 11:16:59 -0700

At 10:49 AM 9/19/2005, Stephen Kent wrote:
>>I just checked the compliance requirements section (Sec 4) of ikev2-17, 
>>and the following are under "
>>There are a series
>This is unambiguous, so if you don't support multiple SAs, you will be 
>non-compliant.
>
>Steve

Thanks for the reference Steve.  It appears then the compliance 
requirements of IKEv2 and 2401bis are at odds with each other.  The 
ikev2-17 draft does say that a minimal implementation can support only the 
base exchange to establish an IPsec SA -- no scope for multiple SAs 
there.  I can see an IPsec implementation that supports multiple IPsec SAs 
-- one manual (or via another key management protocol) and another 
supported by IKEv2 (but don't want to really go there in this thread).  Do 
you think the ikev2-17's compliance requirements need to be rewritten?

You seem to have followed this thread, so let me pose the original question 
that led us here:

In IKEv2 CREATE_CHILD_SA exchange, the N payload is supposed to carry the 
SPI of the IPsec SA being rekeyed.  I was wondering if that allows us to 
"replace" the old IPsec SA with the new one (with the understanding that 
some traffic encapsulated with the old SA might be dropped, if sent after 
rekeying -- and in some cases that's ok since both sides have decided to 
stop using the old SA).  The alternative of course if to create a parallel 
SA and delete the old one, which could have been done without including the 
N payload in the rekey message.  The N payload, as has been pointed out in 
this discussion, only serves the purpose of say, book keeping (e.g., 
statistics, optimization of rekeying).

Many thanks for your time.

regards,
Lakshminath

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Sep 2005 15:39:36 -0400

At 11:16 AM -0700 9/19/05, Lakshminath Dondeti wrote:
>ikev2-17 draft does say that a minimal implementation can support 
>only the base exchange to establish an IPsec SA -- no scope for 
>multiple SAs there.  I can see an IPsec implementation that supports 
>multiple IPsec SAs -- one manual (or via another key management 
>protocol) and another supported by IKEv2 (but don't want to really 
>go there in this thread).  Do you think the ikev2-17's compliance 
>requirements need to be rewritten?

A clarification is is order, at a minimum. It should be included in 
the in-progress IKEv2 c;larifications document.

I didn't quote the rest of the IPsec text, but it provided the 
rationale for this requirement, and it is something that the WG 
agreed upon, e.g., to support different SAs for QoS purposes.

>You seem to have followed this thread, so let me pose the original 
>question that led us here:
>
>In IKEv2 CREATE_CHILD_SA exchange, the N payload is supposed to 
>carry the SPI of the IPsec SA being rekeyed.  I was wondering if 
>that allows us to "replace" the old IPsec SA with the new one (with 
>the understanding that some traffic encapsulated with the old SA 
>might be dropped, if sent after rekeying -- and in some cases that's 
>ok since both sides have decided to stop using the old SA).  The 
>alternative of course if to create a parallel SA and delete the old 
>one, which could have been done without including the N payload in 
>the rekey message.  The N payload, as has been pointed out in this 
>discussion, only serves the purpose of say, book keeping (e.g., 

Rekeying ultimately does replace an old SA (pair) with a new SA 
(pair). But, I think the intent is to create a new SA and have both 
in place simultaneously, to facilitate the transition and minimize 
packet loss during rekey.

Steve

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Sep 2005 14:07:17 -0700

At 12:39 PM 9/19/2005, Stephen Kent wrote:
>>ikev2-17 draft does say that a minimal implementation can support only 
>>the base exchange to establish an IPsec SA -- no scope for multiple SAs 
>>there.  I can see an IPsec implementation that supports multiple IPsec 
>>SAs -- one manual (or via another key management protocol) and another 
>>supported by IKEv2 (but don't want to really go there in this 
>>thread).  Do you think the ikev2-17's compliance requirements need to be 
>>rewritten?
>
>A clarification is is order, at a minimum. It should be included in the 
>in-progress IKEv2 c;larifications document.
>
>I didn't quote the rest of the IPsec text, but it provided the rationale 
>for this requirement, and it is something that the WG agreed upon, e.g., 
>to support different SAs for QoS purposes.

Yes indeed.  However, my understanding was that QoS considerations do not 
apply to all implementations.  In any event, a clarification one way or 
another should happen in some form -- ikev2-clarifications would be a 
start.  But, the ikev2 draft can also be edited during the RFC Ed processes 
to note that supporting multiple simultaneous child SAs with the same TSs 
is not optional.

>>stop using the old SA).  The alternative of course if to create a 
>>parallel SA and delete the old one, which could have been done without 
>>including the N payload in the rekey message.  The N payload, as has been 
>>pointed out in this discussion, only serves the purpose of say, book 
>>keeping (e.g., statistics, optimization of rekeying).
>
>Rekeying ultimately does replace an old SA (pair) with a new SA (pair). 
>But, I think the intent is to create a new SA and have both in place 
>simultaneously, to facilitate the transition and minimize packet loss 
>during rekey.

ok, thanks for the clarification Steve.

best regards,
Lakshminath

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Sep 2005 14:56:52 -0700

At 2:07 PM -0700 9/19/05, Lakshminath Dondeti wrote:
>Yes indeed.  However, my understanding was that QoS considerations 
>do not apply to all implementations.  In any event, a clarification 
>one way or another should happen in some form -- 
>ikev2-clarifications would be a start.

That could happen if this group agrees. But...

>   But, the ikev2 draft can also be edited during the RFC Ed 
>processes to note that supporting multiple simultaneous child SAs 
>with the same TSs is not optional.

I don't believe it can. This is a serious technical change, which 
would mean that it would have to go back to the IESG and the WG 
(which no longer exists). From what I have heard from a huge number 
of implementers, they want IKEv2 as an RFC as soon as possible. Such 
a delay would probably be unacceptable.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Sep 2005 15:12:32 -0700

At 02:56 PM 9/19/2005, Paul Hoffman wrote:
>>another should happen in some form -- ikev2-clarifications would be a start.
>
>>   But, the ikev2 draft can also be edited during the RFC Ed processes to 
>> note that supporting multiple simultaneous child SAs with the same TSs 
>> is not optional.
>
>I don't believe it can. This is a serious technical change, which would 
>mean that it would have to go back to the IESG and the WG (which no longer 
>exists). From what I have heard from a huge number of implementers, they 
>want IKEv2 as an RFC as soon as possible. Such a delay would probably be 
>unacceptable.

Hi Paul,

That makes sense.  However, from the discussion over the past several days 
on the topic, it looks like the consensus is either

1) support for multiple CHILD SAs is not optional -- this was based on the 
2401bis requirement.
2) at least if rekeying is implemented, support for multiple CHILD SAs is 
not optional (in other words the optional features in page 84 are not 
independent of each other as the text above the list seems to imply)-- this 
was based on the DELETE exchange requirement.

Is that not the case?

I am among those who would like to see the RFC immediately, but I'd prefer 
to see it with uncontested clarifications incorporated.

thanks and regards,
Lakshminath

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 19 Sep 2005 18:33:11 -0400

> was based on the DELETE exchange requirement.

so, as I understand the specs at present, the place where you can prune
functionality in an IKEv2 implementation without affecting
interoperability is the ability to *initiate* multiple IPsec SA-pairs
from a single IKE SA.

In other words, in a simplified implementation, you can omit code which
initiates a CREATE_CHILD_SA, but if you refuse to accept it when offered
by a peer, you may create an interoperability barrier.

						- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Sep 2005 16:13:12 -0700

At 3:12 PM -0700 9/19/05, Lakshminath Dondeti wrote:
>That makes sense.  However, from the discussion over the past 
>several days on the topic, it looks like the consensus is either
>
>1) support for multiple CHILD SAs is not optional -- this was based 
>on the 2401bis requirement.

To date, fewer people have been as concerned about requirements in 
2401bis as they have been in IKEv2.

>2) at least if rekeying is implemented, support for multiple CHILD 
>SAs is not optional (in other words the optional features in page 84 
>are not independent of each other as the text above the list seems 
>to imply)-- this was based on the DELETE exchange requirement.

I don't agree that there is consensus on that yet, given how few 
implementers have said anything. This part of the IKEv2 document was 
reviewed many times and discussed in the WG many times. The issue can 
be covered as recommendations in the IKEv2 clarification document.

>I am among those who would like to see the RFC immediately, but I'd 
>prefer to see it with uncontested clarifications incorporated.

We do not have that option; that's why Pasi and I are working on the 
clarifications document. I would note, however, that we are hearing 
less and less about the open issues in that document, and that's a 
tad disturbing.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Sep 2005 16:15:50 -0700

At 04:13 PM 9/19/2005, Paul Hoffman wrote:
>>That makes sense.  However, from the discussion over the past several 
>>days on the topic, it looks like the consensus is either
>>
>>1) support for multiple CHILD SAs is not optional -- this was based on 
>>the 2401bis requirement.
>
>To date, fewer people have been as concerned about requirements in 2401bis 
>as they have been in IKEv2.
>
>>independent of each other as the text above the list seems to imply)-- 
>>this was based on the DELETE exchange requirement.
>
>reviewed many times and discussed in the WG many times. The issue can be 
>covered as recommendations in the IKEv2 clarification document.
>
>clarifications document. I would note, however, that we are hearing less 
>and less about the open issues in that document, and that's a tad disturbing.

Thanks for the clarifications (no pun intended) Paul.  On the open issues, 
perhaps an issue list and a tracker might get discussions going.

regards,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Sep 2005 15:57:38 +0300

> be covered as recommendations in the IKEv2 clarification document.

I think most of the implementors do not really care about the minimal
requirements of the IKEv2 draft, as they need to implement more
anyways. And if they are working on the VERY limited environment, they
are going to cut corners anyways, and they KNOW their implementation
is not doing even the minimal required things, but that does not
matter as it is supported to be limited use implementation.
-- 
[email-masked]