Last Call Review of draft-templin-aero-
review-templin-aero-secdir-lc-salowey-2012-04-26-00

I 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 apologize for the delay in getting this review out.  Hopefully it is still
useful.

This first set of comments is primarily for the authors.

1. In section 4.4.4 on Data origin authentication the last paragraph states
that only the 3rd of the above conditions is acceptable, do you really mean the
4th? 2. In section 4.4.4 there is reference to the packet including a digital
signature to authenticate the origin.  What is the signature mechanism?  Is
this SEND or something different? I did not see a reference to it. 3. The
security considerations do not say much about the consequences of trusting an
inappropriate intermediate router, ingress node or egress node. Clearly DOS to
the ingress node is a possibility.   Data modification and disclosure can be a
goal of an attacker who tries to control the routing.   Are there other issues
the reader should be aware of (perhaps other DOS attacks such as amplification
attacks).  Anything outside the considerations of RFC4861)? 4. The security
consideration section indicates that spoofing protection can be provided by
links that provide link layer security mechanisms.    Link Layer security
mechanisms may or may not help.   I believe more information is needed here. 
L2 mechanisms may not provide adequate protection of upper layer address
bindings.  In some cases L2 mechanisms do not provide source origin
authentication such as multicast  traffic protected with the group  key in WiFi
and group security associations in 802.1AE (MACSEC).

This set of comments is mostly for the area directors:

1. I am mostly concerned about the lack of definition for the digital signature
mechanism.  Perhaps this is easily rectified by a reference to an existing
specification. Its not clear to me what the specification would be (perhaps
SEND??)?  Is something needed in addition? 2.  The risks of not securing the
proposal are not defined in the security considerations section. I think this
would be helpful, but may not be strictly necessary.  There is some mention of
Link-Layer security helping in some aspects of this, but its not clear on what
characteristics the lower layer security needs to provide.

Cheers,

Joe