Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)
draft-ietf-bfd-vxlan-16
Yes
(Martin Vigoureux)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-12-16 for -09)
Sent
I support Ben Kaduk’s DISCUSS position. * Section 9. Per “The document requires setting the inner IP TTL to 1, which could be used as a DDoS attack vector”, could you please clarify what part(s) of the notional architecture would be impacted (e.g., physical, virtual; and how)? * Section 9. Per: Thus the implementation MUST have throttling in place to control the rate of BFD Control packets sent to the control plane. On the other hand, over-aggressive throttling of BFD Control packets may become the cause of the inability to form and maintain BFD session at scale. Hence, throttling of BFD Control packets SHOULD be adjusted to permit BFD to work according to its procedures. I’m having difficulty parsing the guidance above – it points out the need to throttle and the ramifications of doing so. Per the last sentence, could you please clarify how the throttling should be calibrated. * Section 9. Per “this specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references”, I recommend being clearer which references you mean (i.e., I’m assuming you don’t mean RFC2119, RFC8174, etc.) * Editorial Nits: - Abstract. s/forming up/used to form/ - Section 9. s/such address/such an address/
Warren Kumari
No Objection
Comment
(2019-12-17 for -09)
Sent
I support Benjamin and Eric's DISCUSSES - I considered holding a DISCUSS on the "loopback address" terminology and formatting (which was also noted in the excellent OpsDir review by Jürgen Schönwälder), but think that Eric can carry it. In addition, like Jurgen, I think it would be helpful to have pointers to where terms are defined - the "Terminology" section isn't really terminology, but rather just an acronym expansion section.
Erik Kline
Abstain
Comment
(2020-10-03 for -15)
Sent
doc{draft-ietf-bfd-vxlan-15} ballot{Abstain} [[ comments ]] I was tempted to ballot Discuss, but I'm not sure about re-opening old discussions into which I've no insight (it all happened before my tenure). [ sections 3,5 ] * I agree with Eric Vyncke's concerns about the use of ::ffff:127.0.0.0/104 space. This is not especially well-motivated, nor do I think the use of 127.0.0.0/8 is particularly well-motivated. In IPv6, 2001::/23 is reserved for IETF protocol assignments and in my opinion this is an example of where that should be used. There is also still plenty of space to carve out from 192.0.0.0/24 for internal tunnel uses like this. Alternatively, a better approach might be for each VTEP to allocate their own IPv4 and/or IPv6 link-local addresses and uses these addresses for whatever traffic is to be sent within the data plane. If the VTEPs use inner Ethernet headers for this traffic, then this would seem to make more sense to me. [ section 9 ] * It's not clear that the security of a prohibition on routers is sufficiently motivating securit when the packet is logically "switched" because it's on the same (effectively) VLAN. The same router forwarding prohibition applies to link-local IP addresses and these could be used instead. * What prevents a machine like VM1-1 from crafting a packet with the magic destination MAC and src & dst IPs from the magic range? Should there be text about not forwarding any packets from VMs toward the magic dst MAC?
Éric Vyncke
(was Discuss)
Abstain
Comment
(2020-07-22 for -13)
Sent
Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point about TTL = Hop Limit not being 255. But, the authors and I are in an impasse about the use of IPv4-mapped IPv6 addresses but I do not want to block the document. I change my ballot to "ABSTAIN" in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others". BTW, I understood that the use a prefix rather than /32 or /128 was to allow for entropy (to explore multiple ECMP/LAG paths). BTW2, the right wording is "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice in the document. Did you (or actually the authors) also investigate the use of the: - ::/0 : unspecified address - 100::/8 the discard prefix used for RTBH RFC 6666 - or even requesting a block out of the 2001::/23 (reserved for IETF special use) Previous COMMENTs for archive as they were on revision -09 RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to address the Ethernet encapsulation ? I.e. specifying the Ethernet MAC addresses? -- Section 3 -- At first sight, I was surprized by having a BFD session per VXLAN VNI as it will create some scalability issue, but, I assume that this is to detect misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind? In "the inner destination IP address SHOULD" it is unclear whether it is in the all BFD packets, or only the request one or ... ? -- Section 4 -- While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet FCS" for consistency with the "Outer Ethernet Header" in figure 2 ? Why not using the Source MAC address as the Destination MAC address ? This would ensure that there is no conflict at the expense of "forcing" the transmission of the frame even if addressed to itself. Please consider rewriting the section about TTL/Hop Limit as it is not easy to parse/read. -- Section 9 -- This section is mainly about IPv4 (RFC 1812). Please address IPv6 as well in the explanation of packet not being forwarding when addressed to 127/8
Martin Vigoureux Former IESG member
Yes
Yes
(for -09)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2019-12-16 for -09)
Sent
Thanks for the work that everyone has put into this document. I have a couple of relatively important, related comments that should be taken into account prior to publication. --------------------------------------------------------------------------- §3: > As per Section 4, the inner destination IP address SHOULD be set to > one of the loopback addresses (127/8 range for IPv4 and > 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). Please consider reformatting this IPv6 address according to the recommendations of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5): ::ffff:127.0.0.0/104 It's also worth noting that, as a practical matter, modern operating systems do not seem to bind to anything in the IPv4-mapped range assigned to IPv4 loopback: Linux: ~$ ping6 ::ffff:127.0.0.1 PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes ^C --- ::ffff:127.0.0.1 ping statistics --- 14 packets transmitted, 0 received, 100% packet loss, time 13316ms MacOS: ~$ ping6 ::ffff:127.0.0.1 PING6(56=40+8+8 bytes) ::ffff:127.0.0.1 --> ::ffff:127.0.0.1 ping6: sendmsg: Invalid argument ping6: wrote ::ffff:127.0.0.1 16 chars, ret=-1 It is not clear to me whether this poses an issue for your intended usage. In any case, please do not refer to ::ffff:127.0.0.0/104 as "loopback addresses": IPv6 has only one loopback address defined (::1). The range you cite is best described as "IPv4-mapped IPv4 loopback addresses." Alternately -- and this is probably better -- use "::1/128" instead of "::ffff:127.0.0.0/104" for the inner IP header destination address. As an aside, I share Benjamin's unease around the use of loopback addresses in this fashion. It may be worth noting that IETF protocols can reserve addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such reserved addresses won't ever correspond to a valid destination. (There is corresponding text in section 4 that all of the preceding pertains to as well) --------------------------------------------------------------------------- §9: > This document recommends using an address from the Internal host > loopback addresses (127/8 range for IPv4 and > 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP > address in the inner IP header. Using such address prevents the > forwarding of the encapsulated BFD control message by a transient > node in case the VXLAN tunnel is broken as according to [RFC1812]: > > A router SHOULD NOT forward, except over a loopback interface, any > packet that has a destination address on network 127. A router > MAY have a switch that allows the network manager to disable these > checks. If such a switch is provided, it MUST default to > performing the checks. In addition to the comments above about IPv6 address formatting, the improper use of "loopback" terminology as it applies to IPv6, and concerns about using localhost: it's worth noting that this text in RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language, and so the use of ::ffff:127.0.0.0/104 implies no special router handling. ::1 *probably* does, at least as a practical matter.
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -09)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Not sent
Alvaro Retana Former IESG member
(was Discuss)
No Objection
No Objection
(2020-06-17 for -12)
Sent for earlier
[Thank you for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection
(2019-12-16 for -09)
Sent
I support Ben’s DISCUSS. In addition, I have a number of editorial comments. General: there are a lot of missing or incorrect articles, making the document harder to read than it should be. It would be good to fix that. If you let the RFC Editor fix it, it will require careful review during AUTH48 to make sure it’s correct. — Abstract — The phrase “forming up” is odd; I suggest just “forming”. — Section 3 — BFD packets intended for a VTEP MUST NOT be forwarded to a VM as a VM may drop BFD packets leading to a false negative. This needs two commas: one before “as” and one before “leading”. And what does “leading to a false negative” mean here? I don’t understand. It is RECOMMENDED to allow addresses from the loopback range through a firewall only if it is used as the destination IP address in the inner IP header, and the destination UDP port is set to 3784 [RFC5881]. I THINK the antecedent for “it” is meant to be “addresses from the loopback range”, though because of the number mismatch it looks like the antecedent is “a firewall”. One fix is to change “addresses” to “an address”, correcting the number error, but that leaves the ambiguity. Maybe betterto make it “only if they are used as destination IP addresses”. Also, remove the comma. That fixes the sentence as written, but I also agree with Ben’s comment that this might need more significant rewording. — Section 4 — BFD packet MUST be encapsulated and sent to a remote VTEP as explained in this section. This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”. The MAC address MAY be configured, or it MAY be learned via a control plane protocol. Are those the only two choices? As both “MAY” are optional, as written it allows for others. I suggest not using BCP 14 key words here, and instead saying, “The MAC address is either configured or learned via a control plane protocol.” This addresses the scenario when the inner IP destination address is of VXLAN gateway and there is a router in underlay which removes the VXLAN header, then it is possible to route the packet as VXLAN gateway address is routable address. This sentence is too fractured for me to make any sense of it, so I can’t suggest a fix. Please fix it. It looks like Ben made more sense of it than I could, so maybe his suggestion will work. — Section 5 — received VXLAN packet MUST follow the procedures described in Section 4.1 [RFC7348]. This needs to say “Section 4.1 of [RFC7348].”
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2020-09-29 for -14)
Sent
Thank you for the discussions around my discuss point, and the ensuing changes resulting from the discussions! My apologies that I was tardy in re-reviewing after the updates were made. I think the core issues have been resolved, but do have a couple comments on the -14: Section 3 says: Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). Using a BFD session to monitor a set of VXLAN VNIs between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration. An implementation that supports this specification MUST be able to control the number of BFD sessions that can be created between the same pair of VTEPs. [...] While the first two sentences are probably true, they are arguably out of scope for this document, since Section 6 says that BFD control packets on non-management VNI is outside the scope of this specification. The third sentence is quite surprising in the context of this document only defining BFD for the management VNI, since multiple BFD sessions on the same VNI seem redundant. Section 5 Destination MAC: A Management VNI, which does not have any tenants, will have no dedicated MAC address for decapsulated traffic. The value [TBD1] SHOULD be used in this field. While this normative language seems like the appropriate level of stringency, I do find myself wondering what other value might be used and why. (This, of course, need not be answered in the document, though it could be if the answer is known and useful.)
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -09)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-12-10 for -09)
Sent
UPDATE: I didn't not see a reply to the original issue raised by the TSV-ART review (Thanks Olivier!). Please have a lock and provide a response. I don't think this raises discuss level but I think some clarifications would be good! This document describes the use of BFD in VXLAN, however, it does not specify any new protocol elements or extension. Therefore I would expect such a document to be informational. The shepherd write-up doesn't give any additional information about why this doc is PS.
Robert Wilton Former IESG member
No Objection
No Objection
(2020-10-02 for -15)
Sent
Hi, This document seems pretty straight forward to me. A few, non blocking, comments: Assigning a single unicast MAC address seems slightly odd in that it isn't globally unique, but I can't think of any good alternative. At the same time, a service layer BFD session may be used between the tenants of VTEPs IP1 and IP2 to provide end-to-end fault management (this use case is outside the scope of this document). In such a case, for VTEPs BFD Control packets of that session are indistinguishable from data packets. "for VTEPs BFD Control" => "for VTEPS, the BFD Control" Ethernet Header: Destination MAC: A Management VNI, which does not have any tenants, will have no dedicated MAC address for decapsulated traffic. The value (TBD1) SHOULD be used in this field. Source MAC: MAC address associated with the originating VTEP. Should the TypeOrLen field in the Ethernet header also be specified (presumably set to IPv4 or IPv6)? Regards, Rob
Suresh Krishnan Former IESG member
No Objection
No Objection
(2019-12-19 for -09)
Sent
Support Eric's DISCUSS on the IPv6 destination address and would like to see this clarified and resolved.