Subject: Re: [Maprg] UDP zero-checksum in IPv4

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 10 Mar 2016 17:36:39 +0000

CC maprg

On 2016-03-10, at 18:29, Poscic, Kristian (Nokia - US) <[email-masked]> wrote:
> 
> Hi,
> 
> Does anyone have any info on the percentage of UDP packets with zero-checksum
> for IPv4 packets in today’s networks (enterprise, internet, any network).
> Seems like there is not a whole lot of info about this on the WEB. Anyone has any firsthand/realworld experience with this? Thanks.
> 
> Kris

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Mar 2016 15:45:18 -0800

On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) <[email-masked]> wrote:
>
>> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) <[email-masked]> wrote:
>>
>> Hi,
>>
> A good place to start might be https://tools.ietf.org/html/rfc6936
> 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
>      Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format:
>      TXT=99557 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936)
>
> The big consideration there is a middleware device (usually a router, but potentially something else) that is receiving packets at line rate one a set of interfaces and funneling them to another interface on which it is obligated to send them tunneled in UDP packets, or a corollary device at the other end of the tunnel. It would be theoretically possible to add hardware that could parse to the correct point and calculate the checksum while the data being received was stored into memory. However, practically, that is far more likely to be done as a second step, to packets it is applicable to. The configuration of a tunnel that creates or verifies a UDP checksum on a tunneled datagram, in such a case, is essentially a DOS vector.
>
Note that this problem is mostly specific to switches that lack HW to
efficiently perform checksum. On the host side, we have long standing
support in NIC HW to to perform checksum offload (whether UDP sends
zero checksum in IPv6, checksums are always used in TCP so we need a
host solution regardless!). Due to the capabilities of currently
deployed NICs, we get much better performance with the UDP checksum
enabled for tunnels when sourcing or terminating tunnels on the same
host that sends or receive an encapsulated TCP packet-- in fact the
default was recently changed in Linux to enable checksum for UDP
tunnels (it can still be disabled by per tunnel configuration).

Tom

> Any discussion of "percentages of traffic for which X is true in the Internet" are necessarily vague and hand-wavy. The Internet is the proverbial elephant, and those that would statistically describe it are the proverbial philosophers. How one describes it has a lot to do with what part of it one touches.
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Poscic, Kristian (Nokia - US)" <[email-masked]>
Date: Fri, 11 Mar 2016 06:03:33 +0000

Thanks, this is all helpful.
But let me rephrase the question in hope to get a bit more quantifiable answer:
- can some share user experience (broken apps) when traffic with zero UDP checksum is dropped?

The available options when translating*/tunneling IPv4 UDP packet with zero-checksum into IPv6:
1) drop IPv4 packets with zero UDP checksum, RFC 6145, section 4.5, point 1
2) recalculate UDP checksum in IPv6 packet from scratch RFC 6145, section 4.5, point 2   (calculating UDP checksum from scratch is different that updating is according to RFC 1624 - this would be the case if IPv4 packet would have non-zero checksum)
3) perform translation or encapsulation into IPv6 and leave zero-checksum (UDP)  in IPv6 . This is in violation of RFC 2460, but RFCs 6935 and 6936 alleviate the restriction from RFC 2460 .

Anyone can share experience in terms of broken apps in cases 1 and 3?

*options above apply to tunnels but I see no reason why would they not apply to translations as well (v4->v6)
Thanks.

-----Original Message-----
From: EXT Tom Herbert [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:45 PM
To: Fred Baker (fred)
Cc: Poscic, Kristian (Nokia - US); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] UDP zero-checksum in IPv4

On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) <[email-masked]> wrote:
>> Does anyone have any info on the percentage of UDP packets with 
>> zero-checksum for IPv4 packets in today’s networks (enterprise, internet, any network).
Note that this problem is mostly specific to switches that lack HW to efficiently perform checksum. On the host side, we have long standing support in NIC HW to to perform checksum offload (whether UDP sends zero checksum in IPv6, checksums are always used in TCP so we need a host solution regardless!). Due to the capabilities of currently deployed NICs, we get much better performance with the UDP checksum enabled for tunnels when sourcing or terminating tunnels on the same host that sends or receive an encapsulated TCP packet-- in fact the default was recently changed in Linux to enable checksum for UDP tunnels (it can still be disabled by per tunnel configuration).

Tom

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 10 Mar 2016 21:46:27 +0000

---

From: "Poscic, Kristian (Nokia - US)" <[email-masked]>
Date: Fri, 11 Mar 2016 13:31:47 +0000

The apps are not broken in pure IPv4 environment. But when IPv4 is tunneled/(translated) in IPv6, then they may become broken (between IPv4 end-nodes, with some v6 transport in between) because of inconsistencies in UDP checksum calculation requirement between v4 and v6 (v4 allows zero-checksum for UDP but v6 originally does not - so when v4 is tunneled within v6, the outcome will depend on one of the 3 options below). So I'm just trying to sense how much of a real problem is this today in real networks of today.
  
Simple example to clarify:
- there are two IPv4 end-nodes, N1 and N2 
- somewhere in between there is a part of the network where IPv4 gets tunneled within v6
- N1 sends UDP traffic with zero UDP checksum to N2
- When this traffic gets to the head of v6 tunnel, the node which is supposed to encapsulate it in v6 simply drops it (since RFC 6145 allows this).

Have anyone run into issues like this (customer calling and complaining that their apps not working because of this)?

OR alternatively:
- When this traffic gets to the head of v6 tunnel, the node which is supposed to encapsulate it in v6 simply tunnels it with zero-checksum in v6 header (rather than calculating v6 checksum) - my option 3 below.
- when the node at the tail of the v6 tunnel receives such traffic, it may drop it because RFC 2460 says that is must.

 Same question - have anyone run into issues like this (customer calling and complaining that their apps not working because of this)?

I understand that boxes should do this or that and that RFCs have been amended.  But this is more of a user experience question.

-----Original Message-----
From: EXT [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 11:37 PM
To: Poscic, Kristian (Nokia - US)
Cc: EXT Tom Herbert; Fred Baker (fred); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Int-area] UDP zero-checksum in IPv4

Your subject field says v4, and I don't see why you call these apps "broken". Although IPv4 permits an option to disable their use, because there are good reasons why you may want to do that for a particular application (see references in Fred's reply), the default in RFC768 is for applications SHOULD enable UDP checksums. Echoed in RF5405 as a SHOULD.
Checksums not only validate the payload and the the UDP header, they offer protection from reassembly errors when packets are fragmented.

> But let me rephrase the question in hope to get a bit more 
> quantifiable
> answer:
> 1) drop IPv4 packets with zero UDP checksum, RFC 6145, section 4.5, 
> point
> 1
RFC1122 also contains an option that intentionally discards UDP datagrams received with a zero (Section 4.1.3.4). There are reasons why an application (or host stack) may wish to do this.

> 2) recalculate UDP checksum in IPv6 packet from scratch RFC 6145, section
> 4.5, point 2   (calculating UDP checksum from scratch is different that
> updating is according to RFC 1624 - this would be the case if IPv4 
> packet would have non-zero checksum)

> 3) perform translation or encapsulation into IPv6 and leave 
> zero-checksum
> (UDP)  in IPv6 . This is in violation of RFC 2460, but RFCs 6935 and 
> 6936 alleviate the restriction from RFC 2460 .
>
True, but this is permitted only for some deployment scenarios, as in the encapsulation of MPLS in UPD within an operator network.

> apply to translations as well (v4->v6)
I think so, when translating IPv6 UDP zero checksum to IPv4, but certainly not intended to be permitted when translating to IPv6, unless this was operating within a controlled environment (such as the case in RFC7510).

Gorry

> Cc: Poscic, Kristian (Nokia - US); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
>>> zero-checksum for IPv4 packets in todayâ€™s networks (enterprise, 
>>> internet, any network).
>>> Seems like there is not a whole lot of info about this on the WEB.
>>> Anyone has any firsthand/realworld experience with this? Thanks.
>>>
>>> Kris
>>
>> The big consideration there is a middleware device (usually a router, 
>> but potentially something else) that is receiving packets at line 
>> rate one a set of interfaces and funneling them to another interface 
>> on which it is obligated to send them tunneled in UDP packets, or a 
>> corollary device at the other end of the tunnel. It would be 
>> theoretically possible to add hardware that could parse to the 
>> correct point and calculate the checksum while the data being 
>> received was stored into memory. However, practically, that is far 
>> more likely to be done as a second step, to packets it is applicable 
>> to. The configuration of a tunnel that creates or verifies a UDP 
>> checksum on a tunneled datagram, in such a case, is essentially a DOS vector.
>>
>> Any discussion of "percentages of traffic for which X is true in the 
>> Internet" are necessarily vague and hand-wavy. The Internet is the 
>> proverbial elephant, and those that would statistically describe it 
>> are the proverbial philosophers. How one describes it has a lot to do 
>> with what part of it one touches.
>>

---

From: [email-masked]
Date: Fri, 11 Mar 2016 07:36:43 -0000

Your subject field says v4, and I don't see why you call these apps
"broken". Although IPv4 permits an option to disable their use, because
there are good reasons why you may want to do that for a particular
application (see references in Fred's reply), the default in RFC768 is for
applications SHOULD enable UDP checksums. Echoed in RF5405 as a SHOULD.
Checksums not only validate the payload and the the UDP header, they offer
protection from reassembly errors when packets are fragmented.

> 1) drop IPv4 packets with zero UDP checksum, RFC 6145, section 4.5, point
RFC1122 also contains an option that intentionally discards UDP datagrams
received with a zero (Section 4.1.3.4). There are reasons why an
application (or host stack) may wish to do this.

> updating is according to RFC 1624 - this would be the case if IPv4 packet
> would have non-zero checksum)

> 3) perform translation or encapsulation into IPv6 and leave zero-checksum
> (UDP)  in IPv6 . This is in violation of RFC 2460, but RFCs 6935 and 6936
> alleviate the restriction from RFC 2460 .
>
True, but this is permitted only for some deployment scenarios, as in the
encapsulation of MPLS in UPD within an operator network.

> apply to translations as well (v4->v6)
I think so, when translating IPv6 UDP zero checksum to IPv4, but certainly
not intended to be permitted when translating to IPv6, unless this was
operating within a controlled environment (such as the case in RFC7510).

Gorry

>> but potentially something else) that is receiving packets at line rate
>> one a set of interfaces and funneling them to another interface on which
>> it is obligated to send them tunneled in UDP packets, or a corollary
>> device at the other end of the tunnel. It would be theoretically
>> possible to add hardware that could parse to the correct point and
>> calculate the checksum while the data being received was stored into
>> memory. However, practically, that is far more likely to be done as a
>> second step, to packets it is applicable to. The configuration of a
>> tunnel that creates or verifies a UDP checksum on a tunneled datagram,
>> in such a case, is essentially a DOS vector.
>>
> support in NIC HW to to perform checksum offload (whether UDP sends zero
> checksum in IPv6, checksums are always used in TCP so we need a host
> solution regardless!). Due to the capabilities of currently deployed NICs,
> we get much better performance with the UDP checksum enabled for tunnels
> when sourcing or terminating tunnels on the same host that sends or
> receive an encapsulated TCP packet-- in fact the default was recently
> changed in Linux to enable checksum for UDP tunnels (it can still be
> disabled by per tunnel configuration).
>
> Tom
>
>> proverbial elephant, and those that would statistically describe it are
>> the proverbial philosophers. How one describes it has a lot to do with
>> what part of it one touches.
>>