Subject: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 16 Dec 2008 16:19:49 -0800

Hi Tero,

Changing the object since I want to discuss the proposal you had.

On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen <[email-masked]> wrote:

> Note,
> that server can reject the IPsec SA creation by returning suitable
> error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and
> then the full exchange would be:
>
>
>   Initiator                         Responder
>   -------------------------------------------------------------------
>   HDR, SAi1, KEi, Ni,
>        N(REDIRECT_SUPPORTED)  -->
>
>
>                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]
>
>
>   HDR, SK {IDi, [CERT,] [CERTREQ,]
>        [IDr,] AUTH, SAi2,
>        TSi, TSr}  -->
>
>
>                                <--  HDR, SK {IDr, [CERT,] AUTH,
>                                          N(NO_ADDITIONAL_SAS)}
>                                <--  HDR, SK {N(REDIRECT)}
>
>
>   HDR, SK {N(REDIRECT_ACK)} -->
>   HDR, SAi1, KEi, Ni,
>        N(REDIRECT_FROM)  -->
>
> I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after
> that send N(REDIRECT) notify as separate INFORMATINAL exchange. The
> initiator would first get the IKE_AUTH reply, process that, and
> immediately after that get INFORMATINAL exhange asking to N(REDIRECT).

RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to
reject an CREATE_CHILD_SA request. Its not clear to me if it can be
used to reject an IKE_AUTH request.

        NO_ADDITIONAL_SAS                        35

        This error indicates 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.

Yaron and I had a discussion on this offline. We can either explicitly
allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in
IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH
request. Neither is ideal of course. Another option is to just allow
the IKE_AUTH exchange to complete as normal and then re-direct the
client.

Vijay
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Dec 2008 09:42:11 +0200

> the IKE_AUTH exchange to complete as normal and then re-direct the

or we could use TS_UNACCEPTABLE, because every TS is unacceptable if  
you need to redirect (although any sane client would delete the IKE SA  
if it proposed a universal selector and the gateway refused.

or we could define a new error type REDIRECT_COMING to fail the child  
SA   :-)

or we could just allow the REDIRECT in IKE_AUTH

I don't like the idea of letting the exchange complete, because that  
will lead the client to send IPsec traffic, which we (for some reason)  
are not willing to process.

But if we're set on not allowing REDIRECT in IKE_AUTH, I would go with  
NO_ADDITIONAL_SAS.

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Dec 2008 14:38:18 +0200

> the IKE_AUTH exchange to complete as normal and then re-direct the

I have always interpreted that the "CREATE_CHILD_SA request" in the
text also includes the imbedded CHILD_SA creation happening during the
IKE_AUTH.

I for example do assume that you can send SINGLE_PAIR_REQUIRED error
message to even to the first child SA created during IKE_AUTH, even
when its description says exactly same "This error indicateds that a
CREATE_CHILD_SA request is ...".

As that SINGLE_PAIR_REQUIRED error is most likely coming back to the
autostart type of rules which are created when IKE SA is created, I
think the most common case for that error message is actually in the
IKE_AUTH...

We could fix this by simply removing the "CREATE_CHILD_SA" text from
SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS errors.

That same text is also in the REKEY_SA, but as there cannot be any
rekeyed SAs during IKE_AUTH, that is correct there.

NO_PROPOSAL_CHOSEN error is also quite ok, altough NO_ADDITIONAL_SAS
would give better feedback to the other end what is going on (and it
would also indicate that there is no point of retrying of creating the
IPsec SA, as it will fail also).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 18 Dec 2008 17:01:35 -0800

Tero, Yoav,

I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH
response followed by the re-direct message.

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.

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Thu, 18 Dec 2008 18:29:57 -0800

Hi all,

Whether to send N(Redirect) during the IKE_AUTH or after the IKE_AUTH,
essentially we want to achieve two things:
1) an indication from the server to the client that the normal IKE procedure
cannot continue (i.e. not allow the client to do what it intended to
accomplish before.)
2) an indication from the server to the client that redirection needs to be
performed

If including N(Redirect) during the IKE_AUTH, it indicates both 1) and 2)
in one message. This seems to me it is a clearer solution, because
we do not have to update RFC 4306 or change some exisitng implementations
if they interpret the NO_ADDITIONAL_SAS as rejection of a CREATE_CHILD_SA
request only.

Furthermore, based on my understanding, the NO_ADDITIONAL_SAS does not
allow additional Child_SA to be created, but it is not a rejection of IKE_AUTH.
Therefore, as soon as the client processes the IKE_AUTH reply with the
NO_ADDITIONAL_SAS,
it considers the IKE_AUTH procedure is completed, even though it cannot
create a child SA, it can send any informational message under this IKE SA
until it receives the N(Redirect). When the server receives such informational
messages from the client, it is not clear to me whether the server will have to
respond to such requests from the client even though it knows that the
N(Redirect)
is already sent (the chances are that N(Redirect) may be lost or
delayed). When the
client receives the N(Redirect) while it has some pending requests, it is not
clearer to me whether the client will have to wait for the responses from the
server or immediately start the redirect procedure.

Any clarification would be appreciated.

Sincerely,
fan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Dec 2008 12:03:26 +0200

> if they interpret the NO_ADDITIONAL_SAS as rejection of a CREATE_CHILD_SA

Not really true, we still need to define what we do for the Child SA
creation payloads in the IKE_AUTH reply. Obvious solutions are just
leave them out and assume N(REDIRECT) is interpreted as non fatal
error (just like NO_ADDITIONAL_SAS or NO_PROPOSAL_CHOSEN) which will
create the IKE SA but not create Child SA, or we can also add the
NO_ADDITIONAL_SAS or NO_PROPOSAL_CHOSEN error messages to indicate
that we are not going to create Child SA.

All this really depends whether REDIRECT is allocated from error types
or from status types notify messages.

Note, that in all cases I do assume we need to delete the IKE_SA
created by IKE_SA_INIT and IKE_AUTH with deparate explicit
INFORMATIONAL message having empty delete payload inside. This should
be done by the client when it is see the redirect and the message
request containg delete payload will be acknowledged by the server
with empty reply. 

> until it receives the N(Redirect).

I do not think this will be changing regardless what we do. The
IKE_AUTH will create the IKE_SA, thus IKE_SA will be up and running
after the IKE_AUTH regardless whether the IKE_AUTH contained
NO_ADDITIONAL_SAS or REDIRECT notify. Client can still send messages
to it if it wants, but in most cases there is nothing that would be
useful for him to send except delete notification when it decideds to
delete the IKE SA as it is redirecting itself to some new server.

> When the server receives such informational
> delayed).

Yes, server must respond to them in both cases. The IKE_SA stays valid
until the delete has been sent to it, thus the normal IKEv2 SA rules
must be followed for the SA all the time.

> When the client receives the N(Redirect) while it has some pending
> requests, it is not clearer to me whether the client will have to
> wait for the responses from the server or immediately start the
> redirect procedure.

It can immediately start the redirect procedure, as that is separate
IKE SA, and it is not tied to the original IKE SA created with the
other server. This means those two IKE SA will be run in parallel way.
I.e. it can immediately start creating new IKE SA with new server,
then reply ACK to the REDIRECT, and then after small timeout send
delete notifications for the old IKE SA to delete it.

Hmmm... actually this opens the question why do we send REDIRECT_ACK
back at all, as empty reply would be sufficient, or is the intention
that if client does NOT send REDIRECT_ACK but sends empty reply then
server must assume that client rejected moving to new server, and is
staying on the old server. I will take this as separate email, and
explain it better... 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Dec 2008 12:23:45 +0200

> response followed by the re-direct message.

Good.

> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 21 Dec 2008 13:58:35 +0200

Hi Vijay, Tero,

First a minor technical point that's alluded to in Tero's discussion: the
IANA considerations should say explicitly that the Notification type is
taken from the Status space. You don't want to deduce it from the number
range.

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. 

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
> 
> Scanned by Check Point Total Security Gateway.

---

From: [email-masked]
Date: Mon, 22 Dec 2008 17:11:07 +0900

>    SA from being set up include at least the following:

I was wondering what the "at least" here means.  Does that mean I can
include other values in specific implementation on a whim?

					FUKUMOTO Atsushi
					[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Dec 2008 10:25:40 +0200

> 					[email-masked]

"at least" here is in the sense of "including, but not limited to". If  
we forgot some error notification (such as NO_ADDITIONAL_SAS) it does  
not mean that the IKE SA is failed.

Any error notification that relates to the child SA or to the  
configuration payload does not automatically fail the IKE SA.

Certainly the initiator may decide that an IKE SA needs to be closed  
following a NO_ADDITIONAL_SAS or a FAILED_CP_REQUIRED, but in that  
case, the initiator needs to send a DELETE in a separate  
INFORMATIONAL, otherwise the IKE SA is still valid.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Dec 2008 14:48:41 +0200

> include other values in specific implementation on a whim?

Yes and no...

I think the list tries to include error messages defined in the IKEv2
document which could be used to indicate error in Child SA, but other
documents might define new errors and some of those might also be such
errors which only affect the Child SA creation, and those should not
cause the IKE SA creation to fail.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Dec 2008 15:22:51 +0200

> arrive. If the Redirect never arrives, we just have a useless timeout. 

My proposal does not want client to guess what gateway wanted, it
wants client to wait for gateway to tell him what to do.

Lets take another example which is not at all related to the redirect
draft but where NO_ADDITIONAL_SAS could be useful.

We have SGW which has limited number of hardware Child SA contexts,
but the actual IKE SA processing is done on the software so it can
still allow IKE SA exchanges even when it is out of the Child SA
contexts. Now when the SGW runs out of Child SA contexts there are few
things it can do to new clients trying to connect:

1) It can drop all new IKE_SA_INIT requests, which for client looks
   like the server has crashed/dropped out from the net. The client
   will try for few minutes retrying the IKE_SA_INIT messages, and
   then fail the exchange, and then most likely the next triggering
   packet will restart the process, i.e. client starts to create new
   IKE_SA and starts sending IKE_SA_INIT requests again. This means
   client is constantly sending requests to server, and server will
   drop them. Client also most likely will do new Diffie-Hellman for
   every single connection retry, unless it is smart enough to reuse
   the Diffie-Hellman from the previous try.

2) Server will reply to the IKE_SA_INIT, but will return
   AUTHENTICATION_FAILURE or other similar fatal IKE_SA error to the
   client. Client will delete the IKE SA when getting that fatal
   error, and then next trigering packet will again start the process
   again. In this case both client and server will do Diffie-Hellman
   for each retry, and client will also do the authentication
   calculations (signature etc).

3) Server will reply to the IKE_SA_INIT and IKE_AUTH, but instead of
   creating child sa (which it cannot as it is out of hardware
   contexts), it returns some other non-fatal error than
   NO_ADDITIONAL_SAS. The client will fail the Child SA creation, but
   again most likely the next triggering packet will cause client to
   retrigger the creation of Child SA, so it will try it again, and it
   will again be failed. This might also result the user seeing
   misleading error messages like NO_PROPOSAL_CHOSEN or
   TS_UNACCEPTABLE even when there is nothing wrong with the client's
   policy. If the client is really smart it can mark the SPD entry
   which triggered the negotiation as broken, and will not trigger
   again for that for some time, but other SPD entries will still
   cause more triggers.

4) Server will reply to the IKE_SA_INIT, and IKE_AUTH, but return
   NO_ADDITIONAL_SAS to the client for the Child SA creation. Now the
   client will know that there is nothing wrong with his policy, and
   there is no point of retrying any Child SA creations, as the server
   does not allow new Child SAs to be created now. Client will wait
   until server indicates the situation has been corrected. Server can
   indicate this situation in two ways, either it can delete the IKE
   SA, which will cause the client to retry the IKE SA creation again
   when next triggering packet comes, or it can simply remember what
   kind of IPsec SA client was trying to create and do create child SA
   himself when he has enough resources for it (this option would save
   the extra Diffie-Hellman calculations and authentication calculates
   related to the IKE SA creation, but requires more code from the
   client and server end, thus might not work with all clients). 

I.e the NO_ADDITIONAL_SAS during IKE_AUTH will cause client to mark
the IKE SA to be up and working, but mark it also so that any child SA
creation will not get triggered for that specific IKE SA. I.e. it will
put the client on hold, waiting for server to tell when to go ahead
again. 

> Redirect notify in IKE_AUTH, so that the client knows for sure what type of

I still do not want to add that REDIRECT notify to the most
complicated state machine state we have. Also adding REDIRECT there
would mean that REDIRECT is both status and error type of notify
message. I.e. it is status type sent during INFORMATIONAL exchange,
but when sent during IKE_AUTH it is also error type as it causes the
Child SA creation to fail. That makes the REDIRECT notify bit
confusing. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Wed, 24 Dec 2008 13:27:30 +0900

> not mean that the IKE SA is failed.

I was under impression that IKE SA implicitly dies upon receiving
error notify payload unless it is about child SA.  Do you mean that an
initiator conformant to ikev2bis should never assume a specific error
notify is about child SA or IKE SA, and SHOULD be capable of handling
either way?

					FUKUMOTO Atsushi

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Dec 2008 11:14:43 +0200

> notify is about child SA or IKE SA, and SHOULD be capable of handling

I don't mean that. Errors that relate to the IKE SA delete the IKE SA.  
Errors that relate to CP or Child SA do not delete the IKE SA. "at  
least" only says that the list that follows it may not be  
comprehensive - indeed we forgot the NO_ADDITIONAL_SAS