Date: Tue, 23 Sep 1997 20:46:15 +0900 To: Cary Howell <chowell@comstar.net> From: Martyn Williams <martyn@twics.com> Subject: Re: Spammer at new home. Cc: nanog@merit.edu
Isn't spammer Quantum at quantcom.com ?
Actually, quantumcomm.com is a more interesting traceroute. Especially hops 11 and 12, clearly being passed by Sprintlink. Does anyone besides me see it as an issue that Sprintlink would pass those packets? No, the network 10 isn't in my routing tables. 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? Or is my view on the situation incomplete? traceroute www.quantumcomm.com traceroute to www.quantumcomm.com (206.191.222.77), 30 hops max, 40 byte packets 1 www-186 (205.210.186.2) 2 ms * 1 ms 2 bcicor1-100bt-e1.barrie.connex.net (205.189.200.35) 1 ms 1 ms 1 ms 3 207.107.244.217 (207.107.244.217) 6 ms 207.107.244.213 (207.107.244.213) 6 ms spc-tor-7-Serial11-0-0-28.Sprint-Canada.Net (207.107.244.209) 6 ms 4 204.50.251.33 (204.50.251.33) 112 ms 11 ms 220 ms 5 144.228.165.25 (144.228.165.25) 20 ms 22 ms 19 ms 6 144.228.60.21 (144.228.60.21) 20 ms 21 ms 20 ms 7 144.232.0.78 (144.232.0.78) 21 ms 48 ms 20 ms 8 144.232.8.86 (144.232.8.86) 71 ms 77 ms 31 ms 9 144.228.50.18 (144.228.50.18) 43 ms 40 ms 37 ms 10 sl-sspace-1-S0-T1.sprintlink.net (144.228.18.78) 41 ms 39 ms 43 ms 11 10.1.0.5 (10.1.0.5) 41 ms 44 ms 41 ms 12 10.0.0.138 (10.0.0.138) 110 ms 71 ms 50 ms 13 206.191.222.77 (206.191.222.77) 76 ms 53 ms 51 ms bcicor1.barrie>sh ip rout 10.0.0.0 % Network not in table bcicor1.barrie>sh ip bgp sum BGP table version is 3941193, main routing table version 3941193 48010 network entries (187332/187900 paths) using 11208976 bytes of memory 19645 BGP path attribute entries using 2615348 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Dampening enabled. 243 history paths, 78 dampened paths 93539 received paths for inbound soft reconfiguration Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State 206.186.255.219 4 3602 1397791 460484 3941185 0 0 1w1d 206.221.252.1 4 6327 1107934 701905 3941185 0 0 1d07h
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
Or is my view on the situation incomplete?
I think so. -- --bill
What about providers that use portions of the private address space on their network (up to and including the client's serial interface)? Mohamad On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote:
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
Or is my view on the situation incomplete?
I think so.
-- --bill
What about providers that use portions of the private address space on their network (up to and including the client's serial interface)?
Mohamad
On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote:
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. -- --bill
On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote:
What about providers that use portions of the private address space on their network (up to and including the client's serial interface)?
Mohamad
On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote:
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
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
This type of question is very much a private matter between consenting adults/peers/clients. I would not presume that my clients would know what I was doing with this address space. I would not presume that they were not using it either. IMHO, this is something that is placed in the contract. Sort of like a prenup, AIDS check, or whether my date bites -BEFORE- its too late/embarassing. -- --bill
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.
On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote:
! 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.
-- --bill
On Tue, Sep 23, 1997 at 12:43:29PM -0400, Todd R. Stroup wrote:
Why not use a standard access-list like :
Because some people like to do prefix length filtering as well, in which case you need to use an extended access list. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
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. On Tue, 23 Sep 1997, Alec H. Peterson wrote:
On Tue, Sep 23, 1997 at 12:43:29PM -0400, Todd R. Stroup wrote:
Why not use a standard access-list like :
Because some people like to do prefix length filtering as well, in which case you need to use an extended access list.
Alec
-- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
On Tue, Sep 23, 1997 at 04:43:16PM -0400, Todd R. Stroup wrote:
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 -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
On Tue, 23 Sep 1997, Alec H. Peterson wrote:
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.
Alec
-- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
On Tue, 23 Sep 1997, Todd R. Stroup wrote:
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.
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
On Tue, 23 Sep 1997, John A. Tamplin wrote:
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.
John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Tue, 23 Sep 1997, Todd R. Stroup wrote:
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?
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
On Tue, Sep 23, 1997 at 08:50:09AM -0400, Dennis Simpson wrote:
Actually, quantumcomm.com is a more interesting traceroute. Especially hops 11 and 12, clearly being passed by Sprintlink. Does anyone besides me see it as an issue that Sprintlink would pass those packets? No, the network 10 isn't in my routing tables.
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?
You don't need to see the prefix for 10/8 to be able to pass packets through hosts in said prefix. Some consider it poor form to use RFC1918 space for hosts that are visible to the outside world. As long as you don't _announce_ said space to the rest of the world it really only breaks MTU path discovery and maked debugging a little more difficult. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
participants (6)
-
Alec H. Peterson -
bmanning＠ISI.EDU -
Dennis Simpson -
John A. Tamplin -
Mohamad Eljazzar -
Todd R. Stroup