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

[Edward Crabbe <[e-mail]>]

I don't think the 'experience' card is such a good play here Lloyd.  Many
people on this list, and certainly a few of the ones you've been directly
arguing with, have no small amount experience running *extremely* large,
geographically distributed networks.   I've spent a bit of time running
some very large backbones and major content providers myself, and I have to
say, I'm finding most of your arguments here to be unconvincing at best.

I do find it a bit ironic that you're asking for (difficult to gather,
vendor variable and generally poorly documented) data form Stewart, when
your own argument has yet to be substantiated via any form of quantitative
impact analysis, either empirically or theoretically in a modern setting.
 I'd be interested in seeing empirical (back)scatter collection data
(similar to what Morley or Savage have done) to get some idea of impact
here.  I strongly suspect that corruption scatter will be trivial, and
certainly completely overwhelmed in terms volume by typical, day to day
DDoS backscatter.  Perhaps this may be an idea for your next research paper?

With regard to the congestion-control-of-all-tunnel-protocols argument: I
find the argument to be specious.  Curtis summed up the end-to-end version
of this argument pretty succinctly in an earlier email, to wit:

If congestion aware or using a congestion aware transport, the top
level applications are still congestion aware.  If congestion
ignorant, they are still congestion ignorant.  If hostile, they are
still hostile.


On Tue, Jan 21, 2014 at 9:56 AM, <[e-mail]> wrote:

> 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 [[e-mail]]
> Sent: 21 January 2014 12:29
> To: Eggert, Lars
> Cc: Wood L  Dr (Electronic Eng); [e-mail]; Joel Jaeggli;
> [e-mail]
> 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 <[e-mail]> 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
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>