Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document

From: [email-masked]
Date: Fri, 23 Sep 2005 15:23:56 +0300

Tero Kivinen:

> I am using Message ID 0, as it is IKE_SA_INIT. On the other hand I
> am trying to cope with the implementation which is doing something
> differently anyways, so I just try to be cope with it (I do assume
> he did have some reason I do not know, and he returned me SPIr
> because of he needs it).

IMHO you should assume the reason is an implementation bug; if the
other end really needs it (doesn't work just fine if you send 0),
it's not compliant with the IKEv2 spec anyway.

While in general coping the implementation quirks is a good thing, it
can also lead to a situation where implementators learn to expect that
the other end does this, and gradually the "de-facto protocol" drifts
away from what was actually written in the spec.  Here "be liberal in
what you receive but conservative in what you send" principle would
IMHO tell that you don't fail if you receive something else than zero,
but you always send zero.

> > The spec in general seems to follow the principle that it
> > describes how the protocol works, but not how it doesn't. For
> > instance, there's nothing saying that you're not allowed to
> > include N(COOKIE) in the CREATE_CHILD_SA exchange. Nevertheless,
> > I would not consider that to be part of the interoperable
> > behavior defined by the specification.
> 
> N(COOKIE) payloads are allowed in CREATE_CHILD_SA exchanges too. On
> the other hand there is no requirement for the other end to copy them
> back in any places. 

In other words, the specification doesn't say what including N(COOKIE)
in CREATE_CHILD_SA exchange "means". Thus if some party expects it to
mean something, it's not following the IKEv2 base specification (but
this might be specified in some future extension).

> The text which says it must be replied to IKE_SA_INIT if it was
> returned by the responder, do apply for later IKE_SA_INITs too. So I
> would say it is mandatory to include it in all IKE_SA_INIT messages
> if responder gave it to you based on the "This notification MUST be
> included in an IKE_SA_INIT request retry if a COOKIE notification
> was included in the initial response.".

Hmm... maybe it could be interpreted that way too; but then it needs 
to be clarified that COOKIE calculation cannot expect "all other 
payloads unchanged" to apply to all requests that include the COOKIE.

I'll try to write some text for the clarifications draft about
this... (but it seems that in IKEv2, one of the main security 
features is "job security", for those trying to interprete and 
clarify the spec :-)

Cheers,
Pasi

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Sep 2005 16:17:48 +0300

> it's not compliant with the IKEv2 spec anyway.

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.

> but you always send zero.

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 :-)

> this might be specified in some future extension).

Yes. 

> payloads unchanged" to apply to all requests that include the COOKIE.

All other payloads were returned unchanged for the first reply, but
not for the later requests, as he did himself request the initiator to
do some changes. 

> features is "job security", for those trying to interprete and 

Good for us... :-)
-- 
[email-masked]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Sep 2005 09:55:43 -0700 (PDT)

> invalid ke payload, thus he might want to allocate
Is there a valid reason as to why the responder would
allocate state in the invalid KE payload case ? The
responder can do anything :-) But coping for all this
makes it more complicated. 

> will not really matter what initiator does in that
I think the clarification draft should just clarify
that the cookie case and invalid ke payload case
should be treated the same way unless there is a
*real* convincing reason that the responder wants to
allocate state for invalid ke payload.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Sep 2005 20:30:54 +0300

Mohan Parthasarathy writes:
> allocate state in the invalid KE payload case ?

Hmm.. not that I can think of right now. Someone might think something
later, for example allocate some crypto resources for the coming
diffie-hellman calculation or something, but I do not think we need to
think about that now. 

> The responder can do anything :-) But coping for all this makes it
> more complicated.

Actually at least for me the copying comes automatically. Immediately
wen we receive a message having SPIr set we update the current SA to
have that SPIr. Then we continue processing the packet and if we
notice that it was INVALID_KE_PAYLOAD we retry with new group.

In the responder end I do allocate SPIr when I get the packet in, but
then when sending the error message back (COOKIE or
INVALID_KE_PAYLOAD) I clear up the SPIr before sending the error, and
after that I delete the state I created to be able to process the
request.

I could do same thing in the initiator i.e. when I notice that I need
to restart from the beginning, but it requires more stuff there as I
need to downgrade the SA back to the half-open state if it was already
upgraded to have SPIr. Thats why I am not likely going to do it just
to cope with some buggy implementations on the other end, unless those
buggy implementations start to be more common...

> allocate state for invalid ke payload.

I agree. I think the clarification document should say that use SPIr
of zero every time when responding with those notifies.

I think that clarification does not really need to specify what the
other end should do in case the responder does not follow that
recommendation (i.e. I do not think we need to specify how to cope
around bugs in other implementations). 
-- 
[email-masked]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 23 Sep 2005 11:41:48 -0700 (PDT)

> notice that it was INVALID_KE_PAYLOAD we retry with
My implementation assumes that one has to retry if
SPIr is zero and it is IKE_SA_INIT response. I need to
do this check to reset my msgid to zero so that the
next packet goes out with the right msgid.

> after that I delete the state I created to be able
In the responder, i don't allocate SPIr until both
cookie and KE payload checks are successful.

> around bugs in other implementations). 

Agreed.

-mohan