October 2002 - Test - lists.nanog.org

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

Reach Communications
by Todd Mitchell 07 Oct '02

07 Oct '02

Is anyone else having sporadic latency, packet loss & sub-optimal routing issues with Reach Communications routers in the UK over the last few hours? Todd --

1 0

Good quotes on importance of good network addressing
by Pete Kruckenberg 07 Oct '02

07 Oct '02

I'm doing a presentation and white paper to convince a bunch of people that network addressing is one of (if not the most) important aspect of network design and management. The goal is to convince them that we need a plan, which will probably require them to do some renumbering. I'm looking for a couple of good quotes to include in the presentation. Anyone got some good ones from some Internet/network luminaries? Something to confirm the importance of a generally boring topic. Thanks. Pete.

6 6

Re: UUNET is not the Internet (and neither is AOL)
by Dave Israel 07 Oct '02

07 Oct '02

On 10/5/2002 at 12:30:36 +0000, Tim Thorne said: > After reading all the stories about what supposedly happened does > anyone know what really happened? Did UUNet US really do an IOS > upgrade on a sizable proportion of their border routers in one go? > This seems like suicide to me. What possible reason could there be for > a network-wide roll out of an untested IOS apart from being in the > mire already? The assumption that it was untested is probably an unfair one. Once a network reaches a certain size, it is very difficult to simulate it in a lab. Number of routes/updates, variety of packet destinations, different card revisions and layouts... heck, even statistically, you have problems. An issue that appears 5% of the time will only show up in a a 10-router test lab half the time, but in a 400-router network it'll pop up on about 20 routers and wreck your whole day. And when you're out of cash, you can't really afford to devote lots of hardware to a lab. I'm not saying that their testing procedures were correct, or that they tested the image as well as they could have... but the assumption that, if it blew up in the field it must not have been tested at all probably isn't accurate. -Dave

2 1