Subject: [babel] Opinions wanted: Babel over DTLS ports

From: David Schinazi <[email-masked]>
Date: Sat, 07 Jul 2018 09:54:55 -0700

Hi everyone,

One of the Babel over DTLS questions we haven't answered yet is UDP port numbers.
https://tools.ietf.org/html/draft-decimo-babel-dtls-01#section-3

We have two options:

1) run Babel over DTLS on the same port as regular Babel

This means all Babel over DTLS packets use UDP source and destination ports both equal to 6696.
Implementations need to differentiate between regular Babel and DTLS on reception.
The downside is that it significantly increases implementation complexity when your TLS stack creates its own sockets.
Additionally, this complicates the DTLS stack as it now needs to handle multiple concurrent connections on the same five-tuple,
which is something most DTLS stacks do not support today (RFC 6347 section 4.2.8).

2) run Babel over DTLS on a separate port

This means regular Babel packets are sent on 6696 and DTLS is run as a server on a new port and as client on ephemeral ports.
This simplifies parsing since the UDP port dictates how to parse the packet.
This would match how HNCP works.
The downside is that it would require administrators that have firewall rules that allow 6696 to also open the new port.

Do people have opinions one way or the other?

I’ll be presenting this question in Montreal as well.

Thanks,
David

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Jul 2018 13:45:30 -0400

I think the firewall issue isn't important because there shouldn't be a
firewall within a babel routing domain; if there is, the extra work of
managing the holes punched for Babel isn't too bad.   It would be nice if
people started implementing PCP anyway.

On Sat, Jul 7, 2018 at 12:54 PM, David Schinazi <[email-masked]> wrote:

> The downside is that it significantly increases implementation complexity
> when your TLS stack creates its own sockets.
> Additionally, this complicates the DTLS stack as it now needs to handle
> multiple concurrent connections on the same five-tuple,
> This means regular Babel packets are sent on 6696 and DTLS is run as a
> server on a new port and as client on ephemeral ports.
> The downside is that it would require administrators that have firewall
> rules that allow 6696 to also open the new port.
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Jul 2018 00:35:01 +0200

> https://tools.ietf.org/html/draft-decimo-babel-dtls-01#section-3

I think that implementation complexity is about the same.  Using different
ports requires opening an extra socket, but that's a small cost (just
a slight complication to your main event loop, and slightly more complex
error handling in case one of the binds fails).  It might be slightly
easier to hook your DTLS library if you use a different port, but we
haven't found that to be a significant problem.

Using different ports might cause packet reordering (since you're using
different sockets).  That is not likely to be a big deal, since we only
send Hellos and IHUs on the unencrypted socket, and since Babel is fairly
resistant to packet reordering.  It might cause trouble with extensions
that are sensitive to packet reordering -- for now, HMAC is the only such
extension.

I have a slight preference for using a single port.  David prefers the two
port solution, I believe, since he wants to hook as high up as possible
into his DTLS library.  Antonin would appear to agree with David, but he's
afraid to tell me clearly ;-)

I think the policy of listening to people with an implementation more than
people without one has served us well.  David, what's the state of your
implementation?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 11 Jul 2018 16:05:04 -0700

> On Jul 11, 2018, at 15:35, Juliusz Chroboczek <[email-masked]> wrote:
> 

If I understand you correctly, this would only cause packet reordering
between multicast and unicast (as in all unicast is ordered, and all
multicast is ordered, but multicast 1 might arrive after unicast 2).

For HMAC specifically, this could be solved by using a different index
for unicast and multicast - but that would require receivers to keep
track of multiple indices. And that complexity's probably not worth it
because you don't need HMAC over DTLS.

I agree that this is a valid concern though - but it doesn't tip the scales for me.

> people without one has served us well.  David, what's the state of your

Our DTLS stack [1] only lets you handle DTLS above the abstraction of
a connection - you don't want to be messing with sockets. In order to
get the same port variant to work, I had to write 400 lines of Obj-C that
create UDP sockets over loopback so I can pull the encrypted packets
out from under the DTLS stack. Needless to say that's not an ideal solution.

And on the topic of implementation, have you modified the DTLS stack
you use to support multiple concurrent connections on the same port yet?
Last time we talked your implementation was trivially DoSable by sending
bad DTLS client hellos.

[1] https://developer.apple.com/documentation/network <https://developer.apple.com/documentation/network>

David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Jul 2018 01:45:37 +0200

> David, what's the state of your implementation?

Are you saying you've implemented both variants already?  If so, that
gives you 100XP, double damage when using a melee weapon, and slightly
faster recovery of mana.

> out from under the DTLS stack. Needless to say that's not an ideal solution.

I sympathise, that's pretty nasty.  I'd argue it's a limitation of the
DTLS stack, though, and one that will come back to bite you in the future.
Say, when somebody wants to use DTLS over DCCP, or use DTLS with UDP-Lite
and only protect part of the packet.

I think you should go explain the issue to your DTLS guys, and see what
they say.

> And on the topic of implementation, have you modified the DTLS stack you
> use to support multiple concurrent connections on the same port yet?

I don't think it requires any changes to the DTLS stack, but I agree that
that needs checking.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Wed, 11 Jul 2018 14:21:07 -1000

Just as a side note, I used to make test versions of babel run over
udplite. That way it shared the same port number and it was obvious what
routers were running the newer code. Udplite seems rarely disabled, in the
Linux world at least, one line to firewall, and... a lot easier than
getting another port number out of iana.