Dear all,
Draft-ietf-homenet-babel-profile-01 says:
REQ5: a Homenet implementation of Babel MUST implement HMAC-based
authentication, as defined in RFC 7298, MUST implement the two
mandatory-to-implement algorithms defined in RFC 7298, and MUST
enable and require authentication when instructed to do so by HNCP.
This requirement is completely useless in its current form. It expresses
the intent pretty well, but does nothing to specify the mechanism. In
particular, it is nowhere specified how HNCP peers decide to secure
a link, and how HNCP peers communicate the authentication information to
each other. (Communication between HNCP and Babel is not an issue, as it
is local to a single host.)
For this requirement to be useful, somebody needs to:
(1) precisely define the algorithm that HNCP peers use to decide on
authentication paramaters;
(2) precisely define the on-the-wire format that HNCP peers use to
communicate the authentication parameters;
(3) provide an implementation.
Please do not dismiss point 3 above. This is a healthy working group, one
with a proud tradition of only standardising algorithms and protocols that
have been implemented (and in most cases reimplemented independently). It
has been a lot of work to make it so, and it would be a shame if we gave up.
An important point to understand is that the lack of a cryptographic
authentication mechanism does not make HNCP insecure. The expected
deployment model is that HNCP and Babel only run on links that are secured
at a lower layer, while guest links only run the usual leaf protocols (RA,
ND, DHCPv4, ARP, etc.). Cryptographic mechanisms are only needed if for
some reason a network is using untrusted links for transit.
We've just had a private chat with the chairs and Markus, and I suggested
that we should simply remove REQ5 until we've got a precise specification
and an implementation. Markus agrees, although for slightly different
reasons (he's in favour of running HNCP on trusted links only, as
described in the paragraph above). The chairs, however, have expressed
their unease at removing this requirement, fearing it might cause trouble
during IESG review, and have asked me to bring the discussion to the list.
Which I am presently doing.
Please tell me what to do. Shall I remove REQ5, and hope for the best
during IESG review, or is somebody intending to implement REQ5 in HNCP and
collaborate on writing a detailed specification? I'd like to be clear on
one point: I shall not be the editor of a specification that contains
requirements that nobody has any intention to implement.
Thanks for your help,
-- Juliusz
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
