[mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
<l.wood@surrey.ac.uk> Thu, 09 January 2014 03:00 UTC
Return-Path: <l.wood@surrey.ac.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 860C91AE0A0 for <mpls@ietfa.amsl.com>; Wed, 8 Jan 2014 19:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable
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 J4JPYwjud98j for <mpls@ietfa.amsl.com>; Wed, 8 Jan 2014 19:00:00 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) by ietfa.amsl.com (Postfix) with ESMTP id EAA031AE090 for <mpls@ietf.org>; Wed, 8 Jan 2014 18:59:58 -0800 (PST)
Received: from [195.245.231.67:5848] by server-6.bemta-5.messagelabs.com id 0C/C9-16310-3A01EC25; Thu, 09 Jan 2014 02:59:47 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-12.tower-82.messagelabs.com!1389236387!35269059!1
X-Originating-IP: [131.227.200.39]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27475 invoked from network); 9 Jan 2014 02:59:47 -0000
Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jan 2014 02:59:47 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 9 Jan 2014 02:59:29 +0000
From: l.wood@surrey.ac.uk
To: david.black@emc.com, gorry@erg.abdn.ac.uk
Date: Thu, 09 Jan 2014 02:59:28 +0000
Thread-Topic: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
Thread-Index: AQHPDObQGmJ4SKwhQk6QfMrFWtjgXA==
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346B0@EXMB01CMS.surrey.ac.uk>
References: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF305B4@MX15A.corp.emc.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: ietf@ietf.org, mpls@ietf.org, jnc@mit.edu, lisp@ietf.org, tsvwg@ietf.org
Subject: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)
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: <http://www.ietf.org/mail-archive/web/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: Thu, 09 Jan 2014 03:00:02 -0000
Thanks, David. Apart from the pollute-other-ports aspect that I've discussed in other mails, MPLS itself is not self-checking (GRE is for header and payload - if its optional checksum is used.) Without checking, corrupt the MPLS label, send it to another tunnel. Without checking, corrupt the UDP port, send the packet elsewhere and pollute another port and stream. I see L. Yong and X. Xu, who are coauthors of draft-yong-tsvwg-gre-in-udp-encap, are also authors of draft-ietf-mpls-in-udp which again plays fast and loose with UDP checksums. This is clearly a widespread problem, and the reliability of the internet is being undermined. We can class UDP zero checksum use as an attacks on other streams and services, if that helps. Reliability is an unfashionable topic, but an attack? That must be mitigated immediately. Because they specify zero UDP checksums, I oppose publication of draft-ietf-mpls-in-udp in its current form I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current form. I oppose the IETF lisp documents. regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Black, David [david.black@emc.com] Sent: 08 January 2014 23:20 To: Wood L Dr (Electronic Eng); gorry@erg.abdn.ac.uk Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org Subject: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) Lloyd, <tsvwg WG co-chair hat OFF> This is only at the draft adoption stage - the tsvwg WG gets to take a hard look at the zero checksum conditions in the gre-in-udp-encap draft and make sure that they're right (the WG could even remove the support for zero checksums) - that's among the good reasons for adopting the draft in tsvwg as opposed to elsewhere. Speaking of elsewhere, draft-ietf-mpls-in-udp is in IETF Last Call and has language allowing zero UDP checksums - I might suggest that you (and anyone else who cares about this topic) go read that draft and consider whether making Last Call comments would be appropriate. Thanks, --David </tsvwg WG co-chair hat OFF> > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk > Sent: Wednesday, January 08, 2014 3:58 PM > To: gorry@erg.abdn.ac.uk > Cc: lisp@ietf.org; jnc@mit.edu; tsvwg@ietf.org; ietf@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Zero UDP checksums are being selected for convenience, without an appreciation > of the overall effects and costs on other traffic. I see this is occurring in > both tsvwg > and lisp, and it's probably happening elsewhere: > > From the recently adopted by tsvwg draft: > http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 > To simplify packet processing at the tunnel egress, packets destined > to this assigned UDP destination port [TBD] SHOULD have their UDP > checksum and Sequence flags set to zero because the egress tunnel > only needs to identify this protocol. Although IPv6 [RFC2460] > restricts the processing a packet with the UDP checksum of zero, > [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP > checksum. > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > > (That's a misreading of Saltzer - the UDP checksum is also protecting against > misdelivery and pseudoheader corruption, and 'usually' is not a good defence. > For shame, Noel.) > > After all, the best examples of end2end systems failure are with zero > checksums > at the endhosts. > > The TCP and UDP checksums catch significant numbers of errors, e.g. Stone's > work: > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > and some of those errors will appear in the headers, where they will send > the data to other ports and destinations. > > The potential for polluting other ports and applications because > there is no pseudoheader demultiplexing sanity check is there. > > IPv6 leaving this check implemented on a per-transport basis has opened the > door, > and rewriting that section of RFC2460 in RFC6935 has taken the door off its > hinges. > These RFCs break the minimal multiplexing pseudoheader sanity check that > RFC2460 > offered; IPv6 is a mess in so many ways, but making it worse? > > I think publishing RFC6935 and 6936 and letting in zero checksums again to > IPv6 > was a mistake, frankly. (alas, I wasn't paying much attention at the time - > moving countries etc.) > > A strong recommendation that UDP-Lite covering headers offers minimal > computation > overhead on tunnelled packets while protecting against polluting other ports > is one > solution, while acknowledging deployment limitations. Section 2.4 of RFC696 is > mostly there. > But zero UDP checksums should always come with copious warnings on the effects > not on the > carried traffic, which can have its own payload checks, but on traffic sharing > the network > with traffic delivered with zero UDP checksums. Drafts relying on zero > checksums should be discouraged, not adopted by workgroups. > > It's a tragedy of the commons, but the I'm-alright-Jack engineers who want > zero udp checksums for their traffic, and do protect against the effects of > zero > checksums on their own payloads, won't care about effects on other traffic. > Hey, maybe this should be treated as an attack, which falls under perpass? > That > should get it attention... > > tsvwg needs to give (or get) some careful input on the implications here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Sent: 08 January 2014 12:55 > To: Wood L Dr (Electronic Eng) > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Lloyd, > > Here is a little context... which could help. The IETF agreed to update > the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the > applicability specified in RFC 6936. > > One of the reasons why a simple encapsulation like this needs to be done > in tsvwg is to minimise the end-to-end implications on other traffic. > Sure, using a zero checksum has such implications, and my own first > concern is that the new GRE-in-UDP work follows the applicability > statement in RFC 6936. To me, it seems the authors are heading this way - > but maybe more help is needed. It would be no bad thing to highlight the > implications of using zero checksums on other traffic. > > Gorry > > > Am I the only one who finds putting zero checksums in proposed standards > > to be a worrying > > trend? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of IETF Secretariat > > [ietf-secretariat-reply@ietf.org] > > Sent: 07 January 2014 20:20 > > To: tsvwg@ietf.org > > Subject: [tsvwg] Milestones changed for tsvwg WG > > > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > > IESG as a PS RFC", due December 2014. > > > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > > > >
- [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp … l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Randy Bush
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Adrian Farrel
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- [mpls] misdelivered mpls packets - Was: Re: draft… Loa Andersson
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Gregory Mirsky
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Huub van Helvoort
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Andrew G. Malis
- Re: [mpls] misdelivered mpls packets - Was: Re: d… David Allan I
- Re: [mpls] misdelivered mpls packets - Was: Re: d… Curtis Villamizar
- Re: [mpls] misdelivered mpls packets - Was: Re: d… l.wood
- [mpls] OT was Re: draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… l.wood
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Wesley Eddy
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … Dino Farinacci
- Re: [mpls] [lisp] draft-ietf-mpls-in-udp was RE: … gorry
- Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Curtis Villamizar
- Re: [mpls] OT was Re: draft-ietf-mpls-in-udp was … Mark Tinka
- [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE:… Curtis Villamizar
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Randy Bush
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Stewart Bryant
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… l.wood
- Re: [mpls] mpls-in-udp entropy Eric Rosen
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… gorry
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in… Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Curtis Villamizar
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein
- Re: [mpls] mpls-in-udp entropy Curtis Villamizar
- Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp … Saku Ytti
- Re: [mpls] mpls-in-udp entropy Alexander Vainshtein