[54861] in North American Network Operators' Group
Re: FW: Re: Is there a line of defense against Distributed Reflective
daemon@ATHENA.MIT.EDU (hc)
Sun Jan 19 01:25:30 2003
Date: Sun, 19 Jan 2003 01:24:50 -0500
From: hc <haesu@towardex.com>
To: Chris Adams <cmadams@hiwaay.net>
Cc: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu
--------------090607040708090201060500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Everyone probably knows... But if not -- just a reminder that you can
also add access-list number after 'ip verify unicast reverse-path' to
allow any hosts you think that should be able to get allowed through the
filter :-) It's convenient when you are doing some mobileIP+vpn stuff in
which some type of setup breaks when there is egress filtering.
Multihomed customers should use uRPF at their Ethernet/local interface
as egress filter... Using uRPF as ingress filter at ISP connections
(such as Serial3/0, Pos2/0, whatever connects to your ISP's) when you
are doing BGP can be quite a nightmare.. :-D So I guess they would have
to use plain-old manual access-list at their ISP-connection interfaces
for ingress filtering.
i.e..
!
int Gig2/0
des backbone connection, egress
ip add 192.0.2.21 255.255.255.252
ip ver unicas reverse-path 180
!
int Pos3/0
des OC-3 from XXX ISP, ingress
ip add 199.99.99.99 255.255.255.252
ip access 101 i
!
!
acc 101 remark plain-old regular ingress filter for multihomed networks
acc 101 den ip $my_network an
acc 101 den ip 10.0.0.0 0.255.255.255 an
acc 101 den ip 172.16.0.0 0.15.255.255 an
acc 101 den ip 192.168.0.0 0.0.255.255 an
acc 101 per ip an an
acc 180 remark exceptions to egress filtering
acc 180 per ip host 199.59.9.110 an
!
!
-hc
Chris Adams wrote:
>Once upon a time, John Kristoff <jtk@aharp.is-net.depaul.edu> said:
>
>
>>It might be nice if all router vendors were able to associate the
>>interface configured address(es)/nets as a variable for ingress
>>filters. So for in the Cisco world, a simple example would be:
>>
>> interface Serial0
>> ip address 192.0.2.1 255.255.255.128
>> ip access-group 100 in
>> !
>> interface Serial1
>> ip address 192.0.2.129 255.255.255.128
>> ip access-group 100 in
>> !
>> access-list 100 permit ip $interface-routes any
>> access-list 100 deny ip any any
>>
>>
>
>How is this different than "ip verify unicast reverse-path" (modulo CEF
>problems and bugs, which of course NEVER happen :-) )?
>
>Multihomed customers are more interesting, but if all the single homed
>customers had uRPF (or $VENDOR's equivalent) enabled it would cut down
>on a significant amount of the spoofed traffic.
>
>
>
--------------090607040708090201060500
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Everyone probably knows... But if not -- just a reminder that you can also
add access-list number after 'ip verify unicast reverse-path' to allow any
hosts you think that should be able to get allowed through the filter :-)
It's convenient when you are doing some mobileIP+vpn stuff in which some
type of setup breaks when there is egress filtering.<br>
<br>
Multihomed customers should use uRPF at their Ethernet/local interface as
egress filter... Using uRPF as ingress filter at ISP connections (such as
Serial3/0, Pos2/0, whatever connects to your ISP's) when you are doing BGP
can be quite a nightmare.. :-D So I guess they would have to use plain-old
manual access-list at their ISP-connection interfaces for ingress filtering.<br>
<br>
i.e..<br>
<br>
!<br>
int Gig2/0<br>
des backbone connection, egress<br>
ip add 192.0.2.21 255.255.255.252<br>
ip ver unicas reverse-path 180<br>
!<br>
int Pos3/0<br>
des OC-3 from XXX ISP, ingress<br>
ip add 199.99.99.99 255.255.255.252<br>
ip access 101 i<br>
!<br>
!<br>
acc 101 remark plain-old regular ingress filter for multihomed networks<br>
acc 101 den ip $my_network an<br>
acc 101 den ip 10.0.0.0 0.255.255.255 an<br>
acc 101 den ip 172.16.0.0 0.15.255.255 an<br>
acc 101 den ip 192.168.0.0 0.0.255.255 an<br>
acc 101 per ip an an<br>
acc 180 remark exceptions to egress filtering<br>
acc 180 per ip host 199.59.9.110 an<br>
!<br>
!<br>
<br>
-hc<br>
<br>
<br>
Chris Adams wrote:<br>
<blockquote type="cite" cite="mid20030118224511.B191482@hiwaay.net">
<pre wrap="">Once upon a time, John Kristoff <a class="moz-txt-link-rfc2396E" href="mailto:jtk@aharp.is-net.depaul.edu"><jtk@aharp.is-net.depaul.edu></a> said:
</pre>
<blockquote type="cite">
<pre wrap="">It might be nice if all router vendors were able to associate the
interface configured address(es)/nets as a variable for ingress
filters. So for in the Cisco world, a simple example would be:
interface Serial0
ip address 192.0.2.1 255.255.255.128
ip access-group 100 in
!
interface Serial1
ip address 192.0.2.129 255.255.255.128
ip access-group 100 in
!
access-list 100 permit ip $interface-routes any
access-list 100 deny ip any any
</pre>
</blockquote>
<pre wrap=""><!---->
How is this different than "ip verify unicast reverse-path" (modulo CEF
problems and bugs, which of course NEVER happen :-) )?
Multihomed customers are more interesting, but if all the single homed
customers had uRPF (or $VENDOR's equivalent) enabled it would cut down
on a significant amount of the spoofed traffic.
</pre>
</blockquote>
<br>
<br>
</body>
</html>
--------------090607040708090201060500--
