Last Call Review of draft-ietf-mip4-generic-notification-message-
review-ietf-mip4-generic-notification-message-secdir-lc-salowey-2009-09-10-00

 have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I have primarily focused on the security considerations section in this
document.  I also quickly reviewed the rest of the document.  Based on
my review I have the following comments:

1. In section 4.1, Identification

It states "nonces" are optional.  Nonces are not mentioned in the rest
of the document.  This option should be removed.  

2. Section 4.1, extensions

I found this section confusing as to when the AE is required.  It seems
the document states that the AE is always required, however it also uses
optional.   For example its not clear to me what is required in the case
given is section 3.2.

3. Section 4.2, extensions

Shouldn't the AE be required for GNAM?

4. Security considerations Section 8

It also wasn't quite clear to me when the AE is optional and mandatory.


5. Section 8.1

There are several places in the document where different replay
mechanisms are alluded to, included this section.  This section states
that nodes must agree on the mechanism used.  However there appears to
be no way to signal what mechanism is in use.  Is this assumed to be
pre-configured in each node, or is there another mechanism for this?  Is
this realistic for deployments? 

6. Section 8.1.1

NTP RFC 1305 needs to be included in the normative references.

Why is it important "those bits which are not available from a time
source SHOULD be generated from a good source of randomness" ? (it seems
that you don't really want bits to be random since you want to enforce
ordering)

This section also talks very briefly about clock synchronization.  It
seems there could be security implications here.  One node may be able
to poison a clock to an in appropriate value.  There probably should be
more discussion here.  

7. Section 8.2 

This section makes a statement but does not describe how impacts the
security of the system.  Since authentication is not performed can you
use the extension defined in the document in this case?  What is the
effect of the lack of authentication.