Subject: [tsvwg] Some things I think need to be fixed in: draft-ietf-tsvwg-gre-in-udp-encap-07

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 09 Jul 2015 11:15:41 +0100

These comments on WG rev -07 relate to the intended scope and the
language of the draft - I’m expecting these topics to be discussed in 
the meeting, and mailing list to help us see the appropriate way forward.

It strikes me that the draft at present seems focused on the important
problem of using GRE over UDP as a way to support ECMP. However, there 
are plenty of usages for GRE that do not relate to ECMP. This is what I 
refer to when I note the issue with “scope”. It seems to me that TSVWG 
should be specifying something that enables GRE to provide generic 
support to a range of protocols in a range of deployment choices. The 
scope of GRE-in-UDP needs to allow this - otherwise there is a danger 
the group specifies a generic IETF encapsulation that is not deployable 
in the general Internet, which to me seems wrong!

This is a good topic to bring to the list and discuss at the next 
meeting. I do have a proposal (read on).

The biggest single issue to me is that this is still written like it is 
a protocol spec that is to be deployed into an operator-only 
environment.  I seriously doubt if this will be the only use case.

I could for instance think of a draft that has a “standard” mode that
requires IPv6 checksum, uses a single source port, etc. This could 
assert the mode was considered safe for deployment in the general 
Internet, etc.  Then the draft could also define a mode where there were 
deployment constraints. Operator filtering, and the others suggested, 
but if these were in place, the spec would then allow the an endpoint to 
enter the ECMP mode and use multiple source ports, etc.  By describing 
these sections the draft could then perhaps place a clear picture of 
what are the merits and pitfalls.

Gorry

---

Some specific comments on these topics (as an individual in tsvwg) follow:

1) Section 1:
  1) Within a single operator network or networks of an adjacent set
  of cooperating network operators where traffic is managed to
  avoid congestion.
- I see this as a constraint for an ECMP usage - but text needs to be
clear with respect to later text on multi-operator use.

2) This seems like it really should not be in a “generic” spec. It
suggests to me there may be a need for more than one usage scenario:
“Each UDP tunnel is unidirectional, as GRE-in-UDP traffic is
    sent to the IANA-allocated UDP Destination Port, and in particular,
    is never sent back to any port used as a UDP Source Port (which
    serves solely as a source of entropy). This is at odds with a common
    middlebox (e.g., firewall) assumption that bidirectional traffic
    uses a common pair of UDP ports.  As a result, arranging to pass
    bidirectional GRE-in-UDP traffic through middleboxes may require
    separate configuration for each direction of traffic.”

- If I understand it basically says you have to use additional ports if
a sender uses UDP in GRE, and by doing so effectively prevents NAPT
traversal.
This is a bad side effect for interoperability in general (the general
Internet case), although it could be OK ECMP.

3) UDP Checksum Handling
- Could this be a rule ONLY for ECMP usage:
“     a. Use of GRE-in-UDP in networks under single administrative
         control (such as within a single operator’s network) where it
         is known (perhaps through knowledge of equipment types and
         lower layer checks) that packet corruption is exceptionally
         unlikely and where the operator is willing to take the risk of
         undetected packet corruption.”
- This becomes much more permissive text that finally agreed for MPLS,
where the edge device filtering was noted I see this as a real issue 
here, and I do not know how you can check where the egress is easily 
with a userland tunnel encaps. I’m not yet personally happy with this 
text yet for either usage.

- Could this be rules ONLY for ECMP usage:
“b. Use of GRE-in-UDP in networks under single administrative
         control (such as within a single operator’s network) where it
         is judged through observational measurements (perhaps of
         historic or current traffic flows that use a non-zero checksum)
         that the level of packet corruption is tolerably low and where
         the operator is willing to take the risk of undetected packet
         corruption.”
- Although, I don’t yet see why this is substantially different to (a) 
in terms of scope or issues.

“c. Use of GRE-in-UDP for traffic delivery for applications that
         are tolerant of mis-delivered or corrupted packets (perhaps
         through higher layer checksum, validation, and retransmission
         or transmission redundancy) where the operator is willing to
         rely on the applications using the tunnel to survive any
         corrupt packets.”
- I do not buy this as a different case, because this is a transport
protocol, the statement here seem to applies to GRE/IP, not GERE/UDP
- the misdelivered packets are delivered to this or other end hosts, 
when used to generate entropy they can be over a wide range of source 
addresses and this all seems to me to be a problem for an endpoint that 
is using UDP.

“For these exceptions, the UDP zero-checksum mode can be used.”
- This needs discussion: Should this be when *ALL* are true?

“An encapsulator SHOULD use different IPv6 addresses for each GRE-
       in-UDP tunnel that uses UDP zero-checksum mode regardless of the
       decapsulator in order to strengthen the decapsulator’s check of
       the IPv6 source address (i.e., the same IPv6 source address
       SHOULD NOT be used with more than one IPv6 destination address,
       independent of whether that destination address is a unicast or
       multicast address). When this is not possible, it is RECOMMENDED
       to use each source IPv6 address for as few UDP zero-checksum mode
       GRE-in-UDP tunnels as is feasible.”
- Two comments:
(i) The requirement seems reasonable for an ECMP usage, but is not 
obvious for a standard pt-2-pt tunnel. However, it could only be the 
ECMP usage that needs this?
(ii) “as feasible” is loose - can we more precise?

- Could this be rules ONLY for ECMP usage:
“f. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
       checksums from "escaping" to the general Internet; see Section 6
       for examples of such measures.”
- I can understand this within a managed network, such as MPLS, but I do
not understand this requirement within the Internet as a whole. This 
text seems hard to understand how to comply at the moment.

- Could this be rules ONLT for ECMP usage:
“IPv6 traffic with zero UDP checksums MUST be actively monitored
       for errors by the network operator.”
- I’m Ok with actively monitoring. Is this at the tunnel egress, since 
it is a requirement how does the spec enable this to be compliant? what 
is actually needed?

/ It is worth to mention that the use of a zero UDP checksum should
    present the equivalent risk of undetected packet corruption when
    sending similar packet using GRE-in-IPv6 without UDP and without GRE
    checksums./
- I do not understand the meaning of these clauses.

- Could this be rules ONLY for ECMP usage:
/In summary, UDP zero-checksum mode for IPv6 is allowed to be used
    with GRE-in-UDP when one of the three exceptions specified above
    applies, provided that additional requirements stated above are
    complied with./
- This is complicated, can it be made simpler or just omitted.

/However, GRE-in-UDP tunneling can be also used to carry traffic that
    is not necessarily congestion controlled. In such cases network
    operators may avoid congestion by careful provisioning of their
    networks, by rate limiting of user data traffic, and/or by using
    Traffic Engineering tools to monitor the network segments and
    dynamically steers traffic away from potentially congested links.
/
- This is again a scoping issue - for GRE used within an operator 
network this is true. When GRE is used by an endpoint this is an unfair
requirement to place on the transit operator. Which is kind of what the
next para says. Would it better to create two subsections that clearly
separate the two cases.
- I am not sure without seeing other points addressed whether this
particular text is heading in a good direction yet.

Gorry

-- 
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.