Subject: Re: [IPsec] Issue #26: Missing treatment of error cases

From: Keith Welter <[email-masked]>
Date: Fri, 4 Sep 2009 09:04:46 -0700

>>> In an IKE_AUTH
>>>    exchange, or in the subsequent INFORMATIONAL exchnage, only the
>>>    following notifications cause the IKE SA to be deleted or not
>>>    created, without a DELETE payload:
>>>    o  UNSUPPORTED_CRITICAL_PAYLOAD
>>>    o  INVALID_SYNTAX
>>>    o  AUTHENTICATION_FAILED
>>>
>>>    Extension documents may define new error notifications with these
>>>    semantics, but MUST NOT use them unless the peer is known to
>>>    understand them.
>>
>> In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD
>> should not be fatal. It only means that the responder ignored the
>> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does
>> not delete IKE SA.
>>
>> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
>> SA as IKE SA is not yet ready.
>
>That's what I meant. I will clarify this.
I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted 
either.

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Sep 2009 15:48:30 +0300

> I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted 

I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be
deleted immediately after sending that response containing
INVALID_SYNTAX and if I receive INVALID_SYNTAX notification I will
immediately silently delete the IKE SA.

INVALID_SYNTAX can only happen in if there bugs in implementations.
There is no way it could happen during normal operation, and it is
also error which does NOT go way. I.e. if other end has bug that it
sends payload whose for example payload length exceeds the packet
length, that error will not go away even if we ignore the exchange.

Usually receiving INVALID_SYNTAX means there is something seriously
wrong in the either implementation, and there is no point of trying to
continue connection with it, as future attemtps to communicate will
most likely result in same error (or at least cause peers to get out
of sync (for example if delete payload had incorrect length and was
ignored, then peers do not agree on which SAs are up after that)).

As this is only error code that can be fixed by the programmers
fixing bugs in implementations, there is no point of writing code to
cope with such cases. If such code is written it is most likely be
completely untested, thus it most likely have even more bugs (in worst
case it can have security bugs), thus it is better to take the simple
and easy solution instead, and simply delete the IKE SA immediately.

As this cannot ever happen with conforming implementations there is no
need for conforming implementations to agree on what they do on this
error... If this error is ever seen that means either implementation
is not conforming the specification.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Sep 2009 16:38:30 +0300

> length, that error will not go away even if we ignore the exchange.
<snip/>

I wish that were true, but here's what the draft says about  
INVALID_SYNTAX

    INVALID_SYNTAX                            7
        Indicates the IKE message that was received was invalid because
        some type, length, or value was out of range or because the
        request was rejected for policy reasons. To avoid a denial of
        service attack using forged messages, this status may only be
        returned for and in an encrypted packet if the message ID and
        cryptographic checksum were valid.

This "or because the request was rejected for policy reasons means  
that even perfectly good implementations might get an INVALID_SYNTAX.   
I don't know why this is so, but that's the way it is in RFC 4306 as  
well.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Sep 2009 18:56:47 +0300

> I don't know why this is so, but that's the way it is in RFC 4306 as  

I do not think it should be sent because of policy reasons, as we do
have specific errors (authentication failed, no proposal chosen and ts
unacceptable etc).

I have not seen anybody sending this because of policy reasons, only
case where I have seen this was in interops when someone send some
broken packets to other end.

I think we should remove the "for policy reasons" part and specify
that this is only used in protocol error situations. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Sep 2009 22:02:06 +0300

OK. One more try:

2.21.  Error Handling

    There are many kinds of errors that can occur during IKE processing.
    If a request is received that is badly formatted, or unacceptable  
for
    reasons of policy (e.g., no matching cryptographic algorithms), the
    response MUST contain a Notify payload indicating the error.  If an
    error occurs in the processing of an IKE_AUTH response, and leads to
    an authentication failure, then the initiator MAY initiate an
    INFORMATIONAL exchange with a Notify payload describing the problem.
    For other invalid responses, it is not a good idea to initiate an
    exchange for carrying a Notify payload, but the node should take  
care
    to clean up the state (for example, by sending DELETEs for bad SAs).

    If an error occurs outside the context of an IKE request (e.g., the
    node is getting ESP messages on a nonexistent SPI), the node SHOULD
    initiate an INFORMATIONAL exchange with a Notify payload describing
    the problem.

    Errors that occur before a cryptographically protected IKE SA is
    established must be handled very carefully.  There is a trade-off
    between wanting to be helpful in diagnosing a problem and responding
    to it and wanting to avoid being a dupe in a denial of service  
attack
    based on forged messages.

    If a node receives a message on UDP port 500 or 4500 outside the
    context of an IKE SA known to it (and not a request to start one),  
it
    may be the result of a recent crash of the node.  If the message is
    marked as a response, the node MAY audit the suspicious event but
    MUST NOT respond.  If the message is marked as a request, the node
    MAY audit the suspicious event and MAY send a response.  If a
    response is sent, the response MUST be sent to the IP address and
    port from whence it came with the same IKE SPIs and the Message ID
    copied.  The response MUST NOT be cryptographically protected and
    MUST contain a Notify payload indicating INVALID_IKE_SPI.  The
    INVALID_IKE_SPI notification indicates an IKE message was received
    with an unrecognized destination SPI; this usually indicates that  
the
    recipient has rebooted and forgotten the existence of an IKE SA.

    A node receiving such an unprotected Notify payload MUST NOT respond
    and MUST NOT change the state of any existing SAs.  The message  
might
    be a forgery or might be a response, the genuine correspondent was
    tricked into sending.  A node should treat such a message (and  
also a
    network message like ICMP destination unreachable) as a hint that
    there might be problems with SAs to that IP address and should
    initiate a liveness check for any such IKE SA.  An implementation
    SHOULD limit the frequency of such tests to avoid being tricked into
    participating in a denial of service attack.

    A node receiving a suspicious message from an IP address (and port,
    if NAT traversal is used) with which it has an IKE SA SHOULD send an
    IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
    The recipient MUST NOT change the state of any SAs as a result, but
    may wish to audit the event to aid in diagnosing malfunctions.  A
    node MUST limit the rate at which it will send messages in response
    to unprotected messages.

    All errors that occur in an IKE_AUTH exchange, causing the
    authentication to fail for whatever reason (invalid shared secret,
    invalid ID, untrusted certificate issuer, revoked or expired
    certificate, etc.)  SHOULD result in an AUTHENTICATION_FAILED
    notification.  If the error occurred on the responder, the
    notification is returned in the protected response, and is usually
    the only payload in that response.  If the error occurs on the
    initiator, the notification MAY be returned in a separate
    INFORMATIONAL exchange, usually with no other payloads.  Note,
    however, that messages that contain an unsupported critical payload,
    or where the whole message is malformed (rather than just bad  
payload
    contents), MUST be rejected in their entirety, and only lead to an
    UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification.  The
    receiver should not verify the payloads related to authentication in
    this case.

    If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
    is established, but establishing the child SA, or requesting
    configuration information may still fail.  This failure does not
    automatically cause the IKE SA to be deleted.  Specifically, a
    responder may include all the payloads associated with  
authentication
    (IDr, Cert and AUTH) while sending error notifications for the
    piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
    NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the
    authentication because of this.  The initiator MAY, of course, for
    reasons of policy later delete such an IKE SA.

    Only authentication failures and malformed messages lead to a
    deletion of the IKE SA without requiring an explicit INFORMATIONAL
    exchange carrying a DELETE payload.  Other error conditions require
    such an exchange, if policy dictates that this is needed.

    In an IKE_SA_INIT exchange, any error notification causes the
    exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or
    INVALID_MAJOR_VERSION may lead to a subsequent successful exchange.
    In an IKE_AUTH exchange, or in the INFORMATIONAL exchange  
immediately
    following it, only the following notifications cause the IKE SA to  
be
    deleted or not created, without a DELETE payload:

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Sep 2009 22:03:28 +0300

OK. One more try:

2.21.  Error Handling

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Sep 2009 15:51:25 +0300

> OK. One more try:

I think this is still bit confusing. How about splitting it to few
subsections, i.e.

2.21. Error Handling
2.21.1 Error Handling in IKE_SA_INIT
2.21.2 Error Handling in IKE_AUTH
2.21.3 Error Handling after IKE SA is Authenticated
2.21.4 Error Handling Outside IKE SA

or something.

Now you need to be very careful when reading the text to understand
when it is taking about IKE_AUTH or some other exchange and whether it
is talking about errors in request and replies.

For example the text could look something like this:
----------------------------------------------------------------------
2.21. Error Handling

    There are many kinds of errors that can occur during IKE
    processing. The general rule is that if a request is received that
    is badly formatted, or unacceptable for reasons of policy (e.g.,
    no matching cryptographic algorithms), the response contains a
    Notify payload indicating the error. Whether to send such response
    depends whether the there is authenticated IKE SA or not.

    If there is an error parsing or processing response packet, then
    generic rule is not to send any error back, as responses should
    not generate new requests (which would be the only way to send
    error message back). Such errors in parsing or processing response
    packets should still take care to clean up the state (for example,
    by sending DELETEs for bad SAs). 

    Only authentication failures (AUTHENTICATION_FAILED) and malformed
    messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
    requiring an explicit INFORMATIONAL exchange carrying a DELETE
    payload. Other error conditions require such an exchange, if
    policy dictates that this is needed.

2.21.1 Error Handling in IKE_SA_INIT

    Errors that occur before a cryptographically protected IKE SA is
    established must be handled very carefully. There is a trade-off
    between wanting to be helpful in diagnosing a problem and
    responding to it and wanting to avoid being a dupe in a denial of
    service attack based on forged messages.

    In an IKE_SA_INIT exchange, any error notification causes the
    exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD
    or INVALID_MAJOR_VERSION may lead to a subsequent successful
    exchange. Note, as all error notifications are completely
    unauthenticated, the recipient should not immediately act based on
    them (unless corrective actions are known like COOKIE,
    INVALID_KE_PAYLOAD etc), but continue trying for some time before
    giving up.

2.21.2 Error Handling in IKE_AUTH

    All errors that occur in an IKE_AUTH exchange, causing the
    authentication to fail for whatever reason (invalid shared secret,
    invalid ID, untrusted certificate issuer, revoked or expired
    certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
    notification. If the error occurred on the responder, the
    notification is returned in the protected response, and is usually
    the only payload in that response. Note, that although the
    IKE_AUTH messages are encrypted and integrity protected, if the
    peer receiving this notification has not authenticated the other
    end yet, the information needs to be treated with caution.

    If the error occurs on the initiator, the notification MAY be
    returned in a separate INFORMATIONAL exchange, usually with no
    other payloads. This is exception for the general rule of not
    starting new exchanges based on errors in responses.

    Note, however, that request messages that contain an unsupported
    critical payload, or where the whole message is malformed (rather
    than just bad payload contents), MUST be rejected in their
    entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
    INVALID_SYNTAX Notification sent as response. The receiver should
    not verify the payloads related to authentication in this case.

    If authentication has succeeded in the IKE_AUTH exchange, the IKE
    SA is established, but establishing the child SA, or requesting
    configuration information may still fail. This failure does not
    automatically cause the IKE SA to be deleted. Specifically, a
    responder may include all the payloads associated with
    authentication (IDr, Cert and AUTH) while sending error
    notifications for the piggybacked exchanges (FAILED_CP_REQUIRED,
    INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator
    MUST NOT fail the authentication because of this. The initiator
    MAY, of course, for reasons of policy later delete such an IKE SA.

    In an IKE_AUTH exchange, or in the INFORMATIONAL exchange
    immediately following it (in case error happened in when
    processing response to IKE_AUTH), only the following notifications
    cause the IKE SA to be deleted or not created, without a DELETE
    payload:

2.21.3 Error Handling after IKE SA is Authenticated

    After the IKE SA is authenticated all requests having errors MUST
    result in response notifying about the error.

    In normal situation there should not be cases where valid response
    from other end results in error situation in the initiator, so
    there should not be any reason for initiator to send error
    messages to the other end. Because sending such error messages as
    INFORMATIONAL exchange might lead to further errors causing loops
    such errors SHOULD NOT be sent. If such errors are seen that might
    mean that the peers do not have same state, thus it might be good
    to delete the IKE SA to clean up state and start over from the
    beginning.

    Similarly if the responder parsing the request notices it is badly
    formatted (after it has passed the message authentication code
    checks and window checks) and it sends INVALID_SYNTAX notification
    back, then this error notification is considered fatal in both
    ends meaning that IKE SA is deleted without explicit delete
    payload. 

2.21.4 Error Handling Outside IKE SA

    A node MUST limit the rate at which it will send messages in
    response to unprotected messages.

    If a node receives a message on UDP port 500 or 4500 outside the
    context of an IKE SA known to it (and not a request to start one),
    it may be the result of a recent crash of the node. If the message
    is marked as a response, the node MAY audit the suspicious event
    but MUST NOT respond. If the message is marked as a request, the
    node MAY audit the suspicious event and MAY send a response. If a
    response is sent, the response MUST be sent to the IP address and
    port from whence it came with the same IKE SPIs and the Message ID
    copied. The response MUST NOT be cryptographically protected and
    MUST contain a Notify payload indicating INVALID_IKE_SPI. The
    INVALID_IKE_SPI notification indicates an IKE message was received
    with an unrecognized destination SPI; this usually indicates that
    the recipient has rebooted and forgotten the existence of an IKE
    SA.

    A node receiving such an unprotected Notify payload MUST NOT
    respond and MUST NOT change the state of any existing SAs. The
    message might be a forgery or might be a response, the genuine
    correspondent was tricked into sending. A node should treat such a
    message (and also a network message like ICMP destination
    unreachable) as a hint that there might be problems with SAs to
    that IP address and should initiate a liveness check for any such
    IKE SA. An implementation SHOULD limit the frequency of such tests
    to avoid being tricked into participating in a denial of service
    attack.

    If an error occurs outside the context of an IKE request (e.g.,
    the node is getting ESP messages on a nonexistent SPI), the node
    SHOULD initiate an INFORMATIONAL exchange with a Notify payload
    describing the problem. 
 
    may wish to audit the event to aid in diagnosing malfunctions.  
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Sep 2009 09:03:08 -0700

>For example the text could look something like this:

Yoav, does Tero's proposed new text work for you?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Sep 2009 00:48:08 +0300

> Yoav, does Tero's proposed new text work for you?

It works for me. However, Keith Welter has a couple of issues with it:

The part about errors in IKE_AUTH exchanges (now 2.21.2) has several  
times the phrase "usually with no other payloads" or "and is usually  
the only payload in that response". To me this just means that we're  
not forbidding putting other payloads in the message, but we don't see  
why one would need it. Keith finds it unduly mysterious, and would  
like to mention the possibility of adding a DELETE payload when the  
error is sent in a separate INFORMATIONAL. I don't like the idea of  
having an optional payload with no added semantics, but I do think  
that any implementation should be able to handle this extra payload.

Also, the phrase "or the INFORMATIONAL exchange immediately following  
it" (same section) should be clarified to state that it's an  
INFORMATIONAL exchange initiated by the original initiator to send an  
error message about the IKE_AUTH exchange.

Other than that, yes, I think you can copy & paste it into the bis.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Sep 2009 15:37:33 -0700

Here is the edited text. Please make sure it still is correct.

<section anchor='sect-2.21' title='Error Handling'>

<t>There are many kinds of errors that can occur during IKE
processing. The general rule is that if a request is received that is
badly formatted, or unacceptable for reasons of policy (such as no
matching cryptographic algorithms), the response contains a Notify
payload indicating the error. The decision whether or not to send
such a response depends whether or not there is an authenticated IKE
SA.</t>

<t>If there is an error parsing or processing a response packet, the
general rule is to not send bac any error message because responses
should not generate new requests (and a new request would be the only
way to send back an error message). Such errors in parsing or
processing response packets should still cause the recipient to clean
up the IKE state (for example, by sending a DELETE for a bad SA).</t>

<t>Only authentication failures (AUTHENTICATION_FAILED) and malformed
messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
requiring an explicit INFORMATIONAL exchange carrying a DELETE
payload. Other error conditions MAY require such an exchange if
policy dictates that this is needed.</t>

<section anchor='sect-2.21.1' title='Error Handling in IKE_SA_INIT'>

<t>Errors that occur before a cryptographically protected IKE SA is
established need to be handled very carefully. There is a trade-off
between wanting to help the peer to diagnose a problem and thust
responding to the error, and wanting to avoid being part a denial of
service attack based on forged messages.</t>

<t>In an IKE_SA_INIT exchange, any error notification causes the
exchange to fail. Note that some error notifications such as COOKIE,
INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
successful exchange. Because all error notifications are completely
unauthenticated, the recipient should continue trying for some time
before giving up but not immediately act based on the error
notification unless corrective actions are defined in this
specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
INVALID_MAJOR_VERSION.</t>

</section>

<section anchor='sect-2.21.2' title='Error Handling in IKE_AUTH'>

<t>All errors that occur in an IKE_AUTH exchange, causing the
authentication to fail for whatever reason (invalid shared secret,
invalid ID, untrusted certificate issuer, revoked or expired
certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the
notification is returned in the protected response, and is usually
the only payload in that response. Although the IKE_AUTH messages are
encrypted and integrity protected, if the peer receiving this
notification has not authenticated the other end yet, that peer needs
to treat the information with caution.</t>

<t>If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually with no other
payloads. This is exception for the general rule of not starting new
exchanges based on errors in responses.</t>

<t>Note, however, that request messages that contain an unsupported
critical payload, or where the whole message is malformed (rather
than just bad payload contents), MUST be rejected in their entirety,
and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
INVALID_SYNTAX Notification sent as response. The receiver should not
verify the payloads related to authentication in this case.</t>

<t>If authentication has succeeded in the IKE_AUTH exchange, the IKE
SA is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
authentication because of this. The initiator MAY, of course, for
reasons of policy later delete such an IKE SA.</t>

<t>In an IKE_AUTH exchange, or in the INFORMATIONAL exchange
immediately following it (in case an error happened in when
processing response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD,
INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only
ones to cause the IKE SA to be deleted or not created, without a
DELETE payload. Extension documents may define new error
notifications with these semantics, but MUST NOT use them unless the
peer has been shown to understand them.</t>

<t>NOTE FOR WG DISCUSSION: Having other payloads in the message is
allowed but there are none suggested. One WG member mentioned the
possibility of adding a DELETE payload when the error is sent in a
separate INFORMATIONAL exchange. Do we want to allow such additional
payloads that have operational semantics?</t>

</section>

<section anchor='sect-2.21.3' title='Error Handling after IKE SA is Authenticated'>

<t>After the IKE SA is authenticated all requests having errors MUST
result in response notifying about the error.</t>

<t>In normal situations, there should not be cases where valid
response from one peer results in an error situation in the other
peer, so there should not be any reason for a peer to send error
messages to the other end except as a response. Because sending such
error messages as INFORMATIONAL exchange might lead to further errors
that could cause loops, such errors SHOULD NOT be sent. If errors are
seen that indicate that the peers do not have same state, it might be
good to delete the IKE SA to clean up state and start over.</t>

<t>If a peer parsing a request notices that it is badly formatted
(after it has passed the message authentication code checks and
window checks) and it returns an INVALID_SYNTAX notification, then
this error notification is considered fatal in both peers, meaning
that the IKE SA is deleted without needing an explicit DELETE
payload.</t>

</section>

<section anchor='sect-2.21.4' title='Error Handling Outside IKE SA'>

<t>A node needs to limit the rate at which it will send messages in
response to unprotected messages.</t>

<t>If a node receives a message on UDP port 500 or 4500 outside the
context of an IKE SA known to it (and the message is not a request to
start an IKE SA), this may be the result of a recent crash of the
node. If the message is marked as a response, the node can audit the
suspicious event but MUST NOT respond. If the message is marked as a
request, the node can audit the suspicious event and MAY send a
response. If a response is sent, the response MUST be sent to the IP
address and port from where it came with the same IKE SPIs and the
Message ID copied. The response MUST NOT be cryptographically
protected and MUST contain an INVALID_IKE_SPI Notify payload. The
INVALID_IKE_SPI notification indicates an IKE message was received
with an unrecognized destination SPI; this usually indicates that the
recipient has rebooted and forgotten the existence of an IKE SA.</t>

<t>A peer receiving such an unprotected Notify payload MUST NOT
respond and MUST NOT change the state of any existing SAs. The
message might be a forgery or might be a response that a genuine
correspondent was tricked into sending. A node should treat such a
message (and also a network message like ICMP destination
unreachable) as a hint that there might be problems with SAs to that
IP address and should initiate a liveness check for any such IKE SA.
An implementation SHOULD limit the frequency of such tests to avoid
being tricked into participating in a denial of service attack.</t>

<t>If an error occurs outside the context of an IKE request (e.g.,
the node is getting ESP messages on a nonexistent SPI), the node
SHOULD initiate an INFORMATIONAL exchange with a Notify payload
describing the problem.</t>

<t>A node receiving a suspicious message from an IP address (and
port, if NAT traversal is used) with which it has an IKE SA SHOULD
send an IKE Notify payload in an IKE INFORMATIONAL exchange over that
SA. The recipient MUST NOT change the state of any SAs as a result,
but may wish to audit the event to aid in diagnosing
malfunctions.</t>

</section>

</section>

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Sep 2009 15:28:13 +0300

> general rule is to not send bac any error message because responses
			      ^^^
s/bac/back/

> INVALID_MAJOR_VERSION.</t>

I think the last sentence is bit hard to parse. 

> payloads that have operational semantics?</t>

As I do not see any other reason to start new informational exchange
when processing IKE_AUTH reply than fatal errors when creating it
(i.e. AUTHENTICATION_FAILED) which already deletes the IKE SA, I do
not see any benefit from adding DELETE notification to the message. It
would be saying the same thing twice: "There was fatal error delete
the sa, and by the way delete the sa."
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Sep 2009 07:19:04 -0700

Thanks for the two editorial notes; fixed.

We want more input on the following:

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 21 Sep 2009 11:10:43 -0400

Paul,

> between wanting to help the peer to diagnose a problem and thust

s/thust/thus/

> wanting to avoid being part a denial of service attack

Suggest either "being part *of* a" or "being a willing participant in a".

> payloads that have operational semantics?</t>

I think you are asking specifically about the IKE_AUTH response?  If so, I 
agree that DELETE does not make sense in the IKE_AUTH response, and 
N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. 
 I think we can forbid DELETE in the IKE_AUTH response.  However, because 
a separate INFORMATIONAL exchange cannot be definitively correlated to the 
IKE_AUTH exchange, I'd like to retain the option of sending both DELETE 
and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <[email-masked]>
To:
Tero Kivinen <[email-masked]>, Yoav Nir <[email-masked]>
Cc:
"[email-masked] WG" <[email-masked]>
Date:
09/19/2009 06:49 PM
Subject:
Re: [IPsec] Issue #26: Missing treatment of error cases

</section>

</section>

<section anchor='sect-2.21.3' title='Error Handling after IKE SA is 
Authenticated'>

</section>

</section>

</section>

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2009 12:00:37 +0300

> and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange.

You cannot really get AUTHENTICATION_FAILED in any other places than
IKE_AUTH, as the text says:

   AUTHENTICATION_FAILED                    24
       Sent in the response to an IKE_AUTH message when for some reason
       the authentication failed. There is no associated data.

Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH.

On the other hand, I think it is clear that unless we explictly forbid
other payloads you are free to add whatever payloads are normally
allowed in INFORMATIONAL exchange anyways (i.e. notice, delete,
vendori ID payloads, or even configuration payloads etc). Most likely
the other end either processes those or ignores them, and if your
error notify is fatal error like INVALID_SYNTAX then it really does
not matter as the IKE SA will be deleted anyways.

The IKEv2 does not really restrict what you can send in INFORMATIONAL
exchange, but there are lots of cases where those simply do not make
any sense. 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 22 Sep 2009 10:58:25 -0400

Tero, I don't understand.  Two weeks ago you said:

> If you use that kind of halfway up IKE SA for sending INFORMATIONAL
> message to other end (who thinks the IKE SA is up and valid), then I
> agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be
> the correct way to do it. DELETE only would also be ok.

Now I think you are suggesting that DELETE is improper in this case, which 
directly contradicts your earlier note.

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
Paul Hoffman <[email-masked]>, "[email-masked] WG" 
<[email-masked]>, [email-masked], Yoav Nir <[email-masked]>
Date:
09/22/2009 05:06 AM
Subject:
Re: [IPsec] Issue #26: Missing treatment of error cases

   AUTHENTICATION_FAILED                    24

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Sep 2009 17:38:01 +0300

> directly contradicts your earlier note.

You can either send N(AUTHENTICATION_FAILED) or you can send DELETE,
sending them both does not really help (if you send both you just say
twice that delete this SA). Or you can simply log the situation to the
local end and ask user to take corrective actions (for example if you
are VPN client software) and assume that next connection with
INITIAL_CONTACT or DPD will take care of the old IKE SA.

The reason sending both of them might make sense is that it should be
complatible with almost any implementation, i.e. those who consider
N(AUTHENTICATION_FAILED) fatal will delete IKE SA because of that and
those who do not, still delete the IKE SA because of the DELETE
payload.

As this is very small corner case which do not affect the
interoperability, and in most situations it does not even have any
perceivable effect on the whole system, I do not really have strong
opinion in either way.

It also depends what kind of other text we have. In my suggested text
it is clear that N(AUTHENTICATION_FAILED) causes IKE SA to be deleted,
so in that case sending delete would be unnecessary (i.e.
N(AUTHENTICATION_FAILED) would be enough). With the RFC4306 text
sending delete might be helpful (but not required).
-- 
[email-masked]