Last Call Review of draft-ietf-bfd-seamless-use-case-04
review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14-00
| Request | Review of | draft-ietf-bfd-seamless-use-case |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-04-12 | |
| Requested | 2016-03-23 | |
| Authors | Sam Aldrin , Carlos Pignataro , Greg Mirsky , Nagendra Kumar Nainar | |
| Draft last updated | 2016-04-14 | |
| Completed reviews |
Genart Last Call review of -04
by
Dale R. Worley
(diff)
Genart Telechat review of -06 by Dale R. Worley (diff) Secdir Last Call review of -04 by Tobias Gondrom (diff) Opsdir Telechat review of -05 by Benoît Claise (diff) |
|
| Assignment | Reviewer | Tobias Gondrom |
| State | Completed | |
| Review |
review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14
|
|
| Reviewed revision | 04 (document currently at 08) | |
| Result | Has Issues | |
| Completed | 2016-04-14 |
review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14-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.
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