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

[<[e-mail]>]

Yes, RFC6936 section 3 cites these concerns. I've cited it previously a number of times in this discussion, perhaps you've just ignored those messages?

RFC6935 ignores the concerns raised by RFC 6936  because, hey, tunnel performance.
And RFC6936, while emphasising considering the effect on the protocol using zero cUP hecksums, does not emphasise considering the effect of those checksums on other applications.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Edward Crabbe [[e-mail]]
Sent: 21 January 2014 20:03
To: Wood L  Dr (Electronic Eng)
Cc: [e-mail]; Eggert, Lars; joel jaeggli; [e-mail]
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Please see 6935,6936.

You've conveniently ignored most if not all of the arguments Curtis has made in the past ~30 messages.  I won't repeat them again here.

If you really are so concerned about potential corruption scatter and header integrity issues beyond FEC/FCS for v6 protocols, perhaps you should propose a v6 checksum hop-by-hop extension header.  :)


On Tue, Jan 21, 2014 at 11:36 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Oh, 'experience' is never a good play; after all, all experience is ultimately anecdotal. But as an argument, it's being used by all sides. We haven't seen missent traffic errors, because we're not looking for them.

The question is, what does the end-to-end argument support?

And surely the burden of proof falls on those making the change (this draft); first, do no harm. The end-to-end principle and the precautionary principle are strong arguments.

Stone's papers, though technologically dated, support the underlying principle and provide analysis - you want a modern setting, I'm quite happy with proof of principle. Weird stuff happens; an end-to-end check can catch it.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Edward Crabbe [[e-mail]<mailto:[e-mail]>]
Sent: 21 January 2014 19:19
To: Wood L  Dr (Electronic Eng)
Cc: [e-mail]<mailto:[e-mail]>; Eggert, Lars; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

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