Subject: [IPsec] [IKEv2] Error in Child SA creation

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 22 Apr 2009 16:38:22 +0200

Hello all,

As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester
that there was an error in creating a Child SA using the IKE_AUTH exchange
is:

error in Child SA  <--  IDr, [CERT+],
creation                AUTH,
                           N(error),
                           [V+]

A point came up about this in a previous thread today (IKE_AUTH without TSi,
TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed that
a general agreement was to send an INVALID_SYNTAX message without the IDr
and AUTH payloads. As it was put:

>INVALID_SYNTAX is fatal error meaning that other end didn't follow the
>protocol specification, and the IKE SA is going to be removed anyways,
>and there is not really point of putting AUTH payload there (it can be
> there, but there is no need).

> If the other end is not following protocol specification (i.e. is
> non-complient), there is not really point of trying to be nice. This
> is something that cannot be seen by normal customers ever, it should
> only be seen by the implementors when they are testing against broken
> implementations.

>So better just send error message back as it is easiest for your
> implementation (i.e. if it is easy to include AUTH etc to the error
> message, then do so, if not, then leave them out).

The above seems reasonable to me.

What would be the reasoning for adding IDr, [CERT+], AUTH in this scenario?
Would it be possible/acceptable to some better text covering INVALID_SYNTAX?
Maybe it would specify that when INVALID_SYNTAX would be sent, no other
payloads are needed, and what would happen to the SA. Would the SA be
interrupted (removed from memory instantly without any confirmation by the
party sending the notification), an Informational exchange to delete the SA
be initiated or would the party sending INVALID_SYNTAX allow the other
endpoint to take some action when receiving this error (maybe the initiator
would give up and start an Informational Exchange to delete the SA)?

Regards,
Matt

---

From: "J. Sun" <[email-masked]>
Date: Wed, 22 Apr 2009 13:34:57 -0700

Matt,
  In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr, 
[CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, 
SINGLE_PAIR_REQUIRED,  TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify 
ERROR TYPES that would generally still include the IDr, [CERT+] & AUTH 
payload in the response. 

  In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really 
up to the implementation to decide what to do next in respect to 
receiving a malformed IKE_AUTH Request.  One option is suggested by Tero 
- sending an IKE_AUTH Response with an INVALID_SYNTAX and no other 
payloads.  Another option is to simply drop the malformed IKE_AUTH 
Request and not even send a reply.  The point is, there's not much you 
can really do when a device sends you a malformed request/response 
message - it's not like it's gonna figure out what's wrong and fix it.  
Whichever option that you go with, you'll have to eventually locally 
delete the unauthenticated IKE_SA - I would not continue operating as if 
the IKE_SA is authenticated by initializing a INFORMATIONAL Request with 
Delete Payloads.  RFC 4306 does not define what to do in such cases, and 
essentially leaves it up to implementations to decide on how to handle 
it - in other words, there isn't a specified way to handle every oddball 
case out there.

- Jeff Sun

Matthew Cini Sarreo wrote:
> Hello all,
>
> As IKEv2bis-02 defines in Appendix C, the proper way to notify a 
> requester that there was an error in creating a Child SA using the 
> IKE_AUTH exchange is:
>
> A point came up about this in a previous thread today (IKE_AUTH 
> without TSi, TSr), where an initator would send IKE_AUTH without TSi, 
> TSr. It seemed that a general agreement was to send an INVALID_SYNTAX 
> message without the IDr and AUTH payloads. As it was put:
>
> What would be the reasoning for adding IDr, [CERT+], AUTH in this 
> scenario? Would it be possible/acceptable to some better text covering 
> INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would 
> be sent, no other payloads are needed, and what would happen to the 
> SA. Would the SA be interrupted (removed from memory instantly without 
> any confirmation by the party sending the notification), an 
> Informational exchange to delete the SA be initiated or would the 
> party sending INVALID_SYNTAX allow the other endpoint to take some 
> action when receiving this error (maybe the initiator would give up 
> and start an Informational Exchange to delete the SA)?
>
> Regards,
> Matt
> ------------------------------------------------------------------------
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: raj singh <[email-masked]>
Date: Thu, 23 Apr 2009 08:21:31 +0530

Hi Matt,

I agree with Jeff.
Sending INVALID_SYNTAX notify with no payload and immediately delete IKEv2
SA  will be good idea in case of malformed IKE_AUTH  request.
As SA is still unauthenticated, sending DELETE notify will cause another
problems.

Thanks,
Raj

On Thu, Apr 23, 2009 at 2:04 AM, J. Sun <[email-masked]> wrote:

> [CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED,
>  TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify ERROR TYPES that would
> generally still include the IDr, [CERT+] & AUTH payload in the response.
>  In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really up
> to the implementation to decide what to do next in respect to receiving a
> malformed IKE_AUTH Request.  One option is suggested by Tero - sending an
> IKE_AUTH Response with an INVALID_SYNTAX and no other payloads.  Another
> option is to simply drop the malformed IKE_AUTH Request and not even send a
> reply.  The point is, there's not much you can really do when a device sends
> you a malformed request/response message - it's not like it's gonna figure
> out what's wrong and fix it.  Whichever option that you go with, you'll have
> to eventually locally delete the unauthenticated IKE_SA - I would not
> continue operating as if the IKE_SA is authenticated by initializing a
> INFORMATIONAL Request with Delete Payloads.  RFC 4306 does not define what
> to do in such cases, and essentially leaves it up to implementations to
> decide on how to handle it - in other words, there isn't a specified way to
> handle every oddball case out there.
>
> - Jeff Sun
>
>> A point came up about this in a previous thread today (IKE_AUTH without
>> TSi, TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed
>> that a general agreement was to send an INVALID_SYNTAX message without the
>> IDr and AUTH payloads. As it was put:
>>
>> INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would be
>> sent, no other payloads are needed, and what would happen to the SA. Would
>> the SA be interrupted (removed from memory instantly without any
>> confirmation by the party sending the notification), an Informational
>> exchange to delete the SA be initiated or would the party sending
>> INVALID_SYNTAX allow the other endpoint to take some action when receiving
>> this error (maybe the initiator would give up and start an Informational
>> Exchange to delete the SA)?
>>
>> Regards,
>> Matt