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

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Thu, 08 Aug 2019 06:06:02 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-babel-rfc6126bis-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's DISCUSS. 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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Suresh's DISCUSS.

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

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.6: s/is not left-distributive Section 3.5.2/is not left-distributive
(Section 3.5.2)/

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 10 Aug 2019 04:35:26 +0200

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.

> I support Suresh's DISCUSS.

I have tried to answer it.

> appear in the introduction of this document.

Could you please give me an example of suitable text?

> 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

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