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

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Jun 2019 13:40:33 -0700

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 <[email-masked]> 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.
> --

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jun 2019 17:26:43 -0400

> mode, but more standardization work may be required.

Speaking as a BFD chair, this is the relevant observation.  BFD Echo is
underspecified to the point where claiming compliance is difficult at best.
In general, it relies on single-hop and the ability to have the remote Echo
client loop the packets. 

This packet loop may not be practical for several encapsulations and thus is
out of scope for such encapsulations.  Whether this is practical for vxlan
today, or in the presence of future extensions to vxlan is left out of scope
for the core proposal.

-- Jeff

---

From: Shawn Emery <[email-masked]>
Date: Fri, 7 Jun 2019 16:30:50 -0600

Comments begin with SME...

>    the maximum number of such session that can be active at the same

SME: Yes, I think that this recommendation helps in resolving the issue.

> 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.
>

SME: OK, I'm fine with the response that no additional information is
disclosed that could lead to confidentiality, integrity, or DoS exposure.

> 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

SME: OK, I'll let the IESG deal with this aspect of the document.

> mode, but more standardization work may be required.

SME: Could you use Jeff's text below to help with why BFD Echo is out of
scope for this draft?

Thanks,

Shawn.
--

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 7 Jun 2019 20:42:47 -0400

Shawn,

> SME: Could you use Jeff's text below to help with why BFD Echo is out of
[...]

> > today, or in the presence of future extensions to vxlan is left out of

To ask the question succinctly: Can vxlan support such a packet loop?  If
not, bfd echo is out of scope.

-- Jeff