RE: Understanding Loose uRPF for preventing spoof attacks

No worries Jorge.

For the CCIE R&S you need to know the following link:
http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html

For being a successful engineer and a good Security candidate, please read through the whole security RFC as well as the book that I mentioned earlier.

HTH

--------------------------
Kambiz Agahian
CCIE (R&S), CCSI, WAASSE, RSSSE
Technical Instructor
CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
Email: kagahian_at_ccbootcamp.com
Toll Free: 877-654-2243
International: +1-702-968-5100
Skype: skype:ccbootcamp?call
FAX: +1-702-446-8012
YES! We take Cisco Learning Credits!
Training And Remote Racks: http://www.ccbootcamp.com

-----Original Message-----
From: Jorge Cortes [mailto:jorge.cortes.cano_at_gmail.com]
Sent: Tuesday, May 11, 2010 12:16 PM
To: Carlos G Mendioroz
Cc: Kambiz Agahian; Tyson Scott; Marko Milivojevic; Cisco certification
Subject: Re: Understanding Loose uRPF for preventing spoof attacks

Thank you everyone for taking the time for discussing on this topic,
this has really been very enlightening to me and hopefully to others
as well.

Regards,

Jorge

On Tue, May 11, 2010 at 11:45 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
> Got it. Strict, loose, loose w/o default.
> And the RFC says what we all are saying:
>
> Loose Reverse Path Forwarding has problems, however. Since it
> sacrifices directionality, it loses the ability to limit an edge
> network's traffic to traffic legitimately sourced from that network,
> in most cases, rendering the mechanism useless as an ingress
> filtering mechanism.
>
> and cisco adds strict w/o default as a non RFC based mech.
> On the ohter hand, filtering based on ACLs is also a "standards based
> method" :)
>
> -Carlos
>
> Kambiz Agahian @ 11/5/2010 13:17 -0300 dixit:
>>
>> RFC-3704; read that carefully please.
>>
>>
>> --------------------------
>> Kambiz Agahian
>> CCIE (R&S), CCSI, WAASSE, RSSSE
>> Technical Instructor
>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>> Email: kagahian_at_ccbootcamp.com
>> Toll Free: 877-654-2243 International: +1-702-968-5100 Skype:
>> skype:ccbootcamp?call
>> FAX: +1-702-446-8012
>> YES! We take Cisco Learning Credits!
>> Training And Remote Racks: http://www.ccbootcamp.com
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar] Sent: Tuesday, May 11,
>> 2010 2:35 AM
>> To: Tyson Scott
>> Cc: Kambiz Agahian; 'Marko Milivojevic'; 'Jorge Cortes'; 'Cisco
>> certification'
>> Subject: Re: Understanding Loose uRPF for preventing spoof attacks
>>
>> You guys rock!
>> Kambiz says there are 3 in the RFC, but the RFC talks about 5:
>> 1 is ACL based (no fun), one is not cisco implemented, and that leaves 3
>> to choose from: loose, strict and strict with default.
>>
>> Too bad feasible it's not there, it would be great.
>>
>> Keep the good work!
>> -Carlos
>>
>> Tyson Scott @ 11/05/2010 2:49 -0300 dixit:
>>>
>>> Jorge,
>>>
>>> Yes your assumptions are correct.
>>> ingress filtering is the best way to prevent spoofing with multi-homed
>>> networks.
>>> As you can never fully control inbound traffic from an ISP because
>>> regardless of your attempts to control traffic with as-path prepending
>>
>> etc
>>>
>>> the ISP will still send traffic it chooses to you regardless of what
>>
>> you
>>>
>>> have configured for where you want to learn it from. You will always
>>
>> end up
>>>
>>> dropping traffic with multi-homed networks no matter how much you try
>>
>> to
>>>
>>> influence BGP.
>>>
>>>
>>> Carlos/Jorge,
>>>
>>> With Cisco there are three techniques
>>> legacy using "ip verify unicast reverse-path"
>>> strict "ip verify unicast source reachable-via rx"
>>> loose "ip verify unicast source reachable-via any" All three support
>>> using an ACL to specify either traffic you want to
>>
>> ignore
>>>
>>> or the specific traffic you only want to track.
>>> All three support the allow-self-ping feature.
>>> Both strict and loose support allow-default. Using the allow-default
>>
>> with
>>>
>>> the loose turns it from not very useful to basically useless.
>>>
>>> Ignore any other talk in this conversation about BGP. It has nothing
>>
>> to do
>>>
>>> with the feature. Just remember the FIB is what is important.
>>>
>>> Regards,
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>> Technical Instructor - IPexpert, Inc.
>>> Mailto: tscott_at_ipexpert.com
>>> Telephone: +1.810.326.1444, ext. 208
>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>> eFax: +1.810.454.0130
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Kambiz Agahian [mailto:kagahian_at_ccbootcamp.com] Sent: Tuesday, May
>>> 11, 2010 1:25 AM
>>> To: Tyson Scott; Marko Milivojevic
>>> Cc: Jorge Cortes; Carlos G Mendioroz; Cisco certification
>>> Subject: RE: Understanding Loose uRPF for preventing spoof attacks
>>>
>>> Tyson,
>>> 1- Yeah thanks mate. I'm happy to be right:) Just found the Juniper
>>> config; I'll give it a shot soon.
>>> 2- What you said is pretty much what I asked Marko to read about in
>>
>> that
>>>
>>> book and the RFC so yeah that's what I'm saying :)
>>> 3- I would not ask an R&S student very RFC specific security topics.
>>
>> But
>>>
>>> as I mentioned before a "sharp" R&S student might with to read through
>>> the RFC to learn more. But for the R&S track usually the ACL thing is
>>> the end point. 4- The feasible option is still not supported even in the
>>> IOS 15.1.
>>>
>>> Cheers,
>>>
>>> --------------------------
>>> Kambiz Agahian
>>> CCIE (R&S), CCSI, WAASSE, RSSSE
>>> Technical Instructor
>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>> Email: kagahian_at_ccbootcamp.com
>>> Toll Free: 877-654-2243 International: +1-702-968-5100 Skype:
>>> skype:ccbootcamp?call
>>> FAX: +1-702-446-8012
>>> YES! We take Cisco Learning Credits!
>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>
>> Of
>>>
>>> Tyson Scott
>>> Sent: Monday, May 10, 2010 10:08 PM
>>> To: Kambiz Agahian; 'Marko Milivojevic'
>>> Cc: 'Jorge Cortes'; 'Carlos G Mendioroz'; 'Cisco certification'
>>> Subject: RE: Understanding Loose uRPF for preventing spoof attacks
>>>
>>> Kambiz,
>>>
>>> You are correct, Juniper supports feasible RPF. It is a much more
>>> realistic
>>> solution then loose RPF which really is of little use in my opinion.
>>> Hopefully this will be a 15 Mainline new feature sometime for Cisco.
>>>
>>> But, BGP really has nothing to do with the RPF feature "directly".
>>
>> The
>>>
>>> point of the RFC is the FIB (which can be built by any routing
>>
>> protocol)
>>>
>>> needs to agree with the incoming path of traffic when working with
>>> strict
>>> RPF. Now because this feature is typically used at the enterprise
>>
>> edge
>>>
>>> BGP
>>> is mentioned throughout the RFC to be a point of reference of what
>>> routing
>>> protocol is most likely used to build the FIB with the ISP. You could
>>> attempt to use BGP to further control path selection thru multiple
>>> filtering
>>> techniques but again it is just fixing the FIB. BGP still has nothing
>>> directly to do with the RPF feature. And you can never fully control
>>> inbound traffic as you cannot control what the ISP will send to you so
>>> strict RPF in multi-homed networks is unrealistic.
>>>
>>> Whether it is a Security focused topic or not is irrelevant as RPF is
>>> important for R&S/SP students to understand as it is in the blueprint,
>>> as
>>> Marko was saying, and was even there when I took the test in 04.
>>>
>>> I think the things you discussed and bringing the RFC into the
>>> discussion
>>> were very helpful to everyone though.
>>>
>>> Regards,
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>> Technical Instructor - IPexpert, Inc.
>>> Mailto: tscott_at_ipexpert.com
>>> Telephone: +1.810.326.1444, ext. 208
>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>> eFax: +1.810.454.0130
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>
>> Of
>>>
>>> Kambiz Agahian
>>> Sent: Tuesday, May 11, 2010 12:35 AM
>>> To: Marko Milivojevic
>>> Cc: Jorge Cortes; Carlos G Mendioroz; Cisco certification
>>> Subject: RE: Understanding Loose uRPF for preventing spoof attacks
>>>
>>> Marko,
>>>
>>> Please read Chapter 4 of this book or just the RFC-3704:
>>>
>> http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/158
>>>
>>> 7053365/ref=sr_1_1?ie=UTF8&s=books&qid=1273551557&sr=8-1
>>>
>>> I personally like the traffic plane stuff like this one.
>>> Believe me it's an IE security thing :-) that's why you've never
>>
>> touched
>>>
>>> it, but if I come across a sharp student I'll push him to read through
>>> the while RFC-3704; a nice one. The beauty of this could be a appeared
>>> in a question like "choose the best industry standard (RFC-based)
>>> solution to ensure..." or something like that.
>>>
>>> PS0. I've never tried this out on a Juniper box; but I'm under
>>> impression that Juniper does support the feasible mode; to get rid of
>>> the whole BGP thing. PS1. I doubt it, really!; that you can find such
>>> sharp security
>>
>> students
>>>
>>> PS2. CCIE R&S candidates usually don't go beyond the ACL attached to
>>
>> the
>>>
>>> uRPF command.
>>> PS3. RFC's are usually good :)
>>>
>>>
>>> --------------------------
>>> Kambiz Agahian
>>> CCIE (R&S), CCSI, WAASSE, RSSSE
>>> Technical Instructor
>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>> Email: kagahian_at_ccbootcamp.com
>>> Toll Free: 877-654-2243 International: +1-702-968-5100 Skype:
>>> skype:ccbootcamp?call
>>> FAX: +1-702-446-8012
>>> YES! We take Cisco Learning Credits!
>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>
>> Of
>>>
>>> Marko Milivojevic
>>> Sent: Monday, May 10, 2010 7:59 PM
>>> To: Kambiz Agahian
>>> Cc: Jorge Cortes; Carlos G Mendioroz; Cisco certification
>>> Subject: Re: Understanding Loose uRPF for preventing spoof attacks
>>>
>>> I wonder how you "use BGP to use even strict mode" in real live
>>> multihomed network where asymmetric traffic is abundant ;-).
>>>
>>> This is btw. a perfectly valid R&S/SP topic, as it is on both
>>> blueprints.
>>>
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427
>>> Senior Technical Instructor - IPexpert
>>>
>>> Mailto: markom_at_ipexpert.com
>>> Telephone: +1.810.326.1444
>>> Fax: +1.810.454.0130
>>> Community: http://www.ipexpert.com/communities
>>>
>>> :: Sent from my phone. Apologies for errors and brevity. ::
>>>
>>> On 11 May 2010, at 04:01, "Kambiz Agahian" <kagahian_at_ccbootcamp.com>
>>> wrote:
>>>
>>>> Jorge,
>>>>
>>>> Long, long story...
>>>>
>>>> Very briefly, no the Feasible uRPF has not been implemented within the
>>>> IOS yet. In dual or multihomed SP/enterprise networks we usually
>>
>>>> use BGP to be able to deploy (even) the Strict mode; BUT to get rid of
>>>> that BGP thing you could use the "Feasible feature" :)
>>>>
>>>> If this imaginary discussion is not still crystal clear and you need
>>
>>>> to know more; please give me a buzz. This however sounds more like a
>>
>>>> CCIE security to me.
>>>>
>>>>
>>>> --------------------------
>>>> Kambiz Agahian
>>>> CCIE (R&S), CCSI, WAASSE, RSSSE
>>>> Technical Instructor
>>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>>> Email: kagahian_at_ccbootcamp.com
>>>> Toll Free: 877-654-2243
>>>> International: +1-702-968-5100
>>>> Skype: skype:ccbootcamp?call
>>>> FAX: +1-702-446-8012
>>>> YES! We take Cisco Learning Credits!
>>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jorge Cortes [mailto:jorge.cortes.cano_at_gmail.com]
>>>> Sent: Monday, May 10, 2010 5:40 PM
>>>> To: Kambiz Agahian
>>>> Cc: Carlos G Mendioroz; Cisco certification
>>>> Subject: Re: Understanding Loose uRPF for preventing spoof attacks
>>>>
>>>> Thanks Kambiz,
>>>>
>>>> Interesting reading. It has raised more questions though:
>>>>
>>>> Does cisco implement Feasible RPF? Or only Strict and Loose
>>>> implementations are supported?
>>>>
>>>> The following paragraph from section 4.2 confuses me a bit:
>>>>
>>>> "There are a number of techniques which make it easier to ensure the
>>>> ISP's ingress filter is complete. Feasible RPF and Strict RPF with
>>>> operational techniques both work quite well for multihomed or
>>>> asymmetric scenarios between the ISP and an edge network."
>>>>
>>>> I would think Strict RPF doesn't work well in multihomed scenarios
>>>> where traffic flows asymmetric since most likely you will be
>>
>> receiving
>>>>
>>>> traffic not on the interface used for getting to the network the
>>>> traffic is coming from.
>>>>
>>>> Jorge
>>>>
>>>> On Mon, May 10, 2010 at 5:53 PM, Kambiz Agahian
>>>
>>> <kagahian_at_ccbootcamp.com
>>>>>
>>>>> wrote:
>>>>> Jorge,
>>>>>
>>>>> Nice question.
>>>>>
>>>>> According to RFC-3704 there is only three modes of RPF: Strict,
>>
>> Loose
>>>>>
>>>>> and Feasible.
>>>>>
>>>>> When you use the loose mode you're actually ignoring what's called
>>>>> "directionality" - why? Because as you've noticed as long as you see
>>>>> the
>>>>> route the box is happy to forward it. If you take a look at RFC-3704
>>>>> Chapter 2.4; they've exactly answered your question. In that case
>>>>> you're
>>>>> right; the loose thing is inefficient.
>>>>>
>>>>> HTH
>>>>>
>>>>> --------------------------
>>>>> Kambiz Agahian
>>>>> CCIE (R&S), CCSI, WAASSE, RSSSE
>>>>> Technical Instructor
>>>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>>>> Email: kagahian_at_ccbootcamp.com
>>>>> Toll Free: 877-654-2243
>>>>> International: +1-702-968-5100
>>>>> Skype: skype:ccbootcamp?call
>>>>> FAX: +1-702-446-8012
>>>>> YES! We take Cisco Learning Credits!
>>>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>>>> Of
>>>>> Carlos G Mendioroz
>>>>> Sent: Monday, May 10, 2010 11:33 AM
>>>>> To: Jorge Cortes
>>>>> Cc: Cisco certification
>>>>> Subject: Re: Understanding Loose uRPF for preventing spoof attacks
>>>>>
>>>>> uRPF has, appart from vrf modes, 4 alternatives:
>>>>> loose/strict, with or w/o default.
>>>>>
>>>>> Strict needs the (default/specific network) pointing to the incoming
>>>>> if.
>>>>> Loose needs the (default/specific network) pointing somewhere.
>>>>>
>>>>> Loose with default is kind of useless, IMHO, but loose needs the route
>>>>> to the origing to be at the RIB, so the source has to be known...
>>>>>
>>>>> -Carlos
>>>>>
>>>>> Jorge Cortes @ 10/5/2010 12:42 -0300 dixit:
>>>>>>
>>>>>> Hi Team,
>>>>>>
>>>>>> I've been thinking about uRPF for preventing spoof attacks and so far
>>>>>> this is what I understand:
>>>>>>
>>>>>> When strict uRPF is in use, the incoming packets are checked
>>
>> against
>>>>>>
>>>>>> the routing table and there must be an exact match [network, outgoing
>>>>>> interface] in it in order for the packet to be forwarded, otherwise
>>>>>> it
>>>>>> is dropped.
>>>>>> When loose uRPF is in use, the routing table is only checked for
>>>>>> routes pointing to the source network of the incoming packets, but
>>
>> a
>>>>>>
>>>>>> check on the incoming interface is not enforced.
>>>>>>
>>>>>> So given the above facts strict uRPF is very well suited for
>>>>>> preventing spoof attacks when the offending packets have an spoofed
>>>>>> IP
>>>>>> address in any network that is not in the routing table, as well as
>>>>>> internal networks; however, I can see that loose uRPF fails to
>>>>>> prevent
>>>>>> spoof attacks when the offending packets have an spoofed IP address
>>>>>> in
>>>>>> the internal network, since the routers have routes for the
>>
>> internal
>>>>>>
>>>>>> networks and there is no check enforced on the incoming interface,
>>
>>>>>> is
>>>>>> my understanding correct?
>>>>>>
>>>>>> If we have a multihomed topology where the traffic flows are
>>>>>> asymmetric and we are asked to prevent spoof attacks with IP
>>>>>> addresses
>>>>>> in the internal network, what would be the way to accomplish this?
>>
>>>>>> The
>>>>>> simplest solution that comes to my mind would be applying ingress
>>>>>> access lists denying packets with source ip address from the internal
>>>>>> network on the interfaces facing the external network, but I would
>>>>>> like to expand the possibilities.
>>>>>>
>>>>>> Thanks,
>>>>>> Jorge
>>>>>>
>>>>>>
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>
>>>>>>
>> _______________________________________________________________________
>>>
>>>
>>>>>>
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>>
>> _______________________________________________________________________
>>>
>>>
>>>>>
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>>
>> _______________________________________________________________________
>>>
>>>
>>>>
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>>
>> _______________________________________________________________________
>>>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>>
>> _______________________________________________________________________
>>>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>>
>> _______________________________________________________________________
>>>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Tue May 11 2010 - 13:10:17 ART