What about providers that use portions of the private address space on
their network (up to and including the client's serial interface)?
Mohamad
> > Should I be filtering all reserved space at my border, or would
> > it be reasonable for me to expect the big guys not to take packets
> > with clearly inappropriate source addresses?
>
> Yes you should. (and with kudos to Andrew)
>
> ! Loopback
> access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255
> ! RFC 1918 private blocks
> access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255
> access-list 100 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255
> access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255
> ! Test Network
> access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255
> ! Tiny networks.
> access-list 100 deny ip any 255.255.255.128 0.0.0.127
> access-list 100 permit ip any any
>
The operative phrase here is border.
That means ASN border, i.e. where you BGP
peer with others. At the provider/subscriber
interface, within your IGP, using RFC 1918 space
is ok.
>
> What about providers that use portions of the private address space on
> their network (up to and including the client's serial interface)?
>
> Mohamad
>
>
> > > Should I be filtering all reserved space at my border, or would
> > > it be reasonable for me to expect the big guys not to take packets
> > > with clearly inappropriate source addresses?
> >
> > Yes you should. (and with kudos to Andrew)
> >
[ access lists deleted ]
> >
The operative phrase here is border.
That means ASN border, i.e. where you BGP
peer with others. At the provider/subscriber
interface, within your IGP, using RFC 1918 space
is ok.
I agree if BGP is running between the customer and the provider. However,
if:
- both the provider *and* the customer are using the same private
address space
*and*
- the provider assigns the p2p link addresses from that same
address space (according to its own subnetting plan)
the question becomes: where do you apply the filters? Is it safe for the
provider to assume, in the first place, that its use of private addresses
should extend to customer networks?
Mohamad
Why not use a standard access-list like :
access-list 50 deny 0.0.0.0 0.0.0.0
access-list 50 deny 127.0.0.0 0.255.255.255
access-list 50 deny 10.0.0.0 0.255.255.255
access-list 50 deny 172.16.0.0 0.15.255.255
access-list 50 deny 192.168.0.0 0.0.255.255
access-list 50 deny 192.0.2.0 0.0.0.255
access-list 50 deny 128.0.0.0 0.0.255.255
access-list 50 deny 191.255.0.0 0.0.255.255
access-list 50 deny 198.32.184.0 0.0.0.255 ! MAE-WEST (could be done)
access-list 50 deny 198.32.136.0 0.0.0.255 ! MAE-WEST (to include all EPs)
access-list 50 deny 198.32.186.0 0.0.0.255 ! MAE-EAST
access-list 50 deny 192.41.177.0 0.0.0.255 ! MAE-EAST
access-list 50 deny 198.32.130.0 0.0.0.255 ! AADS
access-list 50 deny 206.183.224.0 0.0.31.255 ! FNSI
access-list 50 deny 209.41.192.0 0.0.31.255 ! FNSI
access-list 50 deny 209.115.0.0 0.0.31.255 ! FNSI
access-list 50 deny 223.255.255.0 0.0.0.255
access-list 50 deny 224.0.0.0 31.255.255.255
access-list 50 permit any
Then apply this to your peer session on the inbound with the command :
neighbor x.x.x.x distribute-list 50 in
You want to filter on an interface for this? If you get the route into
your routing table thats where the problem starts. Attaching the filter
to the peer session will at least get rid of the bad routes from the
start. I would rather use CPU on keeping the BGP sessions clean than
wasting it on checking the interface for packets with 10/8. If anyone
has any better suggestions, I would love to hear them.
Todd R. Stroup
Fiber Network Solutions, Inc.
Because some people like to do prefix length filtering as well, in
which case you need to use an extended access list.
Alec
Maybe I am missing something, but we use an inbound access list on all
external links that eliminates IP address spoofing, as well as some basic
security issues (blocking NFS, r* commands, etc just in case some machine
inside is misconfigured). If you have an inbound access list that filters
based on the source address already, why would you not add the private
addresses to that?
John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801
I disagree.. how about this:
access-list 50 deny 0.0.0.0 0.0.0.31
or for those brave folk:
access-list 50 deny 0.0.0.0 0.0.0.255
The extended access-list is used in the classic "FROM ip" and "TO ip"
application. My point was to use the standard access-list applied to a
BGP session. The only thing I can think of that you would need a FROM/TO
senerio in would be peering with Route Servers, although in this case I
use route-maps filtering on path and by address. I don't even think an
extended access-list will apply to a bgp session, but I could be wrong.
Your BGP peer config is going to look something like this with a standard
access-list :
router bgp 7171
neighbor 198.32.69.69 remote-as 6969 ; sorry about your luck N2K Inc.
neighbor 198.32.69.69 version 4
neighbor 198.32.69.69 distribute-list 50 in
neighbor 198.32.69.69 route-map as-customers out
access-list 50 deny 0.0.0.0 0.0.0.0
access-list 50 deny 0.0.0.0 0.0.0.31
access-list 50 deny 127.0.0.0 0.255.255.255
access-list 50 deny 10.0.0.0 0.255.255.255
etc...
Todd R. Stroup
Fiber Network Solutions, Inc.
I disagree.. how about this:
access-list 50 deny 0.0.0.0 0.0.0.31
or for those brave folk:
access-list 50 deny 0.0.0.0 0.0.0.255
The extended access-list is used in the classic "FROM ip" and "TO
ip" application. My point was to use the standard access-list
applied to a BGP session. The only thing I can think of that you
would need a FROM/TO senerio in would be peering with Route Servers,
although in this case I use route-maps filtering on path and by
address. I don't even think an extended access-list will apply to a
bgp session, but I could be wrong.
Uhm, your example wouldn't work too well if one wanted to selectively
filter longer prefixes (like all longer than /19 in 206->223). That
is what many people are doing, and IMO what more should do.
Your BGP peer config is going to look something like this with a standard
access-list :
router bgp 7171
neighbor 198.32.69.69 remote-as 6969 ; sorry about your luck N2K Inc.
neighbor 198.32.69.69 version 4
neighbor 198.32.69.69 distribute-list 50 in
neighbor 198.32.69.69 route-map as-customers out
access-list 50 deny 0.0.0.0 0.0.0.0
access-list 50 deny 0.0.0.0 0.0.0.31
access-list 50 deny 127.0.0.0 0.255.255.255
access-list 50 deny 10.0.0.0 0.255.255.255
etc...
Yes yes, but this really limits what you can do.
How would you do:
access-list 101 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0
with a standard access list?
Alec
Maybe I am missing something, but we use an inbound access list on all
external links that eliminates IP address spoofing, as well as some basic
security issues (blocking NFS, r* commands, etc just in case some machine
inside is misconfigured). If you have an inbound access list that filters
based on the source address already, why would you not add the private
addresses to that?
This is sort of a different issue.. you are filtering IP not routes. If
you peer with someone that is sending you 10/8 even though you have it
filtered on the inbound of your interface (which is good for CPU) you will
still have a route injected into your route tables which could be
bad. Why not destroy the bad routes before they get to your routing
table?
Todd R. Stroup
Fiber Network Solutions, Inc.
Uhm, your example wouldn't work too well if one wanted to selectively
filter longer prefixes (like all longer than /19 in 206->223). That
is what many people are doing, and IMO what more should do.
Hmm... got me there. You would need individual entries in the
access-list to do that one.
I guess I was referring to those comments in this thread suggesting that
instead of using inbound access filters, which cause CPU performance issues,
instead routes should be generated to null0 (which from my understanding it
is still process switched). Perhaps my choice of message to quote was poor,
but my point is that it seems like you need an ACL on every incoming link
regardless, and you need a filter list on every BGP peer regardless, so why
not put checks in both? I wouldn't think that, given that you need an access
list, adding a few more entries is going to significantly impact performance.
John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801