Thanks for the feedback Thomas! Responses inline. On Wed, Nov 7, 2018 at 8:30 PM Fossati, Thomas (Nokia - GB/Cambridge) < thomas.foss...@nokia.com> wrote:
> One high level thing which I can't extrapolate from the draft (which is > probably due to my ignorance with Babel) is whether you envisage that > *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes > are excluded from the mesh? Or would it be acceptable to mesh HMAC and > DTLS neighbours? What about clear-text speakers? (It'd seem unwise to > let them in an otherwise secured enclave.) > The main use-case would be that the entire mesh runs over DTLS and cleartext nodes are excluded. However, if a deployment has specific properties, one could configure this per-interface: a router could require DTLS over the Wi-Fi interface but allow non-DTLS on the secure VPN interface. That would allow cleartext speakers over VPN into the DTLS-secured enclave, but that should only be used by someone who wants that property. I've added a subsection. > You should probably provide some guidance about the kind of > credentials do you plan to use (certs, raw pkeys)? > We actually don't currently have guidance to give, as it might depend on the use-case. For example, there will be a document specifying how HOMENET uses Babel over DTLS, and I suspect that document will provide very specific guidance on what credentials to use and how they are provisioned. > It seems to me that the P2P nature of the protocol requires mutual > authentication, could you confirm it? This seems to be a critical thing > to prevent a rogue node to spoof the lowest (highest, I have already > forgot, sorry) L-L address in a clear-text multicast Hello and bypass > authentication. > Absolutely, this requires mutual authentication, I'll add a specific note to the draft. > - s2.1 > "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." > > Maybe you could suggest using a sufficiently entropic connection id here > as a more robust alternative. > Good point, I added text. > - s2.5 > Not sure what the ceremonies around flushing a neighbor are, but I'd > make explicit signalling EOD at least a SHOULD? It seems more polite > :-) > I agree, I upgraded politeness to a SHOULD. > - s.3 > Not sure which TLS stack Babel nodes will use (are you targeting > extremely constrained devices with custom TLS implementations?), but all > the stacks I know of let the application set the MTU and take care of > splitting the messages in MTU sized chunks transparently. > The goal is for this to work on general-purpose stacks as well as embedded ones. Since Babel datagrams are comprised of a sequence of TLVs, it's best to fragment at the Babel layer because that way a single fragment is still parseable in the presence of packet loss. I added text to clarify this.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
