Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

Hi Mirja,

Negotiated parameters are generally less robust than hard-coded ones
because they open us up to state mismatch bugs.

That said, I'm not certain we want to redesign protocol fundamentals in
this review thread. You had previously asked us
to investigate the feasibility of not having an assigned port within the
working group. The authors took that advice and
brought the discussion to the working group:
https://mailarchive.ietf.org/arch/msg/babel/Mo4wxCQbgcNK8rPcKuNvOqxCopU
The outcome of that discussion appeared to be clear consensus on requesting
another port.

I understand your rationale for pushing back on port allocations, and I'm
glad we had a conversation about alternatives,
but the discussion of pros and cons lead us to the conclusion that a second
port will improve the protocol's chances of success.

Thanks,
David



On Thu, Aug 8, 2019 at 4:45 AM Mirja Kuehlewind <[e-mail]> wrote:

>
>
> > On 8. Aug 2019, at 13:17, Juliusz Chroboczek <[e-mail]> wrote:
> >
> >>> Using an ephemeral port that is discovered at runtime would add a
> failure mode
> >>> to the protocol and make it less robust.
> >
> >> Can you please explain why that would make it less robust? I would
> >> actually think that is would make it more robust. In any case you need
> >> to somehow discovery the neighbour. Usually the babel HELLO would be
> >> used for that. When you add an new TLV to that HELLO that indicates
> >> a port that should be used for DTLS, this also gives you and additional
> >> indication that the peer sending the hello actually supports DTLS which
> >> I believe would make it more robust.
> >
> > That's an intruiguing idea.
> >
> >> Further with respect to security and topics probably recently
> discussed, not having a default port would make it harder for an attacker
> to flood a route with DTLS handshakes on that port.
> >
> > Could you please explain what happens if an attacker sends out 65535
> > spoofed multicast Hellos indicating 65535 distinct ports?
>
> You maybe rate limit DTLS connection attempts…? I didn’t fully design the
> protocol here but would like the wg to consider such an approach. However,
> I guess it might make sense to even rate limit in the proposed approach, or
> cache for a certain time that a connection attempt to a certain peer failed
> before trying again.
>
> Mirja
>
>
> >
> > -- Juliusz
> >
> >
>
>