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

[Ca By <[e-mail]>]

On Monday, May 23, 2016, Tom Herbert <[e-mail]> wrote:

> On Sun, May 22, 2016 at 1:06 PM, Ca By <[e-mail] <javascript:;>>
> wrote:
> >
> >
> > On Sunday, May 22, 2016, Michael Welzl <[e-mail]
> <javascript:;>> 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] <javascript:;>>
> 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?
>
>
My network only "manages" udp.  Ymmv.

UDP based transport protocols would use well know port numbers. A

firewall can allow UDP port X that carries a


>
A "firewall" is a enterprise solution that does not scale for large
national internet providers in the usa

Yes, the bulk of the trash is less than 20 source ports (chargen, ntp,
snmp, ntp, dns, ....). But we also get very large bot swarms doing straight
packet attacks with udp.  Even a novice like me can write to udp sockets in
python on any port and stuff data through it.



>
> 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
> >>
> >
>