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

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.

Ryan Mcdowell (rymcdowe) wrote:
> 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.  
> 
> 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: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] 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
> 
> 
> On Jan 21, 2009, at 2:21 AM, Warren Kumari wrote:
> 
>> 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.
> 
> 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 <rdobbins@cisco.com> // +852.9133.2844 mobile
> 
>       All behavior is economic in motivation and/or consequence.
> 
> 
> 
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 

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