ike2 ambiguities?

["jpickering%creeksidenet.com" <jpickering@xxxxxxxxxxxxxxxx>]

While trying to understand IKE2 behavior in the face of man in the 
middle attacks, I
noticed some ambiguities in the spec that could/should be clarified:

* In section 4.2 the following statements are made:

Each endpoint in the IKE Security
Association maintains two "current" Message IDs: the next one to be
used for a request it initiates and the next one it expects to see
from the other end. These counters increment as requests are
generated and received.
and
Note that Message IDs are cryptographically protected and provide
protection against message replays.

I am presuming that, for cryptographically protected messages, if the 
message is
not authenticated, the message is rejected and message ID counters are 
not incremented.
If this assumption is correct, the requirement should be explicitly 
stated somewhere.

* In section 4.3 the following requirement is imposed on message initiators:

An IKE endpoint MUST NOT exceed the peer's stated window size (see
section 5.3.2) for transmitted IKE requests. In other words, if Bob
stated his window size is N, then when Alice needs to make a request
X, she MUST wait until she has received responses to all requests up
through request X-N. An IKE endpoint MUST keep a copy of (or be able
to regenerate exactly) each request it has sent until it receives the
corresponding response. An IKE endpoint MUST keep a copy of (or be
able to regenerate with semantic equivalence) the number of previous
responses equal to its contracted window size in case its response
was lost and the Initiator requests its retransmission by
retransmitting the request.

However, the required action by a responder if a message is outside the 
window
is not stated in the spec. One would think that an efficient method of 
rejecting
replays would be to reject messages received outside the window. If this 
is the
desired action, it should probably be stated.

* While it would seem intuitive that an endpoint would reject all but 
child-SA messages
after IKE-SA establishment, this is not stated in the spec. Failure to 
reject would allow
a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with
an updated message ID (unless all nonces were tracked which imho is 
adding undesirable
state upon msg1 receipt). It would be nice to add to the draft some text 
about
rejecting messages like this and other things that don't make sense in
the current context.

All feedback appreciated.

Jeff