Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document

From: [email-masked]
Date: Fri, 7 Oct 2005 12:49:04 +0300

Tero Kivinen wrote:

> Unfortunately the spec can be interpreted two ways there.
> 
> The text in 3.1 says:
> 
>       o  Responder's SPI (8 octets) - A value chosen by the
>          responder to identify a unique IKE security association. This
>          value MUST be zero in the first message of an IKE Initial
>          Exchange (including repeats of that message including a
>          cookie) and MUST NOT be zero in any other message.
> 
> which says that it MUST be zero for the cookie request. It does not
> clearly say what should be used for the invalid ke payload.
> 
> In the COOKIE notifies there is similar text in 3.10.1:
> 
>         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
> 
> If I have understood correctly, you interpret the text in 3.1 include
> all IKE_SA_INIT packets (not just cookie retry), but you interpreted
> the 3.10.1 you interpreted it to include only the first retry (only
> the cookie retry).
> 
> I think we should interpret both of those texts to include all
> IKE_SA_INIT retries, i.e both COOKIE and INVALID_KE_PAYLOAD retries.
> I.e. SPIr MUST be zero for all of IKE_SA_INIT replies, and COOKIE must
> be included by the initiator to the all the retries of the IKE_SA_INIT
> after it was first returned by the responder to the initiator.

I fully agree with you about the 3.1 part: I think it was intended to 
cover all IKE_SA_INIT retries. I'm a bit ambiguous about the cookie
part, but well, I guess it can be reasonably interpreted that way
as well.

> There might be reason for the responder to allocate state in the
> invalid ke payload, thus he might want to allocate SPIr for that.
> 
> The general text there in 2.6 says:
> 
>    initial two eight octet fields in the header are used as a
>    connection identifier at the beginning of IKE packets. Each
>    endpoint chooses one of the two SPIs and SHOULD choose them so as
>    to be unique identifiers of an IKE_SA. An SPI value of zero is
>    special and indicates that the remote SPI value is not yet known by
>    the sender.
> 
> which would indicate that if the initiator do know the remote SPI
> (SPIr), he should use it. I.e. if the responder have returned SPIr to
> initiator, then initiator cannot claim he do not know it and he wants
> to use zero because of that. That text would indicate that if the
> responder do return SPIr in the COOKIE/INVALID_KE_PAYLOAD (against the
> MUST in the document), then initiator should then use that same value
> when sending next packet.
> 
> But if consider the text in 3.1 to cover all IKE_SA_INIT messages,
> then this MUST NOT happen in any valid implementation of the draft, it
> will not really matter what initiator does in that case :-)

Yes, I think the text in 3.1 is correct here (and 2.6 was intended
more as an overview that didn't yet all include all the special
cases).

How about adding this to section 2.1 of the clarifications text:

   If the responder sends a non-zero responder SPI, the initiator
   should not reject the response just for that reason.  However, when
   retrying the IKE_SA_INIT request, the initiator will use a zero
   responder SPI, as described in Section 3.1: "Responder's SPI [...]
   This value MUST be zero in the first message of an IKE Initial
   Exchange (including repeats of that message including a cookie)
   [...]".  We believe the intent was to cover repeats of that message
   due to other reasons, such as INVALID_KE_PAYLOAD, as well.

And re-writing section 2.4 as follows:

   There are two common reasons why the initiator may have to retry
   the IKE_SA_INIT exchange: the responder requests a cookie or wants
   a different Diffie-Hellman group than was included in the KEi
   payload.  Both of these cases are quite simple alone, but it is not
   totally obvious what happens when they occur at the same time;
   i.e., IKE_SA_INIT exchange is retried several times.

   The main question seems to be the following: if the initiator
   receives a cookie from the responder, should it include the cookie
   in only the next retry of the IKE_SA_INIT request, or in all
   subsequent retries as well? Section 3.10.1 says that:

      "This notification MUST be included in an IKE_SA_INIT request
      retry if a COOKIE notification was included in the initial
      response."

   This could be interpreted as saying that when a cookie is received
   in the initial response, it is included in all retries. On the
   other hand, Section 2.6 says that:
  
      "Initiators who receive such responses MUST retry the
      IKE_SA_INIT with a Notify payload of type COOKIE containing the
      responder supplied cookie data as the first payload and all
      other payloads unchanged."

   Including the same cookie in later retries makes sense only if the
   "all other payloads unchanged" restriction applies only to the
   first retry, but not to subsequent retries.

   It seems that both interpretations can peacefully co-exist. If the
   initiator includes the cookie only in the next retry, one
   additional roundtrip may be needed in some cases:

      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), SAi1, KEi', Ni -->
                              <-- HDR(A,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   An additional roundtrip is needed also if the initiator includes
   the cookie in all retries, but the responder does not support this.
   For instance, if the responder includes the SAi1 and KEi payloads
   in cookie calculation, it will reject the request by sending a new
   cookie (see also Section 2.5 of this document for more text about
   invalid cookies):

      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,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   If both peers support including the cookie in all retries, a
   slightly shorter exchange can happen:

      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
 
   This document recommends that implementations should support this
   shorter exchange, but it must not be assumed the other peer also
   supports this.

   In theory, even this exchange has one unnecessary roundtrip, as
   both the cookie and Diffie-Hellman group could be checked at the
   same time:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE),
                                            N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   However, it is clear that this case is not allowed by the text in
   Section 2.6, since "all other payloads" clearly includes the KEi
   payload as well.

Does this look right to you?

Best regards,
Pasi

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Oct 2005 11:18:03 +0300

>    due to other reasons, such as INVALID_KE_PAYLOAD, as well.

I think that version is also good, as it gives only one option.
Another option would be to say "value MUST be copied to later
retries". That version could allow later some optional statefull error
processing to be done in case if IKE_SA_INIT requests too, but I do
not think we need that.

> And re-writing section 2.4 as follows:
...
> Does this look right to you?

Yes.

Do we already have section saying what to do if N(COOKIE) returned by
the initiator is incorrect? If not we need to add that, saying that if
N(COOKIE) returned is invalid, then N(COOKIE) is simply ignored and
processing continues just like it never was there, meaning that if
cookie is required new cookie is requested, and if no cookie is
required then processing goes forward. 
-- 
[email-masked]