Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-05

[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.

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