- Test - lists.nanog.org

Re: iBGP next hop and multi-access media
by Ralph Doncaster 09 Oct '02

09 Oct '02

I've already had several direct replies saying to manually configure the 172.16 subnet on router A. Sure, that will work, but I'm looking for a solution that doesn't require manual configuration of all the routers involved. Ralph Doncaster principal, IStop.com

3 2

Implementation practices
by Jason Lixfeld 09 Oct '02

09 Oct '02

Irrd-discuss didn't have anything at all to say about this, so I thought I'd bring it here for a different, practical perspective. I'm wondering what the general concensus is with regards to IRR implementation practices. I've done a little digging and have tried to find practical examples of networks listing their detailed peering sets and detailed aut-num objects to see how their import and export entries look for things like community strings, MEDs, Local-Pref, etc. I haven't had much luck in finding any detailed, practical examples. I can come up with only two conclusions: 1) Security policies for most networks networks likely mandate against disclosing routing policy by means of mirroring your database with RADB. 2) People just don't use the irrd to it's fullest extent, hence no detailed entries. I'd like to think that the former is true :) so if that's the case, what are some of the best practices? Is it just as simple as creating a database which RADB mirrors, containing general maintainer, as and route objects then having a private, un-mirrored/non-exported database containing all the nuts and bolts which you run ratoolset (or other, home made widget) against?

2 1

Re: Who does source address validation? (was Re: what's that smell?)
by Danny McPherson 08 Oct '02

08 Oct '02

> 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). What you're doing makes plenty of sense, we agree on that. I just wanted to be sure folks understood it doesn't validate "valid" sources. -danny

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by Danny McPherson 08 Oct '02

08 Oct '02

> "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. -danny

2 1

Re: Who does source address validation? (was Re: what's that smell?)
by Iljitsch van Beijnum 08 Oct '02

08 Oct '02

There are two separate issues: 1. Making sure packets with falsified source addresses don't leave your network This can be done by having customer-specific filters on all customer-facing interfaces. (And on interfaces connecting to any type of hosts in case those are compromised.) Or use the plain and simple version of uRPF, with just one caveat: when a BGP customer announces a route just for backup, they can't use this route for outbound packets either until their outer route disappears. 2. Making sure packets with falsified source addresses don't enter your network 2a. Customers See 1. 2b. Transit Can't be done. (Well, you could filter traffic with source addresses from peers that comes in over transit.) 2c. Peers This is the part where straight uRPF doesn't work because of asymmetric routing. However, it is possible to make this work by making every border router always prefer its own external routes. This is easily accomplished on Cisco routers by setting a higher weight for EBGP sessions. No, it's not painless, and yes, it will break some weird stuff (one way links, people legitimately sourcing packets but for strange reasons not announcing the accompanying routes), but don't tell me it can't be done. The catch-22 is that if you refuse to peer with people who don't do type 1 filtering so you don't have to implement 2c, you end up with the garbage coming in over transit, where you can't filter it.

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by Danny McPherson 08 Oct '02

08 Oct '02

> install this on all your internal, upstream, downstream > interfaces (cisco router) [cef required]: > > "ip verify unicast source reachable-via any" > > This will drop all packets on the interface that do not > have a way to return them in your routing table. Of course, this is the IP RIB and may not include all the potential paths in the BGP Adj-RIBs-In, right? As such, you've still got the potential for asymmetric routing to break things. > Juniper has a somewhat viable solution to the 100% source > validation for bgp customers. they will consider non-best > paths in their unicast-rpf check on the customer interface. This > means that even if 35.0.0.0/8 is best returned via your > peer instead of via the provider the packet came in, but they > are advertizing the prefix to you, you will not drop the packet. What's a "bgp customer"? Can they support 500K+ uRPF entries here? -danny

4 4

dialtone providers in 215/610/609 area code(s)
by alex＠yuriev.com 08 Oct '02

08 Oct '02

Hello, If your company or a company that you know of provides dial-tone service in 215/610/609 area codes and it is not Verizon, could you please drop me a note off the list. Should there be interest, I will post a summary. Thanks, Alex --

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by Danny McPherson 08 Oct '02

08 Oct '02

> If there is a magic solution, I would love to hear about it. I strongly doubt any of the large providers perform dataplane source address validation from peers. Heck, I doubt any perform explicit route filtering on routes learned from peers at the control plane. Ideally, one would first employ some mechanism to generate *explicit* ingress BGP route filters. With BGP Route Refresh the largest offshoot (manual session reset or "bouncing the route") is no longer necessary. >From there, you could either use BGP's Adj-RIBs-In in some uRPFish thing, or employ the same set of BGP route filters for source address filters. Of course, then the lack of registry route object integrity, secure update mechanism, etc.., etc... comes to question. -danny

1 0

Re: iBGP next hop and multi-access media
by Ralph Doncaster 08 Oct '02

08 Oct '02

A and B are connected via the same multi-access media. It is technically possible for B to tell A "you can reach 172.16.16.0/24 on the same media that you receive this update on". However what people seem to be saying is that there is no dynamic routing protocol that implements this. Ralph Doncaster principal, IStop.com On Sun, 6 Oct 2002, Stephen J. Wilcox wrote: > > I dont understand this.. > > A wants to get to a network which it [thinks it] is not connected to, the only > route is via B. therefore you must advertise the route from B with next hop B > > the only possible way (at least in ethernet IP) that A can send direct onto the > ethernet segment is if it is connected to the other (172.16) network and if > youre not willing to do that then your solution is not possible > > Steve > > On Sun, 6 Oct 2002, Ralph Doncaster wrote: > > > > > Background: > > Router A and B are connected via a common ethernet segment 1. Router A > > uses 10.10.10.1/30, and Router B uses 10.10.10.2/30. Router B also has > > another subnet configured for ethernet segment 1; 172.16.16.0/24. > > > > When I setup a situation like the above, with Router B advertising the > > 172.16.16.0/24 to router A, router A sees a next hop of 10.10.10.2. This > > is not good since packets from A going to the 172.16.16 subnet get sent to > > Router B, which then ARPs the desitnation, instead of just being ARPed by > > router A. > > > > I don't want to turn on ICMP redirects on B since they're insecure and > > ugly. I've also made sure I'm not using next-hop self. Is there a way to > > make this work? > > > > Ralph Doncaster > > principal, IStop.com > > > > > > > >

5 5

69.0.0.0
by Scott Granados 08 Oct '02

08 Oct '02

Hi all, does it seem to anyone else in this space that several other networks are filtering still on the 69.0.0.0 boundary? We have 69.1.64.0/20 and get filtered one in a while. SPecifically digitalisland and turner broadcasting which seems to be part of ans net in arin which I assume is aol. What is the best way to insure that this ip range is unfiltered or that 69.0.0.0 n general isn't filtered. We did file objects as well.

1 0