Subject: [IPsec] Issue #143: Rewrite of 1.5

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jan 2010 18:28:56 -0800

Section 1.5 doesn't read well, and needs a rewrite. Pasi can
 provide text once the substantial issue re: INVALID_IKE_SPI
 is decided.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 12:42:02 +0100

> provide text once the substantial issue re: INVALID_IKE_SPI

That substantial issue is #137; assuming it's resolved the way
Tero proposed (and I agree), I'm proposing the following text:

   There are couple of cases when a node receives a packet it cannot
   process, but may want to notify the sender about this situation:

   o  If an ESP or AH packet arrives with an unrecognized SPI, it
      could be because the receiving node has recently crashed and
      lost state or because of some other system malfunction or
      attack.
 
   o  If an encrypted IKE request packet arrives on port 500 or 4500
      with an unrecognized SPI, it could be because the receiving node
      has recently crashed and lost state or because of some other
      system malfunction or attack.

   o If an IKE request packet arrives with a higher major version
     number than the implementation supports.

   (Note that the first and third cases apply only to IKE request
   packets, not response packets.)

   In the first case, if the receiving node has an active IKE SA to
   the IP address from whence the packet came, it MAY send an
   INVALID_SPI notification of the wayward packet over that IKE SA in
   an INFORMATIONAL exchange. The Notification Data contains the SPI
   of the invalid packet. The recipient of this notification cannot
   tell whether the SPI is for AH or ESP, but this is not important
   because the SPIs are supposed to be different for the two.

   If no suitable IKE SA exists, the node MAY send an INFORMATIONAL
   message without cryptographic protection to the source IP address.
   In this case, it should only be used by the recipient as a "hint"
   that something might be wrong (because it could easily be forged).
   This message is not part of an INFORMATIONAL exchange, and the
   receiving node MUST NOT respond to it (doing so could cause a
   message loop). The message is constructed as follows: There are no
   IKE SPI values that would be meaningful to the recipient of such a
   notification; using zero values or random values are both
   acceptable.  The Initiator flag is set, the Response bit is set to
   0, and the version flags are set in the normal fashion.

   In the second and third cases, the message is always sent without
   cryptographic protection (outside of an IKE SA), and includes
   either INVALID_IKE_SPI or INVALID_MAJOR_VERSION notification (with
   no notification data).  The message is a response message, and thus
   it is sent to the IP address and port from whence it came with the
   same IKE SPIs and the Message ID is copied.  The Response bit is
   set to 1, and the version flags are set in the normal fashion. The
   responder SHOULD copy the Exchange Type from the request.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 14:44:50 +0200

>    packets, not response packets.)

The first case applies to ESP or AH packets, so this text should apply
only to the last two cases.

>    0, and the version flags are set in the normal fashion.

This is against the text in the section 3.1 which says:

   o  Initiator's SPI (8 octets) - A value chosen by the initiator to
      identify a unique IKE security association.  This value MUST NOT
      be zero.

Was that intentional, i.e. can both the Initiator's and responder's
SPIs be zero?

>    responder SHOULD copy the Exchange Type from the request.

Otherwise the text looked good.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 14:00:42 +0100

> only to the last two cases.

Quite right, this should be "second and third".

> Was that intentional, i.e. can both the Initiator's and responder's

I didn't change this part; the text has been there since the first
draft (and is also in RFC 4718, section 7.7). Here's what 4718 said:

   In case of INVALID_SPI, however, there are no IKE SPI values that
   would be meaningful to the recipient of such a notification.  Also,
   the message sent is now an INFORMATIONAL request.  A strict
   interpretation of the specification would require the sender to
   invent garbage values for the SPI fields.  However, we think this
   was not the intention, and using zero values is acceptable.

   (References: "INVALID_IKE_SPI" thread, June 2005.)

Since the value will be anyway meaningless to the recipient, I don't
think it matters what it is; so I would propose we leave this as-is.

> >    In the second and third cases, the message is always sent
> >    without cryptographic protection (outside of an IKE SA), and
> >    includes either INVALID_IKE_SPI or INVALID_MAJOR_VERSION
> >    notification (with no notification data).  The message is a
> >    response message, and thus it is sent to the IP address and
> >    port from whence it came with the same IKE SPIs and the Message
> >    ID is copied.  The Response bit is set to 1, and the version
> >    flags are set in the normal fashion. The responder SHOULD copy
> >    the Exchange Type from the request.
> 

Thanks for checking this!

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 16:07:11 +0200

> think it matters what it is; so I would propose we leave this as-is.

Should we note something that we know this is against MUST in section
3.1, but sending zero initiator SPI is still ok?

The problem I have with this text, is that I know that some day
someone will come to me and ask me to explain why we send zero
initiator SPI when sending these error notifications even when there
is text saying that initiator SPI MUST NOT be zero...

(and yes, I am used to explaining things already saying that "this is
because the document is internally inconsistent" :-)

The text in RFC4718 at least brings this issue out, the text put to
the ikev2bis is silent about the internal inconsistency.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 21:53:56 +0100

> 3.1, but sending zero initiator SPI is still ok?

Yes, we probably should. Proposed rephrasing of that sentence:

   There are no IKE SPI values that would be meaningful to the
   recipient of such a notification; using zero values or random
   values are both acceptable (this is an exception to the usual
   requirement that the initiator's SPI cannot be zero).

> is text saying that initiator SPI MUST NOT be zero...

...or someone will, three years from now, notice this same 
bug again on the mailing list :-)

Best regards,
Pasi