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

[Juliusz Chroboczek <[e-mail]>]

Dear Roman,

Thank your for your review.

> (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?

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

> -- Note that because Babel messages aren’t encrypted any on-path attacker can
> 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.)

> (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.

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.

> (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?

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
> non-normative.

This appendix has been removed.

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

> (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.

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

This section has been removed.

> (12) Section 4.  Per “Both the source and destination UDP port are set to a
> 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.

> (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?

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.

> (16) Appendix D: Per “Nonetheless, in some very constrained environments, such
> 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
> Protocol v2” (as this is a distinct and new protocol)?

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