Re: [babel] DTLS and handshake failure

If I understand this correctly, the only benefit of sending TLVs in the clear
is to interoperate with devices that have not been configured with the
proper authentication. However that won't work, since because they do
not have a way to authenticate, all their TLVs will be unauthenticated
so we will drop of all them (except Hellos) so we will drop their IHU,
so we will never establish bidirectional reachability.

That said, by design we do not want to interoperate with nodes that do
not have the proper authentication, so sending these TLVs in the clear
leaks information without providing benefit.

Having each Hello trigger a handshake attempt would work but can
generate useless traffic. Blacklisting the device for a given period of time
sounds like the best way to limit this traffic.

I would argue that such blacklisting is a local implementation matter,
but that it perhaps should have an upper bound such as 10 minutes to allow
a device to recover when it's provisioned with new authentication credentials.

David

> On Feb 23, 2018, at 15:49, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> This is a matter of policy, but if third party can force DTLS handshake
>> failure, switch to unauthenticated operation basically means you can
>> (potentially) always force unathenticated mode.
> 
> I'm not a specialist, but I don't think we're vulnerable.
> 
> There's two different policies: what you do on reception, and what you do
> on emission.
> 
> What you do on reception is clear: if an interface has been configured to
> requre authentication, we ignore all unauthenticated TLVs except Hellos.
> No exceptions of any kind.
> 
> The question is -- what do we send.  If the DTLS handshake succeeded, we
> send all unicast TLVs authenticated except for Hellos.  If the DTLS
> handshake failed, we can:
> 
>  - send all TLVs in clear, in case the peer is configured without auth;
>  - drop the neighbour association, which will cause the next Hello to
>    trigger a new handshake attempt;
>  - blacklist the neighbour, so that another Hello will not trigger a new
>    handshake attempt.
> 
> As far as I can tell, the three options are equivalent from a security
> perspective when all routers are configured correctly, since we still
> ignore any unauthentified TLVs.  They do differ when some routers are
> mis-configured, and they don't generate the same amount of traffic.
> 
> -- Juliusz
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel