Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

[Tom Herbert <[e-mail]>]

On Sun, May 22, 2016 at 1:06 PM, Ca By <[e-mail]> wrote:
>
>
> On Sunday, May 22, 2016, Michael Welzl <[e-mail]> wrote:
>>
>> Hi,
>>
>> I still didn’t get to read the draft - apologies!  I probably like it  :-)
>> but I hope it allows putting multiple TCP connections under one single UDP
>> 5-tuple.
>> Anyway, not speaking pro- or con- this draft, just a comment in line:
>>
>>
>> On 22. mai 2016, at 05.03, Jana Iyengar <[e-mail]> wrote:
>>
>> Possibly unsurprisingly, I like this draft. I'd like to argue some of the
>> choices made in the draft but I'll do that separately. For now, I just
>> wanted to articulate a few thoughts as I caught up on this thread:
>>
>> - The ship has sailed on new native-IP transports. I worked on SCTP for 6
>> years and tried and watched it get nowhere in terms of deployment over
>> native-IP. It wasn't because it was in the kernel, it was primarily because
>> of NATs and various middleboxes. Yes this is definitely my opinion, but
>> arguing this point is silly. No new native IP transport has seen significant
>> deployment over the internet over the past 20 years, and it's not for lack
>> of trying.
>>
>> “The ship has sailed” and “it’s not for lack of trying” are both wrong
>> IMO. How many applications have tried to use SCTP/IP and fallen back to TCP
>> in case it doesn’t work? How many applications do you expect to change in
>> order to get such a change to happen? And why should anyone expect someone
>> designing or maintaining a router or middlebox to support native SCTP when
>> they never even see the packets and never even hear anyone say “my
>> application works better elsewhere because of SCTP” ?
>>
>> This is what TAPS is trying to address. It’s a very deep architectural
>> problem of the Internet - an inability to automate fall-backs, which
>> unnecessarily burdens application developers. Rant, rant, rant, make me stop
>> :-)
>>
>> Now all this being said, I also don’t fully get why some folks have such a
>> big problem with running stuff over UDP. I’m not against doing that, if only
>> as a temporary solution that would serve to convince people that the
>> transport (option, ..) is useful.
>> In a TAPS world, it’s just another option to try…
>>
>
> The fact that udp is mostly (by volume) internet attack traffic  is my
> concern with udp.
>
> If legitimate traffic starts using udp in volume, it will make distiguishing
> and thwarting voulmetric attacks very difficult at scale. Without currently
> curbing n * 100g blasts of udp traffic with blanket policers, i would not be
> able to keep my network up... This is a daily issue.  For example, my usual
> udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to
> drop 11% and onwards as a 10x increase in udp is 100% certainly not legit.
>
> My request to quic and spud is simply use a different transport protocol
> number so that their interesting and innovative traffic does not run up
> against the many network policers that are required to enforce well known
> baselines of good normal udp traffic. The quic folks say that they cannot do
> that since 10 year old cpe only passes udp and tcp, then they rant about
> ossified stacks and how we need to put everything on udp to make progess ...
> Seems like they are just choosing to ossify on udp ...  And udp is already
> considered trash (reflection attacks) ...So we agree to disagree, i guess
>
Isn't any other protocol besides TCP also considered trash right now?

UDP based transport protocols would use well know port numbers. A
firewall can allow UDP port X that carries a properly congestion
controlled protocols not subject to reflection attacks, but disallow
other UDP ports.

Tom

> https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00
>
>
>
>> Cheers,
>> Michael
>>
>