Re: Things to do to make the network better
I will also point out that many of the recent "smurf" attacks and similar problems people are having on the net would be gone if people would just carefully filter internal/external addresses on their border machines, that is, prevent packets claiming to be from "inside" networks from coming in from the "outside", and prevent packets claiming to be from "outside" networks from going out from the "inside". The latter will stop your network from *ever* being the source of a wide variety of packet forgery attacks, and is necessary to being a good network citizen. The former will stop your network from being the subject of a wide variety fo packet forgery attacks, and is necessary to make your customers even remotely safe on the net.
That's great if you're a downstream provider with no transit customers. However, when you become a transit provider, it becomes much more difficult to determine inside vs. outside, since you're more in the middle between two "outsides" that pass traffic through you. Owen
Owen DeLong writes:
I will also point out that many of the recent "smurf" attacks and similar problems people are having on the net would be gone if people would just carefully filter internal/external addresses on their border machines, that is, prevent packets claiming to be from "inside" networks from coming in from the "outside", and prevent packets claiming to be from "outside" networks from going out from the "inside". The latter will stop your network from *ever* being the source of a wide variety of packet forgery attacks, and is necessary to being a good network citizen. The former will stop your network from being the subject of a wide variety fo packet forgery attacks, and is necessary to make your customers even remotely safe on the net.
That's great if you're a downstream provider with no transit customers. However, when you become a transit provider,
OF COURSE this is mainly a "leaf network" thing, not a thing for transit networks. Large providers serving "leaf networks" with well defined connection points to them *can* do some filtering -- in particular, they can refuse to pass packets to a network claiming to originate from within it, and they can refuse to accept packets from a network claiming not to come from within it. That is not, of course, the true transit network case. Extensive filtering *will* reduce the denial of service attacks of this sort we are getting. They can never eliminate them, but they *will* help. I cannot urge strongly enough that people start implementing this sort of filtering as soon as possible. Perry
That's great if you're a downstream provider with no transit customers. However, when you become a transit provider, it becomes much more difficult to determine inside vs. outside, since you're more in the middle between two "outsides" that pass traffic through you.
i don't agree. i know that the complexity grows out of hand quickly, but you have to know, at any edge of your network, the set of routes which can come from neighbors and the set of transit routes which you have to send to those neighbors. the exception seems to be routes you get from your own transit providers, which, numbering as they do in the 10's of thousands, are too many to list. however, even if you had 10,000 transit customers, you would have to list them in various places to make sure that they were all advertised to your various bgp xp neighbors. it is fairly common to refuse to hear your transit customers' prefixes from external peers. if your customer is multihomed and if you gave permission for a cutout, you are probably still not going to use external paths to reach your own customer even when your igp mesh is screwed up. this lowers the value of multihoming, and exceptions have been made, and this highlights the value of portable address space for multihomed customers. but the thing is, while it's easy to tell IOS "do not listen to these routes from outside" where "these routes" is the same set of routes you _advertise_ to the outside, it is NOT easy to say "do not accept packets which are from these nets unless they come from an igp neighbor." this is something which, so far as i know, we need the router vendors to fix. bsd/os 3.* has a feature whereby stable routing is assumed and packets whose source address makes no sense for the ingress interface are just rejected. i know that this extra routing table lookup would kill performance in IOS, and i know that there are a lot of "core" routers for which stable routing cannot be assumed, but even in big networks where are "leafy" routers where you can be assured that if a packet comes from a source address which is different from the forwarding vector if it were a destination address, that something bad is happening. it seems to me that we had this discussion when the SYN flooding problem was first published on the cover of 2600 magazine, and it seems to me that there is no IOS knob, even now, called "ip enforce-stable-routing".
participants (3)
-
owen＠DeLong.SJ.CA.US -
Paul A Vixie -
Perry E. Metzger