Re: Understanding Loose uRPF for preventing spoof attacks

If you think this is Security only, it's it's your opinion. You have
both Tyson's and mine in this regard to the opposite... and he IS a
Security CCIE among other two. I am also SP one and trust me when I
tell you that it's not a Security-only thing... Not to mention it's
>explicitly< mentioned on R&S blueprint (6.03). While it's there, I'm
going to teach it and my students will continue to be successful. Your
choice is yours ;-).

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
YES! We include 400 hours of REAL rack
time with our Blended Learning Solution!
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
Web: http://www.ipexpert.com/
On Tue, May 11, 2010 at 06:34, Kambiz Agahian <kagahian_at_ccbootcamp.com> wrote:
> 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. B 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 B <tron_at_huapi.ba.ar> B LW7 EQI B 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