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

Various difficulties in ISAKMP ver-06



I have found a number of points which ISAKMP draft ver-06 still seems to
leave up in the air, most of which I would call obstacles to interworking.
So here they are:

  o Initiator should be allowed to send both ID's in all exchanges.

    The drafts seem to forget the firewall/router case, which is the
    more general case and so should be the target of the drafts.
    Note that the original Oakley, and Harkins/Carrell Quick Mode, do
    have this provision.

    Of course this makes the ID payload order dependent and the exchange
    has to say which is which.

  o It is not clear which payload the SA names as Next Payload: the
    Proposal or the next load after the proposals and transforms. There
    are contradictory indications which need to be fixed; I assume
    option 1 is correct and 2 is a mistake:

     1) Description of SA Payload (p. 26) specifies that Next Payload may
	be zero.  This implies that the Next-Payload is the next
	major payload, after all the proposals and transforms.  This
	would conform with the Payload Size of the SA.

     2) The example exchange picture in 4.1.1 (ver-02 p. 42) shows the
	Next-Payload of the SA contains "Proposal".  (Also this picture
	does not show an actual payload-size value.)

  o Ambiguity about correct use of Notification:
	The description of the Notify payload (ver-02 p.37) starts out
	saying, that a Notification in phase 1 is identified by the
	cookies in the message header, and a Notification in phase 2 is
	identified by the cookies and the Message ID. (It also mentions
	"the SPI associated with the current negotiation"; this phrase
	has no connection to the rest of the section; if it is meant to
	convey something particular, it has to be clarified.)

	But the Notification always contains the SPI field; and there
	is the provision for the Informational Exchange which permits
	a fresh Exchange to carry a Notification.  This implies that
	the SPI in the Payload is ALWAYS the defining identifier for
	the SA being acted upon.

	Surely it is permitted to send Notification within a message of
	an exchange in progress, and surely the Notification will contain
	the SPI which the message applies to?  This should be stated.

        It would seem silly to permit sending the Notify "Connected"
        in a separate Informational Exchange; it would be unreasonable
        to require that it MUST be sent in the separate exchange. I
        recommend it be allowed only on the cookies/ID of the original
        exchange.

	Is it forbidden to send Notification for SA B in a message whose
	cookies/msg ID name SA A, when the Exchange Type is not
	"Informational"?  I would want and expect it to be forbidden,
        but it doesn't have to be that way; needs to be spelled out.

	Is it required in any circumstances that a Notify MUST be sent in
	a new Informational Exchange and not with the cookies/ID and
	type of the Exchange in progress?  If this requirement applies in
	common cases, it will use up the space of Message ID's twice as
	fast as otherwise.

	Is it valid to retain the Message ID of an Informational Exchange
	and send further Notifications over time for various SA's?  In
	both directions?

	Is it valid to send a Notification applying to a User SA, when
	the ISAKMP SA is Up, in a message with:

	    The ISAKMP SA cookies
	    Exchange Type = "Informational"
	    Message ID = zero

  o Ambiguity in the correct use of Delete
	The questions above on Notification apply to Delete too.

        One would think that after a connection completes successfully, 
        the Delete SHOULD be sent in a separate Informational Exchange,
        but we have to provide for a necessary ambiguity here. Consider:
the state of setup is unclear in the partner who has sent the 
        last message of the Exchange until it receives something valid
        over the SPI; meanwhile this side doesn't know whether the
        other side has completed.

        The above implies that a Delete MUST be permitted to arrive in
        a separate Informational Exchange for an incomplete connection.

  o Requirements for an adequate cookie should be stated.  Karn's cookie
    is noted as existing but its features are not said to be required.

  o Ordering of payloads
	There is no statement on whether payloads within one message must
	appear in exactly a given order. The diagrams show a specific
	ordering on the face of it, but this is an inadequate basis for
	the reader to deduce a requirement, and the very existence of
        payload types makes it reasonable to allow any order.

	Precision on this point is especially needed wherever a hash
	or signature is prescribed to be over all the content of a
        message.

  o Notifications sent in the clear:
	Does the draft want to address whether a Notification should be
	sent in the clear at all when it says the connection failed,
	considering this is a vulnerability to attack?

  o The term "string" is not defined, e.g. for domain names.
	People can conclude with equal reasonableness,
	a) that it means with zero terminator, or b) all characters
	included in the count are significant content.


  o Alignment
      o General:
	It appears clear to me that all payloads in messages may appear
	unaligned, since some can have a size of odd bytes.  The text
	should state this, since the pictures show several things as
	being four bytes wide though this is not required by the text.

        If we do want alignment it has to be stated explictly, and as
        "aligned at 4-byte multiples" or "2-byte".

      o TLV Attributes:
	The discussion of TLV Attribute format specifies "word alignment";
	"word" is not a precise term. Two-octet?  Four?  And the wording
        of this section does not actually say alignment is required, but
        it sounds like it wants to.

	It unequivocally says any padding must be by leading zeroes; this
	gives no guidance to someone who invents a character attribute.

  o Lifetime Attributes

    The use of "Lifetime Type" and "Lifetime Duration" attribute pairs
    introduces an unnecessary complication and, as it is now, an
    ambiguity.  

    What is the correct procedure for pairing up the attributes, since
    the draft does not specify what order they have to be sent in?  Is it
    absolutely required that each "Lifetime Type" appear before its 
    respective "Lifetime Duration"?  Also, question: can one supply both
    a KB life limit and a time life limit?  I think the draft should
    say Yes".

    I would rather see the simple answer: change to have a separate 
    attribute each for: ESP life in seconds; ESP life in KB, AH life in
    seconds, AH life in KB, etc.  I see no argument against this, and
    it will save us all a hunk of just plain useless implementation code.