Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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 > > consideration
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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)
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. 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 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)
Hiya, On 09/08/16 16:05, Job Snijders wrote: > 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. I figured;-) > > 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. 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. > A few individuals do not agree with this viewpoint, so be it. We can't > please everyone. I'm sure what you mean is that some may end up in the rough (e.g. as per [1]) since I'd be quite surprised to know that there's any one thing that can please all routing folk:-) [1] https://tools.ietf.org/html/rfc7282 > >> (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? 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. TBH, I'm still not sure that's not the case. (Apologies if that's just me being dumb, which happens a lot.) > > 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:
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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 central
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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 into question the utility of > specifying this community
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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 fallbacks without any other
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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)
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)
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)
> 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)
> 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)
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)
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)
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)
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)
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)
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)
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. 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 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)
> 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 but I think it should be in
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)
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? > > most actions like this are