Subject: [babel] Éric Vyncke's Discuss on draft-ietf-babel-applicability-07: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 04:36:22 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-applicability-07: 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-applicability/

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

Julius,

Thank you for the work put into this document. I have one DISCUSS and a couple
of COMMENTs.

One generic comment: is there a need to describe (even in a short format) Babel
again?

Regards,

-éric

== DISCUSS ==

-- Section 2.2 --

The 'bug resistance' property of Babel was perhaps learned during the
implementation, but, I wonder whether the document may simply state 'robust
with respect to bugs', this is quite a strong statement that needs to be backed
by facts or proof.

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

== COMMENTS ==

The title of the document is about 'applicability'; but, should it also include
'use cases' in the title ?

-- Section 3.1 --

The 2nd paragraph is too dense: should explain why Babel is a good fit.

-- Section 5 --

Comparison between HMAC & DTLS variants is probably irrelevant in this
document. Though, a use case with security in mind would be benefitial.

Also, the comparison should include all aspects including confidentiality and
anti-reply for both HMAC & DTLS.

== NITS ==

-- Section 2.2 --

As I am not a native English speaker, I wonder whether 'light' should not be
preferred to 'weak' in "These weak requirements make Babel a robust protocol"

-- Section 3.1 --

Suggest to change the section name into "Diverse networks" or "heterogenous
networks".

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 05 Aug 2019 14:51:02 +0200

Dear Eric,

Thanks for your review.

> with respect to bugs', this is quite a strong statement that needs to be backed

Would you be satisfied if I added the following paragraph?  Or would you
prefer some other resolution?

  For example, an early version of the reference implementation would very
  occasionally corrupt the contents of its receive buffer.  With high
  probability, the bug would corrupt the destination address of an IPv6
  host route, which would cause a spurious "martian" route to be announced
  to the network and then silently time out, with no ill effects.

(For the sake of old times, I'll recall that I was the guilty party, and
that the bug was fixed by Grégoire Henry and Julien Cristau who spent
almost a whole night observing a Babel node.  They weren't pleased.)

> The title of the document is about 'applicability'; but, should it also
> include 'use cases' in the title ?

I prefer shorter titles, but I don't feel strongly either way.  Perhaps
the list can chime in?

> Section 3.1

> The 2nd paragraph is too dense: should explain why Babel is a good fit.

Agreed, I'll reword.

> document. Though, a use case with security in mind would be benefitial.

There are no known use cases.  Our users run Babel over secure link
layers, and nobody has requested security mechanisms embedded within the
protocol.  The security mechanisms were designed solely in order to
satisfy IETF requirements.  (To be fair, it was a lot of fun.)

> anti-reply for both HMAC & DTLS.

The document currently says:

   Babel-HMAC [HMAC] is a simple and easy to implement mechanism that
   only guarantees authenticity and integrity of the routing traffic,
   and only supports symmetric keying with a small number of keys
   (typically just one or two), but is invulnerable to replay even in
   the absence of persistent state.  Babel-DTLS [DTLS] is a more complex
   mechanism, that requires some minor changes to be made to a typical
   Babel implementation and depends on a DTLS stack being available, but
   inherits all of the features of DTLS, notably confidentiality and the
   ability to use asymmetric keys.

Please let me know if you feel that this paragraph needs to be expanded or
otherwise reworded, and, if so, in what way.

Thanks again,

-- Juliusz

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 5 Aug 2019 13:07:01 +0000

About my DISCUSS, the explanatory text is good but it is 'just an explanation' and not a proven property of Babel. If you remove the 'robust wrt bugs' from the list below the assertation of protocol robustness then I will be satisfied and will remove the DISCUSS. Simply add the text below the enumeration bullets and starts with "Experience gained in implementation interoperation testing shows that ....".

For the text about security, what about something like:
"     Babel-HMAC [HMAC] is a simple and easy to implement mechanism that
       only guarantees authenticity, integrity, and anti-replay of the routing traffic,
       and only supports symmetric keying with a small number of keys
       (typically just one or two).  Babel-DTLS [DTLS] is a more complex
       mechanism, that requires some minor changes to be made to a typical
       Babel implementation and depends on a DTLS stack being available, but
       inherits all of the features of DTLS, notably authenticity, integrity,  confidentiality, and the
       ability to use asymmetric keys.
"   (unsure about anti-replay of DTLS though)

-éric

On 05/08/2019, 14:51, "Juliusz Chroboczek" <[email-masked]> wrote:

    Dear Eric,
    
    Thanks for your review.

    

    

    

    Agreed, I'll reword.

    

    

    Thanks again,
    
    -- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 05 Aug 2019 17:06:16 +0200

> About my DISCUSS [...] Simply add the text below the enumeration bullets

Ah, I see now what you mean.  Yes, that makes perfect sense.

   In addition to the above, our implementation experience indicates
   that Babel tends to be robust with respect to bugs: more often than
   not, an implementation bug does not violate the properties on which
   Babel relies, and therefore slows down convergence or causes sub-
   optimal routing rather than causing the network to collapse.

I'll work through your remaining points and submit a -08.

-- Juliusz

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2019 00:09:18 -0500

> "   (unsure about anti-replay of DTLS though)

(see https://weeklyad.target.com/?lnk=dNav_weeklyad -- it's optional,
building off the sequence number.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2019 10:29:58 -0500

Jumping in on one narrow question...

> satisfy IETF requirements.  (To be fair, it was a lot of fun.)

How does the HOMENET usage of babel fit into this?  I would be surprised if
they were expecting secure link layers to be used inside the home, but it
does seem like the threat model for HOMENET includes hostile or compromised
devices in the home.

Thanks,

Ben

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 18:25:11 +0200

> does seem like the threat model for HOMENET includes hostile or compromised

Barbara will correct me if I'm wrong, but as far as I know, the Homenet
working group hasn't decided on a security mechanism yet.  I have heard
opinions to the effect that Homenet requires asymmetric authentication, in
which case Babel-DTLS would be necessary, but I wouldn't presume to judge
whether these opinions represent WG consensus.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 6 Aug 2019 18:13:25 +0000

Removing unnecessary participants from the discussion (I don't think its relevant to the IESG review of babel-applicability?), and adding homenet...

> > How does the HOMENET usage of babel fit into this?  I would be
> > surprised if they were expecting secure link layers to be used inside
> > the home, but it does seem like the threat model for HOMENET includes
> > hostile or compromised devices in the home.
> 

Homenet WG hasn't documented its security requirements -- for anything.
The current model for securing home networks is to secure the physical layers. 
The normal practice for dealing with compromised devices in the home is to remove or fix them when someone figures out they're compromised.
My personal (individual) opinion is it's extremely important to have tools to discover when a device is causing trouble. On-going protection against such devices (so they can be safely(?) left on the home network indefinitely and people can feel secure????) isn't important or even necessarily a good idea.

Babel-HMAC could identify anything trying to talk Babel without a key. If the compromised device has been given the keys (because the user thought it could be trusted and didn't know it was compromised), then neither HMAC nor DTLS will be of any protection.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Aug 2019 15:37:01 -0500

> Babel-HMAC could identify anything trying to talk Babel without a key. If the compromised device has been given the keys (because the user thought it could be trusted and didn't know it was comprom…

Hmm, so do you think it's possible that HOMENET could land in the "uses
secure link layers" bucket?  (It sounds like it's also possible it would
use babel-hmac or babel-dtls.)  I can readjust my expectations accordingly...

Thanks,

Ben

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Aug 2019 23:49:53 +0200

> secure link layers" bucket?

No opinion on the above.  I'll only state that HNCP supports running over
DTLS (this is implemented in hnetd, the reference implementation of HNCP).
Section 8.3 of RFC 7787 describes a distributed algorithm for
semi-autonomously choosing a set of trusted DTLS keys.

> (It sounds like it's also possibl e it would use babel-hmac or babel-dtls.)

If Homenet ends up running HNCP in a secure mode, then it could be used as
a trust anchor for Babel.  We could do either of the following:

  - use HNCP to elect a single Babel-HMAC key for the network;
  - generate random Babel-DTLS keypairs and flood the public part
    over HNCP;
  - reuse HNCP keypairs in Babel-DTLS.

Of course, if HNCP runs insecure, then it would be somewhat doubtful to
use it for key distribution.

-- Juliusz