Re: [babel] Updated 6126bis

[Juliusz Chroboczek <[e-mail]>]

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

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