MAC Authentication for the Babel Routing Protocol
draft-ietf-babel-hmac-12

[[ comments ]]

[ section 4.3 ]

* s/worthwile/worthwhile/

[ section 5 ]

* Is another option for implementations to be in a mode where:

    - they send authenticated packets
    - they attempt to authenticate packets received
    - if a packet does not authenticate is it still accepted
    - if a packet does authenticate then the neighbor entry is updated
      to note that all future communications with that neighbor must be
      use authentication (and any unauthenticated packets from this neighbor
      are dropped and maybe logged)?

[ section 7 ]

* s/an administators/an administrator's/, I think

Thanks for addressing my DISCUSS points.

Thank you for the work put into this document. Using HMAC is usually simple but this document builds a lot of negotiation around HMAC.

Regards,

-éric

== COMMENTS ==

I am a little puzzled by why HMAC keys/mechanisms are not identified to facilitate the key rollover. The used mechanism appears a little heavy on the required computing effort to compute several HMAC.

-- Section 1 --

The text about attacks on the Babel routing protocol should be better placed in the security considerations of RFC7216bis.

== NITS ==

The DTLS document use the writing <"babel" port> while here it is <Babel port>.

Please mention RFC2104 in section 2 when HMAC is mentioned for the first time.

Thank you for addressing my Discuss (and Comment) points!

One further note on the added text: I think that there is only mixed consensus
that PBKDF2 remains an algorithm that effectively hampers dictionary attacks,
since it's parallelizable and not memory-hard, but I don't object to listing it here.

Nits:

- sec 4.3.1.1 please clarify if the challenge request 300ms limit is per neighbor or per sending node (4.3.1.2 says per neighbor for challenge reply; I suspect it’s the same?)

- sec 7. “...this sort of resource attacks less effective...” s/attacks/attack”

Thanks for addressing my discuss and sorry for my late reaction (this somehow slipped through given the on-going discussion on draft-ietf-babel-rfc6126bis)!

OLD COMMENT (for the record):

The shepherd write-up says: "This document updates the rfc6126bis draft as noted on the title page
and in the Abstract." However, that seems not to be the case...?

This brings me to a separate question I would like to ask: Why is this an extension in a separate document and not an (optional) part of rfc6126bis?