[IPsec] Issue #26: Missing treatment of error cases
Tero:
[2.21:]
> 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 test 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 with which
> it has an IKE_SA MAY send an IKE Notify payload in an IKE
> INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} 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.
We should also extend this section and include at least following
cases:
- Errors happening before authentication
- Errors in the IPsec SA creation on IKE_AUTH
- Describe which errors are so fatal that they cause the whole IKE
SA to destroyed.
Paul indicated he's not convinced any of these new cases are needed.
Proposed new text would be welcome.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #26: Missing treatment of error cases
Hello all.
Issue #26 was submitted by Tero Kivinen. It concerns section 2.21
("error handling") and states that several things are missing:
- handling of errors before authentication
- listing what error conditions cause the IKE SA to be deleted entirely
- listing how errors are handled in the piggybacked exchanges.
Following is our suggested new text. Please let us know what you
think. Also, please take a look at the description of
"AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH
message" means either an IKE_AUTH response to an IKE_AUTH request, or
an INFORMATIONAL request that describes an error in the IKE_AUTH
response. Do you think this phrasing is clear enough?
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 a response, then the initiator
SHOULD initiate an INFORMATIONAL exchange with a Notify payload
describing the problem. 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 MAY 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,
unrecognized ID, untrusted certificate issuer, revoked or expired
certificate, etc.) MUST result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the
notification MUST be returned in the protected response, and MUST be
the only payload in that response. If the error occurs on the
initiator, the notification MUST be returned in a separate
INFORMATIONAL exchange, with no other payloads. Note, however, that
messages that contain an unsupported critical payload, or that are
otherwise malformed, MUST be rejected in their entirety, and only
lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX
Notification. The receiver MUST NOT verify the payloads related to
authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established, provided that there are no unsupported critical
payloads. Establishing the child SA, or requesting configuration
information may still fail, but they do not automatically cause the
IKE SA to be deleted. Specifically, a responder
[IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > Following is our suggested new text. Please let us know what you > think. Also, please take a look at the description of > "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH > message" means either an IKE_AUTH response to an IKE_AUTH request, or > an INFORMATIONAL request that describes an error in the IKE_AUTH > response. Do you think this phrasing is clear enough? Yes, altought I think most of the implementations do not bother sending INFORMATIONAL requests when IKE_AUTH response has errors. I think most implementations will then simply remove the IKE SA as failed without any further communications to the other end (I do not know any implementation sending that kind of INFORMATIONAL requests, but I expect that almost all implementations will act correctly if someone happen to send them (i.e. they will delete the IKE SA as failed and send empty reply back)). > All errors that occur in an IKE_AUTH exchange, causing the > authentication to fail for whatever reason (invalid shared secret, > unrecognized ID, untrusted certificate issuer, revoked or expired > certificate, etc.) MUST result in an AUTHENTICATION_FAILED > notification. This MUST there is too strong, especially for the "unrecognized ID" part. For example our implementation send AUTHENTICATION_FAILED return only if processing of AUTH Payload faiiled (i.e. signature check failed (for RSA/DSA), mac failed for shared keys authentication, or no valid public key / shared key found for the ID). In cases where the other end is unknown (i.e. ID is not configured to the policy) it will return NO_PROPOSAL_CHOSEN as it does not find valid policy to accept the other ends proposal when looking it based on the ID. So at least remove the "unrecognized ID" from the list, as it does not belong there, and change the "MUST" to "SHOULD" as specifying exactly one error code in such situations will make lots of implementations non-conforming. I know that people writing conformance tests are going to test this kind of things, and I have already several times explained them that the exact error codes returned by different implementations can differ depending what checks they do and in which order. > If the error occurred on the responder, the > notification MUST be returned in the protected response, and MUST be > the only payload in that response. Again the two MUSTs there will make some implementations non-conforming. We had discussion about this earlier, and in general it is good idea to send them encrypted and MACed, but as that was not required before this is real protocol change. For such I think it requires more explantion. Also I want to have warning here saying that even if it is encrypted and MACed, that does not mean it is authentic from the real recipient. It is coming from the recipient you talked to, but if there is man-in-the-middle he can also generate such messages, meaning the initiator should still continue trying with this peer (he can immediately delete the current IKE SA exchange, as it cannot succeed after this, but next try might get to the real end node instead of man-in-the-middle and succeed). > If the error occurs on the > initiator, the notification MUST be returned in a separate > INFORMATIONAL exchange, with no other payloads. This MUST there is way too strong, as there is no implementations I know that implements that. For example our implementation simply consides the IKE SA failed in such case and removes the IKE SA, and then when next triggering packet comes it will try again. I would say "MAY" would be correct in this case. > Note, however, that > messages that contain an unsupported critical payload, or that are > otherwise malformed, MUST be rejected in their entirety, and only > lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX > Notification. The receiver MUST NOT verify the payloads related to > authentication in this case. This "MUST NOT" is again too strong, as in some implementations they might process payloads in order and depending how deep in which place, they might for example process AUTH payload before noticing that the SA payload of the IPsec SA is malformed in its transform substructure. This "MOST NOT" would make such implementations non-conforming, meaning every single implementation must do full parsing of the payloads first and only after that do second phase when it processes the payloads. > If authentication has succeeded in the IKE_AUTH exchange, the IKE SA > is established, provided that there are no unsupported critical > payloads. The "provide that there are no unsupported critical payloads" is not really needed, as the first part asked to check those first, thus authentication cannot succeed (it is not even tried) if there is unsupported critical payload. Even if we allow parsing AUTH payloads before checking all critical bits, then I do not think that text is needed, i
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote: > Yoav Nir writes: >> Following is our suggested new text. Please let us know what you >> think. Also, please take a look at the description of >> "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH >> message" means either an IKE_AUTH response to an IKE_AUTH request, or >> an INFORMATIONAL request that describes an error in the IKE_AUTH >> response. Do you think this phrasing is clear enough? > > Yes, altought I think most of the implementations do not bother > sending INFORMATIONAL requests when IKE_AUTH response has errors. I > think most implementations will then simply remove the IKE SA as > failed without any further communications to the other end But wouldn't this cause a state de-synchronization? If the responder sends a revoked certificate, the initiator will have no IKE SA, but the responder would have an IKE SA, which it thinks is valid. Wouldn't this necessarily later lead to requests that time out? > (I do not > know any implementation sending that kind of INFORMATIONAL requests, > but I expect that almost all implementations will act correctly if > someone happen to send them (i.e. they will delete the IKE SA as > failed and send empty reply back)). > >>All errors that occur in an IKE_AUTH exchange, causing the >>authentication to fail for whatever reason (invalid shared secret, >>unrecognized ID, untrusted certificate issuer, revoked or expired >>certificate, etc.) MUST result in an AUTHENTICATION_FAILED >>notification. > > This MUST there is too strong, especially for the "unrecognized ID" > part. For example our implementation send AUTHENTICATION_FAILED return > only if processing of AUTH Payload faiiled (i.e. signature check > failed (for RSA/DSA), mac failed for shared keys authentication, or no > valid public key / shared key found for the ID). > > In cases where the other end is unknown (i.e. ID is not configured to > the policy) it will return NO_PROPOSAL_CHOSEN as it does not find > valid policy to accept the other ends proposal when looking it based > on the ID. That allows for ID enumeration. It's similar to a password entry form, that says "wrong user" or "wrong password". An attacker would be able to verify whether a particular ID (say, user name) exists on a system. > So at least remove the "unrecognized ID" from the list, as it does not > belong there, and change the "MUST" to "SHOULD" as specifying exactly > one error code in such situations will make lots of implementations > non-conforming. I know that people writing conformance tests are going > to test this kind of things, and I have already several times > explained them that the exact error codes returned by different > implementations can differ depending what checks they do and in which > order. > >> If the error occurred on the responder, the >>notification MUST be returned in the protected response, and >> MUST be >>the only payload in that response. > > Again the two MUSTs there will make some implementations > non-conforming. We had discussion about this earlier, and in general > it is good idea to send them encrypted and MACed, but as that was not > required before this is real protocol change. For such I think it > requires more explantion. Also I want to have warning here saying that > even if it is encrypted and MACed, that does not mean it is authentic > from the real recipient. It is coming from the recipient you talked > to, but if there is man-in-the-middle he can also generate such > messages, meaning the initiator should still continue trying with this > peer (he can immediately delete the current IKE SA exchange, as it > cannot succeed after this, but next try might get to the real end node > instead of man-in-the-middle and succeed). Agree. Will fix tomorrow or Thursday. >> If the error occurs on the >>initiator, the notification MUST be returned in a separate >>INFORMATIONAL exchange, with no other payloads. > > This MUST there is way too strong, as there is no implementations I > know that implements that. For example our implementation simply > considers the IKE SA failed in such case and removes the IKE SA, and > then when next triggering packet comes it will try again. > > I would say "MAY" would be correct in this case. OK. >> Note, however, that >>messages that contain an unsupported critical payload, or that are >>otherwise malformed, MUST be rejected in their entirety, and only >>lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX >>Notification. The receiver MUST NOT verify the payloads related >> to >>authentication in this case. > > This "MUST NOT" is again too strong, as in some implementations they > might process payloads in order and depending how deep in which place, > they might for example process AUTH payload before noticing that the > SA payload of the IPsec SA is malformed in its transform substructure. > > This "MOST NOT" would
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > > Yes, altought I think most of the implementations do not bother > > sending INFORMATIONAL requests when IKE_AUTH response has errors. I > > think most implementations will then simply remove the IKE SA as > > failed without any further communications to the other end > > But wouldn't this cause a state de-synchronization? Yes, but not in normal case. > If the responder > sends a revoked certificate, the initiator will have no IKE SA, but > the responder would have an IKE SA, which it thinks is valid. Wouldn't > this necessarily later lead to requests that time out? Then the responder is already going against the RFC4306 which says "Certificate revocation checking must be considered during the chaining process used to select a certificate. " meaning the responder cannot send certifiate which itself considers revoced. Only case when this can happen is when responder thinks he has valid certificate but initiator then checks it against certificate authority's system (for example OCSP) and finds out it is not valid anymore. This is not common case, thus it can lead to timeouts. > > In cases where the other end is unknown (i.e. ID is not configured to > > the policy) it will return NO_PROPOSAL_CHOSEN as it does not find > > valid policy to accept the other ends proposal when looking it based > > on the ID. > > That allows for ID enumeration. It's similar to a password entry form, > that says "wrong user" or "wrong password". An attacker would be able > to verify whether a particular ID (say, user name) exists on a system. If the other ends source IP-address is not configured to system (and no wildcard entry found) then it will always return NO_PROPOSAL_CHOSEN regardless of the ID or AUTH payloads. Anyways active attacker can always find out the used IDs anyways. Also from timing it is easy to see whether other end actually did only database lookup for the ID, or whether he actually verified the RSA signature. If you consider ID enumeration a problem that needs to be added to the Security Considerations section (regardless whether we return AUTHENTICATION_FAILED or NO_PROPOSAL_CHOSEN in this case). > > This "MOST NOT" would make such implementations non-conforming, > > meaning every single implementation must do full parsing of the > > payloads first and only after that do second phase when it processes > > the payloads. > > How about if we limit this to packets that are malformed in their > entirety, rather than some particular payload (and packets that have > unrecognized critical payloads) ? If you say MUST in any of these error cases you need to be very specific which cases are covered, most likely giving similar pseudo code saying you first check this, and if it fails, return this error code, then you check this and so on... Similar than RFC2408 Section 5 did, but even then you most likely get implementations which do things differently because they just happen to use some external library or other thing that does parts of the checks in different order than what is listed in the RFC. I have been explaining this to several customers when they have run some external tester which required specific error code to be reported in specific case, and we returned some other error code because we checked things in different order. Thats why it is bad idea to specify MUSTs (or even SHOULDs) when taking which error to return. It is ok to say this check MUST be done (especially if it is security related), but there is no point of listing the order or specific error codes in all possible places. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
>If the error occurs on the >initiator, the notification MUST be returned in a separate >INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: "with no other payloads except an optional empty delete payload". Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. On Sep 3, 2009, at 11:52 PM, Keith Welter wrote: >If the error occurs on the >initiator, the notification MUST be returned in a separate >INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: "with no other payloads except an optional empty delete payload". Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
>Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. >others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Dave Wierbowski___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
>>> 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) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote: >Yes, I will soften the language a bit, but I won't mention a DELETE payload. >If some implementations do it. >others may come to expect it. We don't want to encourage that by suggesting >that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Because the IKE SA was not really created, so there is no IKE SA to delete. It's a bad idea because it is superfluous, and we don't want to risk anyone relying on this. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
OK. Let's try this again. Is this acceptable? 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 a response, then the initiator SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. 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 should be 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 need
Re: [IPsec] Issue #26: Missing treatment of error cases
Keith Welter writes: > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted > either. 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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 7, 2009, at 3:48 PM, Tero Kivinen wrote: > Keith Welter writes: >> I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted >> either. > > 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. I wish that were true, but here's what the draft says about INVALID_SYNTAX INVALID_SYNTAX7 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > OK. Let's try this again. Is this acceptable? > > 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 a response, then the initiator > SHOULD initiate an INFORMATIONAL exchange with a Notify payload > describing the problem. I think MAY is better than SHOULD there, or even forbidding this completely. As said before I do not know any implementation which does this now, and there is also problem that there is no way to correlate the INFORMATIONAL exchange to the exchange which caused this problem. I.e. if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges going, and then you get response to second of them that is invalid and you send INFORMATIONAL exchange out saying there was something wrong with the response, then there is no way for the other end to know to which of those exchanges that INFORMATIONAL related. Also I do not know any normal cases where it would be useful to send error message to the response. In some cases it may possible that initiator will process the response packet, and notice there is something wrong and do actions. One of the cases is for example when initiator asked for transport mode, but responder selected tunnel mode and initiator's policy does not allow tunnel mode. In this example the current RFC4306 text already says initiator deletes the SA. Can you give me any example when it would be possible to use this feature? Note, that this is new requirement that was not in the RFC4306. Note, that this also goes against the rule that no response never generates new requests (it is not explictly mentioned in the IKEv2, but is still there). This means that if either end has bug that cases for example the response packet of the INFORMATIONAL exchange causes other end to send error notification to the other end (using same broken INFORMATIONAL exchange) then the peers will go to INFORMATIONAL exchange loop. Because of the looping problem, and the problem there is no way to relate new INFORMATIONAL exchange request to the response which triggered it, I would actually suggest we forbid this situation and say that errors in response must be handled otherwise (most likely by deleting the IPsec SA or IKE SA or simply ignoring the error case (if it does not affect the state of the SAs)). > 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 should be > the > only payload in that response. When we discussed about the ticket #9 Pasi proposed a text that explains this case better, i.e. specifying that the "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." http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html This was supposed to be added to section 1.2, but it is not there. Perhaps we should add it here instead of 1.2 then (or at least add it to 1.2 if not here). > If the error occurs on the > initiator, > the notification MAY be returned in a separate INFORMATIONAL > exchange, usually with no other payloads. Here creating new INFORMATIONAL exchanges based on the errors in response may be allowed as there is no problems with correlating the message (no other exchanges is allowed before IKE_AUTH finishes), and there should not problems with loops, as the error notification was related to the IKE_AUTH not generic stuff. Also if there was problem when processing IKE_AUTH response, I would indicate that then the IKE_AUTH didn't finishs, thus we do not have IKE SA. If the problem was only in the Chid / IPsec SA part of the exchange then that can be fixed by deleting the IPsec SA. > 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
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 7, 2009, at 4:41 PM, Tero Kivinen wrote: > Yoav Nir writes: >> OK. Let's try this again. Is this acceptable? >> >> 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 a response, then the initiator >>SHOULD initiate an INFORMATIONAL exchange with a Notify payload >>describing the problem. > > I think MAY is better than SHOULD there, or even forbidding this > completely. > > As said before I do not know any implementation which does this now, > and there is also problem that there is no way to correlate the > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > going, and then you get response to second of them that is invalid and > you send INFORMATIONAL exchange out saying there was something wrong > with the response, then there is no way for the other end to know to > which of those exchanges that INFORMATIONAL related. > Agreed. How about SHOULD, but adding "if the error occurred in the response to an IKE_AUTH exchange, and in payloads related to authentication. A new exchange SHOULD NOT be triggered for reporting errors in child SAs, CFG, or notifications." >>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 should be >> the >>only payload in that response. > > When we discussed about the ticket #9 Pasi proposed a text that > explains this case better, i.e. specifying that the "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." > > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html > > This was supposed to be added to section 1.2, but it is not there. > Perhaps we should add it here instead of 1.2 then (or at least add it > to 1.2 if not here). > >> If the error occurs on the >> initiator, >>the notification MAY be returned in a separate INFORMATIONAL >>exchange, usually with no other payloads. > > Here creating new INFORMATIONAL exchanges based on the errors in > response may be allowed as there is no problems with correlating the > message (no other exchanges is allowed before IKE_AUTH finishes), and > there should not problems with loops, as the error notification was > related to the IKE_AUTH not generic stuff. > > Also if there was problem when processing IKE_AUTH response, I would > indicate that then the IKE_AUTH didn't finishs, thus we do not have > IKE SA. If the problem was only in the Chid / IPsec SA part of the > exchange then that can be fixed by deleting the IPsec SA. > >> 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 exchnage
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > I wish that were true, but here's what the draft says about > INVALID_SYNTAX > > INVALID_SYNTAX7 > 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. 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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > > I think MAY is better than SHOULD there, or even forbidding this > > completely. > > > > As said before I do not know any implementation which does this now, > > and there is also problem that there is no way to correlate the > > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > > going, and then you get response to second of them that is invalid and > > you send INFORMATIONAL exchange out saying there was something wrong > > with the response, then there is no way for the other end to know to > > which of those exchanges that INFORMATIONAL related. > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > response to an IKE_AUTH exchange, and in payloads related to > authentication. A new exchange SHOULD NOT be triggered for reporting > errors in child SAs, CFG, or notifications." If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. > I think that any of these would be fatal to the particular exchange, > but will not cause a silent discard of the IKE SA. You might have a > policy that tells you to delete any IKE SA where you got or sent an > INVALID_SYNTAX, but because it can also be a policy matter, we > shouldn't really mandate it. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you get INVALID_SYNTAX errors, then DELETE notification will mostly generate same response) when it receives INVALID_SYNTAX or after it has sent out INVALID_SYNTAX as it assumes there is something badly wrong with either implementation and there is no point of continuing at that situation. I do not have any plans of changing that, and I think other implementations do something similar (i.e if you start sending them properly encrypted and authenticated random garbage they will tear down the IKE SA). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav, You are sending an informational notification, so how could you say the SA does not exist and no delete should be sent? If an authentication error is discovered when processing the IKE_AUTH response then responder thinks an IKE SA exists and the initiator intends to delete that SA. In this case it seems clean for the initiator to send an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the SA as being deleted. I do not see the harm in including a DELETE in this case and it seems to be a more appropriate action than sending the AUTHENTICATION_FAILED. I'm fine with not requiring the DELETE, but I don't think including the DELETE is bad and should be discouraged. I think it reinforces the initiator's intentions and is unambiguous. Dave Wierbowski From: Yoav Nir To: David Wierbowski/Endicott/i...@ibmus Cc: "ipsec@ietf.org" , Keith Welter/Raleigh/i...@ibmus Date: 09/04/2009 03:25 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Sent by:ipsec-boun...@ietf.org On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote: >Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. >others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Because the IKE SA was not really created, so there is no IKE SA to delete. It's a bad idea because it is superfluous, and we don't want to risk anyone relying on this.___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec <><>___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Tero, > > Agreed. How about SHOULD, but adding "if the error occurred in the > > response to an IKE_AUTH exchange, and in payloads related to > > authentication. A new exchange SHOULD NOT be triggered for reporting > > errors in child SAs, CFG, or notifications." > > If that error occurred during IKE_AUTH because of authentication > failure or INVALID_SYNTAX or similar then there is no way to start new > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. We've already bent this rule a little bit if the responder detects an authentication failure. I.e., we've documented that the responder should encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his perspective he doesn't have a valid IKE SA. It seems reasonable to do something similar in this case. I.e., if the initiator detects an authentication failure (say, the responder's certificate has expired), it is reasonable for him to 1) send a protected INFORMATIONAL request over the unauthenticated SA with the error notify, and 2) disallow any other possible activity on that invalid SA except for retransmitting the request and waiting on the response. In our own case, if this happens as initiator, we will do this, sending a protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) and also a DELETE for the IKE SA. In my view the DELETE is actually the more crucial payload here, and the Notify payload is primarily a courtesy to hint to the responder why the delete is being sent (since there is really no way to assert that a Notify in an INFORMATIONAL request relates to some other particular exchange). Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yoav Nir Cc: "ipsec@ietf.org WG" Date: 09/07/2009 12:18 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Yoav Nir writes: > > I think MAY is better than SHOULD there, or even forbidding this > > completely. > > > > As said before I do not know any implementation which does this now, > > and there is also problem that there is no way to correlate the > > INFORMATIONAL exchange to the exchange which caused this problem. I.e. > > if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges > > going, and then you get response to second of them that is invalid and > > you send INFORMATIONAL exchange out saying there was something wrong > > with the response, then there is no way for the other end to know to > > which of those exchanges that INFORMATIONAL related. > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > response to an IKE_AUTH exchange, and in payloads related to > authentication. A new exchange SHOULD NOT be triggered for reporting > errors in child SAs, CFG, or notifications." If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. > I think that any of these would be fatal to the particular exchange, > but will not cause a silent discard of the IKE SA. You might have a > policy that tells you to delete any IKE SA where you got or sent an > INVALID_SYNTAX, but because it can also be a policy matter, we > shouldn't really mandate it. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you g
Re: [IPsec] Issue #26: Missing treatment of error cases
David Wierbowski writes: > You are sending an informational notification, so how could you say the SA > does not exist and no delete should be sent? The IKE SA is NOT up and valid in the initiator. It is halfway up as the other end has not been authenticated, and that IKE SA cannot be used in general. > If an authentication error is discovered when processing the IKE_AUTH > response then responder thinks an IKE SA exists and the initiator intends > to delete that SA. In this case it seems clean for the initiator to send > an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the > SA as being deleted. I do not see the harm in including a DELETE in this > case and it seems to be a more appropriate action than sending the > AUTHENTICATION_FAILED. > > I'm fine with not requiring the DELETE, but I don't think including the > DELETE is bad and should be discouraged. I think it reinforces the > initiator's intentions and is unambiguous. 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. Sending only N(AUTHENTICATION_FAILED) would be bit ambiquous, and I would not recommend that, but as initiator still do not have IKE SA up but has only halfway up SA, for initiator it does not matter what other end does for the INFORMATIONAL exchange anyways... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: > Tero, > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > > > response to an IKE_AUTH exchange, and in payloads related to > > > authentication. A new exchange SHOULD NOT be triggered for reporting > > > errors in child SAs, CFG, or notifications." > > > > If that error occurred during IKE_AUTH because of authentication > > failure or INVALID_SYNTAX or similar then there is no way to start new > > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. > > We've already bent this rule a little bit if the responder detects an > authentication failure. I.e., we've documented that the responder should > encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his > perspective he doesn't have a valid IKE SA. True, but that does not mean the IKE SA is valid, it just means they do have shared unauthenticated keys for encryption and MAC. I.e that encrypt & MAC proves that the reply comes back from the same server who did Diffie-Hellman, but it does not mean it came back from the correct intended responder. The reply could be generated also by man in the middle. > It seems reasonable to do something similar in this case. I.e., if the > initiator detects an authentication failure (say, the responder's > certificate has expired), it is reasonable for him to 1) send a protected > INFORMATIONAL request over the unauthenticated SA with the error notify, > and 2) disallow any other possible activity on that invalid SA except for > retransmitting the request and waiting on the response. That adds quite of lot of special code (i.e you need to make sure that IKE SA is not used for anything else while you are waiting for reply), and does not really help that much. This will cause server to clean up the IKE SA faster than it normally would, but as client initiated this there is most likely no data coming from the server to client anyways thus no traffic is really lost. The client will still fail the IKE SA and as client was the one who initiated it, it will most likely try again and the user noticing things does not work tries to fix things. This kind of authentication failures usually do not go away without user intervention anyways. >From the responders point of view the IKE SA is there, so he does not care which way the initiator does, so this is not something that needs to be defined at all (i.e. there is no need to define whether it is allowed, recommended or forbidden). Whether implementation does this can be completely left to as local matter. > In our own case, if this happens as initiator, we will do this, sending a > protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) > and also a DELETE for the IKE SA. In my view the DELETE is actually the > more crucial payload here, and the Notify payload is primarily a courtesy > to hint to the responder why the delete is being sent (since there is > really no way to assert that a Notify in an INFORMATIONAL request relates > to some other particular exchange). You are free to do that. It will gain you so that server will delete the IKE SA bit earlier than it would otherwise (i.e. otherwise it would need to wait for the DPD to kick in (which would most likely happen quite soon, as there is completely idle IKE and IPsec SA there) and that would then delete the IKE SA). For the original users point of view (i.e. the initiator / client) this does not matter, as he still cannot get connection... I myself as implementor writing code do not want to add such code to our product as it is just adding code that is very seldomly run and even less seldomly tested, and which can contain security bugs, thus the product is safer and better without such code. But this is just my own opinion, and other implementors might have different opinions, and I am ok with text which says you MAY do it. I would object against SHOULD, and object very strongly against MUST. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
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 fail
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: > 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: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension d
Re: [IPsec] Issue #26: Missing treatment of error cases
At 3:51 PM +0300 9/16/09, Tero Kivinen wrote: >For example the text could look something like this: >-- Yoav, does Tero's proposed new text work for you? --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 17, 2009, at 7:03 PM, Paul Hoffman wrote: > At 3:51 PM +0300 9/16/09, Tero Kivinen wrote: >> For example the text could look something like this: >> -- > > Yoav, does Tero's proposed new text work for you? > > --Paul Hoffman, Director > --VPN Consortium 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Here is the edited text. Please make sure it still is correct. 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. 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). 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. 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. 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. 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. 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 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. 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. 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. 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? After the IKE SA is authenticated all requests having errors MUST result in response notifying about the error. 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 sen
Re: [IPsec] Issue #26: Missing treatment of error cases
Paul Hoffman writes: > > > If there is an error parsing or processing a response packet, the > general rule is to not send bac any error message because responses ^^^ s/bac/back/ > 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). > 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. I think the last sentence is bit hard to parse. > 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? 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." -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Thanks for the two editorial notes; fixed. We want more input on the following: At 3:28 PM +0300 9/21/09, Tero Kivinen wrote: > > 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? > >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." --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
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". > 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? 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 (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Tero Kivinen , Yoav Nir Cc: "ipsec@ietf.org WG" Date: 09/19/2009 06:49 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Here is the edited text. Please make sure it still is correct. 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. 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). 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. 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. 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. 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. 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 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. 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 a
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: > > 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? > > 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. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED24 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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
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. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/i...@ibmus Cc: Paul Hoffman , "ipsec@ietf.org WG" , ipsec-boun...@ietf.org, Yoav Nir Date: 09/22/2009 05:06 AM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Scott C Moonen writes: > > 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? > > 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. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED24 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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: > 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. 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). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
