Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt
Marc Binderberger <marc@sniff.de> Thu, 13 September 2018 21:36 UTC
Return-Path: <marc@sniff.de>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69A130E88 for <rtg-bfd@ietfa.amsl.com>; Thu, 13 Sep 2018 14:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBakDo4FvYU5 for <rtg-bfd@ietfa.amsl.com>; Thu, 13 Sep 2018 14:36:14 -0700 (PDT)
Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id B723F130E7C for <rtg-bfd@ietf.org>; Thu, 13 Sep 2018 14:36:13 -0700 (PDT)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 43A534BD0EA; Thu, 13 Sep 2018 21:36:10 +0000 (UTC)
Date: Thu, 13 Sep 2018 14:36:11 -0700
From: Marc Binderberger <marc@sniff.de>
To: Greg Mirsky <gregimirsky@gmail.com>, rtg-bfd WG <rtg-bfd@ietf.org>
Message-ID: <20180913143611411852.0ca9e40a@sniff.de>
In-Reply-To: <CA+RyBmW9x9Y-Ve=1JnFatqisqOkpN6YZuOFimNbUS+Keo1KUnw@mail.gmail.com>
References: <153462297684.27533.6391249246080806217@ietfa.amsl.com> <CA+RyBmW9x9Y-Ve=1JnFatqisqOkpN6YZuOFimNbUS+Keo1KUnw@mail.gmail.com>
Subject: Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.19
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nifl8rpXU4QVe2jxKqfMjTIiWUQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 21:36:17 -0000
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: <internet-drafts@ietf.org> > Date: Sat, Aug 18, 2018 at 1:09 PM > Subject: I-D Action: draft-ietf-bfd-vxlan-02.txt > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > > > > 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/ > >
- I-D Action: draft-ietf-bfd-vxlan-02.txt internet-drafts
- Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt Greg Mirsky
- Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt Marc Binderberger
- Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt Greg Mirsky
- Re: Fwd: I-D Action: draft-ietf-bfd-vxlan-02.txt Greg Mirsky