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/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
