Subject: [nvo3] Review ptB Editorial: draft-ietf-nvo3-gue-04

From: Bob Briscoe <[email-masked]>
Date: Sat, 13 Aug 2016 14:26:06 +0100

Tom, Lucy, Osama,

A) Technical Review of GUE 'As-is'
B) Editorial Review        <--- This email
C) Redesign of parts of GUE

*B/ EDITORIAL PROBLEMS**
*

*1/ Problem**/Motivation?
***Although I said earlier "Don't unnecessarily constrain your protocol 
design solely to the use-case(s) you have in mind," the draft doesn't 
actually do a good job of describing the problems it does aim to solve. 
It could (at least) refer forward to section 6 on Motivation from the 
Introduction.

Also section 6 on "Motivation" doesn't do a good job of saying which 
problems other related protocols solve that GUE doesn't, or vice versa. 
Perhaps you could at least tabulate whether GUE satisfies the 
requirements in draft-ietf-nvo3-dataplane-requirements, altho I think 
the remit of GUE has become wider than NVO3.

Use-cases I found in the draft (not all clearly identified in the same 
place):
* Flow ID entropy for atypical/new protocols over IP (but see A4.9/ in 
my technical review email which questions this claim);
* Maximize deliverability of atypical/new protocols over IP (but see 
caveat below);
* Encapsulation of standardised optional data such as a virtual network 
ID, security data;
* Encapsulation of private-use / experimental optional data;
* Tunnel control messaging;

Additional use-cases not identified in the draft:
* Endpoint control of path diversity (e.g. for MPTCP to create multiple 
paths between the same pair of IP addresses)
* potential as a "path layer" (see PLUS/SPUD)
* IPv6 extensibility (see 2.4/ "GUE: a potential solution to the IPv6 
extension header discard problem" in my separate email).

Deliverability caveat: GUE encapsulation both helps and hinders 
deliverability.

             X) muddlebox    Y) meddlebox
a) Atypical protocols       Better      No worse
b) Atypical TCP options     Better      Worse, or no better

Legend:
   a) new/atypical protocols over IP (e.g. SCTP, DCCP) or
   b) new options in existing protocols over IP (e.g. new TCP options)
   X) muddlebox: NATs, performance enhancers, etc. that unintentionally 
discard atypical protocols;
   Y) meddlebox: security functions, e.g. firewalls, Web filters, that 
intentionally discard incoming UDP datagrams as well as atypical 
protocols and options.

Also, at least one non-goal needs to be mentioned:
* No intent to bypass intentional firewall discard of "high-risk" 
atypical protocols, although non-GUE-aware firewalls may be traversable 
in the outgoing direction until they are updated.

*2/ Terminology**
*You cannot expect to write a readable document about encapsulation 
without defining terms and keeping strictly to those terms. E.g.:
* "various/arbitrary IP protocols" (used twice in the abstract and 
introduction) => "protocols encapsulated by IP" (which could include 
Ethernet, IPv4, IPv6. TCP, DCCP, ICMP)
* "a UDP packet" (S.2) => a UDP header in an IP header (v4 or v6)
* "encapsulated packet" (S.6) => payload encapsulated by GUE;
* "encapsulation header" (S.6) => GUE header.

*3/ Transport encap**: Addressing concepts
*S5.2:

    The addresses in the IP header refer to both the
    endpoints of the encapsulation and the endpoints for terminating the
    the transport protocol.

This sentence omits the main point of this mode of encapsulation, which 
is fundamentally encapsulation of one set of ports within another, 
rather than one set of network addresses within another.

S5.3 contains similar problematic text:

    In either case,
    the intended target (decapsulator) is indicated by the outer
    destination IP address.

Add: "and the destination port in the UDP header."
This applies in both network and transport modes, proved by the fact 
that the UDP header is removed on decap as well as the IP header.

*4/ Checksums**: Missing context
*S.5.7 (including subsections 5.7.1, 5.7.2, 5.7.3)
This section is hard to follow - the reader feels like they have just 
been parachuted into the middle of an argument, and all they read is 
some disconnected points and the final compromise, but not what the 
argument was about or what the original problem was.

Given GUE adds a header with a checksum field to a packet that is 
typically already checksummed, it would seem a reasonable requirement to 
ideally avoid double checksum coverage. This requirement is not listed.

Then, if the compromises written in S5.7 followed the line of reasoning 
written out below, I think it could be written more succinctly and make 
more sense:

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

It would seem sensible for the two GUE endpoints to solely checksum the 
fields that GUE adds/removes, because knowledge of which fields GUE 
adds/removes is contained in all GUE code (ie. out-of-band knowledge). 
However, if GUE placed the checksum of these fields in the outer UDP 
checksum field, middleboxes on the path that attempted to verify the 
outer UDP checksum would not be party to this out of band agreement, so 
they would reject the checksum and discard all GUE packets.

GUE could use UDP-LITE which is based on UDP but redefines the length 
field to specify the checksum coverage. However, UDP-Lite has a 
different protocol number to UDP, so its traversal of middleboxes is 
also very poor. Therefore, the design of GUE has had to consider no 
checksum coverage at all for the headers it adds, otherwise GUE encap 
and decap will involve calculation of a checksum over the whole payload 
of every packet, which will heavily impact performance.

Originally, not covering a UDP header by using a zero checksum [RFC768] 
was allowed but not recommended [RFC1122] for IPv4 (which has its own 
header checksum). However, the UDP checksum was required to be non-zero 
in a UDP/IPv6 packet [RFC2460], because IPv6 does not have its own 
header checksum. RFC 6935 updated the IPv6 spec, to allow a zero UDP 
checksum with IPv6 in certain tunnelling scenarios. However, lack of 
coverage comes with risks, as explained in the guidance on the 
applicability of using zero checksums [RFC6936]. Not only would there be 
a risk of undetected corruption of the outer UDP+GUE+options, but also 
corruption of any /added/ outer IPv6 header.

Note that GUE does not add an IP header in transport encap mode, but it 
does in network encap mode. Therefore in network encap mode, 
IPv6+UDP+GUE+options would not be covered if a zero checksum were used.

Both RFCs 6935 (S.4.3) & 6936 (S.1.3.4) raise the possibility that 
middleboxes (esp. firewalls) will exist that drop UDP/IPv6 datagrams 
with a zero checksum. This further complicates the decision on whether 
GUE should use a zero checksum. However, no data on the likelihood of a 
zero checksum UDP datagram being discarded (for IPv4 or IPv6) is given 
in RFC6935 or RFC 6936.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

S5.7.3:
This section contradicts itself. It starts by saying

     For UDP in IPv6, the UDP checksum MUST be processed as specified in
     [RFC768 <https://tools.ietf.org/html/rfc768>] and [RFC2460 <https://tools.ietf.org/html/rfc2460>]

I assume this first sentence should have been removed, because the 
section goes on to allow zero UDP checksum and other possibilities which 
contravene this first sentence. Whatever, repetition of the same rule in 
different words needs removing from the first para, otherwise it will 
also be prone to inconsistency during later editing.

*5/ Nits**
*
S3.1: first sentence and in the header diagram: Strictly version 0b00 
would be better than 0x0, which implies 4 bits.
S3.1: The definitions of the "C flag", "ctype", "Flags", "Fields" and 
"Private data" are all inadequate and/or circular and it doesn't state a 
principled difference between the Control and Protocol types of header 
(note: all headers are control messages for the protocol they encapsulate).
I think the (unstated) difference is that:
* A control message with a Ctype field (C flag set) carries options and 
a message that are both implicitly addressed to the decapsulator (at 
port 6080) to monitor or control the state or behaviour of the tunnel; 
whereas
* A data message with a Proto field (C flag clear) carries an 
encapsulated packet addressed to the encapsulated protocol stack, 
optionally including options and/or private data that are implicitly 
addressed to the decapsulator, but give /stateless/ control information 
associated solely with the encapsulated datagram.
    I finally worked this out after much head-scratching - but if these 
definitions aren't correct, then I'm still confused.
S3.1 The name "Fields" is too ambiguous for a field! Please choose another.
S3.2.1 s/though other means/through other means/
            s/parse packets the packet based on/parse the packet based on/
S3.3: This section ("Flags and optional fields") is completely 
incomprehensible unless you already know what it is trying to mean (I 
worked it out once I read the examples in other docs, but it's too 
abstract without examples).
S3.6: "GUE transform field" is used (twice) without explaining what it 
is, and with no reference.
S5. s/server/host/ numerous times, in text and figure.
S5.3

    If an encapsulator is tunneling packets, that is encapsulating
    packets of layer 2 or layer 3 protocols (e.g. EtherIP, IPIP, ESP
    tunnel mode), it should follow standard conventions for tunneling of
    one IP protocol over another.

Clearly, it cannot "follow standard conventions for tunneling of one IP 
protocol over another" if it is not tunnelling an IP protocol. For 
non-IP-in-IP cases, RFC2983 is generally applicable for Diffserv-like 
fields in L2 protocols. For ECN propagation between L3 & L2 there is a 
draft BCP nearly finished in tsvwg at the moment: 
draft-ietf-tsvwg-ecn-encap-guidelines.
S5.4 Current:

    If a packet is acceptable, the UDP and GUE headers are
    removed and the packet is resubmitted for protocol processing or
    control message processing if it is a control message.

I suggest this is made clearer by treating each case (C or not-C) 
separately, and in the case of not-C, saying that Fields and Private 
Data are also removed. Also, clarify that "is resubmitted" means to the 
protocol handler of the outer header (IPv4, v6 etc).
S.5.9.
s/rather/whether/
s/then congestion control at the encapsulation layer must be provided./
  /then RFC5405 says congestion control at the encapsulation layer 
"MUST" be provided./
Rationale: Rather than restating a rule that is already stated with all 
the appropriate caveats in another RFC, it is best to refer to the original.
Also, the above text formulation at least only refers to RFC5405, it 
neither agrees nor disagrees with it, which makes RFC5405 easier to 
rescind later ;)

s/may used/may be used/
s/may warranted/may be warranted/

S.5.10 s/independent to/independent of/
5.11.1
s/load balancing (statistical multiplexing)/load balancing/
[Statistical multiplexing is the opposite of load balancing - it 
involves aggregating flows together, not spreading them out.]
s/corresponds the flow of the inner packet/corresponds to the flow of 
the inner packet/
s/examples of deriving an flow entropy/examples of deriving flow entropy/
S.5.11.2
s/...the ephemeral port range. IANA suggests this range to be 49152 to 
65535/
  /...the ephemeral port range (49152 to 65535) [RFC6335]/
S.6. You might want to add a citation of RFC6438 "Using the IPv6 Flow 
Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels" 
as an alternative way to introduce flow entropy in a tunnel.
S.7. The term "security" needs to be expanded somewhere before using it 
in the following:

    Security for GUE can be provided by lower layers or through GUE
    security extensions.   [...]  , including
    security for the GUE header and payload,

And here:

       | Bit 1..2    | 01->8 bytes  | Security    | [GUEEXTENS <https://tools.ietf.org/html/draft-ietf-nvo3-gue-04#ref-GUEEXTENS>]        |
       |             | 10->16 bytes |             |                    |
       |             | 11->32 bytes |             |                    |

Pls just say somewhere that the Security option means "origin 
authentication and integrity protection of the GUE header".
Alternatively use a more meaningful name, e.g. "Authentication option".
S.8.3:
s/New values are assigned via Standards Action [RFC5226]./
  /New values for control types 1-127 are assigned via Standards Action 
[RFC5226]./
S.10.1 Every normative reference has been duplicated.
A2.2 s/to validate an checksums/to validate checksums/

In draft-herbert-gue-extensions-00, in the Security option section 
<https://tools.ietf.org/html/draft-herbert-gue-extensions-00#section-5.1>:
   s/The format of the fragmentation option is:/The format of the 
security option is:/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/