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

[David Schinazi <[e-mail]>]

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.

(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,
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.
>
>
>