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

[Greg Mirsky <[e-mail]>]

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

On Thu, Sep 13, 2018 at 5:36 PM, Marc Binderberger <[e-mail]> wrote:

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



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


> 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.
>
GIM>> Would s/recommends/requires/ work?

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


>
> 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?
>
GIM>> Yes, it is the case.

> But my main question is, why the VNI (or related information like the
> local
> 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
>
>    [...] 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?
>
GIM>> By using different VNI in the VXLAN encapsulation of a BFD Control
packets.

>
>
> 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? ;-)
>
GIM>> Agreed. Would s/inner Ethernet/inner IP packet/ address it?

>
>
>
> Anyway, overall very useful standard (as you see from my comments, there
> are
> feature roadmaps coming ;-)
>
GIM>> Thank you for your kind words and help to improve the specification,
Marc.

>
>
> 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: <[e-mail]>
> > Date: Sat, Aug 18, 2018 at 1:09 PM
> > Subject: I-D Action: draft-ietf-bfd-vxlan-02.txt
> > To: [e-mail]
> > Cc: [e-mail]
> >
> >
> >
> > 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/
> >
> >
>