Re: [Softwires] [Int-area] UDP zero-checksum in IPv4

"Poscic, Kristian (Nokia - US)" <kristian.poscic@nokia.com> Fri, 11 March 2016 13:32 UTC

Return-Path: <kristian.poscic@nokia.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3712D6AE; Fri, 11 Mar 2016 05:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KtVOwwKsZpi; Fri, 11 Mar 2016 05:32:10 -0800 (PST)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB62612D6A1; Fri, 11 Mar 2016 05:32:10 -0800 (PST)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id DC7C1E899F8E5; Fri, 11 Mar 2016 13:32:07 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u2BDW8AF029243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 13:32:08 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u2BDW6qe006330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Mar 2016 13:32:07 GMT
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 11 Mar 2016 08:31:48 -0500
From: "Poscic, Kristian (Nokia - US)" <kristian.poscic@nokia.com>
To: "EXT gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
Thread-Topic: [Int-area] UDP zero-checksum in IPv4
Thread-Index: AdF68bLe5SvLau+lRPK5dqDoIJSUhwAToJGAAAQmmgAAAgwbsAAOarCAAABqszA=
Date: Fri, 11 Mar 2016 13:31:47 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F0BEA30554@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com> <CALx6S34t3KVfEOnh+3vGqZJ1OQUUXg5CwSquaxaWj47khQqFSQ@mail.gmail.com> <7921F977B17D5B49B8DCC955A339D2F0BEA2DF61@US70UWXCHMBA05.zam.alcatel-lucent.com> <fc30e93da2d37e60e4fa81f47e73988a.squirrel@erg.abdn.ac.uk>
In-Reply-To: <fc30e93da2d37e60e4fa81f47e73988a.squirrel@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/sXj07BnKwYIs5vhbfIyOMhHeOEE>
Cc: "maprg@irtf.org" <maprg@irtf.org>, "int-area@ietf.org" <int-area@ietf.org>, EXT Tom Herbert <tom@herbertland.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "Fred Baker (fred)" <fred@cisco.com>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] [Int-area] UDP zero-checksum in IPv4
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2016 13:32:13 -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 gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] 
Sent: Thursday, March 10, 2016 11:37 PM
To: Poscic, Kristian (Nokia - US)
Cc: EXT Tom Herbert; Fred Baker (fred); softwires@ietf.org; tsv-area@ietf.org; int-area@ietf.org; maprg@irtf.org
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.

> 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
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.

> 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)
>
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

> Thanks.
>
>
> -----Original Message-----
> From: EXT Tom Herbert [mailto:tom@herbertland.com]
> Sent: Thursday, March 10, 2016 3:45 PM
> To: Fred Baker (fred)
> Cc: Poscic, Kristian (Nokia - US); softwires@ietf.org; 
> int-area@ietf.org; tsv-area@ietf.org; maprg@irtf.org
> Subject: Re: [Int-area] UDP zero-checksum in IPv4
>
> On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) <fred@cisco.com>
> wrote:
>>
>>> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) 
>>> <kristian.poscic@nokia.com> 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
>>
>> 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
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>