Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Job Snijders]

On Tue, Aug 09, 2016 at 04:50:58PM +0100, Stephen Farrell wrote:
> > I won't delve into the operational complexities of getting operators
> > to supplement their existing transitve community with a
> > non-transitive variant, especially in context of route servers or
> > sibling networks.
> 
> Thanks, that's useful. As I said, I think I'll end up abstaining and
> getting out your way, given the above, when we've sorted the below.
> 
> >> (2) IIUC, this proposal envisages BGP speakers commonly telling
> >> others to blackhole specific /32's or /128's. And of course as the
> >> draft says BGP doesn't provide us with a way to "prevent the
> >> unauthorized modification of information by the forwarding agent."
> >> Given those two things, this scheme seems to be an ideal new way to
> >> cause any service that advertises a fallback to actually fall back,
> >> e.g to use a secondary MX or DNS resolver rather than a primary.
> >> That seems like a fine way to try and possibly succeed in attacking
> >> many possible things.  The discuss point here is to ask if this
> >> really is a new attack vector, and if so, if the appropriate level
> >> of analysis of 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.
> > 
> > This is not new. In addition to Christopher & Joel's comments:
> > 
> > We should also consider the severity in this context: If a
> > forwarding agent is compromised, you are likely to have far bigger
> > problems. Long term criminal profitablity lays with traffic
> > mis-direction or detouring, rarely with full outages. A blackhole is
> > very easy to spot and react against. A full outage (through a
> > blackhole or something else) will trigger investigation and the
> > subsequent plugging of the hole. This is a self repairing mechanism.
> 
> I agree if what is blackholed is a /24 or more but is that equally
> true if all that is blackholed is a /32 or /128?

Yes. Except a /32 won't propagate as far as a /24 or shorter. Long
blackholes (/32 or /128) are in essence a form of propagation control. 

> My concern is that if such a tightly-scoped blackhole is less likely
> spotted 
>
> (incl. by the owner of the service at the blackholed /32 or /128, due
> to a fallback) then the new aspect is that an attacker (using BGP) can
> target fall back hosts in a very selective manner. As I understand it
> (which is not well:-), today, the attacker would more likely have to
> affect a lot more traffic to get the same effect, (or to be more
> active in getting the rest of the traffic routed in a normal looking
> manner) so it's just that "fine-grained targeted" aspect that I'm
> arguing may be new, may become more wide-spread due to this draft, and
> that is therefore worth analysis and possibly documenting.

Short or long prefix: an entry is an entry. People prefer to blackhole
the most specific prefix possible, to avoid blackholing adjacent IP
space which is not under attack. This is documented in section 3.2

My remark was meant in context of people monitoring their services
(there a gazillion ways to do this) - a monitor will detect that a
prefix or a single IP address is unreachable and then someone takes
action.

> TBH, I'm still not sure that's not the case. (Apologies if that's just
> me being dumb, which happens a lot.)

No worries.

> > Currently a ton of carriers have implemented their own codepoints to
> > trigger blackholing, a very incomplete overview based on public data
> > follows of RFC1997 communities currently in use by various carriers:
> > 2914:666, 209:0, 701:, 1239:66, 1273:666, 1299:999, 1759:666,
> > 2828:1650, 3212:, 3257:2666, 65000:0, 3327:666, 3356:, 6762:666,
> > 3561:666, 4323:187, 5580:666, 6461:5990, 7029:4506, 7922:666, 8100:,
> > 8218:, 8220:63999, 8708:, 49544:666, 11537:911, 15756:666,
> > 19401:911, 23265:666 and 286:66. All this draft does is unify those
> > listed above under a single codepoint for the benefit of all their
> > customers.
> > 
> > Just like adding all those communities to a single prefix does not
> > cause internet-wide havoc, a well-known variant won't. 
> 
> To try be clear: it's not wide-spread havoc that's my concern here,
> but the ability to very specifically target one host, e.g. as part
> of an attack on a fallback host that may be less well protected,
> or even just less capable.

This is how people use blackholing today. In fact, NTT only accepts /32s
and /128s for blackholing and nothing shorter. You can only target
hosts due to this policy.

> > Again, a few (the same) individuals won't agree with this
> > assessment.
> > 
> >> (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?)
> > 
> > This well-known codepoint does not alter any of those characteristics or
> > 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 09/08/16 17:04, Gert Doering wrote:
> Hi,
> 
> On Tue, Aug 09, 2016 at 04:50:58PM +0100, Stephen Farrell wrote:
>> Ok - I assume that means that being able to accept a blackholed /32
>> doesn't therefore mean having to accept other BGP announcements for
>> /32's without any additional controls. Would it be sensible to say
>> that implementers MUST/SHOULD allow treating blackholing differently
>> in that respect? (e.g. to keep some different configured limits for
>> the length of prefix they accept for blackholes vs. other BGP stuff?)
> 
> I think this is implicit by the statement that there must be a covering
> prefix permitted by routing policy - so the assumption is "the blackhole
> can be more specific".
> 
> All existing deployments I know do it that way - that is, for regular
> traffic, prefixes are permitted as documented (like: 192.0.2.0/24 is
> accepted, and no more specifics) while blackhole-tagged prefixes
> go up to /32 ("if blackhole-community present, accept 192.0.2.0/24../32").
> 
> I'm not sure if we need to spell this out - it's not something this draft
> is changing.

(Noting that this was an aside that I don't consider blocking...) I
think one could argue that this draft is changing that as it's here
that we're defining this community. And I'd say it would be useful
to call it out too, if there's really no sensible way to implement
this without such an additional configuration.

Cheers,
S.


> 
> Gert Doering
> -- NetMaster
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Job Snijders]

Dear Stephen,

On Wed, Aug 03, 2016 at 08:31:12AM -0700, Stephen Farrell wrote:
> First, I have to say that I'm pretty ignorant about practical routing
> operations, so my plan is to briefly discuss this and to then probably
> move to an abstain position, unless the issues I raise resonate with
> folks who are expert in this space.

OK.

> (1) I agree with the points raised in IETF LC that the transitive
> nature of this proposal has dangers that may outweigh its utility. Was
> there discussion in the WG about potential solutions that do not have
> the transitivity property? If so, can you point me at those? If not,
> is there a reason to think no such solution is feasible?  (I suspect
> the answer may be "no" which is the main reason I plan to move to an
> abstain ballot.)

The short answer is no.

The authors have spent considerable time debating whether an rfc4360
codepoint is appropiate, but the lack of actual deployments using
non-transitive rfc4360 communities for blackhole signaling convinced
the authors to stick to what the operator community uses today: rfc1997
communities.

For most operators the deployment of this well-known BLACKHOLE community
will be very easy, as it in most cases closely aligns with their
existing blackhole routing policy. The operators not only have their own
networks to consider, but also their entire customer cone for whom the
signaling codepoint is intended. It is my opinion that our customer's
expectation is to use rfc1997 communities for signaling.

I won't delve into the operational complexities of getting operators to
supplement their existing transitve community with a non-transitive
variant, especially in context of route servers or sibling networks.

A few individuals do not agree with this viewpoint, so be it. We can't
please everyone. 

> (2) IIUC, this proposal envisages BGP speakers commonly telling others
> to blackhole specific /32's or /128's. And of course as the draft says
> BGP doesn't provide us with a way to "prevent the unauthorized
> modification of information by the forwarding agent." Given those two
> things, this scheme seems to be an ideal new way to cause any service
> that advertises a fallback to actually fall back, e.g to use a
> secondary MX or DNS resolver rather than a primary. That seems like a
> fine way to try and possibly succeed in attacking many possible
> things.  The discuss point here is to ask if this really is a new
> attack vector, and if so, if the appropriate level of analysis of 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.

This is not new. In addition to Christopher & Joel's comments:

We should also consider the severity in this context: If a forwarding
agent is compromised, you are likely to have far bigger problems. Long
term criminal profitablity lays with traffic mis-direction or detouring,
rarely with full outages. A blackhole is very easy to spot and react
against. A full outage (through a blackhole or something else) will
trigger investigation and the subsequent plugging of the hole. This is a
self repairing mechanism.

Currently a ton of carriers have implemented their own codepoints to
trigger blackholing, a very incomplete overview based on public data
follows of RFC1997 communities currently in use by various carriers:
2914:666, 209:0, 701:, 1239:66, 1273:666, 1299:999, 1759:666,
2828:1650, 3212:, 3257:2666, 65000:0, 3327:666, 3356:, 6762:666,
3561:666, 4323:187, 5580:666, 6461:5990, 7029:4506, 7922:666, 8100:,
8218:, 8220:63999, 8708:, 49544:666, 11537:911, 15756:666,
19401:911, 23265:666 and 286:66. All this draft does is unify those
listed above under a single codepoint for the benefit of all their
customers.

Just like adding all those communities to a single prefix does not cause
internet-wide havoc, a well-known variant won't. Again, a few (the same)
individuals won't agree with this assessment.

> (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?)

This well-known codepoint does not alter any of those characteristics or
considerations.

> (3) Given that there are dangers associated with this mechanism, why
> is there no statement in the draft that actions taken based on this
> scheme ought be logged or otherwise publicised as a possible way to
> provide some level of accountability, even if only after the fact?

I like your suggestion about logging, however I can't see our company to
commit to publication. Publication of blackholed IPs is not something
NTT has done in the last 10 to 15 years, I'm not aware of others doing
this either.

On the other hand, logging for internal auditing purposes is useful.
This can help triage incidents or after-the-fact verification of policy
adherence. NTT has iBGP sessions from every edge router to a 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Joel Jaeggli]

Sent from my iPhone

> On Aug 8, 2016, at 15:37, Stephen Farrell  wrote:
> 
> 
> Sorry for the slow response here, had some distraction.
> 
> Responses to two of the bits of my discuss below. I need to read
> more of the thread to figure where we are with point (1)...
> 
>> On 03/08/16 17:02, Christopher Morrow wrote:
>> On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell 
>> wrote:
>> 
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-grow-blackholing-02: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> 
>>> First, I have to say that I'm pretty ignorant about
>>> practical routing operations, so my plan is to briefly
>>> discuss this and to then probably move to an abstain
>>> position, unless the issues I raise resonate with folks
>>> who are expert in this space.
>>> 
>>> (1) I agree with the points raised in IETF LC that the
>>> transitive nature of this proposal has dangers that may
>>> outweigh its utility. Was there discussion in the WG about
>>> potential solutions that do not have the transitivity
>>> property? If so, can you point me at those? If not, is
>>> there a reason to think no such solution is feasible?  (I
>>> suspect the answer may be "no" which is the main reason I
>>> plan to move to an abstain ballot.)
>> 
>> your tools to do signaling in bgp are ... limited you can toggle/adjust/etc
>> things such as:
>>  community
>>  origin
>>  metric
>>  prefix-itself
>> 
>> In the scenario where we want to enable one provider to signal to the other
>> provider: "please take this action"
>> 
>> community is the 'best' option... you can signal somethign meaningful with
>> a commnuity where origin/metric don't really allow you to do more than
>> binary decisions.
>> 
>> In a scenario on the wider network NOT at a peering fabric that has a
>> route-server thingy... you don't really need a 'transitive' attribute
>> because you're just telling your neighbor: "pls do this" to which they
>> presumably have policy to do the right thing (or they may choose to ignore
>> you, of course).
>> 
>> In the scenario that includes a peering-fabric and route-server, you need
>> either:
>>  1) route-server to do some kinky things (ignore some forms of
>> non-transitive, re-map something to the non-transitive, etc)
>>  2) pass the attribute through because it is transitive.
>> 
>> the route-server is the remote network's bgp peer, so you have to ask the
>> route-server to ship stuff across to other peers...
>> 
>> 
>>> 
>>> (2) IIUC, this proposal envisages BGP speakers commonly
>>> telling others to blackhole specific /32's or /128's. And
>>> of course as the draft says BGP doesn't provide us with a
>>> way to "prevent the unauthorized modification of
>>> information by the forwarding agent." Given those two
>> 
>> err, there is MD5 auth for tcp... which SHOULD prevent modification
>> in-flight.
>> of course (ha!) there's notionally tcp-AO which should do the same thing,
>> perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
>> darn! no implementations of AO exist.
>> 
>> 
>>> things, this scheme seems to be an ideal new way to cause
>>> any service that advertises a fallback to actually fall back,
>> 
>> with bgp being in a state where there is no method (there is, md5 auth) to
>> prevent/notice modifications... all bgp sessions are at risk (some risk).
>> 
>> 
>>> e.g to use a secondary MX or DNS resolver rather than a
>>> primary. That seems like a fine way to try and possibly
>>> succeed in attacking many possible things.  The discuss
>>> point here is to ask if this really is a new attack
>>> vector, and if so, if the appropriate level of analysis of
>> 
>> doesn't look new to me, no. and 'worse', today someone COULD just (if they
>> are in the right place and can do bgp packet creation,etc) just tag all of
>> your announcments to your provider(s) with the local provider version of
>> this community, blackholing all of your traffic... or they could change the
>> announcements to withdrawals... or other mean things. the addition of this
>> blackhole community doesn't change this problem, at all.
> 
> Sorry, I'm not seeing that. Are you saying all BGP speakers
> can today commonly know exactly how to ask blackhole *any*
> individual /32 or /128?
> 
> If so, then surely that calls 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Stephen Farrell]

Sorry for the slow response here, had some distraction.

Responses to two of the bits of my discuss below. I need to read
more of the thread to figure where we are with point (1)...

On 03/08/16 17:02, Christopher Morrow wrote:
> On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell 
> wrote:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-grow-blackholing-02: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>>
>> First, I have to say that I'm pretty ignorant about
>> practical routing operations, so my plan is to briefly
>> discuss this and to then probably move to an abstain
>> position, unless the issues I raise resonate with folks
>> who are expert in this space.
>>
>> (1) I agree with the points raised in IETF LC that the
>> transitive nature of this proposal has dangers that may
>> outweigh its utility. Was there discussion in the WG about
>> potential solutions that do not have the transitivity
>> property? If so, can you point me at those? If not, is
>> there a reason to think no such solution is feasible?  (I
>> suspect the answer may be "no" which is the main reason I
>> plan to move to an abstain ballot.)
>>
> 
> your tools to do signaling in bgp are ... limited you can toggle/adjust/etc
> things such as:
>   community
>   origin
>   metric
>   prefix-itself
> 
> In the scenario where we want to enable one provider to signal to the other
> provider: "please take this action"
> 
> community is the 'best' option... you can signal somethign meaningful with
> a commnuity where origin/metric don't really allow you to do more than
> binary decisions.
> 
> In a scenario on the wider network NOT at a peering fabric that has a
> route-server thingy... you don't really need a 'transitive' attribute
> because you're just telling your neighbor: "pls do this" to which they
> presumably have policy to do the right thing (or they may choose to ignore
> you, of course).
> 
> In the scenario that includes a peering-fabric and route-server, you need
> either:
>   1) route-server to do some kinky things (ignore some forms of
> non-transitive, re-map something to the non-transitive, etc)
>   2) pass the attribute through because it is transitive.
> 
> the route-server is the remote network's bgp peer, so you have to ask the
> route-server to ship stuff across to other peers...
> 
> 
>>
>> (2) IIUC, this proposal envisages BGP speakers commonly
>> telling others to blackhole specific /32's or /128's. And
>> of course as the draft says BGP doesn't provide us with a
>> way to "prevent the unauthorized modification of
>> information by the forwarding agent." Given those two
>>
> 
> err, there is MD5 auth for tcp... which SHOULD prevent modification
> in-flight.
> of course (ha!) there's notionally tcp-AO which should do the same thing,
> perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
> darn! no implementations of AO exist.
> 
> 
>> things, this scheme seems to be an ideal new way to cause
>> any service that advertises a fallback to actually fall back,
>>
> 
> with bgp being in a state where there is no method (there is, md5 auth) to
> prevent/notice modifications... all bgp sessions are at risk (some risk).
> 
> 
>> e.g to use a secondary MX or DNS resolver rather than a
>> primary. That seems like a fine way to try and possibly
>> succeed in attacking many possible things.  The discuss
>> point here is to ask if this really is a new attack
>> vector, and if so, if the appropriate level of analysis of
>>
> 
> doesn't look new to me, no. and 'worse', today someone COULD just (if they
> are in the right place and can do bgp packet creation,etc) just tag all of
> your announcments to your provider(s) with the local provider version of
> this community, blackholing all of your traffic... or they could change the
> announcements to withdrawals... or other mean things. the addition of this
> blackhole community doesn't change this problem, at all.

Sorry, I'm not seeing that. Are you saying all BGP speakers
can today commonly know exactly how to ask blackhole *any*
individual /32 or /128?

If so, then surely that calls into question the utility of
specifying this community? If not, then the combination
of common and /32 does still appear to create a new attack
vector being the ability to use BGP to cause specific services
to fall back onto their 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Smith, Donald]

That's is even better. So agreed with referencing that rfc.





if (initial_ttl!=255) then (rfc5082_compliant==0)
donald.sm...@centurylink.com<mailto:donald.sm...@centurylink.com>

From: Gert Doering [g...@space.net]
Sent: Monday, August 08, 2016 11:02 AM
To: Smith, Donald
Cc: Randy Bush; Christopher Morrow; GMO Crops; The IESG
Subject: Re: [GROW] Stephen Farrell's Discuss on 
draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

Hi,

On Mon, Aug 08, 2016 at 04:39:56PM +, Smith, Donald wrote:
> This discusses neighboring networks, and local scope, so one would assume in 
> most cases these are directly connected peers (or not many hops away), I 
> think the security section should recommend use of GTSM on such sessions.
>
> Then it can't easily be spoofed outside of the local network.

While the general recommendation is valid, I'm not seeing why it is
particularily relevant to this draft - whether or not a neighbouring
BGP session is using a well-defined or privately-agreed code point to
signal BGP black holing makes no difference wrt to attacking the local
TCP session...  (assuming that the "privately-agreed" code point is
in fact publicly documented in an IRRdb, which they usually are).

Adding a general reference to BGP security best practices won't hurt,
of course - 7454 comes to mind (which among others recommends GTSM).

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Gert Doering]

Hi,

On Mon, Aug 08, 2016 at 04:39:56PM +, Smith, Donald wrote:
> This discusses neighboring networks, and local scope, so one would assume in 
> most cases these are directly connected peers (or not many hops away), I 
> think the security section should recommend use of GTSM on such sessions.
> 
> Then it can't easily be spoofed outside of the local network.

While the general recommendation is valid, I'm not seeing why it is
particularily relevant to this draft - whether or not a neighbouring
BGP session is using a well-defined or privately-agreed code point to
signal BGP black holing makes no difference wrt to attacking the local
TCP session...  (assuming that the "privately-agreed" code point is
in fact publicly documented in an IRRdb, which they usually are).

Adding a general reference to BGP security best practices won't hurt,
of course - 7454 comes to mind (which among others recommends GTSM).

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Smith, Donald]

This discusses neighboring networks, and local scope, so one would assume in 
most cases these are directly connected peers (or not many hops away), I think 
the security section should recommend use of GTSM on such sessions.

Then it can't easily be spoofed outside of the local network.





if (initial_ttl!=255) then (rfc5082_compliant==0)
donald.sm...@centurylink.com<mailto:donald.sm...@centurylink.com>

From: GROW [grow-boun...@ietf.org] on behalf of Randy Bush [ra...@psg.com]
Sent: Friday, August 05, 2016 9:43 PM
To: Christopher Morrow
Cc: GMO Crops; The IESG
Subject: Re: [GROW] Stephen Farrell's Discuss on 
draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

> doesn't look new to me, no. and 'worse', today someone COULD just (if
> they are in the right place and can do bgp packet creation,etc) just
> tag all of your announcments to your provider(s) with the local
> provider version of this community, blackholing all of your traffic.

note the string of "if"s.  this proposal removes them.  the attacker can
be anywhere, and need forge nothing.  and there's the rub; well-known
and transitive.

randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Randy Bush]

> doesn't look new to me, no. and 'worse', today someone COULD just (if
> they are in the right place and can do bgp packet creation,etc) just
> tag all of your announcments to your provider(s) with the local
> provider version of this community, blackholing all of your traffic.

note the string of "if"s.  this proposal removes them.  the attacker can
be anywhere, and need forge nothing.  and there's the rub; well-known
and transitive.

randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Nick Hilliard]

> On 3 Aug 2016, at 19:02, Christopher Morrow  
> wrote:
> doesn't look new to me, no. and 'worse', today someone COULD just (if they 
> are in the right place and can do bgp packet creation,etc) just tag all of 
> your announcments to your provider(s) with the local provider version of this 
> community, blackholing all of your traffic... or they could change the 
> announcements to withdrawals... or other mean things. the addition of this 
> blackhole community doesn't change this problem, at all.

You're technically correct to say that there is nothing new about this attack 
vector but in practice, this draft will end up changing the /24 and /48 default 
maximum prefix length on all bh-enabled peering sessions to /32 and /128 and 
will encourage configs to be created to make it easy to propagate BH'd prefixes 
around the place. Everyone understands that policy can be written to tie this 
down to be safer and that this will be done on competently managed networks, 
and that for those networks, this draft will be both safe and useful. All the 
operators plugging for this draft in the grow wg fall into this category of 
competence.

In reality, a huge number of networks are spaghetti-built on a jumble of 
incompetently configured devices hacked together by people who don't really 
know what they're doing. Many network operators are going to screw this sort of 
config up and will end up shooting themselves and others in the foot.

This ignores those network operators who have malicious intent. In their case, 
this draft adds another blade to their Swiss Army knife, particularly in 
situations where prefix limits are routinely not used. 

Stepping back a bit, the ietf has an unfortunate tendency to write off certain 
categories of operator problem as "out of scope" or "config/implementation 
error", and this has happened in this case. The problem is, the draft is saying 
"hey guys, if you bypass a bunch of rcds in the distribution board, you can do 
some really cool stuff". You sure can, but the person who gets electrocuted in 
the shower as a result isn't going to care much about whether their shock was 
out of scope at the protocol level or caused by an implementation problem. 
Globally scoped damage will have been done either way, whether through malice 
or incompetence. 

Using a non transitive community (eg rfc4360) instead of a standard bgp 
community from the iana well-known range could limit this problem, because that 
would constrain the scope of any potential damage by enforcing non-transitivity 
at the bgp stack level. Without at least this safeguard, this draft is imho 
inadvisable from a global internet stability point of view. 

Nick


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Gert Doering]

Hi,

On Wed, Aug 03, 2016 at 05:06:22PM +, 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.

source-based blackholing in remote networks is something I do not consider
viable - what customer A might consider an attacker might be an important
source of information to customer B, so you can permit customer A to 
drop packets *to A*, but not "from X, no matter if destined to A or B"
(in some case the network provider might decide "I drop all traffic from
X, because it's causing problems to my infrastructure", but even then,
his upstreams will not permit to do this transitively)

I do not think the draft needs to be extended to say so - we only
define a code point, not define a new mechanism for blackholing.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[joel jaeggli]

On 8/3/16 8:31 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-grow-blackholing-02: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> 
> First, I have to say that I'm pretty ignorant about
> practical routing operations, so my plan is to briefly
> discuss this and to then probably move to an abstain
> position, unless the issues I raise resonate with folks
> who are expert in this space.
> 
> (1) I agree with the points raised in IETF LC that the
> transitive nature of this proposal has dangers that may
> outweigh its utility. Was there discussion in the WG about
> potential solutions that do not have the transitivity
> property? If so, can you point me at those? If not, is
> there a reason to think no such solution is feasible?  (I
> suspect the answer may be "no" which is the main reason I
> plan to move to an abstain ballot.)

transitivity is a required property if n > 2 ASNs are involved in the
propagation of the message...

There are deployed examples that depend on this property.

> (2) IIUC, this proposal envisages BGP speakers commonly
> telling others to blackhole specific /32's or /128's. And
> of course as the draft says BGP doesn't provide us with a
> way to "prevent the unauthorized modification of
> information by the forwarding agent." 

The applies to all learned routes in the internet. operational practices
that prevent leakage and limit the damage of prefix hijacking also
prevent the opportunity for leakage of more specific routes or
inappropriately sourced advertisements. any member of the of the routing
system may simply synthesize a routing update for any prefix and
propagate it subject to the policy constraints imposed by their
neighbors every interceding ASN must necessarily modify the update
before propagating it..

> Given those two
> things, this scheme seems to be an ideal new way to cause
> any service that advertises a fallback to actually fall back,
> e.g to use a secondary MX or DNS resolver rather than a
> primary. That seems like a fine way to try and possibly
> succeed in attacking many possible things.  The discuss
> point here is to ask if this really is a new attack
> vector, and if so, if the appropriate level of analysis of
> its impact has been done?

it is not, imho, an attack using a prefix tagged with the community is a
prefix hijacking. if you accept the route with our without the community
you are installing it in you table and selecting a nexthop in one case
the nexthop is your discard, in the other the nethop is a another router.

> 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?)

a transit ASN might accept but generally will not without coordination
propagate prefix's longer than a  /24 or a /48. so in a global sense no.
configured max prefix limits which providers use a circuit breaker are
likely to discourage spamming updates at your neighbor, as does the fact
that by definition you want connectivity for your prefix.

> (3) Given that there are dangers associated with this
> mechanism, why is there no statement in the draft that
> actions taken based on this scheme ought be logged or
> otherwise publicised as a possible way to provide some
> level of accountability, even if only after the fact?
> 
> 
> --
> COMMENT:
> --
> 
> 
> - 3.2: It isn't clear to me how one might exercise
> "extreme caution" here - can you explain? Or is that
> obvious to the intended audience of this?
> 
> 




signature.asc
Description: OpenPGP digital signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[David Farmer]

On Wed, Aug 3, 2016 at 11:02 AM, Christopher Morrow <
christopher.mor...@gmail.com> wrote:

>
> 
> In the scenario where we want to enable one provider to signal to the
> other provider: "please take this action"
>
> community is the 'best' option... you can signal something meaningful with
> a community where origin/metric don't really allow you to do more than
> binary decisions.
>
> In a scenario on the wider network NOT at a peering fabric that has a
> route-server thingy... you don't really need a 'transitive' attribute
> because you're just telling your neighbor: "pls do this" to which they
> presumably have policy to do the right thing (or they may choose to ignore
> you, of course).
>
> In the scenario that includes a peering-fabric and route-server, you need
> either:
>   1) route-server to do some kinky things (ignore some forms of
> non-transitive, re-map something to the non-transitive, etc)
>   2) pass the attribute through because it is transitive.
>
> the route-server is the remote network's bgp peer, so you have to ask the
> route-server to ship stuff across to other peers...
>

There are other scenarios where cleanly having the BLACKHOLE community be
transitive, it the right thing.  Besides the peering-fabric/route-server
scenario you just described, there are a number of cooperative transit
relationships, where you would properly want to transitively pass the
BLACKHOLE community.

Such as;

Two ASes we sharing transit with each other up, something like this;

(ISP1) --- (AS64500) --- (AS64501) --- (ISP 2)

 Let's say AS64500 was under attack, it could announce the /32 under attack
with the BLACKHOLE community to ISP1 directly and to ISP2 through it
sharing partner AS64501.  AS64501 has to transitively pass the route with
the BLACKHOLE community to ISP2.

Similarly the sharing could be done through a aggregating transit AS;

(AS64501)(ISP 1)
  |/
  (AS64500) -- (ISP 2)
  |\
(AS64502)(ISP 3)

Similarly, AS64500 has to transitively pass the route with the BLACKHOLE
community to ISPs 1, 2, and 3;

Therefore, limiting the propagation by defining the BLACKHOLE community as
non-transitive would either inappropriately limit it's use in a number of
valid scenarios or require people to do "kinky things" like ignoring the
fact that is is suppose to be non-transitive.

I prefer it be transitive and tell people to use it carefully!

But that's my $0.02.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Christopher Morrow]

On Wed, Aug 3, 2016 at 1:45 PM, heasley  wrote:

> Wed, Aug 03, 2016 at 12:02:36PM -0400, Christopher Morrow:
> > > (2) IIUC, this proposal envisages BGP speakers commonly
> > > telling others to blackhole specific /32's or /128's. And
> > > of course as the draft says BGP doesn't provide us with a
> > > way to "prevent the unauthorized modification of
> > > information by the forwarding agent." Given those two
> > >
> >
> > err, there is MD5 auth for tcp... which SHOULD prevent modification
> > in-flight.
> > of course (ha!) there's notionally tcp-AO which should do the same thing,
> > perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
> > darn! no implementations of AO exist.
>
> I do not believe that is the intended meaning; I think it is reference
> to a device's route policy, intentional or accidental.
>

interesting, I didn't read/take-in the 'agent' part... (perhaps I read
'forwarding path' :( )

If 'agent' is to mean 'route server' then sure, neither md5/ao/gtsm will
help... and yes, that 'agent' can mangle routes as it sees fit.

thanks!
-chris
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Jeffrey Haas]

On Wed, Aug 03, 2016 at 08:31:12AM -0700, Stephen Farrell wrote:
> (1) I agree with the points raised in IETF LC that the
> transitive nature of this proposal has dangers that may
> outweigh its utility. Was there discussion in the WG about
> potential solutions that do not have the transitivity
> property? If so, can you point me at those? If not, is
> there a reason to think no such solution is feasible?  (I
> suspect the answer may be "no" which is the main reason I
> plan to move to an abstain ballot.)

This mechanism exists within the existing ecosystem of RFC 1997 communities.
These communities control a significant amount of routing behavior and are
commonly set by upstream routers, perhaps from a different AS, attempting to
influence behavior or provide information to downstream ASes.

Common operational practices include removing undesirable communities at
one's AS border.  While these practices are not written about in the RFC
series, they're well understood.  My suggestion is to proceed with the
knowledge that this is a known operational behavior as are the underlying
security considerations.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[heasley]

Wed, Aug 03, 2016 at 12:02:36PM -0400, Christopher Morrow:
> > (2) IIUC, this proposal envisages BGP speakers commonly
> > telling others to blackhole specific /32's or /128's. And
> > of course as the draft says BGP doesn't provide us with a
> > way to "prevent the unauthorized modification of
> > information by the forwarding agent." Given those two
> >
> 
> err, there is MD5 auth for tcp... which SHOULD prevent modification
> in-flight.
> of course (ha!) there's notionally tcp-AO which should do the same thing,
> perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
> darn! no implementations of AO exist.

I do not believe that is the intended meaning; I think it is reference
to a device's route policy, intentional or accidental.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Smith, Donald]

> On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell  
> wrote:

>

> Stephen Farrell has entered the following ballot position for

> draft-ietf-grow-blackholing-02: Discuss

>

> When responding, please keep the subject line intact and reply to all

> email addresses included in the To and CC lines. (Feel free to cut this

> introductory paragraph, however.)

>

>

> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

> for more information about IESG DISCUSS and COMMENT positions.

>

>

> The document, along with other ballot positions, can be found here:

> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/

>

>

>

> --

> DISCUSS:

> --

>

>

> First, I have to say that I'm pretty ignorant about

> practical routing operations, so my plan is to briefly

> discuss this and to then probably move to an abstain

> position, unless the issues I raise resonate with folks

> who are expert in this space.

>

> (1) I agree with the points raised in IETF LC that the

> transitive nature of this proposal has dangers that may

> outweigh its utility. Was there discussion in the WG about

> potential solutions that do not have the transitivity

> property? If so, can you point me at those? If not, is

> there a reason to think no such solution is feasible? (I

> suspect the answer may be "no" which is the main reason I

> plan to move to an abstain ballot.)

>

>

>

> your tools to do signaling in bgp are ... limited you can toggle/adjust/etc 
> things such as:

> community

> origin

> metric

> prefix-itself

>

>

> In the scenario where we want to enable one provider to signal to the other 
> provider: "please take this action"

>

>

> community is the 'best' option... you can signal something meaningful with a 
> community where origin/metric don't really allow you to do more than binary 
> decisions.

>

>

> In a scenario on the wider network NOT at a peering fabric that has a 
> route-server thingy... you don't really need a 'transitive' attribute because 
> you're just telling your neighbor: "pls do this"

>to which they presumably have policy to do the right thing (or they may choose 
>to ignore you, of course).

Exactly, as I see it this would only be to peers. And probably needs to be 
covered in your peering contract.

How many, how long would Destination based BHFing (DBHF) requests be accepted 
between two peers would be the main concept here.

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.

Should the draft be modified to state that or is it intended to allow SBHFing 
also?





>

>

> In the scenario that includes a peering-fabric and route-server, you need 
> either:

> 1) route-server to do some kinky things (ignore some forms of non-transitive, 
> re-map something to the non-transitive, etc)

> 2) pass the attribute through because it is transitive.

>

>

> the route-server is the remote network's bgp peer, so you have to ask the 
> route-server to ship stuff across to other peers...

>

>

> (2) IIUC, this proposal envisages BGP speakers commonly

> telling others to blackhole specific /32's or /128's. And

> of course as the draft says BGP doesn't provide us with a

> way to "prevent the unauthorized modification of

> information by the forwarding agent." Given those two

>

>

>

> err, there is MD5 auth for tcp... which SHOULD prevent modification in-flight.

> of course (ha!) there's notionally tcp-AO which should do the same thing, 
> perhaps in the 'year 2000' (say with proper gravitas) when we... wait, darn! 
> no implementations of AO exist.

>

> things, this scheme seems to be an ideal new way to cause

> any service that advertises a fallback to actually fall back,

>

>

>

> with bgp being in a state where there is no method (there is, md5 auth) to 
> prevent/notice modifications... all bgp sessions are at risk (some risk).

>

> e.g to use a secondary MX or DNS resolver rather than a

> primary. That seems like a fine way to try and possibly

> succeed in attacking many possible things. The discuss

> point here is to ask if this really is a new attack

> vector, and if so, if the appropriate level of analysis of

>

>

>

> doesn't look new to me, no. and 'worse', today someone COULD just (if they 
> are in the right place and can do bgp packet creation,etc) just tag all of 
> your announcments to your provider(s) with the local provider

>version of this community, blackholing all of your traffic... or they could 
>change the announcements to withdrawals... or other mean things. the addition 
>of this blackhole community doesn't change this problem, at all.

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 

Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Christopher Morrow]

On Wed, Aug 3, 2016 at 11:31 AM, Stephen Farrell 
wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-grow-blackholing-02: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/
>
>
>
> --
> DISCUSS:
> --
>
>
> First, I have to say that I'm pretty ignorant about
> practical routing operations, so my plan is to briefly
> discuss this and to then probably move to an abstain
> position, unless the issues I raise resonate with folks
> who are expert in this space.
>
> (1) I agree with the points raised in IETF LC that the
> transitive nature of this proposal has dangers that may
> outweigh its utility. Was there discussion in the WG about
> potential solutions that do not have the transitivity
> property? If so, can you point me at those? If not, is
> there a reason to think no such solution is feasible?  (I
> suspect the answer may be "no" which is the main reason I
> plan to move to an abstain ballot.)
>

your tools to do signaling in bgp are ... limited you can toggle/adjust/etc
things such as:
  community
  origin
  metric
  prefix-itself

In the scenario where we want to enable one provider to signal to the other
provider: "please take this action"

community is the 'best' option... you can signal somethign meaningful with
a commnuity where origin/metric don't really allow you to do more than
binary decisions.

In a scenario on the wider network NOT at a peering fabric that has a
route-server thingy... you don't really need a 'transitive' attribute
because you're just telling your neighbor: "pls do this" to which they
presumably have policy to do the right thing (or they may choose to ignore
you, of course).

In the scenario that includes a peering-fabric and route-server, you need
either:
  1) route-server to do some kinky things (ignore some forms of
non-transitive, re-map something to the non-transitive, etc)
  2) pass the attribute through because it is transitive.

the route-server is the remote network's bgp peer, so you have to ask the
route-server to ship stuff across to other peers...


>
> (2) IIUC, this proposal envisages BGP speakers commonly
> telling others to blackhole specific /32's or /128's. And
> of course as the draft says BGP doesn't provide us with a
> way to "prevent the unauthorized modification of
> information by the forwarding agent." Given those two
>

err, there is MD5 auth for tcp... which SHOULD prevent modification
in-flight.
of course (ha!) there's notionally tcp-AO which should do the same thing,
perhaps in the 'year 2000' (say with proper gravitas) when we... wait,
darn! no implementations of AO exist.


> things, this scheme seems to be an ideal new way to cause
> any service that advertises a fallback to actually fall back,
>

with bgp being in a state where there is no method (there is, md5 auth) to
prevent/notice modifications... all bgp sessions are at risk (some risk).


> e.g to use a secondary MX or DNS resolver rather than a
> primary. That seems like a fine way to try and possibly
> succeed in attacking many possible things.  The discuss
> point here is to ask if this really is a new attack
> vector, and if so, if the appropriate level of analysis of
>

doesn't look new to me, no. and 'worse', today someone COULD just (if they
are in the right place and can do bgp packet creation,etc) just tag all of
your announcments to your provider(s) with the local provider version of
this community, blackholing all of your traffic... or they could change the
announcements to withdrawals... or other mean things. the addition of this
blackhole community doesn't change this problem, at all.


> 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?)
>
>
'prefix limits' are standard protections for this on your bgp peerings.
so are (ha!) prefix filters so that they can't announce things they ought
not announce.


> (3) Given that there are dangers associated with this
> mechanism, why is there no statement in the draft that
> actions taken based on this scheme ought be logged or
> otherwise publicised as a possible way to provide some
> level of accountability, even if only after the fact?
>

[GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-grow-blackholing-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/



--
DISCUSS:
--


First, I have to say that I'm pretty ignorant about
practical routing operations, so my plan is to briefly
discuss this and to then probably move to an abstain
position, unless the issues I raise resonate with folks
who are expert in this space.

(1) I agree with the points raised in IETF LC that the
transitive nature of this proposal has dangers that may
outweigh its utility. Was there discussion in the WG about
potential solutions that do not have the transitivity
property? If so, can you point me at those? If not, is
there a reason to think no such solution is feasible?  (I
suspect the answer may be "no" which is the main reason I
plan to move to an abstain ballot.)

(2) IIUC, this proposal envisages BGP speakers commonly
telling others to blackhole specific /32's or /128's. And
of course as the draft says BGP doesn't provide us with a
way to "prevent the unauthorized modification of
information by the forwarding agent." Given those two
things, this scheme seems to be an ideal new way to cause
any service that advertises a fallback to actually fall back,
e.g to use a secondary MX or DNS resolver rather than a
primary. That seems like a fine way to try and possibly
succeed in attacking many possible things.  The discuss
point here is to ask if this really is a new attack
vector, and if so, if the appropriate level of analysis of
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?)

(3) Given that there are dangers associated with this
mechanism, why is there no statement in the draft that
actions taken based on this scheme ought be logged or
otherwise publicised as a possible way to provide some
level of accountability, even if only after the fact?


--
COMMENT:
--


- 3.2: It isn't clear to me how one might exercise
"extreme caution" here - can you explain? Or is that
obvious to the intended audience of this?


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow