- Test - lists.nanog.org

Re: Who does source address validation? (was Re: what's that smell?)
by Stephen Gill 10 Oct '02

10 Oct '02

Though the docs aren't indexed in the web search tool yet, JUNOS 5.5 adds the ability to perform loose uRPF now. [edit int <name> unit 0 family inet] set rpf-check mode loose Watch for wrapping. http://www.juniper.net/techpubs/software/junos/junos55/swconfig55-interf aces/download/swconfig55-interfaces.pdf Cheers, -- steve Date: Tue, 8 Oct 2002 12:29:48 -0400 From: Jared Mauch <jared(a)puck.Nether.net> Subject: Re: Who does source address validation? (was Re: what's that smell?) On Tue, Oct 08, 2002 at 10:15:28AM -0600, Danny McPherson wrote: > > > > "reachable-via any" means you're only going to drop the packet if you > > don't have *ANY* route back to them. > > What's a route? An IP RIB instance? A BGP Loc-RIB instance? An IGP LSDB > IP prefix entry? A BGP Adj-RIB-In instance? > > I think you mean "if you don't have *ANY* **FIB** entry for the > source address". > > If I peer with two large providers on the same router and both > have prefix D.1 behind them and advertise the prefix to me, it's > likely that only one of those two paths is going to make it into > the BGP Loc-RIB (and subsequently, the IP RIB then FIB). > > If I use ANY FIB entry as proof that it's a valid source then > that only addresses RFC1918ish space and only suggest that I > first need to generate an invalid BGP route for the prefix, then > spoof the packets. This doesn't fix spoofing with global IP > addresses. > > If I use only entries that occur in the RIB and associate them > with the receiving interface and receive a packet with an SA of > D.1 from the peer whose path wasn't installed in the BGP > Loc-RIB then I'll drop it. (And there's nothing broken with > this configuration -- it's why we have routers with 1 million > BGP paths but only 150K routes/fib entries, as I'm sure you > know). > > If you're going to do source address validation then you need > to associated all potential valid paths for a given prefix with > the associated ingress interface, else it's mostly useless. Yes, but if i continue in my ideal situation of people (mostly) filter their bgp customers, so they won't announce the 1918 space, or similar. even the large peers filter out each other so they don't pick up 1918 announcements. Plus people use Robs "Secure IOS Template" to drop extraneous bgp announcements for unregistered/unassigned space (from IANA). I'm not purporting this as a solution to all problems on the internet, but if one walks before one runs this is a reasonable step in the correct direction. Or at least a nice bandaid (duct tape?) to help keep the network in a bit more sensible shape. And if everyone did it, it would help with the orignal problem/statistics posted about how much 1918 space was hitting one specific root server. I am interested in hearing other solutions to the problem including extra validations such as the above, but those aren't avalable today and what i'm suggesting is in the 12.0S and 12.1E IOS images and probally others. - Jared - -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by alex＠yuriev.com 10 Oct '02

10 Oct '02

> >>>would be interesting to hear details. > > >> Loss of ICMP packets generated by links with endpoints numbered in > >>RFC1918 > >>space. Holes in traceroutes, broken PMTU detection. > > >Why do those links have endpoints in RFC1918 space to begin with? > > > >Alex > > Because some administrators are ignorant, clueless, or malicious. We don't > all have the luxury of saying, "It doesn't work on our network and it does on > our competitor's, and we could fix it if we wanted to at no significant harm > to us, but we won't because we are in the right." In that case you should not complain about 1918 space being used for say.. attacking you either. After all, it does work on the network of your competitors. ALex

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by alex＠yuriev.com 09 Oct '02

09 Oct '02

> >Do you have experience of such breakage from your own customers? It > >would be interesting to hear details. > > Loss of ICMP packets generated by links with endpoints numbered in RFC1918 > space. Holes in traceroutes, broken PMTU detection. Why do those links have endpoints in RFC1918 space to begin with? Alex

2 1

spam, what to do:)
by Scott Granados 09 Oct '02

09 Oct '02

My question is this. The company I work for has a no spam policy. Sometimes users do and of course we shut them off. My own feelings asside its what is considered proper in the isp community so we do it with out question. However, what is the best policy and procedure to prevent people from spamming in the first place and secondly if they do and get terminated fix the damage done. I have no desire to support spam or enable spammers but there are bad users and sometimes they do. Any positive advise on dealing with these guys above just turning them off would be helpful.

3 3

verizon routing engineer?
by Scott Granados 09 Oct '02

09 Oct '02

Could a verizon engineer contact me off list. It appears that 69.0.0.0 is filtered still on your network. Thanks Scott

3 2

Re: Who does source address validation? (was Re: what's that smell?)
by Paul Vixie 09 Oct '02

09 Oct '02

> Just out of interest how do you co-ordinate use of RFC 1918 addresses > and routes amongst your customers? Do you run a registry for them, or > do you just let them fight it out and the one with the biggest packets > wins or something like that? there's a registry. we also maintain IN-ADDR zones for them and encourage the use of "stub" zones in customer name servers in order to direct their queries toward the local RFC1918 registry. now, i'll admit that it took almost two hours to get this working initially, and almost a week for it to settle down, and that the network is small -- only about 50 "customers". but for the last few years no RFC1918-sourced traffic, nor any RFC1918-IN-ADDR DNS query, has egressed from this network. it can't be THAT hard.

1 0

RIR Blueprint for Evolution and Reform of Internet Address Management
by John M. Brown 09 Oct '02

09 Oct '02

this just out from the RIR's. While political in many areas it does impact operations in how you get IP space and how its managed. http://www.arin.net/nrr-blueprint/ The RIR's are asking for feedback.

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by Stephen Stuart 09 Oct '02

09 Oct '02

> Loss of ICMP packets generated by links with endpoints numbered in RFC1918 > space. Holes in traceroutes, broken PMTU detection. Sherman, set the Way-Back Machine for August: To: David Schwartz <davids(a)webmaster.com> Cc: nanog(a)merit.edu Subject: Re: NSPs filter? In-reply-to: Your message of "Thu, 08 Aug 2002 17:57:35 PDT." <20020809005740.AAA18472@shell.webmaster.com@whenever> Date: Thu, 08 Aug 2002 18:45:17 -0700 From: Stephen Stuart <stuart(a)tech.org> In August you said it this way: > One thing that sometimes comes up is that people do number links using > RFC1918 address space which occasionally results in an ICMP 'fragmentation > needed but DF bit set' packet with an RFC1918 source address. Filtering out > this packet could result in TCP breaking. I still say this: That can be accomodated; behold, all the joy of PMTUD, with none of the other crap from designated special-use address space: firewall { family inet { filter external-filter { term allow-icmp-unreach { from { protocol icmp; icmp-type unreachable; icmp-code fragmentation-needed; } then { count allow-icmp-need-frag; accept; } } term allow-icmp-timxceed { from { protocol icmp; icmp-type time-exceeded; icmp-code [ ttl-eq-zero-during-transit ttl-eq-zero-during-reassembly ]; } then { count allow-icmp-timxceed; accept; } } term deny-rfc1918 { from { source-address { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; } } then { count deny-rfc1918; discard; } } term deny-test { from { source-address { 192.0.2.0/24; } } then { count deny-test-net; discard; } } term deny-autoconfig { from { source-address { 169.254.0.0/16; } } then { count deny-autoconfig; discard; } } term LAST { then accept; } } } } Application is left as an exercise to the reader. Stephen

1 0

NMS/ OSS commercial software ?
by m.rapoport＠completel.fr 09 Oct '02

09 Oct '02

Hello, I am working for a service provider based in Europe that sells Internet access, Hosting services,Metro Ethernet Transport and IPSEC VPN (based on a mix of Cisco, Riverstone, and Nortel). For the NMS, we are currently using HP OV and public domain tools (MRTG, Netsaint, and some others). We are considering to deploy several commercial OSS applications to improve the service provided to the customers (performance stats, Extranet SLA reports, percentile usage based billing, ...) and the tools available to our NOC Beside opensource ( that a significant part of you are using, I assume) , I was wondering which commercial applications are used & favored. I have heard about Infovista, Concord, Proviso(Quallaby) for Performance & SLA Reports, and Netcool(Micromuse) for Event & Alarm Correlation. (provisioning tools and mediation tools are not in the scope of our study currently) I found very few information in the nanog archive regarding these products, what is your experience? I would be glad also if some of you have comments regarding the usefulness of CiscoWorks for operating a Cisco IP Backbone (for Cisco network management tools, please send in private, as specific vendor's subjects are off-topic on this list). Best Regards,

4 7

WorldCom Suffers Widespread Internet Outage
by blitz 09 Oct '02

09 Oct '02

http://story.news.yahoo.com/news?tmpl=story2&cid=575&u=/nm/20021003/wr_nm/t… Made the news...

2 1