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

[Shawn Emery <[e-mail]>]

Comments begin with SME...

On Tue, Jun 4, 2019 at 2:40 PM Greg Mirsky <[e-mail]> wrote:

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

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


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

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


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

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


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

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

Thanks,

Shawn.
-- 
On Wed, Jun 5, 2019 at 3:25 PM Jeffrey Haas <[e-mail]> wrote:

> On Tue, Jun 04, 2019 at 01:40:33PM -0700, Greg Mirsky wrote:
> > > 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.
>
> 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
>