Heads-Up: On this, I fear we do not agree. I think there are serious issues - I will send an email summarising what I said at the Mic in IntArea last meeting and we should perhaps then talk. Gorry > On 9 Mar 2019, at 02:24, David Black via Datatracker <noreply@xxxxxxxx> wrote: > > 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. > > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art
