Where is the edge of the Internet? Re: no ip forged-source-address

Daniel Senie dts at senie.com
Mon Nov 4 23:56:25 UTC 2002


At 06:18 PM 11/4/2002, Sean Donelan wrote:

>On Mon, 4 Nov 2002 bdragon at gweep.net wrote:
> > What about the other large isps? What would it take for you to do
> > something? Chris is gracious enough to show up and participate, at
> > least even if it does mean he has to wear nomex.
>
>I'm in favor of source address filtering at the edges.
>
>I'm opposed to some of the suggestions where to put source address
>filters, especially placing them in "non-edge" locations.

No argument there. Bogon filtering could (should?) be done everywhere, but 
ingress is best when done close to, well, the ingress point.

>   E.g. requiring
>address filters at US border crossings is a *bad* idea, worthy of an
>official visit from the bad idea fairy.

This would be a bad idea even if it were possible to clearly delineate 
border crossings somewhere. Many foreign ISPs collocate routers in the USA, 
leading to all kinds of fun questions of where borders lie in cyberspace.


>Our networks, and our customer bases, are not identical.  This is good
>and bad. Not to make excuses, the ease with which this can technically be
>done depends on your network and type of customer connections.  Or more
>precisely how you aggregate customer connections.

Doing absolutely nothing, in any part of one's network seems unreasonable. 
For the large backbone providers, they might consider adding 
terms-of-service requirements for their downstreams, if they themselves 
can't implement on their equipment. UUNet was able to impose something like 
that with port 25 blocking, requiring their wholesale POP customers to add 
that to their RADIUS server configs.

Even the Cisco RPF check that looks to see if there is ANY route to a net 
would be helpful. That would squelch out the packets with 0.0.0.0 source 
addresses and other such bogons. Cisco claims that's not even high 
overhead. Perhaps turning that on in the backbone routers would be worthwhile?


>IMHO the edge is generally the best place to do source address filtering.
>After traffic is aggregated its more difficult.

Clearly. The question is the definition of aggregation. Is it the customer 
premesis router that must do the work,  the aggregation router at the local 
ISP? The backbone vendor's aggregation router that regional ISPs attach to?

>  Some folks have already
>identified the technical limitations of some types equipment.  And with
>the market, we're going to be stuck with that equipment for a while.  In
>hindsight, if every provider and every equipment vendor did it from day 1,
>we would be in great shape.
>
>Does that mean I can wave my magic wand and fix everything tomorrow? No.
>
>Can I work on standards, vendors and purchasing agents to change this over
>time? Yes.  Will yelling at me make it happen faster? I doubt it, but I
>know you will anyway.

When I first got involved in this back in 1996, this was my answer to those 
who complained their routers would melt. "Add it to your requirements 
document for your next round of purchasing" was a common comment. If you 
don't tell your vendors you need a feature, they won't spend their time on 
it. Cisco, to their credit, has been working on this issue. Their automated 
solutions have shortcomings, but they seem to be working on improvements. 
In edge cases with single-homed customers, there's really no excuse not to 
have an ACL to take care of the issue. The extra few lines of config 
(probably script generated anyway) would not hurt. Seems some folks won't 
even do that.




More information about the NANOG mailing list