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
> > t
nen
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 DISCUSS
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 addit
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.
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
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 b
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
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 Hoffm
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 I
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 p
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 gene
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 notification
cott 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 c
Welter/Raleigh/i...@ibmus
Date: 09/04/2009 03:25 PM
Subject: Re: [IPsec] Issue #26: Missing
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 cau
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
>
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 unacceptabl
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 crypto
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_
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
i
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
resp
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 t
>>> 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
>>
>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_
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
>i
>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
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 w
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_AU
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 INFO
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
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
32 matches
Mail list logo
