From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue Jan 14 2003 - 16:55:10 GMT-3
At 3:56 PM +1100 1/14/03, Aidan Marks wrote:
>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
I was aware of this, but there's an intermediate way between loose
and strict check, which is a little more secure. AFAIK, it doesn't
exist in IOS, or, even more importantly, in distributed forwarders.
I don't think I'm the only one to have done this in a router, but in
some experimental code, I added a group ID to the route entry in the
FIB. That allowed me to create classes of interface, rather simply to
say "there exists a route somehow to that address." By doing so, you
avoid the overhead of a conditionally applied access list at the cost
of a byte or so per route of memory. Especially in an intelligent
forwarding card, the overhead of doing this is trivial.
As I say, I've done it in experimental code, but I think there's at
least one commercial implementation, but I can't remember which.
Could be a recent NextHop/GateD or IPInfusion/Zebra, maybe JunOS, etc.
>
>
>
>>>----- 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/122cgcr/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