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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]