Revised Error Handling for BGP UPDATE Messages
RFC 7606
Yes
No Objection
Note: This ballot was opened for revision 18 and is now closed.
(Alia Atlas; former steering group member) Yes
(Kathleen Moriarty; former steering group member) Yes
Thanks for your work on this draft. My only comment would be to see if you could break the first paragraph of the security considerations into a few sentences. Maybe getting rid of the parens to help break out the additional sentences would help.
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
I have to add my thanks to Stephen's for an exceptionally good shepherd writeup. Thanks for taking the time to do that. I agree with Brian's comment that the 2119 key words are inappropriate in Section 6, and that they should be changed to plain-English recommendations.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
Thank you for a clearly written document. The only point I will make is that I do not think the 2119 keywords in section 6 are necessary.
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
This document was exceptionally clear to me, and I'm not skilled in the art of BGP. Thanks to everyone who had a hand in that.
(Stephen Farrell; former steering group member) No Objection
- The writeup is so good it almost convinced me to just ballot no-obj and not bother reading the doc:-) Good job. - There is a perhaps missing security consideration. I think this kind of protocol behaviour argues that any kind of BGPSEC encryption needs to use an AEAD ciphersuite. (Which we'd likely do these days anyway, so that's not a biggie.) The reason is if say CBC or a stream cipher were used, then an attacker could play with ciphertext is various ways that might interact with this error handling behaviour so as to expose information that is intended to be protected by the BGPSEC mechanism. Such an attack would probably be pooh-poohed by all but tin foil hat folks, but it could still be worth noting (maybe in section 8?) and as we've seen recently, many of the tin foil hat fears turn out to be realistic, sadly. I noted a few nitty nits: - section 2: AFI/SAFI are used without expansion - 3.d: "well-known mandatory attributes" sort of yells for a reference, doesn't it. - 3.e: "cases that specify" - specify where? I think you mean in the updated RFCs but it might be nice to say that - 5: NRLI is expanded after 1st use
(Ted Lemon; former steering group member) No Objection