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