I'll reply to this at greater length later, but for now let me associate myself with Jeff and Heas's comments.
--John > On Oct 14, 2015, at 12:44 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
