Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 2 Feb 2009 11:05:34 -0800

Hi Yaron,

On Sun, Dec 21, 2008 at 3:58 AM, Yaron Sheffer <[email-masked]> wrote:
> Hi Vijay, Tero,
>
> Now the real issue: I suggest that we reconsider the solution we're
> proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is
> left with an IKE SA which is basically useless. So the client will naturally
> fail the entire connection attempt. With the current proposal we are asking
> the client to *guess* that the gateway wants to redirect it somewhere else,
> and to wait (for an indefinite time) for that redirect notification to
> arrive. If the Redirect never arrives, we just have a useless timeout.

First, the client does not have to wait for an indefinite amount of
time. The gateway sends a REDIRECT message right away. The REDIRECT
message is re-transmitted until an ack is received from the client. So
I don't think the above is an issue.

Back to the basic question. What do we want to achieve when the
gateway decides the re-direct the client in the middle of an IKE_AUTH
exchange? We want to be able to prevent the client from creating an
CHILD_SA that is worthless. We want to be able to prevent the client
from sending any traffic. Both are achieve by sending
NO_ADDITIONAL_SAS in the IKE_AUTH response.

The IKE SA has already been created. There is nothing that needs to be
done about. The subsequent REDIRECT payload from the gateway to the
client would say the IKE SA to be deleted anyway. Therefore I suggest
going with NO_ADDITIONAL_SAS payload during the IKE_AUTH exchange,
followed by the REDIRECT message from the gateway.

Vijay

>
> In other words, I propose to go back to Fan's proposal of an explicit
> Redirect notify in IKE_AUTH, so that the client knows for sure what type of
> failure it is seeing.
>
> Thanks, and Happy Holidays!
>
>        Yaron
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Tero Kivinen
>> Sent: Friday, December 19, 2008 12:24
>> To: Vijay Devarapalli
>> Cc: [email-masked]; Yoav Nir
>> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH
>>
>> Vijay Devarapalli writes:
>> > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH
>> > response followed by the re-direct message.
>>
>> Good.
>>
>> > However, I think we need a clarification in IKEv2bis draft. It would
>> > be very easy for someone to interpret that the NO_ADDITIONAL_SAS
>> > payload can only be used to reject a CREATE_CHILD_SA request and not
>> > the IKE_AUTH request (because thats what the text in RFC 4306 says.)
>> > and implement accordingly.
>>
>> Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS
>> text in the draft to indicate those can be also sent during imbedded
>> Child SA creation hapening in the IKE_AUTH.
>>
>> This would mean that we dofollowing changes:
>> ----------------------------------------------------------------------
>> In section "1.2. The Initial Exchanges" change
>>
>>    {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
>>    fails for some reason, the IKE SA is still created as usual.  The
>>    list of responses in the IKE_AUTH exchange that do not prevent an IKE
>>    SA from being set up include at least the following:
>>    NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
>>    INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
>>
>> to (i.e add NO_ADDITIONAL_SAS to the example list)
>>
>>    {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
>>    fails for some reason, the IKE SA is still created as usual.  The
>>    list of responses in the IKE_AUTH exchange that do not prevent an IKE
>>    SA from being set up include at least the following:
>>    NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
>>    INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS.
>> ----------------------------------------------------------------------
>> In section "1.3. The CREATE_CHILD_SA Exchange" change
>>
>>    {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
>>    to indicate that a CREATE_CHILD_SA request is unacceptable because
>>    the responder is unwilling to accept any more Child SAs on this IKE
>>    SA.  Some minimal implementations may only accept a single Child SA
>>    setup in the context of an initial IKE exchange and reject any
>>    subsequent attempts to add more.
>>
>> to (explained the situation for minimal clients here already described
>> in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH
>> and explained what it means):
>>
>>    {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS
>>    notification to indicate that a child SA creation request is
>>    unacceptable because the responder is unwilling to accept any more
>>    Child SAs on this IKE SA (either because implementation limitations
>>    or because of policy reasons). Some minimal implementations may
>>    only accept a single Child SA setup in the context of an initial
>>    IKE exchange and reject any subsequent attempts to add more. If
>>    this error message is received it means it is not useful to try to
>>    create more Child SAs with this IKE SA, because all of them will
>>    fail with this error. If this error is received during
>>    CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA
>>    and create new IKE SA with new Child SA if it wants to get the new
>>    Child SA created. If this error is received during initial Child SA
>>    creation in IKE_AUTH that means the Child SA creation was rejected
>>    either because of policy reasons or resource constraint reasons,
>>    and there is no point of retrying Child SA creation immediately.
>>    Instead the recipient should wait for suitable timeout (several
>>    minutes) to see if server either deletes the IKE SA or indicates
>>    that situation has changed (for example creates Child SA himself).
>>    After the timeout expires the client should delete the IKE SA and
>>    try again.
>> ----------------------------------------------------------------------
>> In section "2.9.  Traffic Selector Negotiation" change
>>
>>    {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
>>    CREATE_CHILD_SA request is unacceptable because its sender is only
>>    willing to accept traffic selectors specifying a single pair of
>>    addresses.  The requestor is expected to respond by requesting an SA
>>    for only the specific traffic it is trying to forward.
>>
>> to (replace CREATE_CHILD_SA with "Child SA creation"
>>
>>    {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
>>    Child SA creation request is unacceptable because its sender is
>>    only willing to accept traffic selectors specifying a single pair
>>    of addresses. The requestor is expected to respond by requesting an
>>    SA for only the specific traffic it is trying to forward.
>> --
>> [email-masked]
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> Scanned by Check Point Total Security Gateway.
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 2 Feb 2009 23:26:55 +0200

Hi Vijay,

Apologies for repeating myself. At the point when the client receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's going to receive a Redirect "right away". So the reasonable thing for it to do is to tear down the IKE SA immediately - the SA has just become useless.

In other words, we have a race condition between this notification (and the client's response to it) and the Redirect notification. And the simple solution is to send both notifications together.

Thanks,
        Yaron

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Monday, February 02, 2009 21:06
> To: Yaron Sheffer
> Cc: Tero Kivinen; [email-masked]

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Feb 2009 13:32:11 +0200

Yaron Sheffer writes:
> Apologies for repeating myself. At the point when the client
> receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's
> going to receive a Redirect "right away". So the reasonable thing
> for it to do is to tear down the IKE SA immediately - the SA has
> just become useless. 

It should not tear down the IKE SA immediately, it should have short
delay there before doing that.

That kind of delay is also needed in case NO_ADDITIONAL_SAS is used
for other reasons, as if that is not used, then client will busy loop
creating new IKE_SA with IKE_SA_INIT, IKE_AUTH, INFORMATIONAL exchange
deleting the IKE SA, and then starting immediately from the
IKE_SA_INIT.

If there is short timeout (10 seconds or so) between IKE_AUTH and the
INFORMATIONAL exchange containing the delete payload deleting the IKE
SA then this will not be busy loop doing Diffie-Hellman, but slower
rate loop. The short timeout will also give server time to reply.
Note, that server can send reply immediately it does not need to wait
anything, i.e the INFORMATIONAL message telling client to redirect can
be send just immediately after sending IKE_AUTH reply.

Also client MUST still process incoming exchange while it is waiting
for the reply to the its delete, thus it will most likely get the
redirect message during that even if it issued delete immediately.

> In other words, we have a race condition between this notification
> (and the client's response to it) and the Redirect notification. And
> the simple solution is to send both notifications together.

Which means client code needs to understand that redirect notification
can come also during the IKE_AUTH, and depending on the IKE_AUTH use
of EAP, multiple auth etc things that requires modifications to the
existing complicated code.

So while adding support for the redirect in the client, it would be
good also be quite easy thing to ensure it does not delete the IKE SA
immediately, but wait for some time before deleting IKE SA.

I really do not want to make the most complicated exchange (IKE_AUTH)
even more complicated.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 3 Feb 2009 07:57:04 -0800

Hi Yaron,

> Apologies for repeating myself. At the point when the client receives the NO_ADDITIONAL_SAS notify, it doesn't know yet that it's going to receive a Redirect "right away". So the reasonable thing f…

Even if the client decides to tear down the IKE SA, it sends a
INFORMATIONAL message with the DELETE payload to the gateway.

> In other words, we have a race condition between this notification (and the client's response to it) and the Redirect notification. And the simple solution is to send both notifications together.

The REDIRECT from the gateway to the client will come either before or
along with the response to the DELETE payload.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 3 Feb 2009 10:38:07 -0800

Hello,

Here is the proposed text for re-direct during IKE_AUTH exchange.

   If the gateway decides to re-direct the client during the IKE_AUTH
   exchange, it prevents the creation of a CHILD SA by sending the
   NO_ADDITIONAL_SAS Notify Payload in the IKE_AUTH response.  It then
   follows up with an INFORMATIONAL message with the REDIRECT payload
   immediately.  The following shows the message exchange between the
   client and the gateway.

        Initiator                    Responder ( VPN GW)
        ---------                    -------------------

    (IP_I:500 -> IP_R:500)
    HDR(A,0), SAi1, KEi, Ni,   -->
    N(REDIRECTED_SUPPORTED)

                                  (IP_R:500 -> IP_I:500)
                              <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]

    (IP_I:500 -> IP_R:500)
    HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
    [IDr,]AUTH, SAi2, TSi, TSr} -->

                                  (IP_R:500 -> IP_I:500)
                              <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                           N(NO_ADDITIONAL_SAS)}

                              <--  HDR, SK {N[REDIRECT, IP_R/FQDN_R]}

    HDR, SK {}  -->

   When the client receives the IKE_AUTH response with the
   NO_ADDITIONAL_SAS payload from the gateway, it may decide to delete
   the IKEv2 SA.  In case the gateway receives the INFORMATIONAL message
   to delete the IKEv2 SA before sending the REDIRECT message, then the
   gateway includes the REDIRECT payload in the response along with the
   DELETE payload.

Feel free to modify the text. A temporary pre04 version is at
http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2-redirect-04.txt

Vijay