Re: Alvaro Retana's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Alvaro,
thank you for your thorough review, detailed questions, and helpful
suggestions. Please find answers in-line below under GIM>> tag.
Also, attached is the diff to highlight all the updates in the current
working version of the draft.

Regards,
Greg

On Tue, Dec 17, 2019 at 9:57 AM Alvaro Retana via Datatracker <
[e-mail]> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I support Eric's DISCUSS point about the TTL, but I want to go a step
> further
> because this document contradicts rfc5881, which is clear about the TTL
> setting
> (from §5):
>
>    If BFD authentication is not in use on a session, all BFD Control
>    packets for the session MUST be sent with a Time to Live (TTL) or Hop
>    Limit value of 255.  All received BFD Control packets that are
>    demultiplexed to the session MUST be discarded if the received TTL or
>    Hop Limit is not equal to 255.  A discussion of this mechanism can be
>    found in [GTSM].
>
>    If BFD authentication is in use on a session, all BFD Control packets
>    MUST be sent with a TTL or Hop Limit value of 255.  All received BFD
>    Control packets that are demultiplexed to the session MAY be
>    discarded if the received TTL or Hop Limit is not equal to 255.  If
>    the TTL/Hop Limit check is made, it MAY be done before any
>    cryptographic authentication takes place if this will avoid
>    unnecessary calculation that would be detrimental to the receiving
>    system.
>
> OTOH, Section 4 of this document specifies:
>
>      TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
>      packet is not routed within the Layer 3 underlay network.  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.
>
> Not wanting the packet to be routed in the underlay sounds like a
> reasonable
> justification -- but I couldn't find the specification in rfc7348 about "a
> router in underlay which removes the VXLAN header".  Maybe I missed it...
>
GIM>> You're right, RFC 7348 does not describe what may be referred to as
Penultimate VXLAN termination. We've received the information about the
scenario described in Section 4 (the quote above) from one of the experts
well-familiar with VXLAN deployments and an existing BFD over VXLAN
implementation that sets IP TTL to 1 for BFD control packets.

>
> Independent of VXLAN, the conflict with rfc5881 remains -- given the text
> above, it seems to me that it would be ok if the TTL was set to 1 if
> authentication is is use, but this document doesn't talk about requiring
> authentication.
>
GIM>> You're right, BFD authentication is not dicussed in this document. In
VXLAN's Security Considerations section has been noted that a traditional
security mechanism, e.g., IPsec, may be used to authenticate and/or encrypt
VXLAN traffic. Perhaps the same should be said about BFD over VXLAN. For
example, text below may be added to Section 9:

A BFD over VXLAN session MAY be secured by using a traditional
security mechanism, e.g. IPsec, that authenticates and/or encrypts
VXLAN traffic.


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I also support Ben's DISCUSS.
>
> Non-blocking comments:
>
> (1) §3: "...a service layer BFD session may be used between the tenants of
> VTEPs IP1 and IP2..."   Just to be clear, the use of BFD in a "service
> layer
> session" is out of scope of this document, right?  It might be nice to say
> so.
>
GIM>> Agree. Will the following update be acceptable:
OLD TEXT:
   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.
NEW TEXT:
   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).

>
> (2) §3: "As per Section 4, the inner destination IP address SHOULD be..."
> If
> the specification is already in Section 4, then there doesn't seem to be a
> need
> to repeat it.  It might make more sense to put the text about a potential
> firewall there.
>
GIM>> Resulting from addressing comments by other reviewers this text now
reads as:
   For BFD Control packets encapsulated in VXLAN (Figure 2), the inner
   destination IP address SHOULD be set to one of the loopback addresses
   from 127/8 range for IPv4 or to one of IPv4-mapped IPv4 loopback
   addresses from ::ffff:127.0.0.0/104 range for IPv6.  There could be a
   firewall configured on VTEP to block loopback addresses if set as the
   destination IP in the inner IP header.  It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if they are
   used as the destination IP addresses in the inner IP header and the
   destination UDP port is set to 3784 [RFC5881].
Do you think it is more clear and acceptable form?

>
> (3) §4: "...SHOULD ensure that the BFD packets follow the same lookup path
> as
> VXLAN data packets within the sender system."  What is a "lookup path"?
> When
> would it be ok to not ensure it?  BTW, a better Normative statement might
> me
> (something like): MUST follow the same lookup path...
>
GIM>> Would s/lookup/forwarding/  be acceptable? On your suggestion to
strengthen the normative language, RFC 5880 notes that the ability to
monitor a forwarding engine with BFD is only "to the extent possible". That
is why we've decided to us SHOULD rather than MUST.

>
> (4) §4: "The MAC address MAY be configured, or it MAY be learned via a
> control
> plane protocol. The details of how the MAC address is obtained are outside
> the
> scope of this document."  The Normative MAYs are really just stating a
> fact,
> and out of scope any way.  s/MAY/may
>
GIM>> Agree.
         The MAC address may be
         either configured or learned via a control plane protocol.

>
> (5) §5: "If the Destination MAC of the inner Ethernet frame doesn't match
> any
> of VTEP's MAC addresses, then the processing of the received VXLAN packet
> MUST
> follow the procedures described in Section 4.1 [RFC7348]."  §4.1 of
> rfc7348 is
> about Unicast VM-to-VM Communication -- which makes me think that if the
> procedures from that section are followed then the BFD packet may be
> forwarded
> to a VM, which seems to be in contradiction with this statement (from §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."  What am I missing?
>
GIM>> In the preceding sentence we've tried to emphasize that a BFD packet
MUST use one of MAC addresses associated with VTEP:
   If the
   Destination MAC of the inner Ethernet frame matches one of the MAC
   addresses associated with the VTEP the packet MUST be processed
   further.
The next sentence (your quote) is to state that tenant packets (MAC address
is not of VTEP) MUST be processed as per VXLAN specification.

>
> (6) Related to the last point, the following sentences also mention that
> BFD
> packets MUST NOT be forwarded to VMs...but with qualifications:
>
> §5: "If the BFD session is using the Management VNI (Section 6), BFD
> Control
> packets with unknown MAC address MUST NOT be forwarded to VMs."
>
> §6: "All VXLAN packets received on the Management VNI MUST be processed
> locally
> and MUST NOT be forwarded to a tenant."
>
> The difference between these 2 statements and the one from §3 is that they
> seem
> to be intended only when using the Management VNI...but it would seem that
> the
> general statement applies there too, right?  IOW, the specific statements
> about
> the Management VNIs are simply affirming what was already said more
> generally
> in §3, right?
>
GIM>> Yes, your understanding is absolutely correct.

>
> (7) Nits:
>
> s/of VXLAN gateway and there is a router in underlay/of the VXLAN gateway
> and
> there is a router in the underlay
>

> s/VTEP MUST validate/the VTEP MUST validate
>
> s/then BFD session/then the BFD session
>
GIM>> Done. Thank you.