IETF conflict review for draft-ovsienko-babel-hmac-authentication
conflict-review-ovsienko-babel-hmac-authentication-00

Note that these comments are just my review and are
intended for the authors and ISE to consider however they
wish. Happy to chat about them if someone wants to though.

- p4, 2nd para: this seems to end abruptl

- 2.1, RIPEMD-160 and SHA-1 are odd choices for MTI these
days.  One would expect that SHA-256 perhaps plus a SHA-3
finalist would be more likely as a modern MTI HMAC choice
for an experimental RFC, or if there are reasons to prefer
a shorter output that those might be stated.

- 2.1, which of the combinations mentioned have known weak
keys? Could that be a hangover from old DES based stuff?

- 2.2, I'm not clear why you need padding before doing
HMAC. Ah - I got it at the end of 2.2 - you don't mean what
a cryptographer would call padding but rather you mean
preparing a canonical input for HMAC. 

- 2.4, why oh why do routing people feel the need to
replicate text from RFC 2104 ;-) I think just referring to
the HMAC RFC would be better here.

- 4.3, the length field is in octets and not bits I assume?
Might be a (tiny bit;-) better to say that explicitly.

- 4.3, "Digest" isn't a great name, since those bits are
not actually a digest but an HMAC output. (Authenticator
would be a more common term maybe.)

- 4.3, While this is just about HMAC, with an eight bit
length field and 2 octet KeyID that would only allow a max
of 2038 bits of "Digest" which is not enough for an RSA
2048 signature. Up to you if you think that's important or
not. If you did, using another Type for signatures would be
fine, or a 16 bit Length. Maybe another Type would be
better in this case.

- Section 8: Nice! Thanks for that.

- Section 9: It wasn't clear to me whether or not any
reflection attacks might be possible, nor if use of private
addresses (e.g. Net10) might mean that some odd form of
replay might be doable.