Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document

From: [email-masked]
Date: Wed, 21 Sep 2005 16:06:54 +0300

Tero Kivinen wrote:

> There are couple of issues noticed here in the ipsec bake-off event
> about the INVALID_KE_PAYLOAD that could use some more clarification
> in clarifications document.
> 
> ----------------------------------------------------------------------
> 2.1  SPI values in IKE_SA_INIT exchange
> ...
>    Since the IKE_SA_INIT request always has a zero responder SPI, the
>    value will not be actually used by the initiator.  Thus, we think
>    sending a zero value is correct also in this case.
> ----------------------------------------------------------------------
> 
> I think another possible interpreation would be that if responder
> allocated responder SPI in those error messages, it actually also
> generated some state, thus the initiator should use that responder
> SPI to help the responder to keep track of that state.
> 
> On the other hand there is no reason to generate state in those
> cases, thus the responder should always send responder SPI as zero.
> 
> So for the responder: Use SPIr as zero unless you allocate state.
> 
> For initiator: copy the SPIr from the previous message (most 
> likely it is zero).

No, I think this advice is incorrect: the initiator must send
SPIr as zero, regardless of what it received from the responder.
This case is always required to work; doing something else just
gets into trouble with the text about Message IDs.

> Another issue is the section 2.4. It is missing the most common 
> case that everybody is using:
> 
>       Initiator                   Responder
>      -----------                 -----------
>       HDR(A,0), SAi1, KEi, Ni -->
>                               <-- HDR(A,0), N(COOKIE)
>       HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
>                               <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
>       HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
>                               <-- HDR(A,B), SAr1, KEr, Nr
> 
> I.e. if you have received a cookie during the exchange, you need 
> to use that in all the future versions of the IKE_SA_INIT
> messages. This will cut out one round trip in the exchange.

Section 2.4 does point out that doing something like this would
cut out one roundtrip, but this is not allowed by the spec (it
says "all other payloads unchanged", which includes KEi).

So doing this is a violation of the spec, and leads to 
interoperability problems if the responder includes KEi when
generating the cookie (which is clearly allowed by the current
spec).

(I fully agree that your proposal makes much more sense, but
it's not what got written in the spec -- and IMHO it's way too
late to make technical changes now.)

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Sep 2005 16:45:20 +0300

> gets into trouble with the text about Message IDs.

Where does it say it is required to work? The normal operation is to
use the SPIr that is set by the responder when he sets it. Where is
the exception to this case. Note, that responder is supposed to be
using SPIr zero, but this is the case where he decided not to use SPIr
zero.

> says "all other payloads unchanged", which includes KEi).

All payloads are unchanged in the first cookie exchange. The KEi was
changed only after the INVALID_KE_PAYLOAD, but the difference was that
we also kept the N(COOKIE) we have received before. As this was not
reply to the N(COOKIE) request in the beginning.

> generating the cookie (which is clearly allowed by the current

It is NOT violation of the spec. Show me the point where it says you
are not allowed to include N(COOKIE) for the 2nd messaga. It does say
that COOKIE MUST be inlucded in the IKE_SA_INIT request retry if one
was received before.
----------------------------------------------------------------------
        COOKIE                                   16390

            This notification MAY be included in an IKE_SA_INIT
            response. It indicates that the request should be retried
            with a copy of this notification as the first payload.
            This notification MUST be included in an IKE_SA_INIT
            request retry if a COOKIE notification was included in the
            initial response. The data associated with this
            notification MUST be between 1 and 64 octets in length
            (inclusive).
----------------------------------------------------------------------

I would actually say not including the cookie in the request retries
(i.e. the reply to the INVALID_KE_PAYLOAD is also retry of the
IKE_SA_INIT request).

Note, also that it is completely valid for the COOKIE to change along
the exchange. That is expected to happen when the secret is changed,
and if KE is included to the COOKIE that will also happen when the KE
payload is changed. That is expected operation. 

> late to make technical changes now.)

I disagree with your interpretation of the spec...

Can you show me the place where it says that you are not allowed to
include N(COOKIE) to the all retries IKE_SA_INIT messages?
-- 
[email-masked]