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

[Fred Templin <[e-mail]>]

Hello Joe,

Thank you for your comments. To your question on specifying a digital
signing mechanism, would the concern be addressed if I were to say
something like: "e.g., using IPsec AH, etc." ?

Fred
[e-mail]


----- Original Message -----
> From: Joe Salowey <[e-mail]>
> To: Fred Templin <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>; The IESG <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Tuesday, April 24, 2012 10:47 AM
> Subject: Re: secdir review of draft-templin-aero-10
> 
>T hanks for the quick response, comments inline:
> On Apr 23, 2012, at 9:52 AM, Fred Templin wrote:
> 
>>  (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
>> 
> 
> [Joe] OK
> 
>>  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
>> 
> 
> [Joe] I was hoping that something would be specified for interoperability,  I 
> think there are many cases where you would have to resort to a signing 
> mechanism, however it may be the case that AERO may be deployed where spoofing 
> of messages is not a concern (perhaps this should be the recommendation until a 
> signing mechanism is specified).  The ADs can decide if this is an issue or not.
>
>>  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
>> 
> 
> [Joe] OK thanks.
> 
>>  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
>> 
> [Joe] Thanks. (same comment on the specification of the signing mechanism as 
> above). 
> 
>>  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
>> 
>