Scott C Moonen writes:
tNOTE 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
Kivinen kivi...@iki.fi
To:
Scott C Moonen/Raleigh/i...@ibmus
Cc:
Paul Hoffman paul.hoff...@vpnc.org, ipsec@ietf.org WG
ipsec@ietf.org, ipsec-boun...@ietf.org, Yoav Nir y...@checkpoint.com
Date:
09/22/2009 05:06 AM
Subject:
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes
Paul Hoffman writes:
section anchor='sect-2.21' title='Error Handling'
tIf 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
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:
tNOTE 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
Here is the edited text. Please make sure it still is correct.
section anchor='sect-2.21' title='Error Handling'
tThere 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
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
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
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
, Keith Welter/Raleigh/i...@ibmus
Date: 09/04/2009 03:25 PM
Subject:Re: [IPsec] Issue #26: Missing treatment
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
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
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
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
