Subject: [babel] Updated 6126bis

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 21 Aug 2017 22:36:33 +0200

Dear all,

I've just spent much of the last two days going linearly through 6126bis
and doing my best to fix the language and make minor clarifications.  I've
also updated the Security and IANA Considerations sections.  I haven't
uploaded the document yet, it's on github for now.

The plan is to sleep over it, then submit -04 within a few days, then ask
the respectable Working Group for Last Call.  Speak now, of forever hold
your peace.

Donald, I'd be grateful if you could look through the IANA Considerations
section and let me know if it is okay for IANA.  You'll find it here:

  https://github.com/jech/babel-drafts/commit/2785aa86c1fbee113d82dc4695a628b466d08a46

David, I've tried my best to express the fact that sending/receiving
Multicast Hellos is strongly recommended, and that Unicast is optional.
Please review my work.

Everyone, please check the wording of the Security Considerations.  I'm
not good at Security.

Everyone, please read through the document, and complain if it's not
perfect in all ways.

Thanks,

-- Juliusz

---

From: Matthieu Boutier <[email-masked]>
Date: Tue, 22 Aug 2017 14:44:11 +0200

Some previous comments (see [1]):

  The current 6126bis draft is sometimes using (prefix, plen)
  and sometimes (prefix).

  The draft has inconsistent index ordering.

  The draft use sometimes "route table", and sometimes "routing
  table".

And a question: in IANA considerations, why re-specifying Pad1
and PadN, and not the other TLVs values, while saying "The values
in this registry are not changed by this specification."?

Matthieu

[1] https://www.ietf.org/mail-archive/web/babel/current/msg00852.html

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 22 Aug 2017 16:40:56 +0200

>   The current 6126bis draft is sometimes using (prefix, plen)

The intent is that formal text (e.g. data structures) uses "(prefix,
plen)", while "the prefix" is allowable in prose.  I'll do a pass to
make it uniform.

>   The draft has inconsistent index ordering.

Yeah.  Not a big deal, but I'll make a pass.

>   The draft use sometimes "route table", and sometimes "routing

I'll check.

> in this registry are not changed by this specification."?

Because Pad1 and PadN were specificied in 6126, which this document
updates, so the reference in the IANA registry needs to change, while the
others were specified in other documents, so the reference doesn't need to
change.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 22 Aug 2017 16:24:44 -0400

Hi Juliusz,

>   https://github.com/jech/babel-drafts/commit/2785aa86c1fbee113d82dc4695a628b466d08a46

My suggestions on the IANA Considerations Section:

- I think it would fit better with the way these sorts of things are
usually written to add two line to the "Babel sub-TLV Types" registry:
    4-111  Available for non-mandatory sub-TLV types
and
    128-239  Available for mandatory sub-TLV types
or something like that.

- Add a sentence saying "replace all references to [RFC6126] and
[RFC7557] with references to [this document].

> Everyone, please check the wording of the Security Considerations.  I'm

I suggest dropping the reference to IKEv2 which I don't think is
normally used as a method of securing general unicast traffic.

> Everyone, please read through the document, and complain if it's not

Does this document really, as you stated in your reply to Matthieu,
update RFC 6126? I think that it probably, in IETF terminology,
obsoletes both RFC 6126 and RFC 7557. So an "Obsoletes: 6126, 7557"
line should be added at the top left of the title page.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Thanks,
>
> -- Juliusz
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Margaret Cullen <[email-masked]>
Date: Tue, 22 Aug 2017 17:04:51 -0400

Hi Juliusz,

In general, the new version of the draft looks good to me.  I do have a few comments/questions on the Security Considerations section, though, marked with mrc>>, inline below.

Margaret

========

Security Considerations

As defined in this document, Babel is a completely insecure protocol.
Any attacker can attract data traffic by advertising routes with a low

mrc>>  “attract” => “attract or misdirect”?

metric or a high seqno.  This issue can be solved either by a lower-layer
security mechanisms (e.g. link-layer security), or by deploying a suitable
authentication mechanism within Babel itself.  With the exception of Hello
TLVs used for discovery, Babel control traffic can be carried over
unicast, which makes it possible to protect Babel traffic with a protocol
that can only protect unicast data, for example IKEv2 or DTLS.

mrc>>  I would say “IPsec” or “IPsec/IKEv2" instead of just “IKEv2”.  IKE is a key exchange protocol, but IPsec provides the actual authentication and encryption.  Also, you need 
to expand the acronyms and add informative references for these protocols.

mrc>> Do you think that we should say something in this section about how an attacker who can redirect traffic can perform an on-path attack from a location that would not normally be on-path for a given connection?

The information that a Babel node announces to the whole routing domain
is often sufficient to determine a mobile node's physical location with
reasonable precision.  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.

mrc>> I understand how the information passed in Babel could allow you to pinpoint a node’s topological location, but not it’s physical location.  Therefore, I am not sure how using randomly chosen IPs and addresses would alleviate that risk.  Could you offer a bit more explanation? 

When carried over IPv6, Babel packets are ignored unless they are sent
from a link-local IPv6 address; since routers don't forward link-local IPv6
packets, this provides protection against spoofed Babel packets being sent
from the global Internet.  No such natural protection exists when Babel
packets are carried over IPv4.

mrc>> It is possible to get similar protection by specifying that IPv4 packets are sent with a TTL of 1.  Is there a reason not to do that?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 23 Aug 2017 14:51:09 +0200

mrc> “attract” => “attract or misdirect”?

Yes, that's better.  I've put just "misdirect".

mrc> I would say “IPsec” or “IPsec/IKEv2" instead of just “IKEv2”.  IKE is
mrc> a key exchange protocol, but IPsec provides the actual authentication
mrc> and encryption.  Also, you need to expand the acronyms and add
mrc> informative references for these protocols.

Will do.  (The point here is that it's IKEv2 that is limited to unicast,
there's nothing in IPsec itself that prevents it from being used with
multicast.)

mrc> Do you think that we should say something in this section about how
mrc> an attacker who can redirect traffic can perform an on-path attack
mrc> from a location that would not normally be on-path for a given
mrc> connection?

Will do.

mrc> I understand how the information passed in Babel could allow you to
mrc> pinpoint a node’s topological location, but not it’s physical
mrc> location.  Therefore, I am not sure how using randomly chosen IPs and
mrc> addresses would alleviate that risk.  Could you offer a bit more
mrc> explanation?

I'll see if I can make it concise enough, but I think I won't bother.
(The point is that an attacker might know the location of fixed Babel
nodes, and therefore a node that advertises routes with a low metric is
advertising its topological proximity to a set of fixed nodes.  In
wireless networks, topological proximity coincides to some extent with
physical proximity, so you can find out where a mobile node is.)

> packets are carried over IPv4.

mrc> It is possible to get similar protection by specifying that IPv4
mrc> packets are sent with a TTL of 1.  Is there a reason not to do that?

We already do:

  A Babel packet is sent as the body of a UDP datagram, with network-layer
  hop count set to 1

However, if an attacker knows that he's 3 hops away, he can send a packet
with a hop count of 3, which will appear to the receiver as having a hop
count of 1.

The standard workaround, used e.g. in neighbour discovery, is to send
packets with a hop count of 255, and discard any packets that are received
with a lower hop count (this is known as the "TTL hack" among the hip
crowd).  However, the consequence of the TTL hack is that a misdirected
packet will cruise the network for 255 hops; and therefore neither OSPF
nor RIP use it (I think BGP uses it, but I'm not sure).  Thus, I didn't
mandate the TTL hack in Babel, and I think it's too late to change.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 23 Aug 2017 15:05:24 +0200

>     128-239  Available for mandatory sub-TLV types

Does that not contradict the statement that existing assignments in the
4-111 range are preserved?  I'll think how to formulate it.

> [RFC7557] with references to [this document].

Right.

> normally used as a method of securing general unicast traffic.

David?  Can you patch that section?

> line should be added at the top left of the title page.

Right.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Aug 2017 22:24:25 -0700

Juliusz,

Thanks for making these changes, I thing they improve the document.

A few comments:

- minor: I prefer "route table" instead of "routing table" as the latter evokes the kernel's routing table to me, but I don't feel too strongly about it
- minor: why use the British spelling for neighbour and the American one for acknowledgment? (again don't have strong feelings)
- <<it checks whether it already has a routing table entry indexed by (prefix, plen).
If no such entry exists: [...] otherwise, a new routing table entry is created, indexed by (prefix, plen, neigh)>>
contradicts itself - if my understanding is correct, this should be (prefix, plen, neigh) for both.
- I don't think buffering TLVs to prevent jitter needs to be a MUST instead of a SHOULD
- I think the IANA Considerations section should contain the list of all known values (TLVs, sub-TLVs, flags) at this time and a link to the IANA website for updates
- in security considerations I think IKEv2 should be replaced by IPsec, as that's what protects packets
- While I agree that my appendix about unicast hellos needed work, I think we shouldn't remove all guidance entirely, there's value in discussing rationale and pros/cons.

David

> On Aug 21, 2017, at 13:36, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 Aug 2017 16:08:43 -0400

Hi Juliusz,

> 4-111 range are preserved?  I'll think how to formulate it.

Assuming the ranges are correct in my suggested text, there would be
no contradiction :-)

I guess, what's actually going on is the replacement of the existing
"4-223 Unassigned" and "224-254 Reserver for Experimental Use" lines.
It should be possible to figure out exactly what the new lines should
be if we have a reasonable idea what order drafts will be approved.
And if we are wrong, I think it will be possible to adjust the IANA
Considerations wording later in the process.

Alternatively, you could try to construct a much more complex
directive to IANA on how to change the registry that tried to take
into account all plausible circumstances that might occur, but I don't
think it would be worth the effort.

Thanks,
Donald

> ...