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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 12:19:57 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

Security Considerations.  While the high level statement of Babel being “an
insecure protocol” is accurate and clear, precisely enumerating the threats is
needed to motivate the selection of the appropriate mitigations.

(1) Per “Any attacker can misdirect data traffic by advertising routes with a
low metric or a high seqno.”: -- Can the "any" of the attacker be scoped any
more?

-- Explain why this is possible – because Babel peers are not authenticated and
Babel messages aren’t integrity/replay protected

-- Discuss the impact of this misdirection: denial of service (dropping the
traffic and against a given target), eavesdropping, or allowing for the
possibility of traffic modification (depending on upper level security
mechanisms) – RFC4593 covers a number of them

-- Note that because Babel messages aren’t encrypted any on-path attacker can
gather the routing topology

(2) The rest of this paragraph describes the security properties conveyed by
link-layer security, IPSec, BABEL-HMAC and BABEL-TLS.  They all make sense. 
Please be explicit that IPSec or BABEL-TLS address all of the above described
attacks.  BABEL-HMAC addresses only somet.

(3) Per “HMAC is simpler and does not depend on DTLS, and therefore its use is
RECOMMENDED whenever both mechanisms are applicable”, can you explain this
recommendation and the circumstances where “both mechanisms are applicable”. 
If one wants to ensure confidentiality, it can’t be realized with HMAC – they
aren’t equal.

(4) Per “The privacy issues that this causes can be mitigated somewhat by using
randomly chosen router-ids and randomly chosen IP addresses, and changing them
periodically, who’s IP address should be randomly chosen the Babel node or the
mobile device?

In other sections:

(5) Appendix C: Per the last paragraph, “The packet trailer is intended to
carry cryptographic signatures …”, to what security mechanism is that
referring?  Where is that defined?

(6) Appendix D: Is the stub implementation guidance normative?  If so, will it
satisfy all of the RFC2119 language in this document?

(7) Appendix E.  Please explicitly state that the sample implementation is
non-normative.

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

(8) Section 1.1.  What is a “network diameter”?  Calculated how?

(9) Section 3.6.  Recommend avoiding the phrase “protocol’s correctness”

(10) Section 3.7.2, Per the guidance to send updates with acknowledgement
requests to a small, but not a large number of neighbors.  Is there guidance to
provide on what is a large number?

(11) Section 3.8.2.4.  Is there any guidance on what a “small number of
multicast” requests constitutes?

(12) Section 4.  Per “Both the source and destination UDP port are set to a
well-known port number”, the same one?

(13) Section 4.2.  What is the “carefully chosen” rational for the magic number
being 42 (unless this is a Hitchhikers Guide reference)?

(14) Section 4.6.4.  What are the properties needed for this nonce?

(15) Section 6. Per the concern that Babel packets might escape into the wild
and “No such natural protection exists when Babel packets are carried over
IPv4”, doesn’t setting the TTL=1 per Section 4 help?

(16) Appendix D: Per “Nonetheless, in some very constrained environments, such
as … abacuses”, what does it mean to implement Babel on an analog device?

(17) Did the WG consider renaming the title of this draft “Babel Routing
Protocol v2” (as this is a distinct and new protocol)?

(18) Editorial nits:
-- Section 1.1.  Editorial.  s/Babel never/Babel does not/

-- Section 1.2  Editorial.  s/Babel does impose/Babel imposes/

-- Section 2.  Editorial.  s/venerable RIP/RIP/

-- Section 2.3.  Editorial.  s/It is well known that a/A/

-- Section 4.1.2.  Typo.  s/ones ones/ones/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 23:01:49 +0200

Dear Roman,

Thank your for your review.

> low metric or a high seqno.”: -- Can the "any" of the attacker be scoped any

This whole discussion has been rewritten.  I believe that it now meets
most of your concerns.

> gather the routing topology

(Note that Babel is a distance-vector protocol, the full topology is not
available.  From a security point of view, this can be seen as a good or
a bad thing, depending on your perspective.)

> If one wants to ensure confidentiality, it can’t be realized with HMAC – they

Fully agreed, we must be clear on this point.

> (4) Per “The privacy issues that this causes can be mitigated somewhat
> by using randomly chosen router-ids and randomly chosen IP addresses,
> and changing them periodically, who’s IP address should be randomly
> chosen the Babel node or the mobile device?

It is assumed in this paragraph that the mobile device is a Babel node.
It makes no sense otherwise.

> referring?  Where is that defined?

Babel-HMAC is the only currently defined mechanism that uses the trailer.
If the user community ends up accepting the notion of inline security (as
opposed to using a secure link layer or DTLS), then I expect other such
mechanisms to appear.

> (6) Appendix D: Is the stub implementation guidance normative?

It's not, I've removed all normative language.

> If so, will it satisfy all of the RFC2119 language in this document?

>From the point of view of an outside observer, yes -- it cannot be
distinguished from a compliant implementation just by looking at the
packets it sends or the routes it selects.

>From the point of view of the letter of the specification, obviously not.
The specification says that you maintain a source table which you use to
evaluate the feasibility condition.  In the case of a stub implementation,
the feasibility condition is known to be always true, so the stub
implementation doesn't bother maintaining a source table.

> (7) Appendix E.  Please explicitly state that the sample implementation is

This appendix has been removed.

> (8) Section 1.1.  What is a “network diameter”?  Calculated how?

  http://mathworld.wolfram.com/GraphDiameter.html

> (9) Section 3.6.  Recommend avoiding the phrase “protocol’s correctness”

  I've replaced it with "algorithm's correctness".

> (10) Section 3.7.2, Per the guidance to send updates with
> acknowledgement requests to a small, but not a large number of
> neighbors.  Is there guidance to provide on what is a large number?

Unfortunately not.  It will depend on the relative cost of multicast
vs. unicast, and the expected packet loss.  Coming up with a suitable
algorithm to determine that dynamically would be a fun little project.

> multicast” requests constitutes?

This section has been removed.

> well-known port number”, the same one?

Yes.  That's implied by "both".

> (14) Section 4.6.4.  What are the properties needed for this nonce?

None that are defined in this specification.  The only requirement is that
it will be returned in the Ack.

If an implementation can guarantee that it has at most one ack request in
flight to a given peer, then it can clear the nonce.  If an implementation
wants multiple in-flight requests, it can use a sequential counter.  It
can also use it for some smart algorithm that encodes information about
the packet being acked in the nonce, but I cannot conceive of any such
algorithm offhand.

The choice of ack has no security implications, since spoofing a bogus
route is a much more effective way of attacking an unsecured Babel
implementation.

> IPv4”, doesn’t setting the TTL=1 per Section 4 help?

The concern here is about off-link attackers sending us packets.  It's not
too difficult to choose a TTL that leads to the TTL being 1 on reception.

That's why this document does not require checking the TTL on reception,
just the sender's address.

> as … abacuses”, what does it mean to implement Babel on an analog device?

Abacuses are digital.

> (17) Did the WG consider renaming the title of thisdraft “Babel Routing

No, we didn't, as this would only create confusion.  Both RFC 6126 and
this document use version 2 in the header; see my reply to Alvaro about
details.

(Versions 0 and 1 were early variants that have never been documented.
Version 0 was a hybrid link-state/distance-vector protocol.  Version 1 was
fairly close to the protocol in RFC 6126, but had a design flaw that
caused it to fail in the presence of parallel edges in the adjacency
multigraph.)

> (18) Editorial.  s/Babel never/Babel does not/

Disagree, this states an invariant.

> -- Section 1.2  Editorial.  s/Babel does impose/Babel imposes/

Disagree, the auxiliary is used to stress a weakness of Babel.

> -- Section 2.  Editorial.  s/venerable RIP/RIP/

Disagree, I see RIP like a distinguished gentleman with a white beard, the
kind you tend to meet at IETF meetings.

> -- Section 2.3.  Editorial.  s/It is well known that a/A/

Disagree, the subclause is used to stress that this is a standard
property, not something that we claim to have discoverd.

> -- Section 4.1.2.  Typo.  s/ones ones/ones/

Done, thanks.

-- Juliusz