Re: [mpls] [tsvwg] on UDP encapsulation
"Black, David" <david.black@emc.com> Mon, 16 November 2015 00:53 UTC
Return-Path: <david.black@emc.com>
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 D3E261AD06C; Sun, 15 Nov 2015 16:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.987
X-Spam-Level:
X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] 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 0gvZi8ryzbb5; Sun, 15 Nov 2015 16:53:03 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 BB5401AD06B; Sun, 15 Nov 2015 16:53:02 -0800 (PST)
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tAG0r1b9016555 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Nov 2015 19:53:01 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tAG0r1b9016555
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1447635181; bh=ZiQZ1/fWOdSNbwcQorAsjmluIBk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kEznhC6BwXhoB9zEHufvJ7ZsgM5LR9QrkNRpo3FDpVuPbfpOZ4QXdtfxb3nsphwUw L7Gn/ch0s3p1B9UGHBpsKjOeqZNZhsdGbdkT8gefeub0x5aFkY/PTWqHg4Xsmp1IXg o6OD3kBa+yIczU06H4bQQNkobWSg7NoYW9vTyXbM=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tAG0r1b9016555
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Sun, 15 Nov 2015 19:52:33 -0500
Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tAG0qdUQ022401 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Nov 2015 19:52:39 -0500
Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub37.corp.emc.com (128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 15 Nov 2015 19:52:39 -0500
Received: from MX104CL02.corp.emc.com ([169.254.8.181]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0266.001; Sun, 15 Nov 2015 19:52:39 -0500
From: "Black, David" <david.black@emc.com>
To: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
Thread-Topic: [tsvwg] on UDP encapsulation
Thread-Index: AQHRHooXmlQwuKJBcEaQR2aQKcOP956cJQwAgAGnwzA=
Date: Mon, 16 Nov 2015 00:52:38 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493621ED33A6@MX104CL02.corp.emc.com>
References: <580302963.7269727.1447470634943.JavaMail.yahoo.ref@mail.yahoo.com> <580302963.7269727.1447470634943.JavaMail.yahoo@mail.yahoo.com> <CALx6S37uFpzx8_Cz4WjV2Boo0rD_6NP-X2MAmvuCt3S0KkSVCA@mail.gmail.com>
In-Reply-To: <CALx6S37uFpzx8_Cz4WjV2Boo0rD_6NP-X2MAmvuCt3S0KkSVCA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.105.41.26]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/yWQC8ChsbQiHMndHOC5npIyk_0U>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Black, David" <david.black@emc.com>, "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
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: Mon, 16 Nov 2015 00:53:05 -0000
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
- [mpls] Fw: on UDP encapsulation lloyd.wood
- Re: [mpls] [tsvwg] on UDP encapsulation Tom Herbert
- Re: [mpls] [tsvwg] on UDP encapsulation Black, David
- Re: [mpls] [tsvwg] on UDP encapsulation lloyd.wood