Re: [OPSEC] http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt

["Smith, Donald" <[e-mail]>]

Security through obscurity WORKS against some worms and ssh attacks:)
[e-mail] giac 

> -----Original Message-----
> From: Warren Kumari [mailto:[e-mail]] 
> Sent: Wednesday, September 17, 2008 4:47 PM
> To: Smith, Donald
> Cc: Joel Jaeggli; opsec wg mailing list
> Subject: Re: [OPSEC] 
> http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt
> 
> Hi all,
> 
> I am feeling a little bad that I received this a while ago 
> and haven't  
> responded yet -- I have visitors at the moment and things have been  
> hectic keeping them amused, etc...
> 
> Anyway, thank you very much for your comments -- I haven't 
> had time to  
> fully digest them, so these are incomplete thoughts...
> 
> 
> On Sep 11, 2008, at 3:00 PM, Smith, Donald wrote:
> 
> > First let me say this is valuable work and it is well done.
> > It should be accepted as a WG document.
> >
> >
> 
> Yay! Thank you :-)
> 
> >
> > It suffers from inconsistent use of the following teams 
> which appear  
> > to
> > mean the same thing I recommend Remote Triggered Black Hole 
> filtering
> > but which ever term is used should be used consistently.
> 
> Thank you, will search and replace...
> 
> 
> >
> >
> > Triggered black-hole routing, Remote triggered black hole 
> routing and
> > RTBH filtering.
> >
> >
> > If "As a matter of policy, operators SHOULD NOT accept 
> source-based  
> > RTBH
> > announcements from their peers or customers" then why 
> bother asking  
> > for
> > a registered community from IANA?
> 
> Bah... I was hoping no-one would notice this :-P. I started off  
> writing this because there was a (perceived) need for standard  
> community so that customers can signal their provider that 
> they would  
> like DESTINATION based RTBH applied (I have often run into the "OMG,  
> I'm being attacked, what was $PROVIDERs community for this 
> again? 666?  
> 37? something? Help!" issues. Usually people start calling their  
> provider at this point, then realize that the first tier support has  
> no idea, etc..). This document then morphed into a source based RTBH  
> document...
> 
> I do still believe that it would be beneficial if there was a  
> standardized community to signal your provider that you want  
> DESTINATION based RTBH applied, but probably not SOURCE RTBH. 
> How does  
> this sound? 
That sounds good. 666 is a fairly commonly used community for that.


>I DID try figuring out how to word this in the doc, but,  
> well...
> 
> 
> >
> >
> > The cisco and juniper examples only covers destination based RTBH
> > filtering no urpf statements are included and therefore source based
> > RTBH is not provided by the example configs. That may have been the
> > intention of the authors but it wasn't what I expected.
> 
> Yeah, I was going to put in multiple examples, one for destination,  
> then one for source, but apparently got sidetracked  -- I'll try fix  
> this...

If you just add the loose mode (and feasible vs active paths for junos
maybe?) that should be enough. 

> 
> >
> >
> > Does this imply that strict mode urpf can't be used for source based
> > RTBH?
> >
> 
> Nope, not at all... I was a little wary of suggesting strict mode  
> because, all to often I have seen the "Oooh, a config 
> snippet, let me  
> paste it onto all of our routers without understanding it..." 
> syndrome  
> -- I didn't want to get grumpy emails asking why I suggested that :-)
> 
> > "In loose mode some vendors also verify that the destination route
> >   does not point to a discard interface."
> > If so going from strict mode to loose to support source 
> based RTBH has
> > some serious security implications.

How about:
"In strict or loose mode some vendors also verify that the destination
route does
not point to a discard interface."

That way you can leave strict mode out of the config sample but others
won't wonder if strict mode would work with uppf for src based RTBHF.



> >
> 
> 
> Nope, if you have strict mode, thats fine, but if you have no URPF,  
> you need to be a little more careful turning on strict than loose...
> 
> > Security through obscurity WORKS against some worms and ssh 
> attacks:)
> > [e-mail] giac
> 
> 
> Once again, thank you for you comments, I will try and update the  
> draft ti include them soon...
> 
> W
> 
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> On Behalf Of Joel Jaeggli
> >> Sent: Thursday, September 11, 2008 11:58 AM
> >> To: opsec wg mailing list
> >> Subject:
> >> [OPSEC]http://www.ietf.org/internet-drafts/draft-kumari-blackh
> >> ole-urpf-00.txt
> >>
> >> Was one of the upcoming documents mentioned in the dublin meeting.
> >>
> >> this document expands on the method in RFC3882 and I think 
> much more
> >> accurately represents current operational practice.
> >>
> >> some review on it's current form and consensus as to whether we  
> >> should
> >> accept it as a working group document would be appreciated.
> >>
> >> Thanks
> >> joelja
> >> _______________________________________________
> >> OPSEC mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsec
> >>
> >
> >
> > This communication is the property of Qwest and may contain  
> > confidential or
> > privileged information. Unauthorized use of this communication is  
> > strictly
> > prohibited and may be unlawful.  If you have received this  
> > communication
> > in error, please immediately notify the sender by reply e-mail and  
> > destroy
> > all copies of the communication and any attachments.
> > _______________________________________________
> > OPSEC mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsec
> >
> 
> 
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec