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

Michael's comments on ikev2 draft


It would be helpful if named messages/payloads in the draft were always
called the same thing. IKE_SA_init_response is sometimes called
IKE-SA-RESPONSE. It makes it hard to search through the draft for multiple
uses of the same keyword.

> 1.	is the IKE_SA_init_reject forgeable?
> 	page 10 makes me nervous.
> 	actually, all of 2.6 makes me nervous.

Presumably, the IKE_SA_init_reject would contain the initiator cookie, so
it's weakly DoS resistant, which is appropriate.


> 3.	Delete payloads are a MUST, which is also good.

Agreed. Implementations which don't send deletes continue to be a source of
interoperability problems.


> 5. 	section 2.4.. what about active Distributed Denial of
> Service attacks?
> 	Other than rate limits, I think that there is nothing we can do.

Not quite true. My earlier heartbeat method of dead peer detection is
resistant to this type of attack, but requires extra IKE bandwidth. Most
people didn't seem willing to trade the bandwidth for the DDoS resistance.


> 13.	4.1: "A single child-SA negotiation results in two
> security associations--
> 	      one inbound and one outbound. Different Nonces
> and SPIs for each SA
> 	      (one chosen by the Initiator, the other by the
> Responder) guarantee a
>  	      different key for each direction. The SPI chosen
> by the destination
> 	      of the SA and the Nonces (ordered source followed
> by destination) are
>               used to derive KEYMAT for that SA."
>
> 	This suggests tome that the Nx are different, when they
> are in fact the same.

But won't the order of the nonces in the PRF be different since the sender &
receiver are reversed for inbound and outbound SAs? This will cause the keys
to be different even if the SPIs are the same.


> 25.	I think that VendorID should always have C=0.
> 	Further, given presence of C bit, a vendorID payload
> can now be used
> 	to identify whose private-use space is in use as C bit can tell
> 	receiver of message whether or not the information is
> important or
> 	not.
>
> Suggested text:
>
>    The Vendor ID Payload contains a vendor defined constant.  The
>    constant is used by vendors to identify and recognize remote
>    instances of their implementations.  This mechanism allows a vendor
>    to experiment with new features while maintaining backwards
>    compatibility.
>
>    The Vendor ID payload is both an announcement from the
> sender of which
>    space private payload types will come from, and also an
> announcement of
>    the sort of private payloads it is willing to accept. The
> implementation
>    sending the Vendor ID MAY make assumptions about private
> payloads that it
>    may send, provided that all are not marked critical. Upon
> reception of a
>    Vendor ID of like stature, a sender may then send critically marked
>    payloads as as well.  Multiple Vendor ID payloads MAY be sent. An
>    implementation is NOT REQUIRED to send any Vendor ID
> payload at all.
>
>    A Vendor ID payload may be sent as part of any message.
> Reception of
>    a familiar Vendor ID payload allows an implementation to
> make use of
>    Private USE numbers described throughout this memo-- private
>    payloads, private exchanges, private notifications, etc. Unfamiliar
>    Vendor ID's MUST be ignored.
>
>    Writers of Internet-Drafts who wish to extend this protocol MUST
>    define a Vendor ID payload to announce the ability to implement the
>    extension in the Internet-Draft. It is expected that
> Internet-Drafts
>    which gain acceptance and are standardized will be given "magic
>    numbers" out of the Future Use range by IANA and the requirement to
>    use a Vendor ID will go away.

This is good text. I suggest that it be added to the draft.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
Follow-Ups: References: