Reviewer: David Black Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. GUE is a new generic UDP encapsulation that is intended to provide a common widely applicable encapsulation mechanism that can displace a variety of more specific encapsulation mechanisms. The draft is well written and has a number of clever ideas, e.g., use of the first two bits of the IP version number to define GUE variant 1 without including a GUE header. I found three major issues and a number of minor issues. I apologize for the delay in this review courtesy of a day-job crisis and being one of the recipients of the second round of the flu in the eastern US. --- Major --- [1] IPv6 zero checksum 5.7.3: In IPv6, there is no checksum in the IPv6 header that protects against mis-delivery due to address corruption. Therefore, when GUE is used over IPv6, either the UDP checksum or the GUE header checksum SHOULD be used unless there are alternative mechanisms in use that protect against misdelivery. The UDP checksum and GUE header checksum SHOULD NOT be used at the same time since that would be mostly redundant. If neither the UDP checksum nor the GUE header checksum is used, then the requirements for using zero IPv6 UDP checksums in [RFC6935] and [RFC6936] MUST be met. I don't think the second paragraph works, because it imposes design requirements on the encapsulated protocol to protect the GUE header when one cannot in general expect design of that protocol to anticipate GUE encapsulation. My initial suggestion is to change the first "SHOULD" in the first paragraph to a "MUST" but even that may not meet RFC 6936's requirements. In any case, please read RFC 6936 in detail, and explain how GUE meets RFC 6936's requirements - in general it is not sufficient to require to just state that they have to be met because some of the requirements are protocol design requirements that GUE has to meet. [2] Tunnels Section 5.8 needs to normatively reference draft-ietf-intarea-tunnels and be revised accordingly, e.g., as that draft will update RFC 4459. [3] Congestion control Section 5.9: In the case that the encapsulated traffic does not implement any or sufficient control, or it is not known whether a transmitter will consistently implement proper congestion control, then congestion control at the encapsulation layer MUST be provided per [RFC8085]. Ok, that text has the right overall view, but I question whether this "MUST" requirement is implementable in practice based on the brief discussion in this section. --- Minor --- [A] 3.2.2. Ctype field: This document does not specify any standard control message types other than type 0. Type 0 does not define a format of the control message. Instead, it indicates that the GUE payload is a control message, or part of a control message (as might be the case in GUE fragmentation), that cannot be correctly parsed or interpreted without additional context. Hmm - seems to be a lot of "trust us" in this text. What does this text add over and above the first paragraph in this section? The quoted paragraph does not by itself appear to specify anything that interoperates. [B] 3.3.1. (Flags and extension fields) Requirements: Extension fields are placed in order of the flags. New flags are to be allocated from high to low order bit contiguously without holes. That is not mentioned in the IANA considerations. How will that be enforced? [C] 3.4. Private data: If a decapsulator receives a GUE packet with private data, it MUST validate the private data appropriately. What does "appropriately" mean? In other words, how a protocol designer or implementer determine whether the "MUST" requirement has been complied with? [C] 5.3. Encapsulator operation: For instance, if an IP packet is being encapsulated in GUE then diffserv interaction [RFC2983] and ECN propagation for tunnels [RFC6040] SHOULD be followed. That's close, but not what needs to be said. RFC 2983 is informative - it should be referenced as a useful source of design guidance without using an RFC 2119 keyword. The quoted text requires that RFC 2983 be normatively referenced, which is unlikely to be what was wanted (NB: I'm the author of RFC 2983). In contrast, the RFC 6040 requirement ought to be a "MUST" requirement, not a "SHOULD" requirement. [D] 5.11.1. Flow classification: This discussion of IPsec headers (AH and ESP) needs to reference the relevant IPsec RFCs. In addition, some more discussion on how AH transport mode works is needed, as the GUE receiver does some header processing *before* the IPsec AH transport mode processing that includes header checks. That appears to merit mention in security considerations. [E] Section B.1 on privileged ports appears to contain a security consideration that should be included in the security considerations section --- Editorial --- Section 5.1: Network tunneling can be achieved by encapsulating layer 2 or layer 3 packets. Should explain what layer 2 and layer 3 mean. GUE encapsulation of layer 3 packets is directly provided by GUE variant 1, but how is GUE intended to provide (or how could GUE provide) encapsulation of layer 2 packets? Adding an example will suffice. Section 5.2: When encapsulating layer 4 packets, Say a few words on how this is done, e.g., protocol nubmer for UDP or TCP in GUE variant 0. Section 5.4: Note that set flags in a GUE header that are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is received by a decapsulator with unknown flags, the packet MUST be dropped. This should be stated in Section 3.3.1 also as part of explaining how GUE flags work.
