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
> >>>>
> >>>>
> >>>
> > _______________________________________________________________________
> >
> >
> >>>> 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
>
> _______________________________________________________________________
> 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
Received on Tue May 11 2010 - 00:55:20 ART