Supporting Authentication Trailer for OSPFv3
RFC 7166

Note: This ballot was opened for revision 03 and is now closed.

(Stewart Bryant) Yes

(Adrian Farrel) Yes

Comment (2013-12-02 for -03)
No email
send info
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

(Joel Jaeggli) Yes

(Sean Turner) Yes

Comment (2013-12-04 for -03)
No email
send info
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.


(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2013-12-05 for -03)
No email
send info
- 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

- intro: Why the "believed" there? And I don't think any
RFC is "mathematically identical" to anything, not even

- 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

- 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:-)

(Brian Haberman) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

Comment (2013-12-04 for -03)
No email
send info
[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.

(Martin Stiemerling) No Objection