Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
> Nick Hilliard wrote : > I would have said the opposite, i.e. that any traffic tagged with this prefix > is dropped via e.g. null0 > or martian mechanisms / etc. But it definitely needs to be defined because at > the moment it's ambiguous. > Ambiguity is fine when it's your own network, but not fine when you're > defining something with global scope. Totally agree. Default behavior on vendor "C" router : if the prefix comes with NO-EXPORT, there is nothing to do so that it is not announced out of the local AS. Prefix not announced to eBGP peers because of well-known community. That's what well-known communities are, right ? DEFAULT behavior is coded-in by the vendor. Same as BLACKHOLE : well-known community, router should drop it by default, and here is the major concern : DEFAULT behavior. If BLACKHOLE as currently proposed is handled the same way NO-EXPORT is, having it enabled by default is a danger. As said in my initial reaction : too broad. > Job Snijders wrote : > The word 'source' does not appear in the draft. In my reading of section 3.1 > it is obvious destination based blackholing, > but I welcome a suggestion to reword a sentence in the introduction to > include the phrase 'destination based blackholing'. The destination-based was not obvious to me on the first read. Besides, my concerns are not what the intent of a draft is, but what people will do with it if implemented. A reword will definitely make it more palatable. As of what people will do with it, what tells you that your intent of blackholing the destination will not be perverted as blackholing the source ? There are commercial services out there already that provide source-based BGP blackhole feeds. My personal one happens to be on the wild side, but again what's the difference ? > joel jaeggli wrote: > It should be an inherent property that what is being blackholed is traffic > bound for the prefix that the community is attached to is it not? Yes, but how do you make that happen ? There are some people out there that have implemented uRPF. What you suggest is a standardized codepoint to kill the victim in order to protect the infrastructure. I understand that, sometimes necessary. However, if you are the prefix under attack, there is much better : feed a source-based blackhole to your upstreams, which kills the aggressor instead of killing you. > Source based RTBH requires some explicit coordination between the parties > using it. How so ? if you trust that the party you announce your blackhole to will check that it is indeed your prefix, you are being unrealistic. Especially lately with the thing known as "PA leasing", people do announce prefixes that are not coming from the ASN they are supposed to, and it's not prefix hijacking. I'm not saying it's right, because it's basically multi-homing a PA, but it does happen and it's not going to get better. > heasley wrote : > Why wouldn't you want to propogate BH routes? If you want to BH the traffic, > then let it be dumped closer to the > source. You might accidentally make things exciting for yourself, but it > seems like desirable behavior to me. Indeed, and this is a lot more true when the blackhole targets the source. The further it is propagated, the better. > Christopher Morrow wrote : > I like this game... but, "Why would the document specify that this is > either/or src/dest blackholing?" > maybe I'm expecting consenting adults to still be playing at the end of the > day... Because it would make it less controversial ? Michel. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
> The second major area of concern I have about this proposal is the > transitive nature of the bgp community. The issue is that the draft > specifies a mechanism to cause traffic to be dropped on the floor, > that the signaling mechanism is globally transitive in scope, and the > specific intent is that prefixes tagged in this way are exported to > other ASNs. In other words, the draft specifies behaviour that is > risky by default. risky? this is a disasterous vulnerability large enough to handle a very large truck. we really do not need a global mecahnism by which an attacker can spoof a bgp announcement of someone's prefixes and cause traffic to the specified address space(s) to be discarded on a significant portion of the internet. until bgp annoucements can be rigorously authenticated, this is a disaster waiting to happen. and it will not wait long. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On Wed, Jun 29, 2016 at 4:59 PM, joel jaeggli wrote: > On 6/29/16 1:46 PM, Nick Hilliard wrote: > > Job Snijders wrote: > >> Should it be somehow clarified that router vendors are not supposed to > >> implement mechanisms, which are by default enabled, that discard traffic > >> for BLACKHOLE'ed prefixes? > > > > I would have said the opposite, i.e. that any traffic tagged with this > > prefix is dropped via e.g. null0 or martian mechanisms / etc. But it > > definitely needs to be defined because at the moment it's ambiguous. > > Ambiguity is fine when it's your own network, but not fine when you're > > defining something with global scope. > > > > Also, as Michael Py mentioned, it's not clear whether this refers to > > source based blackholing or destination based blackholing. > > It should be an inherent property that what is being blackholed is > traffic bound for the prefix that the community is attached to is it not? > > Source based RTBH requires some explicit coordination between the > parties using it. > > I like this game... but, "Why would the document specify that this is either/or src/dest blackholing?" maybe I'm expecting consenting adults to still be playing at the end of the day... ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Wed, Jun 29, 2016 at 05:22:44PM -0400, Jared Mauch: > > On Jun 29, 2016, at 5:10 PM, Nick Hilliard wrote: > > Job Snijders wrote: > >> Do you have any more comments or concerns queued up? > > > > I don't think the draft is well specified in terms of its intended > > semantics. This is a problem with a standards track document, > > particularly one with big scary warnings in the security considerations > > section. It needs to be tightened up substantially before publication > > could be considered. > > Looking at section 5 of https://www.rfc-editor.org/rfc/rfc5635.txt Why wouldn't you want to propogate BH routes? If you want to BH the traffic, then let it be dumped closer to the source. You might accidentally make things exciting for yourself, but it seems like desirable behavior to me. Since BH routes tend to be more specific, most are unlikely to be propogated very far anyhow. I think that the security concern lies far more in the lack of origin validation [with rfc7908 usw.]. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Wed, Jun 29, 2016 at 10:54:30PM +0200, Job Snijders: > On Wed, Jun 29, 2016 at 09:46:15PM +0100, Nick Hilliard wrote: > > Job Snijders wrote: > > > Should it be somehow clarified that router vendors are not supposed to > > > implement mechanisms, which are by default enabled, that discard traffic > > > for BLACKHOLE'ed prefixes? > > > > I would have said the opposite, i.e. that any traffic tagged with this > > prefix is dropped via e.g. null0 or martian mechanisms / etc. But it > > definitely needs to be defined because at the moment it's ambiguous. > > Ambiguity is fine when it's your own network, but not fine when you're > > defining something with global scope. > > Why would you say the opposite? That goes counter to what the vendors > are shipping today. The suggestion "do not do anything" is compatible > with what ships today! :) > > We can add a new section "3.4 - Vendor recommendations" and describe > what it is we'd expect a network device vendor to implement or not to > implement. It may be useful to be able to forward BH traffic off a router for analysis, so discarding may not be desired. I'd leave what is done with traffic by default for configuration by operator. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Hi David, Thank you for your feedback. On Wed, Jun 29, 2016 at 04:23:23PM -0500, David Farmer wrote: > > Range Registration Procedures > > 0x-0x8000 First Come First Served > > 0x8001-0x Standards Action > > And given that the code point that is being defined is 0x029A and > that falls in the First Come First Served range, technically standards > action isn't required. Furthermore, this draft is really dependant on > RFC3882 and RFC5635, both Informational Status, for a full description > of the intended functionality. If this draft is Standards Track, > some may mistakenly think there is some kind of preference for this > mechanism for triggering Blackholes, vs. the other mechanisms > discussed in RFC3882 and RFC5635. I fully support this defining this > Well-Known BGP Community, however I believe it should be of equal > stature as the other mechanisms discussed in > RFC3882 and RFC5635. > > Therefore, for the above reasons, I think the more appropriate status > for this draft is Informational. In light of what you described here, I don't mind changing the intended status from STD to INFO. Also, I see similarities with NOPEER/RFC3765 which is "Informational" too. Would anyone object to this change? Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On Sun, Jun 26, 2016 at 11:47 PM, joel jaeggli wrote: > On 6/26/16 6:38 AM, Nick Hilliard wrote: > > There has been no discussion on the GROW mailing list about having this > > document published as Standards Track rather than informational and it's > > coming as a surprise to see that this was only announced at IESG Last > > Call a couple of days ago. At the least, there ought to be some > > discussion about this before pushing it up into the publication queue. > > The looking back at the document that was WGLCed (which is the current > version) the state was standards track. the individual sumbission draft > draft-ymbk-grow-blackholing-00 was flagged as such since initial > submission. It's status therefore I think is well understood. Whether > that's appropriate or not is another question. > > Afaik well know assignments (and there are precious few really) have > been generally regarded as standards action thought the ranges is split > like so. > > > Range Registration Procedures > 0x-0x8000 First Come First Served > 0x8001-0x Standards Action And given that the code point that is being defined is 0x029A and that falls in the First Come First Served range, technically standards action isn't required. Furthermore, this draft is really dependant on RFC3882 and RFC5635, both Informational Status, for a full description of the intended functionality. If this draft is Standards Track, some may mistakenly think there is some kind of preference for this mechanism for triggering Blackholes, vs. the other mechanisms discussed in RFC3882 and RFC5635. I fully support this defining this Well-Known BGP Community, however I believe it should be of equal stature as the other mechanisms discussed in RFC3882 and RFC5635. Therefore, for the above reasons, I think the more appropriate status for this draft is Informational. Thanks. -- === 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] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
> On Jun 29, 2016, at 5:10 PM, Nick Hilliard wrote: > > Job Snijders wrote: >> Do you have any more comments or concerns queued up? > > I don't think the draft is well specified in terms of its intended > semantics. This is a problem with a standards track document, > particularly one with big scary warnings in the security considerations > section. It needs to be tightened up substantially before publication > could be considered. Looking at section 5 of https://www.rfc-editor.org/rfc/rfc5635.txt I think provides some guidance of helpful text to improve this section. While some hardware may not support certain capabilities, limiting a specification to an exact generation of operator hardware would be shortsighted. I suspect one could re-use much of the rfc5635 text without much if any additional commentary. - Jared ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Job Snijders wrote: > Do you have any more comments or concerns queued up? I don't think the draft is well specified in terms of its intended semantics. This is a problem with a standards track document, particularly one with big scary warnings in the security considerations section. It needs to be tightened up substantially before publication could be considered. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On 6/29/16 1:46 PM, Nick Hilliard wrote: > Job Snijders wrote: >> Should it be somehow clarified that router vendors are not supposed to >> implement mechanisms, which are by default enabled, that discard traffic >> for BLACKHOLE'ed prefixes? > > I would have said the opposite, i.e. that any traffic tagged with this > prefix is dropped via e.g. null0 or martian mechanisms / etc. But it > definitely needs to be defined because at the moment it's ambiguous. > Ambiguity is fine when it's your own network, but not fine when you're > defining something with global scope. > > Also, as Michael Py mentioned, it's not clear whether this refers to > source based blackholing or destination based blackholing. It should be an inherent property that what is being blackholed is traffic bound for the prefix that the community is attached to is it not? Source based RTBH requires some explicit coordination between the parties using it. > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > signature.asc Description: OpenPGP digital signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On Wed, Jun 29, 2016 at 09:46:15PM +0100, Nick Hilliard wrote: > Job Snijders wrote: > > Should it be somehow clarified that router vendors are not supposed to > > implement mechanisms, which are by default enabled, that discard traffic > > for BLACKHOLE'ed prefixes? > > I would have said the opposite, i.e. that any traffic tagged with this > prefix is dropped via e.g. null0 or martian mechanisms / etc. But it > definitely needs to be defined because at the moment it's ambiguous. > Ambiguity is fine when it's your own network, but not fine when you're > defining something with global scope. Why would you say the opposite? That goes counter to what the vendors are shipping today. The suggestion "do not do anything" is compatible with what ships today! :) We can add a new section "3.4 - Vendor recommendations" and describe what it is we'd expect a network device vendor to implement or not to implement. > Also, as Michael Py mentioned, it's not clear whether this refers to > source based blackholing or destination based blackholing. The word 'source' does not appear in the draft. In my reading of section 3.1 it is obvious destination based blackholing, but I welcome a suggestion to reword a sentence in the introduction to include the phrase 'destination based blackholing'. Do you have any more comments or concerns queued up? Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Job Snijders wrote: > Should it be somehow clarified that router vendors are not supposed to > implement mechanisms, which are by default enabled, that discard traffic > for BLACKHOLE'ed prefixes? I would have said the opposite, i.e. that any traffic tagged with this prefix is dropped via e.g. null0 or martian mechanisms / etc. But it definitely needs to be defined because at the moment it's ambiguous. Ambiguity is fine when it's your own network, but not fine when you're defining something with global scope. Also, as Michael Py mentioned, it's not clear whether this refers to source based blackholing or destination based blackholing. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
On Wed, Jun 29, 2016 at 01:30:49PM +0100, Nick Hilliard wrote: > The second major area of concern I have about this proposal is the > transitive nature of the bgp community. I thought Section 3.2 provides enough detail on scoping routes tagged with BLACKHOLE, however with your concern and the following in mind: This draft intends to unify the wild variety of blackholing communities which exist in the wild by providing a single Well-known codepoint, see bottom of [1] for an incomplete list. I do not think it is feasible to mandate new behaviour (like automatically adding a NO_EXPORT community) in this draft. It is up to the network operator to decide when and where to honor a blackhole community and when not to honor it. Automatically adding NO_EXPORT (or any of the other scope limiting Well-known communities) is likely to lead to implementation difficulty for operators when prefixes with a blackhole community attached need to be redistributed to some sort of sibling network. So, with your concern and the above in mind: Should it be somehow clarified that router vendors are not supposed to implement mechanisms, which are by default enabled, that discard traffic for BLACKHOLE'ed prefixes? Just like the deployment of honoring the NOPEER [rfc3765] community is 100% driven by the operator, out of the box the vendor implementations do nothing with the community except transit it. Kind regards, Job [1]: https://www.ietf.org/mail-archive/web/ietf/current/msg98740.html ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
Job Snijders wrote: > I believe this update addresses the concerns raised in this phase of the > document. yes, thanks, it addresses these concerns, and the document is a lot better as a result. The second major area of concern I have about this proposal is the transitive nature of the bgp community. The issue is that the draft specifies a mechanism to cause traffic to be dropped on the floor, that the signaling mechanism is globally transitive in scope, and the specific intent is that prefixes tagged in this way are exported to other ASNs. In other words, the draft specifies behaviour that is risky by default. Prefix hijacking rates suggest that adding a new compromise vector is something that should be considered carefully in the context of standardisation. The obvious way to work around this would be to specify a non-transitive community, but that would defeat the purpose of the draft. Other options might include a requirement that BLACKHOLE should automatically be marked as NO-EXPORT when received by a third party ASN. This doesn't deal with backwards compatibility, though, and given the lifetime of bgp implementations, there would be a large time window opened where this may be a problem. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
