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