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
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
Precedence: list

Stewart

the IP header check is not the UDP pseudoheader check - and IPv6 has neithe=
r.

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 t=
he NAT is more likely to reject it as unknown.

'NATs, which rewrite and can trash headers, demonstrate and validate the in=
tegrity of the Internet' is not a good argument imo.

I'd like to see some evidence for '"obscure" IP protocol numbers will get d=
ropped 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 throug=
h 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> (Encapsulati=
ng 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 i=
n UDP. Everything encapsulated with "obscure" IP protocol numbers will get =
dropped by default at NATs and firewalls, whereas UDO traffic happily trave=
rses 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