[nvo3] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06

[Stewart Bryant via Datatracker <[e-mail]>]

Reviewer: Stewart Bryant
Review result: Has Issues

I do not see any boilerplate automatically provided in the review tool, so
assume that the standard RTG-dir boilerplate is here.

The protocol described here is simple and will work. It is well written.

However I do have some concerns about the structure of the document. I think
that the document would be better as either two large sections one describing
the Ethernet payload model and the other describing IP operation, or as an
integrated document (as it is) but with one section describing operation in one
mode and the other describing the differences. The way it is written the reader
has to spend a lot of time looking at the text in adjacent sections/paragraphs
to work out what changed.

Detailed comments:

132     3.  BFD Packet Transmission over Geneve Tunnel

134        Concerning whether the Geneve data packets include an Ethernet frame
135        or an IP packet,
SB> I think that this would be clearer as:
Since the Geneve data packet payload may be either an Ethernet frame or an IP
packet,

                            this document defines two formats of BFD packet
136        encapsulation in Geneve.  BFD session is originated and terminated at
137        VAP of an NVE, selection of the BFD packet encapsulation is based on
138        how the VAP encapsulates the data packets.

SB> I reads better as “The BFD” and “the VAP”

SB> I think that it would help the reader if the authors now summarise what is
about to be described. SB> I think you are saying: If the payload is IP, then
we carry BFD over IP in the payload. If the payload is ethernet then the
Ethernet payload becomes IP regardless of what it might normally carry and we
carry BFD over IP in the same manner as we would carry it in the IP payload
case.

SB> If that was stated (assuming I have it correct) then many readers would
immediately know what follows.

========

193        The BFD packet MUST be carried inside the inner Ethernet frame of the
194        Geneve packet.  The inner Ethernet frame carrying the BFD Control
195        packet has the following format:

197           Ethernet Header:
SB> For clarity that would be better as the "Inner Ethernet Header"

=========

282            Figure 2: Geneve Encapsulation of BFD Control Packet With the
283                                 Inner IP/UDP Header

SB>  I think that this would be a bit clearer if you had a single section
describing the BFD over UDP/IP and then a small section saying how you carry
this directly over Geneve and a sections saying how you carry that UDP/IP over
Ethernet inside Geneve.

===========

319     4.  Reception of BFD packet from Geneve Tunnel

321        Once a packet is received, the NVE MUST validate the packet as
322        described in [RFC8926].

324           If the Protocol Type field equals 0x6558 (Ethernet frame), and the
325           Destination MAC of the inner Ethernet frame matches the MAC
326           address of a VAP which is mapped to the same as received VNI, then
327           the Destination IP, the UDP destination port and the TTL or Hop
328           Limit of the inner IP packet MUST be validated to determine
329           whether the received packet can be processed by BFD.

331           If the Protocol Type field equals 0x0800 (IPv4) or 0x86DD (IPv6),
332           and the Destination IP of the inner IP packet matches the IP
333           address of a VAP which is mapped to the same as received VNI, then
334           the UDP destination port and the TTL or Hop Limit of the inner IP
335           packet MUST be validated to determine whether the received packet
336           can be processed by BFD.

SB> This is technically correct, but again it might be simpler for the reader
to have common text and a difference text.

========

369     5.  Security Considerations

371        Security issues discussed in [RFC5880], [RFC5881], and [RFC8926]
372        apply to this document.

SB> Does the GTSM security mechanism called up in RFC5881 do anything for you?
SB> The key security mechanism is that BFD has to arrive inside a Geneve packet.
SB> I think the security actually comes from RFC8926 i.e. Geneve itself. The
BFD is then a payload that is carried securely between peers just like any
other payload. If the peers cannot trust each other all bets are off. The
security discussion is RFC5880 and RFC5881 are for when BFD is openly carried
across the network, and as far as I can see add no particular value here.

SB> So I think that you can say (in the correct parlance) that BFD is an
application that is run at the two ends of the Geneve connection within the
equipment running Geneve. Geneve provides security between the peers, and
subject to the issue of overload described below, BFD introduces no security
vulnerabilities when run in this manner.

374        This document supports establishing multiple BFD sessions between the
375        same pair of NVEs, each BFD session over a pair of VAPs residing in
376        the same pair of NVEs, there SHOULD be a mechanism to control the
377        maximum number of such sessions that can be active at the same time.
SB> I think that text needs to be expanded a bit, because this is a new threat
and is possibly the biggest threat to the operation of this system.