mailing list archives
Re: On the back of other 'security' posts....
From: Owen DeLong <owen () delong com>
Date: Sun, 31 Aug 2003 14:34:28 -0700
--On Sunday, August 31, 2003 7:28 AM -0400 Matthew Crocker
<matthew () 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
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
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.
Re: On the back of other 'security' posts.... Matthew Sullivan (Aug 31)
Re: On the back of other 'security' posts.... Paul Vixie (Aug 30)