I see. That being the case, I suggest Where the security considerations outlined above are a concern, users of this protocol should use IPsec [RFC4303] in tunnel mode with preshared keys.
We already discussed this in a smaller group (you, me, Chris, Paul Hoffman) and concluded it would be fine, but that decision would presumably need to be ratified (even if only through lack of objection) by the WG. Which of course is on the cc, so WG members (and others, of course) please speak up if you've any objection or changes to suggest! If there are no objections, I'll issue this as -17 early next week. Thanks, --John > On Dec 4, 2015, at 12:00 PM, Stephen Farrell <[email protected]> > wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-grow-bmp-16: 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: > ---------------------------------------------------------------------- > > > Hi, this is an update of my discuss. After some discussion > the authors changed from: > > OLD: > > Where the security considerations outlined above are a concern, users > of this protocol should consider using some type of transport that > provides mutual authentication, data integrity and transport > protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If > confidentiality is considered a concern, a transport providing that > as well could be selected. > > NEW: > > This document does not specify any security mechanism for BMP. > > I do not believe that it is ok to merely state that one is not > paying attention to IETF BCPs (BCP61 specifically) but one > needs to explain why. Hence my original suggestion which > was: > > "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 would like to talk about the right text to add here. My > belief (having chatted with a few folks but not everyone) > was that some people would be ok with saying you ought > implement IPsec, others would be ok with you ought do > TLS so backing right back down to "it's ok and not sad to > do nothing" seems wrong to me. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I didn't check these. Happy to chat about 'em more, but > we don't have to unless you want to. > > 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
