Re: [secdir] secdir review of draft-templin-aero-10

[Fred Templin <[e-mail]>]

(Resending with comments as inline text)

Hello Joe,

Thank you for these comments. Please see below for my proposed
resolutions:

Fred
[e-mail]



>________________________________
> From: Joe Salowey <[e-mail]>
>To: [e-mail]; The IESG <[e-mail]>; [e-mail] 
>Sent: Sunday, April 22, 2012 3:00 PM
>Subject: secdir review of draft-templin-aero-10
> 
>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?
>
>>>> Begin FLT response
>
>You are correct; this should say the 4th and
can be fixed in the next version.>>> End FLT response
>
>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.
>
>>>> Begin FLT response
>
>The digital signature mechanism is out of scope for
this document. The text
>could be adjusted to say: “…, AERO nodes may be obliged
to require the
>use of digital signatures applied through means outside the
scope of this
>document.”>>> End FLT response
>
>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)?
>
>>>> Begin FLT response
>
>Proposed resolution is to re-write the first paragraph
of Section 6 as follows:
> 
>“AERO link security considerations are the same as for standard
IPv6 Neighbor Discovery
>(RFC4861) except that AERO improves on some aspects. In
particular, AERO is dependent
>on a trust basis between AERO edge nodes and intermediate
routers, where the edge nodes
>must only engage in the AERO mechanism when it is
facilitated by a trusted intermediate
>router.”>>> End FLT response
>
>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).
>
>>>> Begin FLT response
>
>Proposed resolution is to re-write the second paragraph
of Section 6 as follows:
>“AERO links must be protected against spoofing attacks in which an attacker
>on the link pretends to be a trusted neighbor.  Links that provide link-layer
>securing mechanisms (e.g., WiFi networks) and links that provide physical
>security (e.g., enterprise network LANs) provide only a fist-line of defense.In some instances, therefore, additional
securing assurances against on-link
>spoofing attacks are required. For example,
if the source can through some
>means digitally sign its messages the
destination can verify the signatures to
>ensure data origin authentication.
Exact mechanisms for digitally signing and
>verifying signatures are outside the
scope of this document.”
>>>> End FLT response
>
>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
>
>