Subject: [IPsec] Final comments for ikev2-redirect-10

From: <[email-masked]>
Date: Tue, 26 May 2009 10:17:09 +0200

<wearing AD hat>

FYI: Tim will be the responsible AD for this draft (since I was listed
as a co-author in an earlier version); he will hopefully do his AD
evaluation soon (and might consider these as IETF Last Call comments).

<not wearing any hats>

There's one remaining issue that was changed due to WGLC comments, but
the result isn't quite what it IMHO should be.

When doing redirection during IKE_AUTH, in some situations the
IKE_AUTH response with the REDIRECT is the last message between the
client and gateway (and the IKE_SA is not used, and cannot be used,
for any other exchanges after that). In other situations, it *is*
used for (at least) one additional exchange (Informational exchange
with DELETE payload).

When the Informational exchange is needed/allowed and when not is
not totally random, but I don't expect that any readers would
understand it (I do know Tero can explain it :-). It also creates room 
for confusion whether the REDIRECT is just a "hint" and the IKE_SA 
could still be used for other exchanges, too.

I would suggest we get rid of this unnecessary complexity, and simply
say that when you do REDIRECT during IKE_AUTH, no more exchanges are
done (on that IKE_SA) after the REDIRECT is sent.

There's also one place that is probably correct, but would 
benefit from some clarification. Section 5 says: 

   "When the client receives this message, it MUST send an empty
   message as an acknowledgement.  Until the client responds with an
   acknowledgement, the gateway SHOULD re-transmit the redirect
   INFORMATIONAL message as described in [2]."

The MUST and SHOULD here give the impression that this Informational
exchange is somehow special, and treated differently from ordinary
Informational exchanges. As far as I can tell, it's *not* meant to be
special, and this text isn't meant to specify any new requirements.
I'd suggest rephrasing this something like

  "As in any other INFORMATIONAL exchange, the clients sends a
  response (usually empty), and the gateway retransmits the request if
  it doesn't receive a response."

BTW, in Section 10, "expert review" probably should be "Expert Review
as specified in [RFC5226]".

Best regards,
Pasi

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 May 2009 14:51:36 -0700

Hi Pasi,

> done (on that IKE_SA) after the REDIRECT is sent.

In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is not
valid is when EAP is used and the redirect is done based on the
unauthenticated ID. In all other cases, the IKEv2 SA is valid and should
be torn down with an INFORMATIONAL exchange.

IMHO, this is clear enough and is captured in the current draft.

> as specified in [RFC5226]".

Made these two changes, Thanks.

Vijay

---

From: <[email-masked]>
Date: Thu, 28 May 2009 19:38:08 +0200

Vijay Devarapalli wrote:

> In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is
> not valid is when EAP is used and the redirect is done based on the
> unauthenticated ID. In all other cases, the IKEv2 SA is valid and
> should be torn down with an INFORMATIONAL exchange.
> 

Well.. I'm a bit skeptical about it being clear to folks who didn't
participate in writing this draft. And having these two cases is more
complex than having just one (IKE_SA is not used for any more
exchanges). What benefits does this additional complexity (both 
in spec and in implementation) get us?

If nothing, let's just remove it....

Best regards,
Pasi

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 29 May 2009 14:46:26 -0700

Hi Pasi,

On 5/28/09 10:38 AM, "[email-masked]" wrote:

> participate in writing this draft.

I would be worried if that is the case. But, IMO, the draft currently
clearly describes when the IKEv2 SA is valid and when it needs to be
explicitly deleted.

> And having these two cases is more

When the AUTH payloads are exchanged and verified, the IKEv2 SA is valid.
This seems straightforward. We are not doing anything out of the ordinary
here by not invalidating the IKEv2 SA just because the gateway sent the
REDIRECT payload to the client.

I can imagine extensions tomorrow that would let the client convey
additional information using the IKEv2 SA to the gateway, after the gateway
had sent a REDIRECT payload to the client.

Vijay