[Int-area] Comments on draft-ietf-intarea-gue-07 (and fllow-up from last IETF meeting)
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 11 March 2019 09:40 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115AE1310C7 for <int-area@ietfa.amsl.com>; Mon, 11 Mar 2019 02:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWBpf350MjiL for <int-area@ietfa.amsl.com>; Mon, 11 Mar 2019 02:40:08 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id ED115131063 for <int-area@ietf.org>; Mon, 11 Mar 2019 02:40:07 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (unknown [86.111.164.170]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 16F841B0007C; Mon, 11 Mar 2019 09:40:04 +0000 (GMT)
Message-ID: <5C862CF3.6090103@erg.abdn.ac.uk>
Date: Mon, 11 Mar 2019 09:40:03 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: int-area@ietf.org
CC: gorry Fairhurst <gorry@erg.abdn.ac.uk>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/dGndnXhHuxUgQyO-yJthdNQihFE>
Subject: [Int-area] Comments on draft-ietf-intarea-gue-07 (and fllow-up from last IETF meeting)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 09:40:19 -0000
I've just looked at draft-ietf-intarea-gue-07again and have a few comments: First, I spoke at the Mic in INTEAREA last IETF meeting, and I then had a few serious concerns about this draft: (1) References. This ID is incomplete because it relies on what appears to be abandoned work for important details. It does not really talk about the security and deployment concerns, or the extensions that are required to implement this. Instead, it points to a set of expired drafts (at least one expired in 2015). I do not believe these dependent drafts are mature. As far as I know they have not been adopted by a working group and have no status - at the very least these need to be adopted, or appropriate parts incorporated. This is still the case. I suggest it is bad practice to require mechanisms in a PS that are informative references, especially ones that are not adopted. e.g. draft-herbert-transportsand this needs working group review. The security issues relating to this document seem to be partly in another non-working-group document. I would expect the fate of these other documents needs to be decided before the present document progresses. (2) I could not understand why this is a “PS”? I suggest that the proposal could be too flexible and extensible to be usefully standardised and demonstrated to interoperate. If this is a “PS”, I would like to be sure that all the functionality described is unambiguous, has been implemented somewhere and is really needed. There are many points of extensibility and likely many issues that will be raised as these extensions emerge. I do not grasp why we need to specify all these possibilities at this time, with no future use identified. -- As David noted in his recent TSV ART Review, from a transport perspective, there are some more major issues. My thoughts on this should be probably read as additional comments following David's review: Tunnels & Endpoints There are concerns because of the wide applicability of various combinations of features. Overall, this flexibility makes it hard to analyse this extensible framework from a transport perspective. At some point I stopped trying to follow the various pathologies that can arise with different combinations of use (so I think there are more issues). I am therefore surprised that this is being proposed as a "PS", because it seems there are at least likely to be unknowns and very likely applicability concerns. I think there are serious issues that emerge because the method lumps tunnels and endpoint encapsulation together. One example is that there is insufficient specification of how congestion collapse is to be avoided, when acting as an endpoint for a non-congestion controlled payload (section 5.9 does not address congestion control). Another is the mis-use of the zero checksum text in 5.7.1 (a misquotation of the spec. RFC1122 states in 4.1.3.4, and incompatible with RFC6935). This is another way of doing many things, many of which are already specified in existing RFCs - albeit with some extra (and interesting) features and a lot more flexibility. The disadvantage is that by widening the applicability it is less clear on the implications of specific techniques and could itself be extended in arbitrary directions. I think the IETF should consider this when determining what to do with this document, and seek to understand why we need interoperability standards in this area. Also: * Section 3.3.1 I do not understand the operation of the paired flags. I suggest that some combinations can result in significant complexity - is this something that the WG has considered, and what do they think about this? e.g.: " Flags can be paired together to allow different lengths for an extension field. " * I do not understand this statement: " If a decapsulator receives a GUE packet with private data, it MUST validate the private data appropriately. " - How does it do that, or what does "appropriately" mean? What are the costs, and the issues if verification fails? - How does the receiver know this is being done? (If we don't standardise it, then why would need to specify it in a RFC?) "An implementation MAY place security data in GUE private data which if present MUST be verified for packet acceptance." * Section 4: " Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP." - How is congestion control handled in this case, I expected text on the congestion safety of this approach for use in different scenarios, but found none. Endpoint checksum v Tunnel Checksum Section 4: Variant 1: This variant appears to be a tunnel that places a packet directly in a UDP packet. * Section 5.2 seems way under-specified with respect to the pseudo-header calculation. This could be contained in anothe ID, I did not check, because I suggest it needs to be in this particular document. * Section 5.7.1: "By default, a decapsulator SHOULD accept UDP packets with a zero checksum. A node MAY be configured to disallow zero checksums per [RFC1122]." I read this is as a misquotation of the spec. RFC1122 states in 4.1.3.4 that: "An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on." - Instead, I read RFC 6935 for IPv6 explicitly stating: "As an alternative, certain protocols that use UDP as a tunnel encapsulation MAY enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode MUST follow the node requirements specified in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]." - I do not yet understand how GUE can safely vary this. The text is insufficient. * Section 5.9 This states " 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 [RFC5405]. Note that this case applies to a significant use case in network virtualization in which guests run third party networking stacks that cannot be implicitly trusted to implement conformant congestion control." It then states: "Out of band mechanisms such as rate limiting, Managed Circuit Breaker [RFC8084], or traffic isolation MAY be used to provide rudimentary congestion control. " This may be just lack of clarity in the text, but I think thisseems like a "magic trick" to escape doing congestion control. - which may be heading in a good direction, but really does not address the issue. This is particularly worrying since 5.10 actually describes the use of the method for multicast, broadcast etc, but still has no explanation of how to provide prevent congestion collapse. I think the following statement is currently flawed and needs more clarity: "For finer-grained congestion control that allows alternate congestion control algorithms, reaction time within an RTT, and interaction with ECN, in-band mechanisms might be warranted." - I think this needs to be removed and replaced by something that is more specific. I'm concerned the interaction with ECN seems under-specified (or perhaps should be removed - or at least be replaced with a mechanism that has IETF consensus). * Section 5.8.2 - I would like to see discussion on whether 5.8.2 is safe or unsafe. I do not know how the integrity will be managed. "The GUE header checksum (in version 0x0) provides a UDP-lite [RFC3828] type of checksum capability as an optional field of the GUE header." Endpoint - NAT * Section 5.7 - This seems about NAT. Is this appropriate? Fragmentation - Elsewhere in the iRTF fragmentation has been described as fragile, why is it safe in this spec? * GUE level fragmentation is mentioned, and interesting as a concept. However, there is so much discussion of IPv6 fragments that I think this needs detailed consideration by the WG. It also directly competes with the TSVWG work on UDP-Options, albeit the IETF can decide to do two more methods that both use UDP, but I'd hope that if it specified either, it would carefully consider the issues in accepting fragments at a receiver. * 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, ..." - Does that imply silently discarded, why not logged? Other comments: "If a received GUE packet in IPv6 contains a protocol number that is an extension header (e.g. Destination Options) then the extension header is processed after the GUE header is processed as though the GUE header is an extension header." * Section 3.2.2 I do not understand the intended IANA allocation method: " Control messages will be defined in an IANA registry. Control message types 1 through 127 may be defined in standards. " - What is the difference between the two use below, and why are they separately mentioned? Are these differentiated in the registry?> " Types 128 through 255 are reserved to be user defined for experimentation or private control messages." * Section 3.4. I don't understand the normative MUST, it could just be that this just a truism, that a receiver can not use data that it does not understand? * Section 5.4: "Such events MAY be logged subject to configuration and rate limiting of logging messages. " - I don't understand the MAY here. I could see why "REQUIRED" or "RECOMMENDED" is stated for operational reasons. - Why is rate limiting only permitted by a "MAY" - should that be required or recommended? * This is another way of doing many things that are specified in existing RFCs - albeit with some extra features and a lot more flexibility. Section 6.2 - This is an alternative proposal to using existing IETF specifications. It states: "A number of different encapsulation techniques have been proposed for the encapsulation of one protocol over another." ... - What follows is mainly a list of PS specifications from IETF, not proposals. And states: "Several proposals exist for encapsulating packets over UDP including ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN [RFC7348], LISP [RFC6830] which encapsulates layer 3 packets, MPLS/UDP [RFC7510], GENEVE [GENEVE], and GRE-in-UDP Encapsulation [RFC8086]." - Many of these are PS specifications from IETF, not proposals. If the WG thinks another spec is needed, this should not regard the existing PS as "proposals", but clearly differentiate the benefits of the new approach. ---------------- If this document is to be published, I would expect it needs significant changes and I would say this would certainly require a much more detailed transport review together with the other drafts that form a part of the spec. Best wishes, Gorry
- [Int-area] Comments on draft-ietf-intarea-gue-07 … Gorry Fairhurst
- Re: [Int-area] Comments on draft-ietf-intarea-gue… Tom Herbert
- Re: [Int-area] Comments on draft-ietf-intarea-gue… Gorry Fairhurst
- Re: [Int-area] Comments on draft-ietf-intarea-gue… Tom Herbert