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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

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