Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

From: "Black, David" <[email-masked]>
Date: Sat, 5 Dec 2015 03:08:21 +0000

<WG chair hat OFF>

I wrote and Tom Herbert responded ...

>> The following text was added to help with the difficulties encountered in
>> dealing with UDP zero-checksum for IPv6:
>>
>>       To protect
>>       from misdelivery, new encapsulation designs SHOULD include an
>>       integrity check at the transport layer that includes at least the
>>       IPv6 header, the UDP header and the shim header for the
>>       encapsulation, if any [RFC6936].
>>
>> I'd like to add a warning here to designers of what may happen if that SHOULD is
>> not followed, e.g. (borrowing some of RFC 2119's choice of words):
>>
>>        Not including such a check can be expected to require significant
>>        effort to understand and carefully weigh the full implications
>>        and provide alternative assurances that misdelivery is unlikely.
>>        While this is possible (see Sections 3.1 and 3.2 of [RFC7510]
>>        for an example), use of an integrity check is RECOMMENDED.
>>
> I think this text is good and is consistent with section 14 in
> draft-rtg-dt-encap-01. I'd also point out that mis-delivering packets
> in a multi-tenant environment may not be innocuous at all, so I think
> "carefully weigh the full implications" is an appropriate directive.

I just realized that there's a something related that seems to be worth
mentioning.   I've forgotten whom to credit, but in hallway discussion
in Yokohama (IIRC), someone pointed out to me that a checksum that covers
the IPv6 header and the UDP header won't go through existing NATs.

In the original discussion, that sounded like a "bug" ... but it might
be a "feature" for some new UDP tunnel encapsulations ... seriously.

The reason for this observation is that one of the major sources of
recent "pain and suffering" in UDP encap design has been the consequences
of UDP being able to reach places that the encapsulated protocol can't.
Among the results are needing to pay a lot more attention to congestion
considerations, and having to provide guidelines on preventing "escape"
of IPv6/UDP encap traffic with zero UDP checksums from the networks that
the traffic is intended for.  

In contrast to UDP reachability, ECMP seems to be the much more important
motivation for quite a bit of the recent UDP encap work (e.g., that's
definitely my impression for both MPLS/UDP and GRE/UDP).

An interesting property of a header checksum in a new encapsulation that
covers at least the IPv6, UDP, and shim headers is that the checksum works
fine with ECMP (including LAG), but breaks when going through a NAT, unless
an ALG is added to the NAT to fix up that new checksum (this assumes that the
packet arrives at a tunnel egress that understands the tunnel and does
verification of the header checksum).

That property may help keep traffic using the new encapsulation where it
belongs, as any NAT is automatically a barrier to "escape" (or has to be
modified with an ALG) insofar as endpoints that understand the new encap
are concerned.  That "escape" barrier property of NATs might even be a
reason to suggest such checksums for IPv4 (although I don't think that
suggestion merits the strength of an RFC 2119 "SHOULD" keyword).

Thoughts?

</WG chair hat OFF>

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 30, 2015 3:16 PM
> To: Tom Herbert
> Cc: Black, David; [email-masked]
> Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update
> 
> That's helpful, I'll include this.
> 
> Gorry
> 
> > On Sun, Nov 22, 2015 at 6:39 PM, Black, David <[email-masked]> wrote:
> >> As WG chair:
> >>
> >> I think this version is reasonably good wrt my concerns, but I'd like to
> >> hold it in the WG for a few weeks before making the publication request
> >> in
> >> order to provide time for additional reviews (e.g., Erik Nordmark
> >> promised
> >> to check this against the encapsulation draft in RTGWG).
> >>
> >> <WG chair hat OFF>
> >>
> >> The following text was added to help with the difficulties encountered
> >> in
> >> dealing with UDP zero-checksum for IPv6:
> >>
> >>                 To protect
> >>               from misdelivery, new encapsulation designs SHOULD include
> >> an
> >>               integrity check at the transport layer that includes at
> >> least the
> >>               IPv6 header, the UDP header and the shim header for the
> >>               encapsulation, if any [RFC6936].
> >>
> >> I'd like to add a warning here to designers of what may happen if that
> >> SHOULD is
> >> not followed, e.g. (borrowing some of RFC 2119's choice of words):
> >>
> >>                 Not including such a check can be expected to require
> >> significant
> >>                 effort to understand and carefully weigh the full
> >> implications
> >>                 and provide alternative assurances that misdelivery is
> >> unlikely.
> >>                 While this is possible (see Sections 3.1 and 3.2 of
> >> [RFC7510]
> >>                 for an example), use of an integrity check is
> >> RECOMMENDED.
> >>
> > I think this text is good and is consistent with section 14 in
> > draft-rtg-dt-encap-01. I'd also point out that mis-delivering packets
> > in a multi-tenant environment may not be innocuous at all, so I think
> > "carefully weigh the full implications" is an appropriate directive.
> >
> > Tom
> >
> >> Continuing (nit)
> >>
> >>            o  One way to help satisfy the requirements of [RFC6936] may
> >> be to
> >>               limit the usage (e.g., to constrain traffic to an operator
> >> network
> >> OLD
> >>               Section 3.6, as in [RFC7510]).
> >> NEW
> >>                 or set of closely cooperating networks, as further
> >> described in
> >>                 Section 3.6 below, see [RFC7510] for an example of this
> >> approach).
> >>
> >>
> >> </WG chair hat OFF>
> >>
> >> Thanks,
> >> --David
> >> ----------------------------------------------------
> >> David L. Black, Distinguished Engineer
> >> EMC Corporation, 176 South St., Hopkinton, MA  01748
> >> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> >> [email-masked]        Mobile: +1 (978) 394-7754
> >> ----------------------------------------------------
> >>
> >>
> >
>

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 5 Dec 2015 09:27:08 +0000 (UTC)

A corrupted packet can have a corrupted protocol identifier.Corrupt it to something handled by a NAT ALG, and it can be processed...one reason checksums matter. 

(What is usual NAT ALG behaviour on udp with zero checksums? I'm guessing they process and pass those packets, which would make MPLS-in-zero UDP generally useful.)

Lloyd [email-masked]

On Saturday, December 5, 2015, 2:08 PM, Black, David <[email-masked]> wrote:

<WG chair hat OFF>

Thoughts?

</WG chair hat OFF>

Thanks,
--David

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 5 Dec 2015 09:27:08 +0000 (UTC)

<WG chair hat OFF>

Thoughts?

</WG chair hat OFF>

Thanks,
--David

---

From: [email-masked]
Date: Sun, 6 Dec 2015 08:09:02 -0000

> be a "feature" for some new UDP tunnel encapsulations ... seriously.
You mean a new checksum rather than the UDP one - indeed - and I've said
the same.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 6 Dec 2015 14:47:15 -0800

> You mean a new checksum rather than the UDP one - indeed - and I've said
Unfortunately, it seems unlikely we would be a able distinguish a
translated address from a corrupted one with such a checksum.

---

From: [email-masked]
Date: Mon, 7 Dec 2015 08:13:20 -0000

> translated address from a corrupted one with such a checksum.
I was agreeing with this. If you embed a payload checksum of IP headers
in  the encapsulation you can effectively prevent packets emerging on
home IPv4 networks that are intended only for operator networks. (Of course
a NAPT could snoop the payload find the checksum and fix it - but that's
not going to happen.)

For IPv6, we assume no NAPT - only firewall policies and other
middle-boxes that enforce policies. Which means the above
is not true for IPv6 - which I think was where we started the discussion.

Gorry

>>> an ALG is added to the NAT to fix up that new checksum (this assumes
>>> that
>>> the
>>>> >> I think this version is reasonably good wrt my concerns, but I'd
>>>> like
>>>> to

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 Dec 2015 22:02:53 +0000

The leaking issue is unexpected. However there may be the case that UDP tunnel need to pass through NAPT in IPv4. In this case, UDP src port ECMP usage has conflict with UDP port usage in NAPT. Thus, if UDP tunnel is intended to pass through a NAPT, UDP src port ECMP usage needs to be disabled. NAPT recalculate the UDP checksum if it is not-zero.

Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 07, 2015 2:13 AM
To: Tom Herbert
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

>>>>> The following text was added to help with the difficulties 
>>>>> encountered in dealing with UDP zero-checksum for IPv6:
>>>>>
>>>>>       To protect
>>>>> I'd like to add a warning here to designers of what may happen if 
>>>>> that SHOULD is not followed, e.g. (borrowing some of RFC 2119's 
>>>>> choice of words):
>>>>>
>>>> draft-rtg-dt-encap-01. I'd also point out that mis-delivering 
>>>> packets in a multi-tenant environment may not be innocuous at all, 
>>>> so I think "carefully weigh the full implications" is an appropriate directive.
>>>
>>> in Yokohama (IIRC), someone pointed out to me that a checksum that 
>>> covers the IPv6 header and the UDP header won't go through existing 
>>> NATs.
>>>
>>> In the original discussion, that sounded like a "bug" ... but it 
>>> might be a "feature" for some new UDP tunnel encapsulations ... seriously.
>>>
>> You mean a new checksum rather than the UDP one - indeed - and I've 
>> said the same.
>>
I was agreeing with this. If you embed a payload checksum of IP headers in  the encapsulation you can effectively prevent packets emerging on home IPv4 networks that are intended only for operator networks. (Of course a NAPT could snoop the payload find the checksum and fix it - but that's not going to happen.)

For IPv6, we assume no NAPT - only firewall policies and other middle-boxes that enforce policies. Which means the above is not true for IPv6 - which I think was where we started the discussion.

Gorry

>>> recent "pain and suffering" in UDP encap design has been the 
>>> consequences of UDP being able to reach places that the encapsulated 
>>> protocol can't.
>>> Among the results are needing to pay a lot more attention to 
>>> congestion considerations, and having to provide guidelines on preventing "escape"
>>> of IPv6/UDP encap traffic with zero UDP checksums from the networks 
>>> that the traffic is intended for.
>>>
>>> In contrast to UDP reachability, ECMP seems to be the much more 
>>> important motivation for quite a bit of the recent UDP encap work 
>>> (e.g., that's definitely my impression for both MPLS/UDP and 
>>> GRE/UDP).
>>>
>>> An interesting property of a header checksum in a new encapsulation 
>>> that covers at least the IPv6, UDP, and shim headers is that the 
>>> checksum works fine with ECMP (including LAG), but breaks when going 
>>> through a NAT, unless an ALG is added to the NAT to fix up that new 
>>> checksum (this assumes that the packet arrives at a tunnel egress 
>>> that understands the tunnel and does verification of the header 
>>> checksum).
>>>
>>> That property may help keep traffic using the new encapsulation 
>>> where it belongs, as any NAT is automatically a barrier to "escape" 
>>> (or has to be modified with an ALG) insofar as endpoints that 
>>> understand the new encap are concerned.  That "escape" barrier 
>>> property of NATs might even be a reason to suggest such checksums 
>>> for IPv4 (although I don't think that suggestion merits the strength 
>>> of an RFC 2119 "SHOULD" keyword).
>>>
>>> Thoughts?
>>>
>>> </WG chair hat OFF>
>>>
>>> Thanks,
>>> --David
>>>
>>>> > On Sun, Nov 22, 2015 at 6:39 PM, Black, David 
>>>> > <[email-masked]>
>>>> wrote:
>>>> >> As WG chair:
>>>> >>
>>>> >> order to provide time for additional reviews (e.g., Erik 
>>>> >> Nordmark promised to check this against the encapsulation draft 
>>>> >> in RTGWG).
>>>> >>
>>>> >> <WG chair hat OFF>
>>>> >>
>>>> >>               integrity check at the transport layer that 
>>>> >> includes
>>>> at
>>>> >> least the
>>>> >>               IPv6 header, the UDP header and the shim header 
>>>> >> for
>>>> the
>>>> >> I'd like to add a warning here to designers of what may happen 
>>>> >> if
>>>> that
>>>> >> SHOULD is
>>>> >>                 and provide alternative assurances that 
>>>> >> misdelivery
>>>> is
>>>> >> unlikely.
>>>> >>            o  One way to help satisfy the requirements of 
>>>> >> [RFC6936]
>>>> may
>>>> >> be to
>>>> >>                 or set of closely cooperating networks, as 
>>>> >> further described in
>>>> >>                 Section 3.6 below, see [RFC7510] for an example 
>>>> >> of
>>>> this
>>>> >> approach).
>>>> >>
>>>> >>
>>>> >> </WG chair hat OFF>
>>>> >>
>>>> >> Thanks,
>>>> >> --David
>>>> >> David L. Black, Distinguished Engineer EMC Corporation, 176 
>>>> >> South St., Hopkinton, MA  01748