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

ISAKMP Draft: NotifyCodes, alignment



Doug, two suggestions for ISAKMP v-09 to bring it into line with the IP DOI
and what I believe to be implementors' current understanding and working code:

Notification Codes

The IP DOI (v-06 and earlier) actually violated the ISAKMP draft by using
codes in the Private range as Status codes (the DOI is a standard, not
Private, right?).  Since people are presumably implementing these codes
already, perhaps it would be better for the ISAKMP draft to change to make
the present DOI valid.  Also the draft should spec the full range of the
16-bit number.  How about this:

Status codes in v-08:
                   CONNECTED                  16384
                   RESERVED (Future Use)  16385-  24575
                   Private Use            24576 - 32767
Change to:
                   CONNECTED                  16384
                   RESERVED (Future Use)  16385-  24575
                   DOI-specific codes     24576 - 32767
                   Private Use            32768 - 40959 
                   RESERVED (Future Use)  40960 - 65535


Notification affecting phase I

The text has these contradictory assertions:

    Notification which occurs during, or is concerned with, a Phase 1 nego-
    tiation 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.

     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 is the ISAKMP SPI, therefore, the SPI Size would be 16
        octets for the SPI.

I believe implementations generally are using SPI size zero.  Most people
would probably accept any SPI size and not care what's in the SPI.
Probably the draft should say,

        [ ... ] 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 to 16 [? require
        alignment?  See below].  If the SPI size is nonzero the content
        of the SPI field MUST be ignored[? zero?].

The Phase II description asserts that Message ID identifies the session. 

    Notification which occurs during, or is concerned with, a Phase 2 nego-
    tiation is identified by the Initiator and Responder cookie pair in the
    ISAKMP Header and the Message ID and SPI associated with the current nego-
    tiation.  

This would require that the notification be sent as part of the Quick Mode
exchange;  but between ISAKMP v-08 and IKE (was "Resolution"), I understand
that all Notifications are supposed to be sent as an Informational
Exchange; it is asserted that an exchange prescribes exactly what messages
and payloads are permissible, and no exchanges have a place for
Notifications, particularly, a Notification returned in reply to the final
message sent.  An exception is that the IP DOI prescribes additional Status
Notifications and prescribes they get combined into the standard exchange
messages.

My understanding, which I am not at all sure reflects current practice:

    Notification which occurs during, or is concerned with, a Phase 2 nego-
    tiation is identified by a current Initiator and Responder cookie pair 
    in the ISAKMP Header, and the protocol and SPI associated with the
    affected negotiation.  The Message ID of the ISAKMP header DOES NOT
    identify the negotiation targetted by the Notification.

Other people may have different understandings of the above. If so, I hope
they'll speak now; we may all have to resolve differences where we are not
be interoperable.


Alignment

Remove the assertion that the Message is aligned.  It is not possible for
ISAKMP to demand alignment of a message; it is where IP prescribes that the
UDP body is, period, and this must be left open for IP/UDP.

State explicitly that any payload can be of arbitrary alignment, depending
on the content of previous payloads (e.g. a certificate).

Matt Thomas <matt@ljo.dec.com> said the SPI in a Notification is to be
padded to 4-bytes; I don't see that anywhere.  If it is anywhere it needs
to be more prominent; if not, then never mind.




Follow-Ups: