Subject: [tsvwg] Some comments on draft-ietf-tsvwg-gre-in-udp-encap-07

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 08 Jul 2015 18:26:14 +0100

I have comments on WG rev -07. To keep things a little simpler, I shall 
be writing my comments in two parts.

The first parts are as an individual (see below), and largely relate to
wording.

The second part of what I would like to go through relate to the 
intended scope and intended use 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.

Gorry

So part 1 of my comments is below:

Section 1.1:
/The payload type is IP or a type of network protocol that has
  congestion control capability when the encapsulated traffic is
  over the Internet./
- I think this is a really odd requirement for a Generic Encaps.

Section 3.1:
/IANA suggests this range to be 49152 to 65535/
… do you know a reason why this is not “specifies” the ephemeral port
range - I thought this was defined in the registry?

Section 5.2:
“ a. Use of the UDP checksum with IPv6 MUST be the default
       configuration of all GRE-in-UDP implementations.”
- OK, but not so clear that this is the same as the requirement earlier:
can this text be combined with the text in section (c)?

Section 5.2:
“ However the use of the UDP zero-checksum mode must meet the
    requirements specified in [RFC6935] and [RFC6936] as well at the
    additional requirements stated below.”
- This causes concern, as I understand the specification in this 
document must meet these design requirements, they are not operational 
guidance on use.
So to me, the real question is does THIS spec meet them?

 >From the zero checksum BCP:
“5.   A transported protocol with a non-tunnel payload or one that
         encapsulates non-IP packets MUST have a CRC or other mechanism
         for checking packet integrity, unless the non-IP packet is
         specifically designed for transmission over a lower layer that
         does not provide a packet integrity guarantee.”
- I think the above may be useful to add to the Spec, recommending use of
the GRE integrity check and/or DTLS.

Section 5.2:
“These exceptions may also be extended to the use of GRE-in-UDP
    within a set of closely cooperating network administrations (such as
    network operators who have agreed to work together in order to
    jointly provide specific services).
“
- I don’t understand this text, is that saying the administrators can 
make more restrictions, or I suspect the opposite. If the latter, this 
causes me serious concern. I think a protocol that fails to meet the 
spec should be non compliant - whether operators choose to use of not 
RFC-based specs is not something the IETF can control, but making those 
specs ambiguous is I think a poor design choice.

Section 5.2 (e):
/in Section 5 of [RFC6936].[RFC6936]./
- Double reference citation.

/ A corrupt GRE results in either packet/
- insert “packet”  after GRE?

/Active
    monitoring of GRE-in-UDP traffic for errors is REQUIRED as
    occurrence of errors will result in some accumulation of error
    information outside the protocol for operational and management
    purposes.  This design is in accordance with requirement 4 specified
    in Section 5 of [RFC6936]./
- Seems useful, although active monitoring within a endpoint does not
result in any action. If this is required, as it may be, can the draft
specify what to do?

/   As such, GRE-in-UDP MUST NOT be used over the general Internet, or
    over non-cooperating network operators, to carry traffic that is not
    congestion-controlled./
- This belongs in that special subsection on non-congestion-controlled
traffic.

/In
    these cases, the router will conform to normal UDP processing and
    respond to an encapsulator with an ICMP message indicating "port
    unreachable" according to [RFC792].  Upon receiving this ICMP
    message, the node MUST NOT continue to use GRE-in-UDP encapsulation
    toward this peer without management intervention.
/
- Please add a note to the protocol requirement, stated in the security
section for checking protocol fields to know that the packet originated
from the source.

Does use with DTLS also REQUIRE that the UDP checksum is used?

/This document does not require that decapsulator validates the IP
    source address of the tunneled packets (with the exception that the
    IPv6 source address MUST be validated when UDP zero-checksum mode is
    used with IPv6), but it should be understood that failure to do so
    presupposes that there is effective destination-based (or a
    combination of source-based and destination-based) filtering at the
    boundaries.
/
- Change IP to IPv6?
- I am not sure I really understand this - you say there is filtering at
the boundaries, is there not also a requirement for all systems within 
the network? Explain the logic to me.

/ A major motivation for GRE-in-UDP encapsulation is to tunnel a
    network protocol over IP network and improve the use of multipath
    (such as ECMP) in cases where traffic is to traverse routers which
    are able to hash on UDP Port and IP address. As such, in many cases
    this may reduce the occurrence of congestion and improve usage of
    available network capacity. However, it is also necessary to ensure
    that the network, including applications that use the network,
    responds appropriately in more difficult cases, such as when link or
    equipment failures have reduced the available capacity.
/

- This section may be seen as about operator congestion, but seems to me
to be about long-term management of capacity, rather than the short-term
congestion that transport protocols typically try to reduce. It seems a
little confusing in the current text, and I personally would see it as 
OK to remove this, but you may like to rewrite it if you think it adds
context to people managing networks.

/Requirements 6 and 7 do not apply
    because GRE does not have a GRE-generic control feedback mechanism./
- true, but this does mean that there are potential failure modes when
traffic uses a path that passes through a middlebox - a reference to
5.2.1.would be helpful at this point.

Section 3.3. GRE Header
“An encapsulator SHOULD NOT enable both the GRE checksum and
UDP checksum simultaneously as this would be mostly redundant.”

- I’m not sure why this “SHOULD NOT”, although I can see a warning that 
this can have performance implications, but it does not seem to impact
interoperability. The text later says: “Use of GRE checksum favors non-
use of the UDP checksum.” - which needs better English, but avoids the
keyword requirements in the above text.

Have all the issues in draft-ietf-intarea-gre-ipv6 been addressed in 
this draft?

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Jul 2015 10:46:21 -0700

On 7/8/2015 10:26 AM, Gorry Fairhurst wrote:
...
> - I think this is a really odd requirement for a Generic Encaps.

The correct recommendation can probably be found in RFC5405.

> range - I thought this was defined in the registry?

RFC6335.

> can this text be combined with the text in section (c)?

IMO, documents should not create redundant requirements when citing
existing ones is sufficient. Just cite RFC6935 and RFC6936.

> So to me, the real question is does THIS spec meet them?

I agree; this doc should instead discuss whether this use case meets the
requirements of those existing standards.

> the GRE integrity check and/or DTLS.'

This is already covered in Section 3.1.4 of RFC RFC6936. Again, cite,
don't reinvent.

I'm sure there are other places where that rule should apply, but the
horse has been beaten.

Joe