Re: [Int-area] Comments on draft-ietf-intarea-gue-07 (and fllow-up from last IETF meeting)

[Tom Herbert <[e-mail]>]

Hi Gorry,

Thanks for the reply. I will reply to comments in time. However, I
would note that some number of the comments are more about UDP
encapsulation than GUE specifically. draft-ietf-rtgwg-dt-encap-02
provides a good description of considerations for UDP encapsulation
(including NAT handling, middleboxes, next protocol header indication,
etc.). We'll add a reference for this in the draft.

Tom

On Wed, Mar 13, 2019 at 9:08 AM Gorry Fairhurst <[e-mail]> wrote:
>
> So thanks for your clarifications. I read this draft because an early
> review was requested, and the purpose of an early review is often to
> judge where more work may be needed, or whether there may be issues if a
> formal review for IETF-LC were made. I think there are issues.
>
> In places the comments are a little general - but they show the places
> where I would dig if I did a detailed reveiw, and should help you
> prepare a better draft.  Some replies are in-line, but likely I will
> await the next revision before commenting on the entire draft again.
>
> My comment concerning applicability are more difficult to write in word, so to set the scene:
>
> I think there are many things that can be run over UDP. Some of these are useful
> to standardise in the IETF, often for interoperability reasons, and one of the more
> difficult jobs for a WG to figure out is how to "limit" the scope of a proposal
> to help achieve useful operational, security or more interop implementation. I'm
> not sure how far the WG scoped this particular draft (i.e. who else
> is needing the spec besides the implementor) and what The WG decided to
> add or remove over the years - others in INTAREA will know that better than me
> (and maybe in NVO03 - perhaps things have been refined since NVO3).
> I think it would be helpful to understand this.
>
>
> On 11/03/2019, 18:01, Tom Herbert wrote:
> > Hi Gorry,
> >
> > Thanks for the comments. Some replies inline.
> >
> > On Mon, Mar 11, 2019 at 2:40 AM Gorry Fairhurst<[e-mail]>  wrote:
> >>
> >> 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.
> >>
> > The [GUEEXTEN] reference is incorrect in the version 7. This should
> > refer to draft-ietf-intarea-gue-extensions-06 which is a WG item.
> >
> >> 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.
> >>
> > As I said, reference is incorrect. It will be fixed in next version.
> >
> GF: I suspect both documents will need reviewed together.
>
> >> The security issues relating to this document seem to be partly in
> >> another non-working-group document.
> >>
> > draft-ietf-intarea-gue-extensions-06 defines security options and
> > security payload transforms (i.e. DTLS).
> >
> I was aware of those - but this document does not discuss other security
> considerations concerned with teh mechanisms in this document.
> >> I would expect the fate of these other documents needs to be decided
> >> before the present document progresses.
> >>
> > Right, all normative references are RFCs or the WG item.
> They were not, if this is fixed, the document is improved.
> >> (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.
> > Again see draft-ietf-intarea-gue-extensions-06. That defines eight
> > initial options. The protocol is extensible, however beyond the
> > initial set of options I would expect at most one new option to be
> > introduced every couple of years. Note this is markedly different from
> > a protocol like Geneve that has a 24 bit TLV space allowing thousands
> > of option (including proprietary options),and as AFAICT haven't
> > proposed a single one as standard.
>
> > GUE is implemented and in deployment.
> > It has been in upstream Linux since 2014.
> Has it also been implemented on other OS/platform? (i.e. what does it
> interop with?)
> - this is really helpful to understand.
> >> --
> >>
> >> 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.
> >>
> > This is a very general comment. Can you give a specific pathological
> > case not properly handled by the protocol?
> How do you know there are none?
> >> 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).
> >>
> > Tunnels and encapsulation are separate concepts in the draft. Section
> > 5.1 defines network tunnels. We can add definition in the terminology
> > section of 1.2.
> I read the draft, and made the comment.
> > Exactly where is the draft misquoting RFC1122?
> Does it default to using a checksum?
> > Exactly how is this incompatible with RFC6935 (note David's point was
> > that the protocol needs to show how requirements of RFC6935 and
> > RFC6936 are met).
> Relating to RFC6935 - there were a set of requirements for IPv6 usage,
> and I expected this to be clearly explained and asserted that hosts can
> not just disable the checksum and then encapapsulate a transport, etc.
> >> 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.
> >>
> > Again, a very general comment for which it is hard to provide a
> > specific response. GUE has been discussed in depth in two working
> > groups and in being run in the wild for a while. For instance, if this
> > is just "another way of doing many things, many of which are already
> > specified in existing RFCs", then my question is what exactly are
> > those RFCs? Note that section 6 gives a comparison with similar
> > protocols and describes differentiating features.
> Yes this was the sction that generated this comment. It seems that if we
> need a new PS we should be very clear why people are not encoraged to
> use the existing PS that have been specified.
>
> I do encourage you not to call the, "proposals" when they marked as
> PS in the RFC series.
>
> This didn't appear necessarily as an advantage to me: "
>
> GUE permits encapsulation of arbitrary IP protocols, which
>          includes layer 2 3, and 4 protocols." :-)
>
> Is the claim:
>   GUE provides a uniform and
>          extensible mechanism for encapsulating all IP protocols in UDP
>          with minimal overhead (four bytes of additional header).
>
> Is saving a  few bytes so important? I'm curious also about how this
> interacts with offload, and I think you have quite some experience here.
>
> The same as the next:
> "
>
> GUE is extensible. New flags and extension fields can be
>          defined."
>
>
> You say multiplexing different protocols over the same port is a
> feature. I'm sure this does not come without issues - can you elaborate
> these please?
>
> If this is the target usage:
> "
>
>    o The GUE header includes a header length field. This allows a
>          network node to inspect an encapsulated packet without needing
>          to parse the full encapsulation header.
>
> "
> I'd also comment that the spec is pretty wide-ranging and complex so are
> you really saying this is the designed usage?
>
> I'd have expected this to have raised some security concerns.
>
> "
>
>        o Private data in the encapsulation header allows local
>          customization and experimentation while being compatible with
>          processing in network nodes (routers and middleboxes).
>
> "
> - I'd have expected this to have raised at least some security concerns.
>
> "
>
>   GUE includes a variant that encapsulates IPv4 and IPv6 packets
>          directly within UDP.
> "
> Well - it just places the packets in UDP payloads. How would ICMP messages be handled? How are extension headers handled?
> Etc.
>
> So, I'm objecting  to simply listing lots of RFCs and they saying yours is different.
>
>
> >> 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?
> > IMO, they're actually quite simple to allow variable length fields.
> > The example in the draft is:
> >
> >   "Two flag bits are paired, a field can possibly be three different
> > lengths-- that is bit value of 00  indicates no field present; 01, 10,
> > and 11 indicate three possible lengths for the field."
> >
> > This is used in the security extension field described in
> >
> > The values in the SEC flags are:
> >        o 000b - No security field
> >        o 001b - 64 bit security field
> >        o 010b - 128 bit security field
> >        o 011b - 256 bit security field
> >        o 100b - 320 bit security field (HMAC)
> >        o 101b, 110b, 111b - Reserved values
> Ahhh - So do you mean the "paired" bits form a 2-bit field?
> >> 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?
> > That was comment David also made. The point will be clarified.
> >
> >> - 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.
> > In this case GUE is carrying IP protocol. Per RFC 8085 congestion
> > control is generally assumed when encapsulation carries an IP
> > protocol.
>
> > Technically, GUE always carries an IP protocol (as opposed
> > to GREoUDP that carries an EtherType).
> Dies the Spec say this explicitly - please also discuss in the security
> considerations.
> >   The congestion considerations
> > in GUE are to cover cases where GUE would carry something like EtherIP
> > or GRE.
>
> > Those can be  encapsulations of non-IP protocols hence should
> > have their own congestion considerations,
> Ah I thought so, and how will this be handled?
> > however neither RFC2784 nor
> > RFC3378 mention congestion. I think it is valuable to have congestion
> > considerations in this doc to cover those cases.
> >
> >> 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.
> >>
> > An example can be added should a simple TCP/GUE and the pseudo header
> > for TCP checksum calculation.
> And does that introduce issues with NAT or NAPT and how do you handle
> MSS etc across this sort of encaps?
> >> * 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]."
> >>
> > This is referring to receiver processing. It is allowed by requirement
> > in RFC1122:
> >
> > "An application MAY optionally be able to control whether UDP
> > datagrams without checksums should be discarded or passed to the
> > application".
> That is allowed. For an endpoint, the app is permitted to decide
> whether datagrams are passed to the application when there is
> a zero checksum. How does GUE handle this request?
> >> 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.
> >>
> > David made same comment, it will be addressed in next draft version.
> >
> >> * 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.9 is mistitled, it should be " Congestion Considerations".
> > It is based on section 8 in RFC8086 (GRE-UDP). More text can be
> > imported from RFC8086 if it helps to clarify.
> Please consider carefully the applicability. Are you going to change to
> an applicability statement of only to be used in controlled environments?
> >> * 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.
> >>
> > Which section are you referring to (there is no section 5.8.2).
> >
> I suspect I intended 5.7.2 - but you already said you would update.
>
> >> "The GUE header checksum (in version 0x0) provides a UDP-lite
> >> [RFC3828] type of checksum capability as an optional field of the
> >> GUE header."
> Is that wise?
> >> Endpoint - NAT
> >>
> >> * Section 5.7
> >> - This seems about NAT. Is this appropriate?
> >>
> > 5.7 is about UDP checksum. NAT opertation with UDP checksums is
> > unaffected by use of GUE.
> >> Fragmentation
> >>
> >> - Elsewhere in the IETF fragmentation has been described as fragile, why
> >> is it safe in this spec?
> >>
> > You interchanged the concepts of  "fragile" and "not safe"
> Not really.
> > -- they are
> > not equivalent. draft-ietf-intarea-frag-fragiledescribes how IP
> > fragmentation is fragile in the Internet. This is because IP fragments
> > are often dropped by intermediate nodes.
> And serious attacks can be made against the reassembly engine. There is
> also a quetsion of how much capabiluity your remote receiver is expected
> to supply - what range of fragements and how many outstanding frag/packets
> it needs to support so that the encaps knows the network reordering and loss
> etc are compatible with how it is fragmenting.
> > Fragmentation in an
> > encapsulation is hidden to intermediate nodes so for that reason it
> > may be more deployable (for instance, ECMP works better with GUE
> > fragmentation than IPv4 fragmentation).
> That also is true.
> > As for being safe, it is as
> > safe as any other fragmentation and DOS mitigations for fragmentation
> > learned over the years are applicable. The GUE fragment header also
> > has a larger ID field to avoid the problem that was seen in IPv4.
> The poblem - was that wrap of the ID space?
> >
> >> * 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.
> >>
> > They are very different. UDP-options are being defined as part of the
> > transport layer to allow fragmentation of packets for a UDP
> > application.
> Yes. The application could be a tunnel, but that is also the transport.
> > GUE does fragmentation in the encapsulation layer and
> > addressed the problems of tunnel fragmentation described in RFC4459.
> > UDP options have nothing to do with tunnels.
> I do not know if the authors think this.
> > I'd also point out that
> > UDP options are very preliminary, there is no deployment and it has
> > yet to be proved if they are even deployable.
> >
> >> * 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?
> >>
> > They can be logged, will add text.
> OK
> >> 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."
> >>
> > Yes, only 0 to 127 are IANA assigned. Types 129 to 255 are site local.
> >
> Site-local may not be the correct term? If you expect two endpoints to
> agree,
> but I understand they are not IANA assigned.
> >
> >> * 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?
> I'd encourage to review that text to rephase that MUST as something
> other than a requirement.
> >> * 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?
> I'd encourage to review that text.
> >> * 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.
> I'm objecting again to simply listing lots of RFCs and they saying yours
> is different,
> this does not represent a clear statement of the problem that this
> particular draft is trying to solve.
> >> ----------------
> >>
> >> 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 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area
>
> At the end of this, I now conclude there are transport-related issues
> that would need to be addressed. Thanks again for your helpful replies,
>
> Gorry
>