On the back of other 'security' posts....

Owen DeLong owen at delong.com
Sun Aug 31 21:34:28 UTC 2003




--On Sunday, August 31, 2003 7:28 AM -0400 Matthew Crocker 
<matthew at crocker.com> wrote:

>
>>
>> As I'v said many times (so have a few others, more now than before) you
>> have to define the 'edge' first... My definition is: "as close to the
>> end
>> system as possible". For instance the LAN segment seems like the ideal
>> place, its where there is the most CPU per packet, with the most simple
>> routing config and most predictable traffic patterns/requirements.
>>
>
> The 'edge' is the last piece of equipment on your network.  It is what
> connects you to your customer and what connects you to your upstreams.
> Every ISP should put Anti spoofing filters on ALL edge interfaces.  My
> entire customer edge (dialup,ISDN,DSL, T1, FR, ATM, Wireless, colo) is
> defined in LDAP/RADIUS.  When a session is established my edge equipment
> configures itself over RADIUS.  It isn't hard to use that information to
> build a customer specific filter for the session.  For example,  Every
> dialup (PPP) or DSL (PPPoE) session should have a filter which *only*
> allows packets sourced from the customer IP in.  It should also deny
> packets coming from the customer out to the customer.  It is pretty
> simple to do this but you do need to maintain proper customer records.
> Your customer edge is his equipment and they should also put anti-spoof
> filters in line.  Security is not a single point on a map.  Security must
> be established on every interface.  Most people say that you can't filter
> an OC-48 at line speeds, or that it will increase the latency too much.
> If filtering increases latency by 5% but decreases junk traffic by 20%
> don't you think you and the network are better off?  For true redundancy
> for dual-homed sites the links shouldn't be running above 40% capacity
> anyway.  If your router can't filter at 40% line speed you need another
> router.  I know in the core it gets much more complex but when I
> connected my Verio link I had to make sure all of my IRR entries were
> correct.  They already filter my BGP prefixes I would assume they filter
> my IP as well.  I know I filter my outbound to make sure it is only
> coming from me.
>
What you are saying works only so long as none of your edge connections
represent a significant portion of the internet.  How do you anti-spoof,
for example, a peering link with SPRINT or UUNET?  It's not realistic
to think that you know which addresses could or could not legitimately
come from them.  You might be able to validate that SOME of your addresses
should not come from them, but, that would assume that your customers
don't multihome with them.  It gets even more sticky when you have edge
connections to more than one provider near the top of the food chain.

As to latency, trying to filter an AS of any significant size across an
OC-48 would require a rule for each prefix said AS advertises to you.  If
said AS can advertise, say, 10,000 prefixes, then you need an ACL on the
edge with 10,000 rules.  Most routers won't accept a 10,000 line ACL
at all.  Even if they do, I suspect on an OC48 the increase in latency
would be much more than 5%.  Probably more than 20% for any packet that
had to traverse the entire list.

Yes, VERIO filters your BGP connection because you don't provide a
large number of prefixes and have a small number of ASs behind you.
I bet they don't filter their connection to SPRINT, UUNET, or AOL.

Of course, I also bet your connection to VERIO is probably OC3 or
smaller.

> The edge is everywhere and the more specific you get the more specific
> your filters can be.  In the core you can't be very specific.  We have a
> bunch of routes that we announce (/16, 2 x /21, 3 x /24).  It wouldn't be
> hard for my upstreams to filter my traffic.  I already have to notify
> them (via IRR) when I have a new announcement.  They can update my filter
> when they update the prefix-list
>
Yes.  Your situation is simple.  Your situation isn't everyone's situation.

Owen




More information about the NANOG mailing list