Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00

(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com gcia   

> -----Original Message-----
> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] 
> On Behalf Of Joel Jaeggli
> Sent: Thursday, February 05, 2009 7:22 PM
> To: opsec wg mailing list
> Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00
> 
> Warren Kumari wrote:
> > Now, for the big question:
> > 
> > In the draft we are are requesting a registered BGP 
> community to be used
> > to signal your provider that you want destination based 
> RTBH applied to
> > an announced prefix.
> 
> So I presented this idea and both viewpoints in the NANOG isp security
> BOF and to be honest I couldn't get a rise out of anyone, They neither
> called me a moron nor adopted it as their own...
> 
> I suppose one thought would be to carve it out and drop it in a second
> draft so we can proceed this document without it. Personally I think a
> reserved community has sufficient utility to make it a useful addition
> to the toolkit, but reviews here are obviously mixed.
> 
> > There are two viewpoints on this -- I will try to capture them both,
> > apologies if I mess this up:
> > Viewpoint 1:
> > This should be removed -- different providers will 
> implement RTBH (src
> > and dest) in different ways and will provide different capabilities
> > (drop on the "edge", only install in a specific region, etc) and so
> > there will need to be multiple communities. Getting this 
> info from your
> > provider (and having them enable the feature), etc is (and should
> > remain) a required step.
That sounds like what I said:)
I agree with 1.

> > 
> > Viewpoint 2:
> > I'd like to keep the registered community -- while 
> different providers
> > will support different subsets of this, having a well known way to
> > enable this seems good to me. Currently providers support different
> > communities for different things (e.g: announce this only 
> to peers, set
> > the MED, etc) but there are still some well known (e.g NO_EXPORT)
> > communities that the provider probably implements. I 
> dislike being in
> > the situation where I am experiencing a DoS attack and have 
> misplaced
> > the napkin that I scribbled the secret community on last time. Now,
It had better be better documented then scribbled on a napkit.
It should be part of a standard operations document that your NOC has available to them:)

> > while I am down I need to fight my way through Tier 1 - 
> Tier N trying to
> > find the magic community to apply for provider X. I'd 
> rather just tag an
> > announcement with the registerd RTBH community. If the 
> provider doesn't
> > support this, I'm no worse off, if they do, I've bought some time.
If the provide supports it but only allows /32s or only allows you to advertise your own space (tm good idea)
you might be worse off especally if you think you have done something to mitigate an attack only to find that the mitigation didn't work because you advertised a /30 or space you don't own/route or ...

So while I lean away from a reserved community the worse effect I can come up with is you think you started mitigation but it hasn't started yet. It wouldn't be long before a victim realized the mitigation isn't working and contacted their upstream to find out why:)

> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 