- Test - lists.nanog.org

RE: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
by Daniel Senie 03 Jun '04

03 Jun '04

At 08:04 AM 6/3/2004, Krichbaum, Eric wrote: >Because there are legitimate reasons for async routing. >DirectPC/Isat/etc. (Satelite based services) come to mind immediately. DirecPC has had satellite return path for a long time. Their older systems with dialup/cable for upstream involved loading of software into your PC. That software could EASILY have encapsulated the upstream packets into UDP packets so that their upstream packets were valid. >Customers dial-up to an ISP and downstream traffic returns via the sat >connection. Reverse-path immediately disables every one of these >customers. Qwest deployed this on us with no notice and killed off >thousands of customers in one fell swoop. > >Although I agree with the principal, the implentation needs more thought >than a simple 'turn it on for 100%'. The documents leading up to BCP38 began in 1996. This didn't just happen out of the blue. Some assumptions made by more than one group that routing decisions would forever be made based on destination IP address only. One of these was mobile IP, and that WG worked on an alternative as soon as the ingress filtering draft started gaining momentum. Tunnels are a good answer where legitimate traffic has to flow in a way that does not match the addressing topology. Having this dropped on you by Qwest without warning was a bad thing. I wonder if you asked them to temporarily undo it while while you worked with the vendor (Hughes in this case) to implement tunneling of the return traffic? >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of >Alexei Roudnev >Sent: Thursday, June 03, 2004 1:40 AM >To: Jon R. Kibler; nanog(a)merit.edu >Subject: Re: Real-Time Mitigation of Denial of Service Attacks Now >Available With AT&T > > >You even do not need to maintain ACL - many routers have 'back-path >verification' feature. >I wonder, why DSL and other 'consumer level' providers are not doing it >for 100% of their customers. > > >----- Original Message ----- >From: "Jon R. Kibler" <Jon.Kibler(a)aset.com> >To: <nanog(a)merit.edu> >Sent: Wednesday, June 02, 2004 8:25 AM >Subject: Re: Real-Time Mitigation of Denial of Service Attacks Now >Available With AT&T > > > > John Obi wrote: > > > ... since DDoS is the > > > nightmare of the internet now. > > > > > > > The sad fact is that simple ingress and egress filtering would > > eliminate the majority of bogus traffic on the Internet -- including > > (D)DoS attacks. If all ISPs would simply drop all outbound packets > > whose source address is not a valid IP for the subnet of origin, > > and all inbound packets that do not have valid source IP addresses, > > the DDoS problem would be (for all intents and purposes) fixed. If > > proper filtering was done, then any DoS attacks would have to have > > either valid source IP addresses, or IP addresses that spoofed IPs > > within their network of origin. In either case, identifying and > > shutting down the attackers would become a greatly simplified task > > compared to the mess it is today. > > > > Why no filtering by ISPs? "Because it takes resources and only >benefits > > the other guy" -- unless your network is the one under attack. > > > > Maintenance of the ACLs should not be the issue. A single ACL for each > > subnet would be all that would be required for egress filtering. About > > 30 ACLs on an inbound border router would be required for ingress > > filtering. Keeping the ingress ACLs current is a brain-dead task -- >just > > subscribe to the bogon mailing list at cymru.com. > > > > ACLs have had a bad reputation for greatly slowing down routers. That > > may have been true in the past, but properly written ACLs do not seem > > to have a significant impact on most new routers. Yes, they may cut > > peak through-put a few percent -- but if you are running that close to > > the edge, it is time to upgrade anyway. > > > > IMHO, there is absolutely no excuse for not doing ingress and egress > > filtering. In fact, if you are an ISP, I would argue that you are > > negligent in your fiduciary responsibilities to your customers and > > shareholders if you are not filtering source IP addresses. > > > > Fancy solutions may make great marketing, but simple proper router > > filtering is a very workable lower-cost solution. > > > > (Step down from soap box.) At least, that's my $0.02 worth. > > > > Jon Kibler > > -- > > Jon R. Kibler > > Chief Technical Officer > > A.S.E.T., Inc. > > Charleston, SC USA > > (843) 849-8214 > > > > > > > > > > ================================================== > > Filtered by: TRUSTEM.COM's Email Filtering Service > > http://www.trustem.com/ > > No Spam. No Viruses. Just Good Clean Email. > > > >

1 0

Re: Cable networks RE: best effort has economic problems, maybe OT
by frank＠dticonsulting.com 03 Jun '04

03 Jun '04

An excellent article in this month's LIGHTWAVE Magazine on Cable's entry into traditionally-LEC and ISP deployments. In fact, Cablevision's Lightpath division is a registered LEC in its own right: http://lw.pennnet.com/Articles/Article_Display.cfm? Section=ARTCL&ARTICLE_ID=204382&VERSION_NUM=1&pc=ENL Frank On Wed, 2 Jun 2004 14:09 , Curtis Maurand <curtis(a)maurand.com> sent: > > >That's how time-warner is doing it here in Maine. However, they've >assigned voip to its own channel while digital channels occupy another and >hdtv signals are compressed and on another, etc. Its a 1Ghz system. >Everything on the system is IP including the control boxes. They also >have certain video and PPV on demand as well. Very interesting system >that serves as a model for the rest of the country. Whatever they do they >roll it out here first and this system totally rocks. I regularly get >downloads at 3Mbps. > >Curtis > >-- >Curtis Maurand >curtis(a)maurand.com','','','')">curtis(a)maurand.com >http://www.maurand.com > > >On Sun, 30 May 2004, Christopher J. Wolff wrote: > >> >> Folks, >> >> This is a great discussion. I'm interested in understanding these types of >> limitations in the context of HFC cable networks. In my opinion, HDTV >> channel bandwidth (30mhz?) , increased demand for voip, and growing demand >> for IP connectivity is going to stress the cable network model as well, >> forcing cable operators to convert everything to IP before going out across >> the wire. Any input is appreciated. >> >> Regards, >> Christopher >>

1 0

RE: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
by Michel Py 03 Jun '04

03 Jun '04

> Jon R. Kibler wrote: > IMHO, there is absolutely no excuse for not doing ingress and > egress filtering. In fact, if you are an ISP, I would argue > that you are negligent in your fiduciary responsibilities to > your customers and shareholders if you are not filtering > source IP addresses. Hey, I'm all for it. Where's the money and the staff? Michel.

3 2

RE: ARIN awol?
by Hannigan, Martin 02 Jun '04

02 Jun '04

ARIN's back up. -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: John Curran [mailto:jcurran@istaff.org] > Sent: Wednesday, June 02, 2004 3:16 PM > To: Hannigan, Martin > Subject: RE: ARIN awol? > > > No biggie... crank it out and make tomorrow night happy hour work. > 6:30 McCormick and Schmitd. > > /John > > At 3:12 PM -0400 6/2/04, Hannigan, Martin wrote: > >JC -- I can't make it again tonight. This is bad. I'm stuck here. > >It's going to be late again. > > > > > > > > > > > >-- > >Martin Hannigan (c) 617-388-2663 > >VeriSign, Inc. (w) 703-948-7018 > >Network Engineer IV Operations & Infrastructure > >hannigan(a)verisign.com > > > > > > > >> -----Original Message----- > >> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >> John Curran >> Sent: Wednesday, June 02, 2004 2:05 PM >> To: nanog(a)merit.edu >> Subject: Re: ARIN awol? >> >> >> >> ARIN is presently having connectivity problems out of the >> Chantilly VA office. >> These are being worked with the relevant providers but there >> is no ETA at >> this time. >> >> FYI, >> /John >> >> >> At 10:37 AM -0600 6/2/04, Mike Lewinski wrote: >> >Lots of history entries, nothing usable. Been this way a while now. >> > >> >route-views.oregon-ix.net>sh ip bgp 192.149.252.17 >> >BGP routing table entry for 192.149.252.0/24, version 18274110 >> >Paths: (38 available, no best path) <- >> > Not advertised to any peer >> > 7660 2516 7911 701 7046 (history entry) >> > 203.181.248.233 from 203.181.248.233 (203.181.248.13) >> > Origin IGP, localpref 100, external >> > Dampinfo: penalty 518, flapped 3 times in 00:30:43 >> > 3277 13062 2854 2854 5511 1239 701 7046 (history entry) >> > 194.85.4.55 from 194.85.4.55 (194.85.4.55) >> > Origin IGP, localpref 100, external >> > Community: 3277:13062 3277:65301 3277:65307 >> > Dampinfo: penalty 549, flapped 4 times in 00:41:51 >> > 4513 1239 701 7046 (history entry) >> > 209.10.12.28 from 209.10.12.28 (209.10.12.28) >> > Origin IGP, metric 12, localpref 100, external >> > Dampinfo: penalty 498, flapped 3 times in 00:31:36 >>

1 0

Re: best effort has economic problems
by Gordon Cook 02 Jun '04

02 Jun '04

may I make just a passing observation? From a technology point of view the best effort internet certainly "works." Not surprisingly the comments here are primarily debating the finer points of the technology. The point I am making in my report is NOT that the best effort network has technology problems but rather that it has ECONOMIC PROBLEMS. That it might support 2 or 3 players not 2 or 3 HUNDRED. That until companies begin to go chapter seven and vanish, the best effort net will be a black hole that burns up capital because, for many players, the OPERATIONAL expense is more than they get for bandwidth never mind cap-ex. best effort won't go away. many best effort players will. for the time being, best effort bandwidth prices as an absolute commodity cannot sustain networks over the long haul. A network that can deliver QoS the report hypothesizes may be able to attract enough revenue to become profitable. How to to this my group is still discussing. We don't pretend that QoS is easy or any kind of mature collection of technologies, but increasingly it looks as though the industry, if it is ever going to be self sustaining, really needs to look at QoS services and solutions. >On Sat, 29 May 2004, Edward B. Dreger wrote: > >> Nitpicking: Latency isn't that important with unidirectional >> communication. However, VoIP users seem reasonably happy with >> current latency and jitter -- and the Internet still is _largely_ >> xxTP, anyway... particularly if one ignores peer-to-peer file- >> swapping programs. > >Latency is fine for VOIP as long as you dont interact with the PSTN >network, if you want to interact with PSTN then you need echo >cancellation if you have high latency on the IP part. > >Most VOIP applications can handle 40ms jitter, so that's normally no >problem unless your local access is full. Packet loss is normally no >problem for VOIP if you use a proper (non-telco developed) codec. > >VOIP is actually better off with high packet loss and low jitter than the >other way around (throwing off the old truth that core equipment should >have lots of buffers). > >-- >Mikael Abrahamsson email: swmike(a)swm.pp.se -- ============================================================= The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Report on economic black hole of best effort networks at: http://cookreport.com/13.04.shtml E-mail cook(a)cookreport.com =============================================================

12 15

ARIN awol?
by Mike Lewinski 02 Jun '04

02 Jun '04

Lots of history entries, nothing usable. Been this way a while now. route-views.oregon-ix.net>sh ip bgp 192.149.252.17 BGP routing table entry for 192.149.252.0/24, version 18274110 Paths: (38 available, no best path) <- Not advertised to any peer 7660 2516 7911 701 7046 (history entry) 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, external Dampinfo: penalty 518, flapped 3 times in 00:30:43 3277 13062 2854 2854 5511 1239 701 7046 (history entry) 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, external Community: 3277:13062 3277:65301 3277:65307 Dampinfo: penalty 549, flapped 4 times in 00:41:51 4513 1239 701 7046 (history entry) 209.10.12.28 from 209.10.12.28 (209.10.12.28) Origin IGP, metric 12, localpref 100, external Dampinfo: penalty 498, flapped 3 times in 00:31:36

2 1

RE: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
by Michel Py 02 Jun '04

02 Jun '04

Okay guys and gals, for spam there is the FUSSP: http://www.rhyolite.com/anti-spam/you-might-be.html How to we call it for attacks? The FUSAP (Final Ultimate Solution to the Attacks Problem)? It seems like we have some winners on the list. Michel.

1 0

RE: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
by Michel Py 02 Jun '04

02 Jun '04

>> "Michel Py" wrote: >> Woulda, shoulda. > Richard Cox wrote: > The original quote, from the song title, is "Coulda, Woulda, Shoulda" > ^^^^^^ > And that sums it up MUCH better ... I stand corrected. Michel.

1 0

Re: Tracking the bad guys
by Stewart, William C (Bill), RTSLS 02 Jun '04

02 Jun '04

Eric Brunner-Williams is slightly incorrect in his description of the blog-spammer's attack, because he's misinterpreting whois. He states that based on the spammer's entry in the whois entry, the spammer "claims domicile" in whatever location. Whois records don't make any claims about domicile, legal jurisdiction, True Name, National Identity Number, Retina Prints, likely sleeping location, likely location of hardware, ICBM coordinates, or preferred subpoena acceptance location, though ICANN would certainly like it if they did. They're strictly indicating some postal contact information, and for the billing address, they're indicating where to send a paper bill. (Keeping them current is certainly good practice, and I'd recommend that Eric check nic-naa.net's whois phone numbers, which appear to have suffered from some helpful spreadsheet doing arithmetic on them.) Meanwhile, while it's annoying to have to do self-defense, rather than getting the miscreant's ISP to do it, if Eric's wife's machine is self-administered as opposed to administered by some hosting company, adding the miscreant's IP address to the firewall or routing table can take care of the bandwidth problem, and while collateral damage is a bad thing for ISPs to do, it's not unreasonable for personal machines. Bill Stewart, bill.stewart(a)pobox.com

2 1

Re: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
by nanog 02 Jun '04

02 Jun '04

> ----- Forwarded message from Eric Kuhnke <eric(a)fnordsystems.com> ----- > > Major providers such as Sprint and UUNet have had null route communities > available for quite some time... Unless I am mistaken? Which AT&T does *not* have, unless I cannot find the correct person to enlighten me. (NOC, sales team, implementation teams, customer care and lifecycle teams- all either scratch their head and say "what? why would someone want that?" or just say "no.") Someone, please prove me wrong. I would love to have this rather simple and quite common (these days) functionality in all of my upstreams. Yes, AT&T is the only one (out of 4 major providers we use) that cannot seem to implement this. Of course, I wonder if it will ever come now (assuming they will charge for their whiz-bang Arbor solution...) bill

1 0