IETF Logo Mail Archive

Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

<l.wood@surrey.ac.uk> Tue, 21 January 2014 17:56 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 2930B1A0365 for <mpls@ietfa.amsl.com>; Tue, 21 Jan 2014 09:56:38 -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=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 UP4WFX2A43jC for <mpls@ietfa.amsl.com>; Tue, 21 Jan 2014 09:56:35 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB21A018E for <mpls@ietf.org>; Tue, 21 Jan 2014 09:56:35 -0800 (PST)
Received: from [195.245.231.67:27711] by server-3.bemta-5.messagelabs.com id C8/E5-04773-2D4BED25; Tue, 21 Jan 2014 17:56:34 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-9.tower-82.messagelabs.com!1390326993!29955923!1
X-Originating-IP: [131.227.200.35]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12403 invoked from network); 21 Jan 2014 17:56:33 -0000
Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 17:56:33 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 21 Jan 2014 17:56:33 +0000
From: l.wood@surrey.ac.uk
To: stbryant@cisco.com, lars@netapp.com
Date: Tue, 21 Jan 2014 17:56:32 +0000
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: Ac8WpF8KNXZ4WxXGQNSyADM25xOoDgALJ+Sx
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346D9@EXMB01CMS.surrey.ac.uk>
References: Your message of "Fri, 17 Jan 2014 23:00:33 +0000." <290E20B455C66743BE178C5C84F1240847E63346D1@EXMB01CMS.surrey.ac.uk>, <201401202247.s0KMllSl047284@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346D6@EXMB01CMS.surrey.ac.uk> <52DE5F19.1060907@cisco.com> <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>, <52DE680C.30704@cisco.com>
In-Reply-To: <52DE680C.30704@cisco.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: joelja@bogus.com, mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
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: Tue, 21 Jan 2014 17:56:38 -0000

Stewart

the IP header check is not the UDP pseudoheader check - and IPv6 has neither.

If a NAT gets a corrupted header, won't it open up new state and attempt to translate for that header? Remember, this is UDP, not TCP - it's not on an existing connection that must have already been opened by SYN/ACK, where the NAT is more likely to reject it as unknown.

'NATs, which rewrite and can trash headers, demonstrate and validate the integrity of the Internet' is not a good argument imo.

I'd like to see some evidence for '"obscure" IP protocol numbers will get dropped by default at NATs and firewalls.'. IP/GRE is relatively state-free, nothing much to translate at transport there - it's not SCTP. I've spent a couple of years running an ISP, and the 'oh, that protocol won't go through your NAT' has not come up.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stewart Bryant [stbryant@cisco.com]
Sent: 21 January 2014 12:29
To: Eggert, Lars
Cc: Wood L  Dr (Electronic Eng); curtis@ipv6.occnc.com; Joel Jaeggli; mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

On 21/01/2014 12:07, Eggert, Lars wrote:
> Hi,
>
> On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com> wrote:
>> In terms of congestion and misdelivery it is interesting looking
>> at the number of horses that are already bounding around
>> in the paddock outside the stable:
>>
>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> there is a big difference between encapsulation in IP and encapsulation in UDP. Everything encapsulated with "obscure" IP protocol numbers will get dropped by default at NATs and firewalls, whereas UDO traffic happily traverses them. The reach of UDP traffic is much broader.
>
> Lars
So we have established that it's not the load on the NATs and Firewalls
we are worried about.

Seemingly from the above congestion is off the table as well.

Now surely those same NATs and firewalls will be looking for an SA, DA,
Type, SP, DP match
and that is a lot of things that have to be right for a header
corruption misdelivery to get
through.

- Stewart

v2.23.0 | Report a Bug | By Email