Re: [secdir] Review of draft-ietf-bfd-vxlan-07

[Greg Mirsky <[e-mail]>]

Hi Shawn,
thank you for the review, clear, directed questions, and helpful
suggestions. Please find answers, notes in-lined and tagged GIM>>.

Regards,
Greg

On Fri, May 24, 2019 at 10:45 PM Shawn Emery <[e-mail]> wrote:

> Reviewer: Shawn M. Emery
> Review result: Ready with issues
>
> 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 draft specifies usage of the Bidirectional Forwarding Detection
> (BFD) protocol on
> Virtual eXtensible Local Area Network (VXLAN) tunnels.
>
> The security considerations section does exist and discusses the
> introduction of a possible
> DDoS attack due to the requirement of the protocol to set the IP TTL to
> one hop.  The prescription
> outlined is to throttle this traffic.  The section continues that BFD
> sessions should also have an
> upper limit, but does not give guidance on what is considered reasonable
> to where it would affect
> normal traffic vs. some form of DoS.
>
GIM>> The precise number would depend on many factors and thus we only
recommend to have a knob to control the number of BFD sessions between a
pair of VTEPs. Would the updated recommendation on the control of the
number of concurrent sessions between a pair of VTEP as below address your
concern:
OLD TEXT:
   The implementation SHOULD have a reasonable upper bound on the number
   of BFD sessions that can be created between the same pair of VTEPs.
NEW TEXT:
   If the implementation supports establishing multiple BFD sessions
   between the same pair of VTEPs, there SHOULD be a mechanism to control
   the maximum number of such session that can be active at the same
   time.

> I believe that this section should also document the security
> impact of deploying BFD on VXLANs for monitoring tunnel traffic.  Which
> additional information,
> if any, can now be obtained with BFD usage?
>
GIM>> As stated in RFC 5880, BFD is designed to detect failures in the path
between two BFD systems. BFD detects the loss of path continuity between
forwarding engines used by BFD peers that participate in the given BFD
session. As it is defined now, BFD is not used to monitor the tunnel
traffic for possible performance degradation

>
> General comments:
>
> This standards track draft makes a normative reference to the base RFC,
> 7348, which is informational.
> Are there plans of making the base protocol a standards track
> specification?  Downward references
> will need to be justified.
>
GIM>> As I understand, it is common practice to introduce to IETF process a
de-facto standard as Informational track document and reference it as the
normative document in a specification on the standard track. The flagged
downref requires manual correction.

>
> Editorial comments:
>
> NVE is never expanded and not on the RFC Editors Abbreviation List.
>
GIM>> Thank you. Will expand as Network Virtualization Endpoint.

>
> Echo BFD is out of scope for the document, but does not describe the
> reason for this or why state
> this at all?
>
GIM>> I think that the main reason is that the BFD Echo mode is
underspecified. RFC 5880 defined some of the mechanisms related to the Echo
mode, but more standardization work may be required.

>
> Shawn.
> --
>