Supporting Authentication Trailer for OSPFv3
RFC 7166
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
Thanks for this work and especially for the clear Section 1.2. There are just two minor Comments I'd like you to look at... --- Except for noting the fact that this document obsoletes 6506, the Abstract gives no clue that this document is not a new definition of the Authentication Trailer. I'd like something like: The OSPFv3 Authentication Trailer we originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition including clarifications and refinements of the procedures. --- I want to be clear that it is not your intention (as it was not the intention in RFC 6506) that the procedures in this document will form part of OSPFv3. That is, in your opinion, a new implementation of OSPFv3 is free to ignore this document and not consider it an essential part of the protocol. If I have stated it correctly, there is nothing for you to do. If I have it wrong then some changes to the document are needed (at least "updates 5340").
(Joel Jaeggli; former steering group member) Yes
(Sean Turner; former steering group member) Yes
Is there anyway that we can just point to the OSPFv2 AT RFC for the crypto aspects? It looks very similar just in a numbered list as opposed to separate sections. spt
(Stewart Bryant; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
[Sorry for the re-send. Forgot one bit.] Asking with no insight into the actual technology: The number of changes between 6506 and these seem pretty minimal to me. Is there a reason this is recycling at Proposed Standard and not being offered for Internet Standard? Do you expect that you still haven't gotten it quite right? 6506 is an Informative reference, not a Normative reference.
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- intro: I'm not entirely sure but I don't buy that there's no way to distinguish plain and ciphertext in ESP as a justification for this. I'd say delete the point or justify it properly (which could be be reference). There's suggested changes on this point from the secdir review as well, please consider those. - intro: do you really need all those hash functions? Why? That seems like a recipe for lack of interop for no security benefit. (Agility is a benefit, but there's no need to populate every option you can think of just for fun.) - intro: Why the "believed" there? And I don't think any RFC is "mathematically identical" to anything, not even itself! - 2.1: Does the AT bit really mean that an AT will be used for all packets on this link for all time? Won't that cause deployment problems if you ever need to deploy an "AT++" trailer signalled via a different bit in the header? Maybe you need to qualify the "all" some more? Similarly, if there's any load balancing done on the source end of a link, mightn't this rule cause problems when you initiate turning on AT and there's a delay between getting that into place betweeen two load-balanced speakers? (That last might be nonsense, I've no idea how OSPF if deployed in anything like that manner, but some other systems are. The first point though I think is valid ignoring any load-balancing.) - section 3: is a 16 bit SA-ID enough? That allows guessing fairly trivially and if there's any real DoS or timing attack then an attacker could search that space very quickly. - section 3: I wondered why referring to the karp key table wouldn't have been a good idea here instead of a "key chain"? - 4.1: why is the 64-bit sequence number OSPFv3 packet type specific? That seems to uselessly call for more storage on the validator side. If there's a good reason, I don't get it. I also don't get why you're insisting on strict monotonic increase here but then say that packets can arrive out of order. Is something broken there in the text? - 4.2: An example would really help here. Omitted vs. set to zero is confusing, as stated. - 4.5: You're *still* copy and pasting the HMAC algorithm internals? How many times do you intend to do this before you consider it a bad plan? I think that's a bad idea and wish I'd DISCUSSed it out of you before;-) - Appendix A: I thought HMAC was invented by Hugo and not NIST. You might want to check the ack there. And thanks for thanking me before I'd even seen this draft! Are you perhaps copy and pasting too much here again? (Or, did you just assume I'd have some dumb comment to make for sure:-)