[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

INITIAL-CONTACT issues



I was implementing the INITIAL-CONTACT status notification of the
IPsec DOI when a few things suddenly struck me.

RFC 2408 3.14 states this:

   Notification which occurs during, or is concerned with, a Phase 1
   negotiation is identified by the Initiator and Responder cookie pair
   in the ISAKMP Header.  The Protocol Identifier, in this case, is
   ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
   Header identifies the ISAKMP SA. If the notification takes place
   prior to the completed exchange of keying information, then the
   notification will be unprotected.

This directly contradicts what is said a few lines further down (at
least I think so, but the "SPI value of 0" wording is a bit vague, and
as such I dislike it):

    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
       therefore, the SPI Size is irrelevant and MAY be from zero (0) to
       sixteen (16).  If the SPI Size is non-zero, the content of the
       SPI field MUST be ignored.  The Domain of Interpretation (DOI)
       will dictate the SPI Size for other protocols.

I propose the wording of the first paragraph be changed to:

   Notification which occurs during, or is concerned with, a Phase 1
   negotiation is identified by the Initiator and Responder cookie pair
   in the ISAKMP Header.  The Protocol Identifier, in this case, is
   ISAKMP and the SPI is irrelevant (although there are still some
   limitations on its representation) because the cookie pair in the
   ISAKMP Header identifies the ISAKMP SA. If the notification takes
   place prior to the completed exchange of keying information, then
   the notification will be unprotected.

I also propose the other paragraph be changed to:

    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
       therefore, the SPI Size is irrelevant and MAY be from zero (0) to
       sixteen (16).  If the SPI Size is non-zero, the content of the
       SPI field MUST be ignored.  The Domain of Interpretation (DOI)
       MAY put further restrictions for the DOI-defined notify message
       types and MUST dictate the SPI Size for other protocols.

Maybe my use of MAY & MUST wrt what a DOI should do is bogus, but at
least this covers the extra rules RFC 2407 sets in 4.6.3.3 (e.g. for
INITIAL-CONTACT).

Next thing, RFC 2407 4.6.3.3, is a bit unclear on one point:

	When used, the content of the Notification Data field SHOULD
	be null (i.e. the Payload Length should be set to the fixed
	length of Notification Payload).

The fixed length, to me, meant a null SPI field as well, as that is
variable length, and although I had noted that the SPI field should be
filled in with data I missed to allocate space for it, mainly due to
this wording.  Clearly it was an error of mine, but this also shows
the wording is a bit unfortunate.

I propose:

	When used, the content of the Notification Data field SHOULD
	be null (i.e. the Payload Length should be set to the fixed
	length of a Notification Payload plus the SPI size).


Last, RFC 2407 in 4.6.3 says that INITIAL-CONTACT MUST NOT be sent in
Aggressive Mode.  This is all fine by me (although I could envision
the initiator send his INITIAL-CONTACT in the last message if he chose
to encrypt it, which is at its option).  I bring this up because
draft-jenkins-ipsec-rekeying-01.txt has some text that makes
aggressive mode useless if we follow these rules, in 3.1:

     Initial Phase 1 SA Negotiation:
      -initiator MUST use INITIAL-CONTACT notification
      -responder may use INITIAL-CONTACT notification

Now, there is at least one voice stating that aggressive mode is
useless anyhow, so maybe this is moot.  If it is not, however, I
suggest Jenkins change his text to cover aggressive mode and talk
about the options of sending INITIAL-CONTACT in a separate
Informational Exchange (thus without guarantee of delivery) or as
extra payload(s) in the first Quick Mode (which may not ever occur).
I guess that is the best one can do in aggressive mode?

Comments?

Niklas