[GROW] Jari Arkko's No Objection on draft-ietf-grow-bmp-15: (with COMMENT)
Jari Arkko has entered the following ballot position for draft-ietf-grow-bmp-15: No Objection 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-bmp/ -- COMMENT: -- Comments and questions from the recent Gen-ART review by Vijay Gurbani deserve to be looked at. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
On Wed, Oct 14, 2015 at 08:47:17PM +, heasley wrote: > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext" > option - not for normal runtime, for debugging. its darwinian, if someone > chooses to always run cleartext. This is actually a big deal with regards to streaming routing protocols. It's been my unfortunate experience over the years that most BGP developers have more than the usual familiarity with the implementation behaviors of TCP. Even *normal* TCP has ugly properties that negatively impact BGP. Introduce another couple layers between the protocol PDUs and the final set of transports and it's a royal pain to do anything about. To give a simplified and common issue, when BGP peering sessions on otherwise quiet links time out, you get to look at things like the TCP windows to see if your PDUs ever made it out and were advertised on the wire and acknowledged by the other side. This often requires the sequencing data from both sides to try to pin down the problems. Now introduce the peculiarities of other encapsulations and their interactions with the underlying timings of the protocol. If I'm running TLS, how do I know that it hasn't chosen to hold up a PDU for an extra second or two in order to either have a full enough payload to make the crypto library happy? I realize that these peculiarities can be addressed in the long-run, but I tend to see these issues as having negative consequences on the operational stability of the underlying protocol. > I do not care if your suggested text is added or not; the existing security > section of the draft covers the subject for me. Nor do I disagree that it > could support TLS, just do it in a separate draft and move this one along. > I suspect if you examined the idea of TLS as another one of the recommended transport security options in the context of the existing text, you'd be fine with that too. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Wed, Oct 14, 2015 at 09:04:33PM +0100, Stephen Farrell: > > I'd be happy to see the addition of TLS support in a future document. I > > also do not want TLS use to be required and I would like to see this > > draft move forward without TLS. > > My non-blocking comment asks about the why of that, which I > really do not get, it's not like it's hard or new. I feel that there is an overhead associated with TLS, etc for development, debugging and runtime. All concern me, as does lack of security. For BMP, a protocol most likely to be confined to a lab than the wild Internet, I am more concerned about runtime cost and deployment (ie: initial development) than with security of the session. BMP could be run over an ipsec tunnel as an alternative to it being part of the protocol. For debugging purposes, I'd perfer to see ALL protocols have a "cleartext" option - not for normal runtime, for debugging. its darwinian, if someone chooses to always run cleartext. > But the DISCUSS from me is about truth in advertising - if > the WG are presenting this as something that cannot in practice > be secured (which is how I read the secdir thread) then that > should be what the document says. (See my suggested text.) I do not care if your suggested text is added or not; the existing security section of the draft covers the subject for me. Nor do I disagree that it could support TLS, just do it in a separate draft and move this one along. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
And I failed to include a relevant point: On Wed, Oct 14, 2015 at 04:35:37PM -0400, Jeffrey Haas wrote: > The protocol standardizes the message contents over this stream. > > The protocol by default suggests TCP. But as overly flippantly noted in the > security considerations, you can use something stronger if you desire either > integrity or privacy. > > While I feel your particular pain and anger over the general state of > things, my suggestion is we should work on clarifying the text in the above > fashion: If you want a secured transport, you can use one. We can even > recommend one. Making anything other than stock TCP mandatory will result > in implementor torches and pitchforks at this point because we have shipping > code and customers use it. :-) It's also important to understand that in routing infrastructure, *operators* have some power to control the security of inter-router traffic. They may choose to tunnel traffic between two routers over a secure transport. Their link layers may provide security. A separate management plane may be used for for the protocol. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
[Note that I do not speak for the authors, just as someone who works on software that contains an implementation of BMP.] On Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell wrote: > "This is an inherently insecure protocol for no particularly > good reason and mostly due to the lack of implementation of > basic security mechanisms (SSH, TLS) but also due to a lack > of customer/operator pressure to ensure those are present, > usable and interoperate, despite evidence that attacks on > the links over which this data will be sent are ongoing." > > I'd not be surprised if you preferred some other text:-) It's refreshingly honest, but works from a slightly different perspective than what the implementors give a darn about. You will note that aside from saying that this works over TCP that the protocol doesn't even mention what *port* it should be working on by default. Mostly, the protocol doesn't give a darn as long as we can get a reliable stream session between two devices. The protocol standardizes the message contents over this stream. The protocol by default suggests TCP. But as overly flippantly noted in the security considerations, you can use something stronger if you desire either integrity or privacy. While I feel your particular pain and anger over the general state of things, my suggestion is we should work on clarifying the text in the above fashion: If you want a secured transport, you can use one. We can even recommend one. Making anything other than stock TCP mandatory will result in implementor torches and pitchforks at this point because we have shipping code and customers use it. :-) > Why is using TLS not a no-brainer for this? Given the likes > of the Belgacom and Gemalto reports, I would love to > understand why people are still willing to buy and sell > equipment without such basic features. The "explanation" > that nobody needs it or nobody provides it seems off base > here - this is new code and a new interface, and the > relevant security protocols (SSH, IPsec and TLS) are all > nearly or more than 20 years old. A significant amount of this is simply implementation issues. I'm quite happy to sit down with whomever at the upcoming IETF to help generate some lightbulb moments. While it won't remove your frustration, it will at the very least clarify some of the why involved. At a high level, protocol developers aren't security experts. While routing protocols are treated as system software (in the traditional sense), they are still application level programs for the most part. With a few exceptions, transport services are provided via standard APIs. If the service isn't available to an application developer, it isn't deployed. The question then is why aren't these things more readily available? That's the long conversation. > (And yes, I get that all the stuff as to why AO isn't > available for BGP, but this is not BGP. It's our apparent > need to keep the security level down at the "crap" marker > that I don't get.) The more relevant observation is what piece of your routing ecosystem BMP is implemented in. And given that, it's no surprise that BMP is a very thin wrapper on top of BGP PDUs for the most part. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Kathleen Moriarty's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS)
I guess I didn't do a good job of just sending to the IESG. Sorry for the spam... Brian On 10/14/15 4:23 PM, Brian Haberman wrote: > I dropped the distribution to just the IESG for this response... > > On 10/13/15 10:06 PM, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-grow-bmp-15: 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-bmp/ >> >> >> >> -- >> DISCUSS: >> -- >> >> The statements on authenticated access and confidentiality are helpful, >> but this is a new protocol and should not start out with the security >> property levels of the current BGP deployments. Efforts have been made >> to publish RFCs to fix BGP security and the vulnerabilities have been >> published - even in the Washington Post. I'd like to see more security >> required for the properties mentioned to prevent active and passive >> attacks getting dumps of the BGP data, which was not previously >> available. If this is not possible per the suggestions below, please >> explain why. If there is a good reason, it would be helpful to remove >> the text that says its okay to leave security out because BGP isn't >> secure and just include the security considerations. >> >> Now for specifics: >> >> 1. In the Security considerations, it is not only a passive attacker, but >> also an active one that could gain access to the session if it is not >> encrypted (protected for confidentiality). An active attacker might >> change routes causing network disruption. A passive attacker might >> better understand the possible paths to an AS, assisting with a more >> effective DDoS attack. The latter point is important to consider in the >> first paragraph of this section that currently says, >> "although it's hard to consider the content of BGP routes in the >>public Internet to be confidential," >> >> I think this is a bit of an overstatement as the exact routes and paths >> are not published for each router and could be used for DoS attacks - for >> example taking out one or more paths to a network AS. >> >> What I am suggesting for #1 is a simple text change to address the fuller >> set of security considerations. >> Change from: >>Unless a transport that provides confidentiality is used, >>a passive attacker could gain access to BMP data in flight. >> To: >>Unless a transport that provides confidentiality is used, >>a passive or active attacker could gain access to or tamper the BMP >> data in flight. >> > > Tampering with BMP data will not impact the BGP routing infrastructure. > BMP does not have the ability to modify the BGP routes processed by a > router. It is designed to mirror information to a collector so that the > collector does not have to use archaic techniques like screen scraping > to monitor BGP behavior. An active attack that tampers with the BMP data > will simply make services like BGP mirrors show incorrect data and not > actually influence BGP routing operation. > > Regards, > Brian > > > > ___ > 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] Kathleen Moriarty's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS)
I dropped the distribution to just the IESG for this response... On 10/13/15 10:06 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-grow-bmp-15: 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-bmp/ > > > > -- > DISCUSS: > -- > > The statements on authenticated access and confidentiality are helpful, > but this is a new protocol and should not start out with the security > property levels of the current BGP deployments. Efforts have been made > to publish RFCs to fix BGP security and the vulnerabilities have been > published - even in the Washington Post. I'd like to see more security > required for the properties mentioned to prevent active and passive > attacks getting dumps of the BGP data, which was not previously > available. If this is not possible per the suggestions below, please > explain why. If there is a good reason, it would be helpful to remove > the text that says its okay to leave security out because BGP isn't > secure and just include the security considerations. > > Now for specifics: > > 1. In the Security considerations, it is not only a passive attacker, but > also an active one that could gain access to the session if it is not > encrypted (protected for confidentiality). An active attacker might > change routes causing network disruption. A passive attacker might > better understand the possible paths to an AS, assisting with a more > effective DDoS attack. The latter point is important to consider in the > first paragraph of this section that currently says, > "although it's hard to consider the content of BGP routes in the >public Internet to be confidential," > > I think this is a bit of an overstatement as the exact routes and paths > are not published for each router and could be used for DoS attacks - for > example taking out one or more paths to a network AS. > > What I am suggesting for #1 is a simple text change to address the fuller > set of security considerations. > Change from: >Unless a transport that provides confidentiality is used, >a passive attacker could gain access to BMP data in flight. > To: >Unless a transport that provides confidentiality is used, >a passive or active attacker could gain access to or tamper the BMP > data in flight. > Tampering with BMP data will not impact the BGP routing infrastructure. BMP does not have the ability to modify the BGP routes processed by a router. It is designed to mirror information to a collector so that the collector does not have to use archaic techniques like screen scraping to monitor BGP behavior. An active attack that tampers with the BMP data will simply make services like BGP mirrors show incorrect data and not actually influence BGP routing operation. Regards, Brian 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-bmp-15: (with DISCUSS and COMMENT)
Hiya, On 14/10/15 20:57, heasley wrote: > Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell: >> And introducing new protocols without improving that >> goes against very long held IETF consensus that protocols >> need to have some actually usable strong security mechanism >> defined. It seems the wg here get that but are choosing to >> do nothing about it - I mean in their day-jobs, not that >> writing RFC text is "doing something." The responses to the >> secdir review seem to make it clear that the claim that >> IPsec can be used is mythical, so this discuss to ask that >> the security considerations properly document the utter >> absence of any modern way to secure this protocol and not >> pretend that there are ways that can be used to secure this >> in the real world. > > I'd be happy to see the addition of TLS support in a future document. I > also do not want TLS use to be required and I would like to see this > draft move forward without TLS. My non-blocking comment asks about the why of that, which I really do not get, it's not like it's hard or new. But the DISCUSS from me is about truth in advertising - if the WG are presenting this as something that cannot in practice be secured (which is how I read the secdir thread) then that should be what the document says. (See my suggested text.) S. > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Wed, Oct 14, 2015 at 09:44:01AM -0700, Stephen Farrell: > And introducing new protocols without improving that > goes against very long held IETF consensus that protocols > need to have some actually usable strong security mechanism > defined. It seems the wg here get that but are choosing to > do nothing about it - I mean in their day-jobs, not that > writing RFC text is "doing something." The responses to the > secdir review seem to make it clear that the claim that > IPsec can be used is mythical, so this discuss to ask that > the security considerations properly document the utter > absence of any modern way to secure this protocol and not > pretend that there are ways that can be used to secure this > in the real world. I'd be happy to see the addition of TLS support in a future document. I also do not want TLS use to be required and I would like to see this draft move forward without TLS. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Alia Atlas' Yes on draft-ietf-grow-bmp-15: (with COMMENT)
Alia Atlas has entered the following ballot position for draft-ietf-grow-bmp-15: Yes 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-bmp/ -- COMMENT: -- Thank you for a clear and well-written document. This was easy to read and understand. I do have a couple questions. a) In Section 4.2, I see special casing for an "L3VPN Instance Peer". Will the same thing be necessary for an EVPN peer? Are there other future cases to be considered? b) In Sec 4.4, for the type=0 String, it may be useful to specify that the language is unspecified and based on the configuration. A similar description for the other information strings would be useful. I'm sure that Barry could suggest better text. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-grow-bmp-15: 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-bmp/ -- DISCUSS: -- Apologies in advance for the rant, but this is a new protocol and not something deployed for decades that can't be fixed. (At least so says the write-up.) The state of security here is just sad. It reminds me of the 1980's. And introducing new protocols without improving that goes against very long held IETF consensus that protocols need to have some actually usable strong security mechanism defined. It seems the wg here get that but are choosing to do nothing about it - I mean in their day-jobs, not that writing RFC text is "doing something." The responses to the secdir review seem to make it clear that the claim that IPsec can be used is mythical, so this discuss to ask that the security considerations properly document the utter absence of any modern way to secure this protocol and not pretend that there are ways that can be used to secure this in the real world. I would suggest text that simply says that: "This is an inherently insecure protocol for no particularly good reason and mostly due to the lack of implementation of basic security mechanisms (SSH, TLS) but also due to a lack of customer/operator pressure to ensure those are present, usable and interoperate, despite evidence that attacks on the links over which this data will be sent are ongoing." I'd not be surprised if you preferred some other text:-) -- COMMENT: -- Separate to the discuss, I have some non-blocking points, that I think resonate with Kathleen's discuss: Why is using TLS not a no-brainer for this? Given the likes of the Belgacom and Gemalto reports, I would love to understand why people are still willing to buy and sell equipment without such basic features. The "explanation" that nobody needs it or nobody provides it seems off base here - this is new code and a new interface, and the relevant security protocols (SSH, IPsec and TLS) are all nearly or more than 20 years old. And that is all the more the case for a new protocol like this that is not likely in the critical path and where the monitoring statiion may be off to the side so the traffic flows via BMP in places where BGP doesn't go implying different threat levels, that may need different protection. My best guess as to causes for now is that people are just used to doing nothing and have done that for so long they seem to think that doing nothing is the only possibility. (That's how business models get disrupted isn't it?) Can you educate me some more on this? (And yes, I get that all the stuff as to why AO isn't available for BGP, but this is not BGP. It's our apparent need to keep the security level down at the "crap" marker that I don't get.) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-route-leak-problem-definition-03.txt
On Tue, Oct 13, 2015 at 02:58:26AM +, Sriram, Kotikalapudi wrote: > This version (draft-ietf-grow-route-leak-problem-definition-03) > is a significantly revised and updated draft relative to version-02. > The document (version-02) was in WGLC in the GROW WG. > Many thanks to Charles, Jeff, Wes and Andrei for their > review, comments, and support in response to WGLC > in GROW (it was cross posted to IDR as well). > The authors have considered all their comments/suggestions in revising this > draft, > and we feel that it has significantly benefited from their recent > review/re-review. Thanks, Sriram. You've addressed my comments. Should there be an additional edits, I'd suggest removing "subprefix" and consistently using "more specific prefix". -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
