Subject: Roman Danyliw's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 18:01:33 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-bfd-vxlan-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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/

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Dec 2019 08:28:40 -0800

Hi Roman,
thank you for your review, detailed questions, and helpful suggestions. All
editorial changes applied to the working version of the document. Please
find my answers in-line below tagged GIM>>.

Best regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
GIM>> The scenario we've considered is when a VXLAN tunnel is broken. A
packet that is not using an address from the loopback range (or from
IPv4-mapped addresses for that range for IPv6) may be routed and TTL or Hop
count will be zeroed on the next node. The impact likely to be noticed on
the control plane. Would you agree?

> please clarify how the throttling should be calibrated.
GIM>> I think that it is very much implementation-specific. For example, an
implementation may throttle control packets per BFD session or use a more
aggregate approach. On the other hand, intervals at which BFD Control
packets being transmitted and received play some role in selecting the
throttling limits.

> assuming you don’t mean RFC2119, RFC8174, etc.)
GIM>> Thank you for pointing to this ambiguity. The updated text:
   Other than inner IP TTL set to 1 and limit the number of BFD sessions
   between the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348].
Would it address your concern?