Security Extension for OSPFv2 When Using Manual Key Management
RFC 7474
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Adrian Farrel; former steering group member) Yes
Thanks for this work. I am happy to ballot Yes, but have a couple of minor points I think would benefit the document. --- It would be good to add a very short note on backward compatiblity. I don't find anything in 2328, but I assume that a legacy implementation receiving an unknown AuType is supposed to fail authentication. Could you state this with the appropriate reference? --- The Abstract needs to be updated as: s/draft/document/ s/proposes/defines/ --- Section 1 para 1 s/propose/define/ --- Section 1 final para s/proposes/defines/ --- Section 1.2. The RFC Editor will move this sections to be consistent with their editorial guidelines. --- I think it is a mistake to quote the whole OSPF header in Figure 1. This opens up questions of editorial mismatches and future changes etc. It would be better to model this on Appendix D of RFC 2328. Additionally, it may be better to name the packet-trailing field as "Extended Authentication Data" to avoid confusion with the field in the generic packet header shown in RFC 2328 and called "Authentication"
(Alia Atlas; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
= Section 3 = s/This section of this/This section/
(Barry Leiba; former steering group member) No Objection
It seems that this document should be marked as "updates 5709", but it isn't. Why not?
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
I support the publication of this document, but agree with Adrian's suggestion to include some discussion on backwards compatibility.
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Joel Jaeggli; former steering group member) No Objection
If the non-volatile storage is ever repaired or upgraded such that the contents are lost or the OSPFv2 router is replaced, the authentication keys MUST be changed to prevent replay attacks. or if you ever replace the router... part of the reason manual keying is used is changing the authentication is quite hard particularly in cases where there are multiple neighbors on the same subnet.
(Kathleen Moriarty; 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
(Stephen Farrell; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection