Re: SecDir review of draft-ietf-bfd-base-08.txt

[David Ward <[e-mail]>]

Alexey -

Thanks for the review. Some of the comments are relevant for us to  
clarify in the document but, others are not. A few inline.

On May 21, 2008, at 2:52 PM, Alexey Melnikov wrote:

> 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.
>
> This document describes a protocol intended to detect faults in the
> bidirectional path between two forwarding engines. Separate documents
> define how this protocol can be implemented in protocols connecting  
> the
> forwarding engines.
>
> In general I found the document to be well written and easy to
> understand. I found the Security Considerations section to be  
> adequate, however I have some comments/additional suggestions.
>
> In section 4.1:
>
>> Authentication Present (A)
>>
>>      If set, the Authentication Section is present and the session is
>>      to be authenticated.
>
> It looks like it might be very easy for an attacker to disable
> authentication by clearing this field and stripping the Authentication
> Section of the BFD Control packet.
> I think this should be mentioned in the Security considerations  
> section.
> (Or please let me know if this is covered elsewhere in the document.)
>

DW: If stripped then the session will be invalid. Security is  
negotiated and thus both sides must agree.

>> Length
>>
>>      Length of the BFD Control packet, in bytes.
>
> Does this include all fields, including version, ... and the Length  
> itself?
>

>> Auth Type
>>
>>      The authentication type in use, if the Authentication Present  
>> (A)
>>      bit is set.
>>
>>        0 - Reserved
>>        1 - Simple Password
>>        2 - Keyed MD5
>>        3 - Meticulous Keyed MD5
>>        4 - Keyed SHA1
>>        5 - Meticulous Keyed SHA1
>
> It is good that the document allows for various authentication types.
> However, I don't see a point in defining Keyed MD5 and Meticulous  
> Keyed
> MD5, considering that SHA1 variants are mandatory to implement anyway.
> If there is a reason for defining MD5 variants (such as existing
> implementations, or speed, etc.), I suggest the document say so. In  
> the absence of such reason I don't see a point in standardizing MD5  
> variants in a new protocol.
>

DW: The point is that BFD is bootstrapped by routing protocols and  
often implementations have protocol independent key-chains. Given  
some operators asked that we allow the ability to use either the same  
protocol independent key-chain info and md5 and meticulous keyed md5  
is available to them today; we continued to allow operators to use  
what is available. Therefore, the decision was purely operationally  
pragmatic.


>>        6-255 - Reserved for future use
>
> In Section 4.3:
>
>>   Auth Key/Checksum
>>
>>      This field carries the 16 byte MD5 checksum for the packet.   
>> When
>>      the checksum is calculated, the shared MD5 key is stored in this
>>      field.  (See section 6.7.3 for details.)
>
> This might be obvious, but I think it is worth noting that the shared
> key is exactly 16 bytes in length. If it is not the case, then some  
> text
> about padding the key when calculating the hash is needed.
>

DW: I believe it is clear it is already 16 bytes.


>> 6.3. Demultiplexing and the Discriminator Fields
>>
>>   Since multiple BFD sessions may be running between two systems,  
>> there
>>   needs to be a mechanism for demultiplexing received BFD packets to
>>   the proper session.
>>
>>   Each system MUST choose an opaque discriminator value that  
>> identifies
>>   each session, and which MUST be unique among all BFD sessions on  
>> the
>>   system.  The local discriminator is sent in the My Discriminator
>>   field in the BFD Control packet, and is echoed back in the Your
>
> Are there any considerations on how random (guessable) this value  
> should be?

DW: It doesn't matter.

>
>> 6.7.1. Enabling and Disabling Authentication
> [...]
>
>>   One possible approach is to build an implementation such that
>>   authentication is configured, but not considered "in use" until the
>>   first packet containing a matching authentication section is  
>> received
>>   (providing the necessary synchronization.)  Likewise,  
>> authentication
>>   could be configured off, but still considered "in use" until the
>>   receipt of the first packet without the authentication section.
>>
>>   In order to avoid security risks, implementations using this method
>>   should only allow the authentication state to be changed once  
>> without
>>   some form of intervention (so that authentication cannot be  
>> turned on
>>   and off repeatedly simply based on the receipt of BFD Control  
>> packets
>>   from remote systems.)
>
> I am not sure I understand the last quoted paragraph, can you  
> elaborate
> what are you trying to say?
>

DW: This is how to thwart the negotiation of auth and turning it on  
and off.


Many thanks again

-DWard