Re: [mpls] [tsvwg] on UDP encapsulation

<lloyd.wood@yahoo.co.uk> Sun, 22 November 2015 11:23 UTC

Return-Path: <lloyd.wood@yahoo.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7E1B3240 for <mpls@ietfa.amsl.com>; Sun, 22 Nov 2015 03:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 JTqaL40U5jgH for <mpls@ietfa.amsl.com>; Sun, 22 Nov 2015 03:23:36 -0800 (PST)
Received: from nm42-vm8.bullet.mail.ne1.yahoo.com (nm42-vm8.bullet.mail.ne1.yahoo.com [98.138.120.214]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96AA1B323E for <mpls@ietf.org>; Sun, 22 Nov 2015 03:23:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1448191416; bh=W6EhGzz2p5W3QH9lbGXnmul8VAoarnpMqzwRx0XMOs8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dKkXVVrqhIrV26tQb4PvHW3yOvhxBl16y/iHmkwqDSuBQbfTsMbAx/WfXYWw/aLhcsnLDi2MX6uWP1DqzBgyrJ8z3T2MxB/0Kk3fS+P5C5Uqy4sJjQJV+TX7j674nsXB1EOMu9LVqg9Z0hEuIpFdbBvcw8roUj2S/581LTzO9P1KHRenZpVYk5BBN0x2Rg3QVdoQqzhjZhxo0wM/n7UW5dRjqx9Ws20Wimf0RbJ3IGjmlVTF+GSZiI9kLcOPiJYhEr2A2c/t89pcrGZLMvj5V/zAiNOVGRR5dyNDnGQhUXIVlq1W7Qw4eoWyoSlaFCQ5f5TmZUaEtHjlCeHgLjWUtg==
Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 22 Nov 2015 11:23:36 -0000
Received: from [98.138.100.118] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 22 Nov 2015 11:20:39 -0000
Received: from [212.82.98.124] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 22 Nov 2015 11:20:38 -0000
Received: from [212.82.98.71] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 22 Nov 2015 11:20:38 -0000
Received: from [127.0.0.1] by omp1008.mail.ir2.yahoo.com with NNFMP; 22 Nov 2015 11:20:38 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 732725.82976.bm@omp1008.mail.ir2.yahoo.com
X-YMail-OSG: iojjw3UVM1mjss2m3ugSPXZ2Fv4kP7hw9Vlt0nprHqLB05EUCRLsZc5lTIl2Ai0 2X.sei.ZnmKUvUHNz4NGXZLQ0aaMFsow0E.hEPw.sMh4eLKeM.WDSWCl4ZV92tlaY_Rs84dagLlZ XM1b15xXaFxvZIUz2mDWbg2JTJ.cpgdw6iWNHIjX8ZiPnzlKqi6FIfSauYnUpn5azZK81dytirSV UbYBICH.A.GI_J5AFGuaJbZtg9kZuZ48FzRpQ2hanxyAFMNoVzEThtKOQ4RYUImrtm2UplBHeJel DERoy.aHvIEkkHQLhIbcDnyjM199vMxjDSSJbxwvdsx9GNDlP4ERio8J6RhY2F_953yGraKiKrlD WR6KWHocZFE5eylM8cRKbw_578iIEtmRAGHfqXsKFode4K1Qqk.oUg3jlogGXDVm17eeXlt_LZ5R ZmHNCS20PcQ.wRniq7HF5zO.9nfS1I4xyexmYx1uHfoLF9UQKR_SZPusMLLcGxeB5eU1PqRvjheJ 0UlxkPmiSpUpV0Fb9864-
Received: by 212.82.98.116; Sun, 22 Nov 2015 11:20:38 +0000
Date: Sun, 22 Nov 2015 11:20:37 +0000
From: lloyd.wood@yahoo.co.uk
To: "Black, David" <david.black@emc.com>, Gorry Fairhust <gorry@erg.abdn.ac.uk>, Lars Eggert <lars@netapp.com>
Message-ID: <1078701283.13763942.1448191237743.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D2432779493621ED33A6@MX104CL02.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D2432779493621ED33A6@MX104CL02.corp.emc.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_13763941_1281877583.1448191237743"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/FRRthXT8_uqtEaiqy2RouuRehUc>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [mpls] [tsvwg] on UDP encapsulation
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: lloyd.wood@yahoo.co.uk
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Nov 2015 11:23:40 -0000

David,
good idea. My suggested changes to RFC5405bis's UDP-Lite section, touching on processing overheads, Lite as a preferable alternative to zero checksums etc., are attached. Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood  


    On Monday, 16 November 2015, 11:53, "Black, David" <david.black@emc.com> wrote:
 

 Lloyd,

> > I finally noticed that RFC7510, on MPLS in UDP encap, has
> > been published. Do take a look at all of section 3, which
> > laboriously goes through the nuances of when to choose
> > between UDP checksums, for safety, and turning them off,
> > for speed, at slight risk. That section and the RFCs it
> > refers to are quite the complex read. And that's just on
> > UDP checksums and whether to choose to turn them off. (It
> > gives dull security documents a run for their money.)

To complete the picture, UDP checksums come up again in the
final paragraph of the security considerations section ;-).

With respect to UDP-Lite, Tom described the primary consideration
for MPLS/UDP:

> Also, one of primary reasons for UDP encapsulation (e.g. MPLS/UDP,
> GRE/UDP) is to get ECMP in the network for non-TCP, non-UDP protocols.

That consideration ruled out UDP-Lite for the specific MPLS/UDP encap.
However, a discussion of the applicability and merits of UDP-Lite for
this sort of encap would be germane to the UDP Usage Guidelines draft,
draft-ietf-tsvwg-rfc5405bis:

    http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

Could I ask you to take a look at that draft?  TSVWG plans to send
it to the IESG in the near future.

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tom Herbert
> Sent: Saturday, November 14, 2015 1:06 PM
> To: lloyd.wood@yahoo.co.uk
> Cc: mpls@ietf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] on UDP encapsulation
> 
> On Fri, Nov 13, 2015 at 7:10 PM,  <lloyd.wood@yahoo.co.uk> wrote:
> > https://tools.ietf.org/html/rfc7510
> >
> > I finally noticed that RFC7510, on MPLS in UDP encap, has
> > been published. Do take a look at all of section 3, which
> > laboriously goes through the nuances of when to choose
> > between UDP checksums, for safety, and turning them off,
> > for speed, at slight risk. That section and the RFCs it
> > refers to are quite the complex read. And that's just on
> > UDP checksums and whether to choose to turn them off. (It
> > gives dull security documents a run for their money.)
> >
> > What's odd is that this is standards track, and the third
> > option, use standards-track UDP-Lite to provide checksum
> > protection of the UDP/IP pseudoheader to avoid zero-checksum
> > port pollution on the host (on IPv4) or anywhere pollution
> > (IPv6) is not mentioned as an alternative - particularly as
> > UDP-Lite's partial payload coverage can cover the MPLS stack
> > s well.
> >
> > In some cases the Lite checksum is just a precomputed value
> > across a generated header that doesn't change, at no encode
> > cost and little decode cost, and within corporate private
> > networks the barriers to running UDP-Lite are less.
> >
> > It's unfortunate that UDP-Lite is the ideal approach for
> > this, yet doesn't deserve consideration. Going back further
> > in time, one might argue it's unfortunate that UDP-Lite was
> > pushed to a separate protocol number, dooming it to oblivion.
> > And, further back, that it was unfortunate that designers of
> > IPv6 thought leaving the pseudo-header demux check up to
> > separate transports that could then skip it, while insisting
> > UDP always have its checksum on, which was always going
> > to be relaxed, was a good idea for consistent error-detecting
> > demux...
> >
> 
> Lloyd, the potential for UDP-Lite is mentioned in Encapsulation
> Considerations draft (draft-ietf-rtgwg-dt-encap-00):
> 
> "Conceptually, the ideal solution to this problem is a checksum that
>    covers only the newly added headers of interest.  There is little
>    value in the portion of the UDP checksum that covers the encapsulated
>    packet because that would generally be protected by other checksums
>    and this is the expensive portion to compute.  In fact, this solution
>    already exists in the form of UDP-Lite and UDP based encapsulations
>    could be easily ported to run on top of it.  Unfortunately, the main
>    value in using UDP as part of the encapsulation header is that it is
>    recognized by already deployed equipment for the purposes of ECMP,
>    RSS, and middlebox operations.  As UDP-Lite uses a different protocol
>    number than UDP and it is not widely implemented in middleboxes, this
>    value is lost.  A possible solution is to incorporate the same
>    partial-checksum concept as UDP-Lite or other header checksum
>    protection into the encapsulation header and continue using UDP as
>    the outer protocol.  One potential challenge with this approach is
>    the use of NAT or other form of translation on the outer header will
>    result in an invalid checksum as the translator will not know to
>    update the encapsulation header."
> 
> IMO, the allowance that nodes may send a zero UDP checksum is a
> concession being made for devices that are unable to perform the
> computation. These are precisely devices in the network that before
> the advent of UDP tunneling never had any reason to source UDP
> packets. At end hosts we've had checksum offload capabilities in NICs
> for years, so there is no reason a host should send zero UDP checksums
> for IPv6 (except if it knows that the receiver is an aforementioned
> device that can't do the checksum calculation).
> 
> Also, one of primary reasons for UDP encapsulation (e.g. MPLS/UDP,
> GRE/UDP) is to get ECMP in the network for non-TCP, non-UDP protocols.
> For IPv6 we can use the flow label to provide for this in lieu of
> devices parsing the transport layer (RFC6438). We do need switch
> support for this and there does seem to be good progress on this. So
> the use of the flow label for ECMP should obviate the motivation to
> use UDP encapsulation in the first place (for many use cases).
> 
> Tom