From: Liban.Mohamed@mail.sprint.com
Date: Tue Jan 14 2003 - 10:07:25 GMT-3
Hello,
There are 2 type of URPF. Loose mode and strict mode.
"Loose mode"
ip verify unicast source reachable-via any allow-self-ping 108
This means that every inbound packet on this interface has its source
address checked. If the src ip is in the routing table (excluding NULL
routes) accept the packet, if not check to see if the src is the same as
the interface (the "allow self-ping" part), if not run the src ip
through
ACL 108. If nothing matches, drop the packet. Its sort of like an
inbound ACL, but much more efficient.
"strict mode"
ip verify unicast source reachable-via rx allow-self-ping 108
The same as loose mode, except that instead of checking that the src ip
is
in the routing table, we check that the best route is out the interface
that the packet came in on. IE if you did a "show ip cef <src ip>" and
the interface the packet came in on wasn't in the output of the "show ip
cef, drop the packet.
As you can quickly see, strict mode can ONLY be used when there is NO
asymetric routing occuring (or the possiblity to occur).
Liban Mohamed
IP Engineer
Sprintlink
www.sprint.net
-----Original Message-----
From: amarks [mailto:amarks@cisco.com]
Sent: Monday, January 13, 2003 11:56 PM
To: hcb
Cc: ccielab
Subject: Re: Unicast RPF
At 02:39 PM 14/01/2003, Howard C. Berkowitz wrote:
>At 7:10 PM -0400 1/13/03, Joe Chang wrote:
>>Neat way of foiling DoS attacks, but how could an edge ISP router hold
an
>>RPF entry for every Internet network that a customer could possibly
access?
>>I don't think RPF allows for summary entries in the RPF table...
>
>There's no separate RPF table. RPF works by looking up the packet
_source_
>address as well as the destination address in the FIB (assuming there
is a
>separate one).
>
>The more complex case, which I'm uncertain Cisco has implemented
(although
>I think they have in some SP releases), is whether you can declare a
group
>of interfaces, so even if the source address from one packet is not
>reachable through the incoming interface, it passes RPF if another
>interface in the group is reachable. This deals with a number of corner
>cases in load sharing and multihoming.
I think you are referring to uRPF "Loose Check". This removes the
standard
adjacency check and merely says "is the source in the FIB? If not, drop
it". This takes care of asymmetric flows.
A slightly old document:
http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf
Aidan
>>----- Original Message -----
>>From: "Jason Sinclair" <sinclairj@powertel.com.au>
>>To: <Sam.MicroGate@usa.telekom.de>; <ccielab@groupstudy.com>
>>Sent: Monday, January 13, 2003 6:54 PM
>>Subject: RE: Unicast RPF
>>
>>
>>> Sam,
>>>
>>> Uni RPF is a security technique to help overcome some of the common
DoS
>>> attacks that are based on forged headers (spoofing). For details
see:
>>>
>>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgc
r/fsec
>>> ur_c/fothersf/scfrpf.htm
>>>
>>> Cheers,
>>>
>>> Jason Sinclair CCIE #9100
>>> Manager, Network Control Centre
>>> POWERTEL
>>> 55 Clarence Street,
>>> SYDNEY NSW 2000
>>> AUSTRALIA
>>> office: + 61 2 8264 3820
>>> mobile: + 61 416 105 858
>>> email: sinclairj@powertel.com.au
>>>
>>> -----Original Message-----
>>> From: Sam.MicroGate@usa.telekom.de
[mailto:Sam.MicroGate@usa.telekom.de]
>>> Sent: Tuesday, 14 January 2003 09:08
>>> To: ccielab@groupstudy.com
>>> Subject: Unicast RPF
>>>
>>> Hello Group,
>>>
>>> I know what a multicast Reverse Path Forwarding is. Anyone can
explain to
>>me
>>> what is a unicast RPF? Does it have the same meaning as in
multicast?
>>>
>>> Thanks.
>>>
>>> Sam
>>> .
>>>
**********************************************************************
>>> PowerTel Limited, winners of
>>> Best Corporate/Wholesale Broadband Initiative, Australian Telecom
Awards
>>2002
>>> Broadband Wholesale Carrier of the year, CommsWorld Telecomms
Awards 2001
>>> Best Emerging Telco, Australian Telecom Awards 2001
>>>
>>>
**********************************************************************
>>> This email (including all attachments) is intended solely for the
named
>>> addressee. It is confidential and may contain commercially
sensitive
>>> information. If you receive it in error, please let us know by
reply
>>email,
>>> delete it from your system and destroy any copies.
>>>
>>> This email is also subject to copyright. No part of it should be
>>reproduced,
>>> adapted or transmitted without the prior written consent of the
copyright
>>owner.
>>>
>>> Emails may be interfered with, may contain computer viruses or
other
>>defects
>>> and may not be successfully replicated on other systems. We give no
>>> warranties in relation to these matters. If you have any doubts
about
>>> the authenticity of an email purportedly sent by us, please contact
us
>>> immediately.
>>>
>>>
**********************************************************************
>>> .
>>.
>.
.
.
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:49 GMT-3