Revised Error Handling for BGP UPDATE Messages
draft-ietf-idr-error-handling-19
Yes
(Alia Atlas)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Ted Lemon)
Note: This ballot was opened for revision 18 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -18)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(2015-03-09 for -18)
Unknown
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 IESG member
No Objection
No Objection
(for -18)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-03-11 for -18)
Unknown
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 IESG member
No Objection
No Objection
(for -18)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-03-06 for -18)
Unknown
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 IESG member
No Objection
No Objection
(for -18)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -18)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -18)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -18)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -18)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-03-10 for -18)
Unknown
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 IESG member
No Objection
No Objection
(2015-03-10 for -18)
Unknown
- 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 IESG member
No Objection
No Objection
(for -18)
Unknown