RE: Understanding Loose uRPF for preventing spoof attacks

Probably you can find much better uRPF examples in the 360 stuff, our
content or Narbik's. But they are NOT "RFC specific" as I mentioned
earlier.

HTH

PS. Please respect the NDA as we're not here to discuss about what has
been and what has not been seen on the actual exam.

From: Lala Lander [mailto:sshafi_at_gmail.com]
Sent: Tuesday, May 11, 2010 12:55 AM
To: Kambiz Agahian
Cc: Marko Milivojevic; Jorge Cortes; Carlos G Mendioroz; Cisco
certification
Subject: Re: Understanding Loose uRPF for preventing spoof attacks

Kambiz,

I recently passed my SP lab (In Feb) and I can tell you without breaking
NDA that Marko is right. INE, IPX and Roman's labs cover this topic in
detail and I am extremely glad that i went through them. Marko really
knows his stuff and he is spot on here.

thanks,
Shahid
CCIE#12665 (RS,Sec,SP)

On Tue, May 11, 2010 at 12:17 AM, Kambiz Agahian
<kagahian_at_ccbootcamp.com> wrote:

>> If you think this is Security only,

***
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
***

Hopefully a quick review helps.

But if this depth was really R&S or SP I would have expected "you" (and
not Tyson) to know that.

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
Marko Milivojevic
Sent: Tuesday, May 11, 2010 12:11 AM
To: Kambiz Agahian
Cc: Jorge Cortes; Carlos G Mendioroz; Cisco certification
Subject: 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
>>>>
>>>>
>>>
>