On 04/12/15 18:40, John G. Scudder wrote: > 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.
FWIW, that would be sufficient for me to clear. As would that with s/IPsec/TLS/ S > > 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
