On Wed, Aug 03, 2016 at 05:06:22PM +0000, Smith, Donald wrote:
> Note everywhere this says BHF I assumed DBHF not Source based BHFing.
> I suspect SBHF is out of scope for this effort. I could be wrong.
Correct, the draft is very explicit in the first sentence:
"This document describes the use of a well-known Border Gateway
Protocol (BGP) community for destination based blackholing in IP
networks. " ^^^^^^^^^^^
> Should the draft be modified to state that or is it intended to allow
> SBHFing also?
No. IMHO that should be a different draft / community.
> So the risk looks the same, and should be mitigated with the same
> methods (md5 and GTSM?)
> I didn't hear a recommendation for GTSM but I think it should be in
> here.
The document is supposed to define a codepoint, not to be a BCP. While I
value and somewhat agree these are useful techniques, I consider them
out of scope.
> > its impact has been done? If this is new, then I don't see
> > that the security considerations text adequately describe
> > the range of possible attacks that could be mounted using
> > this scheme. (As an aside, I wonder if asking to blackhole
> > /32's and /128's might impact on routing table sizes and
> > if something ought be said about that?)
We don't put in every single BGP draft that you need to ensure that you
need adequate RAM, CPU, FIB, ASIC, Capacity, or $magic_powder. Whether
prefixes are colored with attributes or not, routing table size is a
consideration in every aspect of BGP life.
> Thus my suggestion that it be in the peering contract for how many and
> how long?
Any contractual terms are up to the network operator that implements a
routing policy that honors (or does not honor) the BLACKHOLE community,
that can't be part of the document.
Kind regards,
Job
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
