Re: Understanding Loose uRPF for preventing spoof attacks

RFC3704 - Ingress Filtering for Multihomed Networks

  2. Different Ways to Implement Ingress Filtering . . . . . . . . 4
        2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . 4
        2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . 5
        2.3 Feasible Path Reverse Path Forwarding . . . . . . . . . . 6
        2.4 Loose Reverse Path Forwarding . . . . . . . . . . . . . . 6
        2.5 Loose Reverse Path Forwarding Ignoring Default Routes . . 7

If you are referring to my comment, would you please hint me about what
am I looking for in a careful read ?

-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