[RTG-DIR] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
Stewart Bryant via Datatracker <noreply@ietf.org> Fri, 05 August 2022 11:08 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8AC157B57; Fri, 5 Aug 2022 04:08:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Stewart Bryant via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-nvo3-bfd-geneve.all@ietf.org, nvo3@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165969771901.55335.13917159119419478173@ietfa.amsl.com>
Reply-To: Stewart Bryant <stewart.bryant@gmail.com>
Date: Fri, 05 Aug 2022 04:08:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/IwWXmViTh7LGnV0Nl4h1L3Wd5u0>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-nvo3-bfd-geneve-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 11:08:39 -0000
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.
- [RTG-DIR] Rtgdir early review of draft-ietf-nvo3-… Stewart Bryant via Datatracker
- Re: [RTG-DIR] [nvo3] Rtgdir early review of draft… xiao.min2
- Re: [RTG-DIR] [nvo3] Rtgdir early review of draft… xiao.min2
- Re: [RTG-DIR] [nvo3] Rtgdir early review of draft… xiao.min2
- Re: [RTG-DIR] [nvo3] Rtgdir early review of draft… Stewart Bryant