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

[Mirja Kuehlewind <[e-mail]>]

Hi David,

Please see below.

> On 7. Aug 2019, at 20:09, David Schinazi <[e-mail]> wrote:
> 
> Hello Mirja, and thank you for your review.
> 
> (1) Discuss - port number
> 
> Using an ephemeral port that is discovered at runtime would add a failure mode
> to the protocol and make it less robust. Implementors in the working group
> felt strongly that a separate port is simpler, safer and more reliable.

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.

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. I think that’s an additional benefit that should be seriously considered.

Was this specific proposal discussed in the working group?

> 
> (2) Comment on IPv4/IPv6
> 
> Thanks for catching this! We've allowed IPv4 in this commit:
> https://github.com/jech/babel-drafts/commit/335e3edf06ac58853e33475e32f2d452022e04e0
> It'll be included in the next revision of the draft.

Thanks!

Mirja

> 
> Thanks,
> David
> 
> 
> On Wed, Aug 7, 2019 at 5:40 AM Mirja Kühlewind via Datatracker <[e-mail]> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-babel-dtls-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Unfortunately I need to discuss the port request again.
> 
> First of all I would like to comment on the shepherd write-up which says:
> "The document requires only the allocation of a port number for Babel
> over DTLS. Having such a second port for the secured version of a
> protocol is a fairly common practice. This is shown in the IANA
> Considerations section."
> This is not correct. Having a second port for the secured version of a protocol
> WAS common practice. However RFC6335 say now "The use of separate
>    service name or port number assignments for secure and insecure
>    variants of the same service is to be avoided in order to discourage
>    the deployment of insecure services."
> 
> Anyway, in this case I understand that a different port is desired because
> unencrypted HELLO messages are still received over the default babel port.
> However, it is not clear to me why a fixed/default port is needed. The
> neighbour needs to be discovered in some why, no matter what, before a DTLS
> connection can be established and this discovery procedure could indicate a
> dynamic port number that the peer is listening on for babel over DTLS. E.g. the
> multicast HELLO could have a new TLV with this port information. Please clarify
> why this option is not suitable! Thanks!
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This specification seems to only support babel over DTLS for IPv6. This should
> be stated clearly in the introduction.
> 
>