<div dir="ltr">Hi Dave,<div><br></div><div>The Babel over DTLS spec states that</div><div>- unicast traffic is sent over DTLS, where DTLS client uses an ephemeral port, and DTLS server uses a well-known port different from 6696</div><div>- multicast traffic still uses 6696 for source and destination</div><div><br></div><div>I don't see any issues with protecting Hellos with HMAC and everything else with DTLS.</div><div><br></div><div>David</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 1:56 PM Dave Taht <<a href="mailto:dave@taht.net">dave@taht.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Have I been enough of a PITA this month?<br>
<br>
Section 4 of rfc6126bis-07 states:<br>
<br>
Both the source and destination UDP port are set to a well-known port<br>
number. A Babel packet MUST be silently ignored unless its source<br>
address is either a link-local IPv6 address or an IPv4 address<br>
belonging to the local network, and its source port is the well-known<br>
Babel port.<br>
<br>
Aside from the fact that all versions of babel prior to now enforced<br>
this requirement that the source and destination port numbers be the<br>
same, which is a major consideration, that idea leaked into the hmac<br>
implementation which does a:<br>
<br>
DO_HTONS(&port, (unsigned short)protocol_port);<br>
if ((err = blake2s_init_key(&S, key->len, key->value, BLAKE2S_DIGEST_LENGTH)) < 0) goto fail;<br>
/* Hash the pseudo header. */<br>
if ((err = blake2s_update(&S, src, 16)) < 0) goto fail;<br>
if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;<br>
^^^^^<br>
if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail;<br>
if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;<br>
^^^^<br>
<br>
the DTLS branch, on the other hand, mandates that ephemeral ports be<br>
used for DTLS communications. Section 2.1 of<br>
<a href="https://tools.ietf.org/html/draft-ietf-babel-dtls-02" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-ietf-babel-dtls-02</a><br>
<br>
The node acting as DTLS client initiates its DTLS connection from an<br>
ephemeral UDP port. Nodes SHOULD ensure that new client DTLS<br>
connections use different ephemeral ports from recently used<br>
connections to allow servers to differentiate between the new and old<br>
DTLS connections.<br>
<br>
The rub, here, ultimately, is that I could see HMAC being used to<br>
protect multicast and DTLS used to protect unicast, in which case,<br>
allowing for ephemeral src ports generally in the bis version<br>
would be helpful. I do not see how requiring a fixed src port helps<br>
anything? (besides backward compatability)<br>
<br>
Selfishly, I have to admit, that by using an ephemeral udp port for<br>
route transfers and a different, either ephemeral or 6696 for hello/ihu<br>
- fq_codel automagically distinguishes between these two very different<br>
types of traffic and in congested network conditions will drop routes<br>
far more often than hellos.<br>
<br>
A backwards compatible mechanism would be to try hellos/ihus from an<br>
ephemeral port and note when you don't get one back, upon starting an<br>
association. A key indicator to other routers no longer respecting the<br>
fixed src port rule would be recieving such.<br>
<br>
...<br>
<br>
As a side note, I had suggested using UDP-lite for development purposes<br>
or dtls communications. It's easier to use a different protocol than it<br>
is to get a new port number out of iana...<br>
<br>
I was queried as to why udp-lite, and my answer that I never got around<br>
to saying was that once you have an HMAC, you don't need a CRC, and<br>
also, to my knowledge, udp-lite is very widely deployed, just not used.<br>
It is the same in all other respects to udp. On a single hop over ipv6,<br>
udp-lite "just works" on the versions of linux and bsd I've tried over<br>
the past 5 years. It's impossible to compile out in linux (although<br>
netfilter support for it can be), for example.<br>
<br>
_______________________________________________<br>
Babel-users mailing list<br>
<a href="mailto:Babel-users@alioth-lists.debian.net" target="_blank">Babel-users@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users</a></blockquote></div>