Re: [babel] Alissa Cooper's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Alissa,

> I support Roman's DISCUSS.

There are no less than 7 points raised by Roman in his Discuss.  We have
tried our best to answer them, please let us know which are the ones you
feel strongly about and whether you feel we have answered them to your
satisfaction.

> I'm also unclear on the over-arching recommendation this document is
> making for securely deploying this protocol. Given that the protocol
> itself is insecure, I would have expected some normative requirement for
> correcting that (e.g., Minimally, Babel deployments MUST be secured
> using a lower-layer security mechanism, Babel over DTLS, or HMAC-based
> authentication.)  This still would not bring it into line with BCP 61
> Section 7, but perhaps there is some argument for making an exception
> for this protocol.

Section 6 of RFC 6126bis describes the two inline security mechanisms
developed for Babel (Babel-DTLS and Babel-HMAC), and recommends that
Babel-HMAC should be used in preference to Babel-DTLS unless
confidentiality or asymmetric keying is required.

We do not think, however, that marking either of these protocols as MTI
would have a positive outcome, either for the security of the Internet,
for the Babel protocol, the Babel standardisation process, or the already
somewhat frayed reputation of the IETF in the free software community.

Please let me give you some background.  Our decision to go to IETF for
standardisation was criticised by part of our user base, who felt that it
would push the protocol in a direction that is not directly useful to
them.  Indeed, before Babel became an IETF protocol, its development was
driven by the needs of our users.  While this is still the case to a great
extent, going to the IETF has meant that we had to suspend development of
Babel for many months while we worked on Babel-DTLS and Babel-HMAC, that
were both developed not to meed the needs of our user community, but
solely to satisfy the requirements of the IETF and the potential future
needs of the IETF Homenet WG.

Babel-DTLS and Babel-HMAC have been duly developed, implemented and
documented in the form of their respective internet-drafts.  We have made
the code publicly available, and are encouraging our users to consider
with the new technologies.

However, we do not feel entitled to impose any more on our users.  If the
Babel user community decide that they do not want to carry code for
security protocols that they are not using, there is nothing we can do to
force them.  Thus, making either security protocol MTI at this time would
have one of the following consequences:

  - it would either force a majority of our users to carry code that they
    do not use, which would fail to improve security in any significant
    way but cause further resentment against us and against the IETF; or

  - it would force a majority of the deployed implementations of Babel to
    become non-compliant, with no improvement security but with
    a resulting dilution of the authority of the IETF.

Either outcome would fail to improve security in any meaningul way, while
being bad for us, bad for our users, and bad for the reputation of the
IETF.  For this reason, we respectfully request that this document should
be allowed to advance without either protocol being marked mandatory to
implement.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

> I support Suresh's DISCUSS.

I have tried to answer it.

> An explanation of why this document obsoletes RFC 6126 and RFC 7557 needs to
> appear in the introduction of this document.

Could you please give me an example of suitable text?

> Section 3.2.3: It's a bit odd that the Multicast Hello is introduced here but
> the difference between the two kinds of hellos is not explained until Section
> 3.4.1. It makes me wonder if 3.2 should come after 3.4.

Section 3.2 defines the (conceptual) data structures.  The reset of
Section 3 describes how they are used.  There are many more instances of
data structures that are defined in Section 3.2 and not used until later.

> Section 3.6: s/is not left-distributive Section 3.5.2/is not left-distributive
> (Section 3.5.2)/

Fixed.

> Appendix C: This section should be in the body of the document.

(This is now Appendix D.)

This is an informative section, and is of no interest to implementers of
the base protocol.  I believe it should remain an appendix.

-- Juliusz