nanog mailing list archives
Re: UDP clamped on service provider links
From: Jason Baugher <jason () thebaughers com>
Date: Thu, 30 Jul 2015 23:07:43 -0500
Oh, I'm aware of the function of an NNI. I even accept that a carrier might feel the need to filter bad traffic. I've certainly done so for things like the Moon exploit. What I don't like is arbitrary filtering of traffic and the denial of such filtering by the carrier. On Thu, Jul 30, 2015 at 10:51 PM, Ca By <cb.list6 () gmail com> wrote:
On Thursday, July 30, 2015, Jason Baugher <jason () thebaughers com> wrote:Several months ago we had an issue with a customer whose IPSEC tunnels we manage. One of the tunnels dropped, and after troubleshooting we were able to prove that only udp/500 was being blocked in one direction for one specific source and destination IP. Level3 resolved the issue, but claimed it was due to a "mis-configured NNI" between themselves and Charter. Seems odd that an NNI mis-config could cause something that specific, doesn't it?NNI is a peering link. Peering links blow up during ddos since they act as a narrow funnel of traffic between networks. So NNI is exactly where udp ddos filters show up most, at least that is my guessOn Thu, Jul 30, 2015 at 9:44 PM, Tom Sands <tsands () rackspace com> wrote:We have similar problems with UDP 500 and being able to keep IPSECtunnelsup over Level3. It happens quite a bit when there are no signs of TCP or ICMP packet loss. Sent from my iPhoneOn Jul 30, 2015, at 9:14 PM, Jason Baugher <jason () thebaughers com>wrote:To bring this discussion to specifics, we've been fighting an issuewhereour customers are experiencing poor audio quality on SIP calls. Theonlycarrier between our customers and the hosted VoIP provider is Level3.Frommultiple wiresharks, it appears that a certain percentage of UDPpackets-in this case RTP - are getting lost in the Level3 network somewhere.We'vegot a ticket open with Level3, but haven't gotten far yet. Has anyoneelseseen Level3 or other carriers rate-limiting UDP and breaking these legitimate services?On Thu, Jul 30, 2015 at 3:45 PM, John Kristoff <jtk () cymru com>wrote:On Mon, 27 Jul 2015 19:42:46 +0530 Glen Kent <glen.kent () gmail com> wrote:Is it true that UDP is often subjected to stiffer rate limits than TCP?Yes, although I'm not sure how widespread this is in most, if evenmanynetworks. Probably not very widely deployed today, but restrictionsandlimitations only seem to expand rather than recede. I've done this, and not just for UDP, in a university environment. I implemented this at time the Slammer worm came out on all the ingress interfaces of user-facing subnets. This was meant as a more general solution to "capacity collapse" rather than strictly as securityissue,because we were also struggling with capacity filling apps likeNapsterat the time, but Slammer was the tipping point. To summarize what we did for aggregate rates from host subnets (these were generally 100Mb/sIPv4 /24-/25 LANs): ICMP: 2 Mb/s UDP: 10 Mb/s MCAST: 10 Mb/s (separate UDP group) IGMP: 2 Mb/s IPSEC: 10 Mb/s (esp - can't ensure flow control of crypto traffic) GRE: 10 Mb/s Other: 10 Mb/s for everything else except for TCP If traffic was staying local within the campus network, limits didnotapply. There were no limits for TCP traffic. We generally did not apply limits to well defined and generally well managed serversubnets.We were aware that certain measurement tools might produce misleading results, a trade-off we were willing to accept. As far as I could tell, the limits generally worked well and helped minimize Slammer and more general problems. If ISPs could implementasimilar mechanism, I think this could be a reasonable approach today still. Perhaps more necessary than ever before, but a big part oftheproblem is that the networks where you'd really want to see this sort of thing implemented, won't do it.Is there a reason why this is often done so? Is this because UDP is stateless and any script kiddie could launch a DOS attack with a UDP stream?State, some form of sender verification and that it and most other commonly used protocols besides TCP do not generally react toimplicitcongestion signals (drops usually).Given the state of affairs these days how difficult is it going tobefor somebody to launch a DOS attack with some other protocol?There has been ICMP-based attacks and there are, at least in theoryifnot common in practice, others such as IGMP-based attacks. Therehavebeen numerous DoS (single D) attacks with TCP-based servicespreciselybecause of weaknesses or difficulties in managing unexpected TCP session behavior. The potential sending capacity of even a small set of hosts from around the globe, UDP, TCP or other protocol, could easily overwhelm many points of aggregation. All it takes is for an attacker to coerce that a sufficient subset of hosts to send the packets. John
Current thread:
- Re: UDP clamped on service provider links, (continued)
- Re: UDP clamped on service provider links Matt Hoppes (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)
- Re: UDP clamped on service provider links Randy Bush (Jul 30)
- Re: UDP clamped on service provider links Brad Fleming (Jul 31)
- Re: UDP clamped on service provider links John Kristoff (Jul 31)
- Re: UDP clamped on service provider links Christopher Morrow (Jul 31)
- Re: UDP clamped on service provider links Jon Lewis (Jul 31)
- Re: UDP clamped on service provider links Tom Sands (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)
- Re: UDP clamped on service provider links Ca By (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)