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

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Jan 2009 13:21:09 -0500

Hello all,

I have just posted draft-ietf-opsec-blackhole-urpf-00 (ex raft-kumari- 
blackhole-blckhole-02)

I appreciate all of the feedback (and especially the suggested  
text :-)) that people have been supplying and hope that I have  
accurately captured your input -- if not, I *do* apologize, I decided  
to batch up all the changes and they might have gotten away from me.  
Please let me know if I messed up and I will fix it...

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.

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.

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,  
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.

I'd appreciate any feedback on this, and the rest of the doc. And,  
once again, thnaks to all who have already provided feedback...

W

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I  
care."  -- Terry Prachett

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Danny McPherson <[email-masked]>
Date: Tue, 20 Jan 2009 20:55:52 -0700

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

Viewpoint 1 is mine..  I've seen providers with 10 communities
or more, and I'm not sure that defining well-known ones fixes
anything.

I too, as you might imagine, agree with Warren that we'd very
much like to see what the WG thinks about this.

-danny

> 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, 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.
>

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 21 Jan 2009 12:07:01 +0800

> known way to enable this seems good to me.

The problem with this is that it lacks granularity, and if this were  
to come to pass and you tagged your announcement accordingly, you  
don't know what the result will be, nor where, nor how.

We've all seen instances of uncoordinated mitigation which have gone  
awry and made things worse, not better.  Any kind of inter-provider  
signaling of this type should only be undertaken/work after an  
explicit mutual understanding has been reached regarding expectations  
and actual behavior.

Given the fact that various operators have implemented various  
communities for various purposes over time, and given the  
situationally-specific nature of the blackholing mechanisms  
themselves, I think that while this is a noble goal, that it simply  
isn't practical in this particular milieu and should probably be  
removed.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // +852.9133.2844 mobile

      All behavior is economic in motivation and/or consequence.

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 21 Jan 2009 12:09:08 +0800

> Any kind of inter-provider

Typo - should be 'inter-operator', apologies.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 20 Jan 2009 23:59:25 -0500

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

I don't believe a 'well known community' helps here... I believe it
will cause more issues than it resolves. I fear that folks will assume
their provider has this enabled (because configuration is required on
the provider side, unlike no-advertise and no-export). This will cause
unpredictable behaviour for customers and operators.

-Chris

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Jan 2009 08:49:04 -0500

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 21 Jan 2009 08:28:26 -0700

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Warren Kumari
> Sent: Wednesday, January 21, 2009 6:49 AM
> To: Christopher Morrow
> Cc: [email-masked]
> Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00
> 
> Cool...
> 
> Well, it looks fairly obvious that Danny's view (viewpoint 1) 
> here is  
> the prevalent one --- I'll update the draft soon to reflect 
> this (I'll  
> give it a couple of days so I can also incorporate any other feed  
> back, hint hint...)
> 
> W
> 
> 
> On Jan 20, 2009, at 11:59 PM, Christopher Morrow wrote:
> 
> > On Tue, Jan 20, 2009 at 1:21 PM, Warren Kumari <[email-masked]>  
> > wrote:
> >
> >> used to

---

From: "Ryan Mcdowell (rymcdowe)" <[email-masked]>
Date: Wed, 21 Jan 2009 19:06:17 -0500

a standard community could capture all the power and options possible.
A standard community would greatly reduce the flexibility.  

Does the provider set no-advertise on such updates so I have to
advertise them over every eBGP session?  Does the provider do source,
destination, or both blackholing?  Does the provider attempt to
propagate it to their upstreams?  If so, which ones?  Can I control
which ones?  If the provider has multiple ASes, do they propagate it to
all their ASes?  If so, which ones?  Can I control which ones?  Does the
provider offer QPPB instead of blackholing? Etc...  

----------------------------
Ryan McDowell
Systems Engineer
Cisco Systems, Inc
(W) +1 703.484.0040
(M) +1 703.201.5742
PGP Fingerprint: EED9 192F 9F45 FAE4 F6A3 8764 FEE1 299D 1B62 A361 
----------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roland Dobbins (rdobbins)
Sent: Tuesday, January 20, 2009 11:07 PM
To: opsec wg mailing list
Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00

> enable this seems good to me.

The problem with this is that it lacks granularity, and if this were to
come to pass and you tagged your announcement accordingly, you don't
know what the result will be, nor where, nor how.

We've all seen instances of uncoordinated mitigation which have gone
awry and made things worse, not better.  Any kind of inter-provider
signaling of this type should only be undertaken/work after an explicit
mutual understanding has been reached regarding expectations and actual
behavior.

Given the fact that various operators have implemented various
communities for various purposes over time, and given the
situationally-specific nature of the blackholing mechanisms themselves,
I think that while this is a noble goal, that it simply isn't practical
in this particular milieu and should probably be removed.

---

From: "Ryan Mcdowell (rymcdowe)" <[email-masked]>
Date: Wed, 21 Jan 2009 20:04:09 -0500

s/I think a standard/I don't think a standard/ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ryan Mcdowell (rymcdowe)
Sent: Wednesday, January 21, 2009 7:06 PM
To: Roland Dobbins (rdobbins); opsec wg mailing list
Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00

Agree with Roland, too many ISP's do slightly different things.  I think
a standard community could capture all the power and options possible.
A standard community would greatly reduce the flexibility.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 21 Jan 2009 17:50:22 -0800

the facility can then get used more, becuase you can teach it document
it reference texts etc. That doesn't mean a more expressive set of
situationially useful tools cannot also be provided, the fact that their
 is some variation is what providers offer their customers and how they
express them reflects different priorties, vendor specfic limitations
and so on.