Subject: Re: [IPsec] Closing issue #143 (rewrite of section 1.5)

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Feb 2010 13:00:23 -0800

I took Yoav's proposed replacement for the last three paragraphs of 1.5 and made some editorial changes. This is a big enough change, I want to be sure everyone agrees to the new wording. The section now (in my temporary copy of the draft) reads:

1.5.  Informational Messages outside of an IKE SA

   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.  The receving node MAY send a notification of
   the wayward packet with a Notify payload without cryptographic
   protection to the source IP address.  Such a 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 INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL
   exchange when a node receives an ESP or AH packet with an invalid
   SPI.  The Notification Data contains the SPI of the invalid packet.
   This usually indicates a node has rebooted and forgotten an SA.  If
   this Notify payload is sent outside the context of an IKE SA, it
   should only be used by the recipient as a "hint" that something might
   be wrong (because it could easily be forged).  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.

   There are some cases in which a node receives a packet that it cannot
   process, but it may want to notify the sender about this situation.

   o  If an ESP or AH request or response packet arrives with an
      unrecognized SPI.  This might be due to the receiving node having
      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 IKE SPI.  This might be due to the receiving
      node having 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.

   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, using the source
   UDP port as the destination port if the packet was UDP (IKE or UDP-
   encapsulated ESP or AH).  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 because 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, this being the exception to the rule in
   Section 3.1 that prohibits zero IKE Initiator SPIs.  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
   an INVALID_IKE_SPI or an 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 and Exchange Type are copied from the
   request.  The Response bit is set to 1, and the version flags are set
   in the normal fashion.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 4 Feb 2010 09:48:29 +0300

Paul Hoffman writes:

A few comments.

> I took Yoav's proposed replacement for the last three paragraphs of 1.5 and made some
editorial changes. This is a big enough change, I want to be sure everyone agrees to the
>    is not important because the SPIs are supposed to be different for

These two paragraphs are left from previous version and
should be removed (now all they are talking about is explained
in more details below).

>    o  If an ESP or AH request or response packet arrives with an

There are no "requests" and "responses" in ESP and AH.
Just remove these words.

>    Informational exchange.  The Notification Data contains the SPI of

s/Informational/INFORMATIONAL

>    IKE SA exists, the node MAY send an informational message without

Probably s/informational/Informational ? I'm not sure because the
term "Informational Message" is never formally introduced in the document
apart from this section...

>    easily be forged).  This message is not part of an Informational

s/Informational/INFORMATIONAL

>    follows: There are no IKE SPI values that would be meaningful to the

Shouldn't the first letter in "There" be lower case 't'?

>    set in the normal fashion.

In is not said which Exchange Type should be set in Informational Message
(one may of course guess that it is INFORMATIONAL, but I think it is better
to spell out this explicitly).

>    request.  The Response bit is set to 1, and the version flags are set

Regards,
Valery Smyslov.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Feb 2010 07:19:47 -0800

>should be removed (now all they are talking about is explained

There were bits in those two paragraphs that were still new, but on further looking, I see that those bits appear (sometimes many times) in the rest of the document. I'll remove them.

>There are no "requests" and "responses" in ESP and AH.

Whoops, good call.

>s/Informational/INFORMATIONAL

Also good call. (I hate the way we still use all caps for this for no good reason, and I guess that colors my writing...)

>apart from this section...

Actually, it is introduced in 1.4: "Note that some informational messages, not
exchanges, can be sent outside the context of an IKE SA."

>s/Informational/INFORMATIONAL

Yes

>Shouldn't the first letter in "There" be lower case 't'?

Yes

>to spell out this explicitly).

I would think *not* INFORMATIONAL because we just said "this is not part of an INFORMATIONAL exchange". Having said that, I have no idea what to use instead. What do others think?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 4 Feb 2010 18:42:40 +0300

> exchanges, can be sent outside the context of an IKE SA."

OK.

> I would think *not* INFORMATIONAL because we just said "this is not part of
> an INFORMATIONAL exchange". Having said that, I have no idea what to use instead.
> What do others think?

I've been thinking that the words "this is not part of an INFORMATIONAL exchange"
mean that one must not reply to such a message, but it's Exchange Type (in cases,
when such a message is not a response) is still INFORMATIONAL.
Note, that it is section 1.4 (The INFORMATIONAL Exchange), where
informational messages are first introduced, so they seem to be correlated somehow, right?

Anyway, as we've understood this differently, I think that Exchange Type for
informational messages which are not responses, (whichever WG will agree upon),
must be written down explicitely.

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 14:07:18 +0200

>    UDP port as the destination port if the packet was UDP (IKE or UDP-
							     ^^^^^^^
>    encapsulated ESP or AH).

Remove the "IKE or" part, as we are still talking about ESP/AH packet
which has unknow SPI. It cannot be IKE packet. Perhaps better to
change the whole sentence to:

    If no suitable IKE SA exists, the node MAY send an informational
    message without cryptographic protection to the source IP address.
    If the incoming ESP or AH packet was UDP-encapsulated, then node
    needs to use NAT-T IKE format and IP addresses and UDP ports from
    the headers are reversed and used for return informational
    message.

>                          In this case, it should only be used by the

I think we should explictly mention that Exchange Type of that messge
is set to "INFORMATIONAL". 

-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Feb 2010 10:35:33 -0800

At 2:07 PM +0200 2/8/10, Tero Kivinen wrote:
>which has unknow SPI. It cannot be IKE packet.

Got it; fixed. However:

>Perhaps better to

This is another significant technical change. If you think it is important, please open a new issue for it.

>is set to "INFORMATIONAL".

Please see my previous message on this topic. I do not understand how we can say both "this message is not part of an INFORMATIONAL Exchange" *and* "mark the Exchange Type as INFORMATIONAL". I am not saying it is inherently wrong, just that it is confusing. For example, I could see choosing IKE_SA_INIT just as easily, given that this message is not part of an INFORMATIONAL Exchange.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Feb 2010 13:20:23 +0200

Paul Hoffman writes:
> This is another significant technical change. If you think it is
> important, please open a new issue for it.

I do not consider it as techincal change, it just changes the wording
a bit to make it easier to understand. The current text already
specifies same thing, I just copied text bit more from section 3.1 to
say that IP addresses and UDP protss are reversed.

This is the only way to get the informational exchange back, so I do
not think anybody will make mistake there, so if you feel that it is
techinal change then feel free to leave it as it is. Implementors will
implement things the same way regardless.

> Please see my previous message on this topic. I do not understand
> how we can say both "this message is not part of an INFORMATIONAL
> Exchange" *and* "mark the Exchange Type as INFORMATIONAL". I am not
> saying it is inherently wrong, just that it is confusing. For
> example, I could see choosing IKE_SA_INIT just as easily, given that
> this message is not part of an INFORMATIONAL Exchange. 

No, we cannot select IKE_SA_INIT, as that has very specific payloads
which can be in it, and the Notify payload is not one of them. On the
other hand in the packet having exchange type of INFORMATIONAL can
have notifications inside.

I do expect that everybody will only process those notifications if
they are inside packet having exchange type of INFORMATIONAL. In a
sense they look like INFORMATIONAL exchange, but they are not
INFORMATIONAL exchange, as only one half of the actual exchange is
included, i.e the first request packet and there is no reply.

INFORMATIONAL exchange consist of two packets having exchange type of
INFORMATIONAL in their header (i.e. two INFORMATIONAL messages one
request and one reply).

The header of this section is "Informational Messages outside of the
IKE SA".
-- 
[email-masked]