- Previous message: William Norton: "Re: Customer-facing ACLs"
- In reply to: Justin Shore: "Customer-facing ACLs"
- Next in thread: Justin Shore: "Re: Customer-facing ACLs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Mark Tinka (no email)
Date: Sat Mar 08 2008 - 23:24:31 EST
On Saturday 08 March 2008, Justin Shore wrote:
> What kind of customer-facing filtering do you do (ingress
> and egress)? This of course is dependent on the type of
> customer, so lets assume we're talking about an average
> residential customer.
We supply to mid-to-small ISP's mostly, and sizeable
enterprise customers; so the degree to which we can filter
is limited.
That said, at the edge, we run uRPF on all customer-facing
ports (loose or strict, depending on the deployment).
In addition, on each edge router's core-facing uplinks, we
run egress ACL's matching RFC 1918 and RFC 3330 (yes, with
uRPF downstream to the customers, this might seem
redundant, but we've actually seen some 'catches', so it
appears to help us solidify our filtering implementation).
In the core, we don't filter or run uRPF, for obvious
reasons.
On our border routers, we deploy ingress filters, again,
cutting off RFC 1918 and RFC 3330.
On peering routers (private peering and exchange points), we
run uRPF on our peering interface (taking care to run loose
mode in case private peers also peer at the public exchange
point). Again, upstream ACL's are implemented on
core-facing uplinks to "double-check".
As you can tell, we don't filter
protocols/ports/applications. We leave that to the
customer, and insist on it.
All the above goes for IPv6 as well, as appropriate.
We are also quite picky about NLRI filtering (BGP), but
that's beyond this scope :-).
Hope this helps.
Cheers,
Mark.
|
|
|