Subject: Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt

From: Marc Binderberger <[email-masked]>
Date: Thu, 13 Sep 2018 14:36:11 -0700

Hello Greg & Authors,

great to see this draft progressing!

As usual I'm a bit late :-/ but I do have some questions/comments:

Q1: the TTL = 1 requirement for the inner IP packet. The explanation for the 
MUST is

         TTL: MUST be set to 1 to ensure that the BFD packet is not
         routed within the L3 underlay network.

I find this a very implementation-specific reason that may not apply to many 
other implementations. But the demand for TTL = 1 may limit what can be done 
with today's silicon, which is why I question this demand here :-)

You will find off-the-shelf silicon that offers you BFD RFC5881 "in 
hardware". For the ASIC user the usage is typically fixed by the API/SDK and 
RFC5881 uses TTL = 255 for send and check on receive. Using a loopback port 
it would be simple to use this RFC5881 BFD engine to send packets over the 
VxLAN tunnel.  But the TTL=1 requirements defeats this.  Could we drop it?

Q2: in this context of TTL you write

   10.  Security Considerations

      The document recommends setting the inner IP TTL to 1 which could
      lead to a DDoS attack.

First, you don't recommend - you say MUST. But as a non-native speaker maybe 
this is a misinterpretation on my side ;-)
More interesting: how does TTL = 1 raises the DDoS risk? By someone directly, 
i.e. without any VxLAN encapsulation, sending a BFD packet to the VTEP IP ?

Q3: for the demultiplexing of incoming BFD packets (section 6.1) you write

   [...] For such packets, the BFD session MUST be identified
   using the inner headers, i.e., the source IP and the destination IP
   present in the IP header carried by the payload of the VXLAN
   encapsulated packet.  The VNI of the packet SHOULD be used to derive
   interface-related information for demultiplexing the packet.

I understand the "MUST" for the source IP, to differentiate a session with 
VTEP A from the session with VTEP B. Why is the destination IP, i.e. my local 
IP, of relevance?  Support for multiple VTEP?
But my main question is, why the VNI (or related information like the local 
VLAN or VFI) is only a "SHOULD" ?  In section 4 you say

   [...] Separate BFD
   sessions can be established between the VTEPs (IP1 and IP2) for
   monitoring each of the VXLAN tunnels (VNI 100 and 200).

How would I separate these BFD sessions when src/dst IP are the same?

Finally a nitpick, you write in section 6:

   The UDP destination port and the TTL of the inner Ethernet frame MUST
   be validated

We all understand what you mean but I first stumbled: Ethernet frames have no 
TTL. You mean (of course) the inner IP packet - why not writing it? ;-)

Anyway, overall very useful standard (as you see from my comments, there are 
feature roadmaps coming ;-)

Thanks & Regards,
Marc

On Sat, 18 Aug 2018 13:54:22 -0700, Greg Mirsky wrote:
> Dear All,
> the new version addresses comments and editorial suggestions we've received 
> from Donald.
> 
> Your reviews are most welcome, comments, questions, and suggestions much 
> appreciated.
> 
> As discussed at the meeting in Montreal, the authors believe that this 
> document is ready for WGLC.
> 
> Regards,
> Greg
> 
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: Sat, Aug 18, 2018 at 1:09 PM
> Subject: I-D Action: draft-ietf-bfd-vxlan-02.txt
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of 
> the IETF.
> 
>         Title           : BFD for VXLAN
>         Authors         : Santosh Pallagatti
>                           Sudarsan Paragiri
>                           Vengada Prasad Govindan
>                           Mallik Mudigonda
>                           Greg Mirsky
>         Filename        : draft-ietf-bfd-vxlan-02.txt
>         Pages           : 10
>         Date            : 2018-08-18
> 
> Abstract:
>    This document describes the use of the Bidirectional Forwarding
>    Detection (BFD) protocol in Virtual eXtensible Local Area Network
>    (VXLAN) overlay networks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-02
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Sep 2018 15:47:34 -0700

Hi Marc,
many thanks for your excellent comments and the most detailed questions -
all much appreciated and the most helpful.
Please find my answers, notes in-line and tagged GIM>>,

Regards,
Greg

> GIM>> I think that this specification is closer to RFC 5884 case where TTL
> for the encapsulated BFD control packet mandated to be set to 1:
>
The IP TTL or hop limit MUST be set to 1 [RFC4379].

>       The document recommends setting the inner IP TTL to 1 which could
GIM>> Would s/recommends/requires/ work?

> i.e. without any VxLAN encapsulation, sending a BFD packet to the VTEP IP ?
GIM>> Agree, the wording is rather confusing. Would the following text make
it clearer:
OLD TEXT:
   The document recommends setting the inner IP TTL to 1 which could
   lead to a DDoS attack.  Thus the implementation MUST have throttling
   in place.  Throttling MAY be relaxed for BFD packets based on port
   number.

NEW TEXT:
   The document requires setting the inner IP TTL to 1 which could
   be used as DDoS attack vector.  Thus the implementation MUST have
throttling
   in place to control the rate of BFD control packets sent to the control
plane.

> IP, of relevance?  Support for multiple VTEP?
GIM>> Yes, it is the case.

> VLAN or VFI) is only a "SHOULD" ?

GIM>> An implementation may support only use of VNI 0 and not to use VNI
value of the received packet.

> In section 4 you say
GIM>> By using different VNI in the VXLAN encapsulation of a BFD Control
packets.

> TTL. You mean (of course) the inner IP packet - why not writing it? ;-)
GIM>> Agreed. Would s/inner Ethernet/inner IP packet/ address it?

> feature roadmaps coming ;-)
GIM>> Thank you for your kind words and help to improve the specification,
Marc.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 25 Sep 2018 10:04:34 -0700

Hi Marc,
hope this note finds you well. Attached you'll find diff between the latest
and working versions of the document. The latter includes the update
suggested by Donald and proposed changes I hope will address your comments.
Your consideration and feedback on the proposed updates much appreciated.

Best regards,
Greg

On Mon, Sep 17, 2018 at 3:47 PM Greg Mirsky <[email-masked]> wrote:

>> GIM>> I think that this specification is closer to RFC 5884 case where
>> TTL for the encapsulated BFD control packet mandated to be set to 1:
>>
> GIM>> Agree, the wording is rather confusing. Would the following text
> make it clearer:
> OLD TEXT: