Subject: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap

From: [email-masked]
Date: Wed, 18 Dec 2013 08:55:12 -0000

The IETF tsvwg has started to consider the adoption of
draft-yong-tsvwg-gre-in-udp-encap to be developed into a Proposed Standard
within the tsvwg on 5th November.  There was initial supporting feedback
from people attending the IETF-88 TSVWG meeting.

We are now asking for any additional comments/feedback prior to confirming
this call.

The call will close on 31st December 2013.

Gorry, James and David.
(TSVWG Chairs)

---

From: Lucy yong <[email-masked]>
Date: Wed, 18 Dec 2013 14:56:33 +0000

Support as one of editors.

Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 18, 2013 2:55 AM
To: [email-masked]
Subject: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap

The IETF tsvwg has started to consider the adoption of draft-yong-tsvwg-gre-in-udp-encap to be developed into a Proposed Standard within the tsvwg on 5th November.  There was initial supporting feedback from people attending the IETF-88 TSVWG meeting.

We are now asking for any additional comments/feedback prior to confirming this call.

Gorry, James and David.
(TSVWG Chairs)

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 18 Dec 2013 18:32:37 +0000

I would like to see the draft discuss how it addresses the issues raised in RFC5405, before I'd be comfortable in stating a position.

Lars

---

From: Lucy yong <[email-masked]>
Date: Wed, 18 Dec 2013 19:22:47 +0000

Hi Lars,

I assume that you mean the MTU issue motioned in RFC5405. Section 4 in the draft describes the tunnel ingress must perform fragmentation on the packet before encapsulation. GTP-in-UDP encapsulation introduces additional 8 bytes beyond GRE header. Thus MTU size parameter set by operator MUST fact this in. 

If this is not your point, please clarify it.

Regards,
Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: Wednesday, December 18, 2013 12:33 PM
To: Gorry Fairhust
Cc: [email-masked]
Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap

Lars

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Dec 2013 19:16:46 -0500

Lars,

<WG chair hat OFF>

This probably needs a longer discussion, as RFC 5405 is not straightforward to address
in this draft because GRE is not the "Application" as that term is used in the title of
RFC 5405.  The "Application" is running above GRE, and if GRE were as widely deployed
and/or used/usable as UDP, RFC 5405 could (in that hypothetical universe) have
been addressed to both UDP and GRE.

In particular, there is probably not much that can be said about congestion control,
as that functionality and/or concerns (e.g., about its absence) are above GRE in the
stack.

I'll echo Lucy's question - what specific aspects of RFC 5405 concern you?

FWIW, as an individual, I support adoption of this draft, as I think it helps deal
with protocols whose preferred encapsulation is GRE when running them over
infrastructure that is more UDP- friendly than GRE-friendly (e.g., in its ECMP
and/or LAG support).

</WG chair hat OFF>

Thanks,
--David

> From: tsvwg [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Wednesday, December 18, 2013 2:23 PM
> To: Eggert, Lars; Gorry Fairhust
> Cc: [email-masked]
> I assume that you mean the MTU issue motioned in RFC5405. Section 4 in the
> draft describes the tunnel ingress must perform fragmentation on the packet
> before encapsulation. GTP-in-UDP encapsulation introduces additional 8 bytes
> beyond GRE header. Thus MTU size parameter set by operator MUST fact this in.
> 
> I would like to see the draft discuss how it addresses the issues raised in
> RFC5405, before I'd be comfortable in stating a position.
> 
> Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 19 Dec 2013 12:42:37 +0000

Hi,

> as that functionality and/or concerns (e.g., about its absence) are above GRE in the

let me expand a bit.

GRE can carry pretty much any traffic that has an EtherType, including congestion-controlled and non-congestion-controlled traffic.

At the moment, because GRE is carried directly in IP, it's pretty much limited to paths without middleboxes. That excludes most consumer Internet connections.

When encapsulated inside UDP, it can traverse those paths. 

The issue I see - and I'm not saying it's a showstopper or anything, but it requires discussion - is that UDP-encapsulated-GRE can make non-congestion-controlled traffic appear in regions in the network where it currently doesn't go as easily.

This is what Section 3.1.3 in RFC5405 is about.

> I'll echo Lucy's question - what specific aspects of RFC 5405 concern you?

See above. And thanks, Lucy, for pointing me a the MTU discussion.

By the way, you probably also need to say a bit more about why a zero UDP checksum is OK here, simply pointing at the RFCs is not enough. There needs to be some machinery present in the encapsulation to make that use OK, IIRC.

Lars

---

From: Lucy yong <[email-masked]>
Date: Fri, 20 Dec 2013 01:06:35 +0000

Hi Lars,

Thank you for the suggestion. I agree that the draft should add some clarifications on these issues described in RFC5405. Will the following be acceptable statements for each issue? If not, like to hear your concern or suggestion.

Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechanism does not use or rely on UDP transport layer functions except demultiplexing. The UDP header just provides the fields for GRE payload indication and flow entropy. Thus it is not a regular UDP application built on the top of UDP transport layer and relying on the UDP layer to provide some transport functions. However it is useful to document the issues raised in RFC5405 against GRE-in-UDP. 

    Congestion Control Guidelines: GRE-in-UDP encapsulation does not provide any congestion control mechanism. Whether an application encapsulated by GRE-in-UDP should employ a congestion control mechanism or not, please refer to the congestion control guideline described in RFC5405.

    Message Size Guidelines: (This is already addressed in section 4 of the draft).

    Reliability Guidelines: Not apply. GRE-in-UDP provides the same reliability and integrity as of GRE encapsulation. In order words, no need additional mechanism when using GRE-in-UDP instead of GRE. 

    Checksum Guidelines: Since GRE already has the checksum function, GRE-in-UDP does not need to use the UDP checksum. For simplifying the process, UDP checksum should be set to zero.

    Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a standard UDP port number [TBD] to indicate GRE payload. This port number MUST not be used by any middlebox or an application for other purpose. This will ensure the consistent behavior along the path when the application is encapsulated by GRE or GRE-in-UDP.

    Programming Guidelines: Not apply. The applicability of GRE-in-UDP is to the GRE encapsulated network protocols that generate a high traffic volume.
 
    ICMP Guidelines: add text in section 7.1.: If tunnel end point uses ICMP to inform no GRE-in-UDP support, peer end point needs additional validation checking. The validation process should follow the guideline described in RFC5405. (does this address Gorry's comment?)

    Security Considerations: like to hear if we should use DTLS in the environment that the security is a concern.

Regards,
Lucy

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 20 Dec 2013 08:37:36 +0000

Hi,

> Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechanism does not use or rely on UDP transport layer functions except demultiplexing. The UDP header just provides the fields for…

I disagree with this view. UDP as protocol doesn't provide anything other than demultiplexing to begin with. That's why we did a BCP on what mechanisms an application or tunnel that uses UDP on the Internet needs to possibly implement. Your GRE-in-UDP tunnel is a user of UDP just as any other application or protocol that uses UDP. It's not special.

>    Congestion Control Guidelines: GRE-in-UDP encapsulation does not provide any congestion control mechanism. Whether an application encapsulated by GRE-in-UDP should employ a congestion control me…

It's not enough to refer to RFC5405. RFC5405 actually recommends some mechanisms that the tunnel should employ. In your case, where you don't know whether the payload is congestion-controlled, the recommendation is:

   2.  A tunnel generates UDP traffic at a volume that corresponds to
       the volume of payload traffic, and the payload traffic is not
       known to be IP-based, or is known to be IP-based but not
       congestion-controlled.

       This can be the case, for example, when some link-layer protocols
       are encapsulated within UDP (but not all link-layer protocols;
       some are congestion-controlled).  Because it is not known that
       congestion losses of tunneled non-IP traffic will trigger an
       appropriate congestion response at the senders, the UDP tunnel
       SHOULD employ an appropriate congestion control mechanism.
       Because tunnels are usually bulk-transfer applications as far as
       the intermediate routers are concerned, the guidelines in
       Section 3.1.1 apply.

>    Security Considerations: like to hear if we should use DTLS in the environment that the security is a concern.

It would be good to see the discussion on the points above in the ID.

Lars

---

From: Lucy yong <[email-masked]>
Date: Fri, 20 Dec 2013 15:32:56 +0000

[Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, from UDP perspective, it is a UDP application. From tunnel encapsulation perspective, GRE-in-UDP does not use or rely on UDP transport layer functions except demultiplexing, i.e. the UDP header just provides the fields for GRE payload indication and flow entropy. However it is useful to document the issued raised in RFC5405 against GRE-in-UDP.

[Lucy] Thanks! We will make it sufficient and refer to this specific section in RFC5405.

Regards,
Lucy

Lars

---

From: <[email-masked]>
Date: Sun, 22 Dec 2013 00:50:08 +0000

It's important to note that protocols sanity-checking their own headers is important, so that stuff arrives where it should and is rejected before arriving where it shouldn't and messing up something else's communications.

Basic GRE doesn't check its own headers,and its optional checksum, if used, does the entire payload.

The UDP protocol header serves double-duty as payload and as pseudo-header check _for both IP and UDP_. It's an important check that demultiplexing happens in the right place, and more so in IPv6. In IPv6, there's no IP header checksum and more reliance on L2 checking that the packet made it across a link intact (a design mistake imo - a header checksum could easily have covered the unchanging field, and excluded TTL, and given future NAT devices more of a headache.)

One way to get a sensible endpoint arrival checksum for both GRE and UDP headers - and the IP pseudoheader, which is much more important in IPv6 due to the above design choice - is to use UDP-Lite (itself an academic design mistake on the assumption it would be a simple upgrade for UDP exploiting redundant checksum fields, but stymied by existing deployed code relying on the wrong checksum field!) with its checksum set to cover the IP pseudoheader, UDP header, and GRE header (especially if the GRE header is checksumless, and the L2 payload being carried has its own checksum).

Saying 'we can just set checksums to zero' is really sloppy engineering - especially for IPv6, which is itself sloppily engineered in this regard (and GRE direct over IPv6 would have the same problem.) I know, I'm just rehashing the arguments in RFC6935 and 6936:

   The operation of IPv6 with UDP with a zero checksum is not the same
   as IPv4 with UDP with a zero checksum.  Protocol designers should not
   be fooled into thinking that the two are the same.

though I draw different conclusions than those RFCs do, erring on the side of reliability. But the arguments (operational deployment/convenience/decent engineering and reliability) are a whole lot more nuanced than just saying 'set checksums to zero, all will be fine'.

I oppose adoption of this draft. It's trying to fix a non-problem in a way no better than using GRE over IPv6 with a key field for entropy.

(I have no idea who said the quoted and unquoted text below.)

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: tsvwg [[email-masked]] On Behalf Of Lucy yong [[email-masked]]
Sent: 20 December 2013 15:32
To: Eggert, Lars
Cc: [email-masked]
Subject: Re: [tsvwg] Working    Group   Adoption        call    for:    draft-yong-tsvwg-gre-in-udp-encap

Regards,
Lucy

Lars

---

From: Edward Crabbe <[email-masked]>
Date: Sat, 21 Dec 2013 20:06:47 -0800

Disagree.

The non-problem part is simply not true, at least for those of who
maintain backbones with older equipment that cannot make use of the
GRE key, or for those networks that already make use of the key for
other purposes.

W/r/t the 'sloppy engineering':  again, disagree.  You've conveniently
ignored the arguments offered up in *favor* of checksum 0 in RFC6935.
I obviously agree that the issue is more nuanced than 'set checksums
to zero, all will be fine';  it was never our intent to imply this.

---

From: <[email-masked]>
Date: Sun, 22 Dec 2013 06:09:47 +0000

The arguments offered up in RFC6935 are explicitly _for_ tunnels. I quote:

     Some non-tunnel protocols operate with general servers that do not
      know the source from which they will receive a packet.  In such
      applications, a zero UDP checksum is unsuitable, because it is
      necessary to provide the first level of verification that the
      packet was intended for the receiving server.  A verification
      prevents the server from processing the datagram payload; without
      this, the server may spend significant resources processing the
      packet, including sending replies or error messages.

[..]

   One unfortunate side effect of increased use of a zero checksum is
   that it also increases the likelihood of acceptance when a datagram
   with a zero UDP checksum is misdelivered.  This requires all tunnel
   protocols using this method to be designed to be robust in the face
   of misdelivery.

There's no discussion of the impact of that 'unfortunate side effect' of misdelivered packets with zero checksum and corrupted port address arriving at some other application, and screwing that up via pollution. In other words, it's fine and dandy for tunnels to protect themselves, but the rest of the Internet be damned, it's not the tunnels' problem if zero-checksum packets wind up elesewhere.

At least GRE over IP direct didn't have that problem as much; other UDP applications were untouched, and a lot more selective corruption would be required to turn a non-UDP packet into a valid UDP packet that hits a port.

We agree on nuance. draft-yong-tsvwg-gre-in-udp-encap is not about nuance, but about expedience, like so much of IETF work.

Lloyd Wood

this just supports my thesis that all transport work im the IETF is dooomed.

________________________________________
From: Edward Crabbe [[email-masked]]
Sent: 22 December 2013 04:06
To: Wood L  Dr (Electronic Eng)
Cc: Lucy yong; Eggert, Lars; [email-masked]
Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap

Disagree.

---

From: Lucy yong <[email-masked]>
Date: Sun, 22 Dec 2013 16:58:37 +0000

It is a fair argument on the checksum. It gives the ability for other UDP applications to detect if a UDP packet mis-delivery occurs.  

Suggested text: since GRE already has the checksum function, GRE-in-UDP does not need to use the UDP checksum. To simplify the process, RECOMMEND to set UDP checksum zero. However, GRE-in-UDP may use UDP checksum at the environment where a UDP packet may be mis-delivered to a wrong port. 

As stated in the draft, GRE-in-UDP primary market place is for IPv4 networks, where the issue has to be addressed sooner than IPv6 upgrade happens.

Thanks,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, December 22, 2013 12:10 AM
To: [email-masked]
Cc: Lucy yong; [email-masked]; [email-masked]
Subject: RE: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap

[..]

Lloyd Wood

Disagree.

The non-problem part is simply not true, at least for those of who maintain backbones with older equipment that cannot make use of the GRE key, or for those networks that already make use of the key for other purposes.

W/r/t the 'sloppy engineering':  again, disagree.  You've conveniently ignored the arguments offered up in *favor* of checksum 0 in RFC6935.
I obviously agree that the issue is more nuanced than 'set checksums to zero, all will be fine';  it was never our intent to imply this.

On Sat, Dec 21, 2013 at 4:50 PM,  <[email-masked]> wrote:
> The UDP protocol header serves double-duty as payload and as 
> pseudo-header check _for both IP and UDP_. It's an important check 
> that demultiplexing happens in the right place, and more so in IPv6. 
> In IPv6, there's no IP header checksum and more reliance on L2 
> checking that the packet made it across a link intact (a design 
> mistake imo - a header checksum could easily have covered the 
> unchanging field, and excluded TTL, and given future NAT devices more 
> of a headache.)
>
>>    ICMP Guidelines: add text in section 7.1.: If tunnel end point 
>> uses ICMP to inform no GRE-in-UDP support, peer end point needs 
>> additional validation checking. The validation process should follow 
>> the guideline described in RFC5405. (does this address Gorry's 
>> comment?)
>>