Hi Pasi,

On 5/26/09 1:17 AM, "pasi.ero...@nokia.com" wrote:

> 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.

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.

> 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]".

Made these two changes, Thanks.

Vijay

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to