[secdir] secdir review of draft-ietf-bfd-seamless-use-case-04

Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 12 April 2016 16:49 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SHnkcsiVX7VxaglXwVs9xuRR2jKXTEI7W7mIRtSNyPiKQ65lNp8ILfiYuzKxUS0+zQPfqiuNEQWjEKOZ2lFOkjFpmMeK6nFB+y0g55mCcY4ctmR9LqhqPS8yp7LBJVLhia5HgvoejwekKn03t1VP0L8oigbOu8WBwM23a4DlIU0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type;
Message-ID: <570D272A.8090105@gondrom.org>
Date: Tue, 12 Apr 2016 18:49:46 +0200
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org
Content-Type: multipart/alternative; boundary="------------090808070701090403000001"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/F4uILEqeeQkMJH27ODEwGQ6KWPs>
Cc: draft-ietf-bfd-seamless-use-case.all@ietf.org
Subject: [secdir] secdir review of draft-ietf-bfd-seamless-use-case-04
Precedence: list

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.

The draft aims for informational and is about various use cases for 
Bidirectional Forwarding Detection (BFD) and various requirements.
Note: Solutions to the identified uses cases and protocol specific 
enhancements are outside the scope of this document.

If this document is seen as use case document only, it appears in good 
shape.
However, it also includes a section 4 about requirements and it seems 
security requirements have not been considered among them.
Maybe that is not intended or not necessary. I will leave that question 
up for the judgement by the WG.

One main comment:
1. section 5: Security Considerations
is empty as it states not to introduce any new protocols. In principle 
that is ok, as long as it is understood that the following proposed 
protocols for these use cases will need to answer to security 
considerations.
However, as the document also speaks about requirements, it would have 
been nice to spell out specific security requirements that are to be 
considered from these use cases. Security requirements (from protection 
against malicious actors) should have been considered in section 4.
Also the various use cases should be explored for whether they may 
expose a system to abuse.
E.g. several requirements are stated as "MUST" (which btw. I am not sure 
is the proper use of RFC2119 definition). The question would be if a 
system will follow these requirements whether it would be exposed to 
additional security risks. E.g. Req#2 "MUST be able to establish a 
unidirectional BFD session without the bidirectional handshake", #3 "BFD 
session MUST be able to be established without the need for session 
negotiation". Overall I can see the request for these requirements. I 
would also like to see a discussion of their security implications and 
risks.


nitbits:
some of the language seems not so clean. Not outright wrong, but very 
hard to understand.
Maybe some native speakers or the RFC editor can help clean this up:
e.g. section 3.2 "All it takes is for the network entities to know what 
the discriminator values to be used for the session."
I read this sentence a few times and not quite sure which words to add 
to match the intended meaning of the authors. ;-)

Thank you and best regards.

Tobias

[secdir] secdir review of draft-ietf-bfd-seamless… Tobias Gondrom