ietf
[Top] [All Lists]

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

2016-07-07 09:00:06
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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)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.


<Prev in Thread] Current Thread [Next in Thread>