Re: [GROW] Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

Hi all,

I've not been following the discussion in all details, sorry for this.
IINM, one comment was that it would be safer to use a non-transitive BGP community.
In which case, you may be interested in the following draft which proposes to define "well known" non-transitive communities based on existing non-transitive extended BGP communities.
https://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities

Caveats: this draft is currently not progressing to RFC publication because it has a normative reference to draft-ietf-idr-as4octet-extcomm-generic-subtype. The latter is not progressing because it is lacking 2 independent implementations (as per IDR rule). Note however that the implementation effort is quite modest so it could be implemented quickly by someone with the motivation to do so.

Hope this may help,
Regards,
--Bruno

> From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Nick Hilliard > Sent: Sunday, July 03, 2016 10:18 PM
> 
> Christopher Morrow wrote:
> > first noting that it'd be helpful if you have concerns to suggestions
> > that you send text that might be used to address them. Playing 'bring me
> > a rock' is not fun for anyone.
> 
> "bring me a rock" was not intended.
> 
> Also, email is a terrible medium for communication (mea culpa) :-(
> 
> > As to the denial of service wording removal/change, i thought the change
> > was actually positive because it removed a bit of ambiguity "if a
> > network offering blackholing is traversed" only really applies if that
> > network:
> >   1) hears the prefix with the community
> >   2) is configured to do something with that announcement
> >
> > To back up a bit in the conversation I viewed the draft/document as
> > doing two specific things:
> >   1) reducing operational complexity between consenting bgp speaking adults
> >   2) letting operations staff decide how/where/what to do with a prefix
> > seen from their peer(s).
> 
> which is fine and we all agree on this.  What we don't agree on is
> whether creating this particular weapon will cause more problems than it
> solves.
> 
> > I think a community today is used (many actually) to signal requested
> > treatment of a prefix across an AS boundary (rfc1998 for example),
> > operators on both sides of the peering decide what to add to a prefix on
> > exit, and what to do with the additions on receipt. I expect peers to be
> > consenting adults and to not shoot themselves in the foot...
> 
> that isn't the problem, though.  The problems will be caused by other
> people either injecting prefixes into their own rtbhs and accidentally
> leaking them to upstreams or else deliberately staging hijacks.  Other
> people have argued that there's no new attack vector here, just a
> different outcome from the same attack vector (i.e. dropping instead of
> redirecting traffic).  There's a case to be made with this argument, but
> OTOH, prefix hijacking is rampant and there are lots of situations where
> people do not or cannot feasibly implement prefix filtering.  This is
> what bothers me.
> 
> > I would expect this proposed community to be used along with adding
> > no-export on receipt at the peer, because sending the community more
> > broadly isn't as helpful.
> 
> Yeah, not doing this is going to be a common misconfiguration.
> 
> I can't decide on the overall aims of the draft.  It would be hugely
> convenient to have a community like this, no doubt about it, but the
> transitive nature of the community and humanity's utter inability not to
> screw things up means that problems are going to happen.  I'd be happier
> if the text were tightened up to be much more specific about what the
> semantics of the term "blackhole", and then we could do an IETF and
> write any problems off as operational misconfiguration, but even still,
> that niggling feeling that this is overall a bad idea is not going away.
> 
> Summary: conflicted.
> 
> Nick
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.