Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Ted Lemon <[e-mail]>]

Wednesday, Nov 18, 2015 10:57 AM Juliusz Chroboczek wrote:
>> If you do have a reason for thinking that DTLS shouldn't be MTI, please
>> state it plainly
> 
> The mesh community has been using a wide range of techniques for
> configuring routers, static configuration, configuration protocols built
> into routing protocols, AHCP, etc.  I am currently working on promoting
> the use of a subset of HNCP instead.
> 
> This work is made difficult by the way the HNCP draft is written -- it is
> not immediately obvious that HNCP is a small and elegant protocol, and
> that most of the messy baggage is optional.  The general perception is "we
> don't need the complexity of HNCP, let's do something ad hoc".  See for
> example
> 
>   http://mid.gmane.org/[e-mail]
> 
> Adding MTI DTLS to HNCP will only make this situation worse: either HNCP
> will be ignored by the communities, or the DTLS requirement will be
> ignored.  The latter will enforce the (widely held) belief that the IETF
> is a fossilised bureaucracy more interested in following its bureaucratic
> rules than producing useful documents.  Neither is a desirable outcome.

There is a reason why IETF standards are harder than ad hoc protocols: we specify what's needed to solve the problem generally and interoperably, and try to think about the problem from a systems perspective, not from the perspective of the immediate problem we have.    Ad hoc protocols do not suffer from that constraint.

If someone's argument for why not to adopt HNCP is "it's too hard," then they are discounting the technical debt that they accumulate when they do a one-off ad hoc protocol.   Do you have any idea, for example, how much technical debt was accumulated with the simple decision many years ago to adopt dbus as the notification protocol for Linux?   That decision was made in precisely the way you describe, and the damage has been incalculable.   It barely works now, a decade later, and the idea of a "linux" desktop is a laughingstock due to this decision, among several other similar decisions made the same way.

There is a reason why the IETF seems slow.  It is because we think hard about problems, together, through a consensus process.   This definitely takes more time than just deciding to do something to solve the immediate problem.   The way the IETF competes with people who think that way is by producing protocols that actually work and are extensible, not by sinking to their level.   There are problems with the consensus process.   We sometimes get stuck in annoying ways, as with the routing discussion.  That was actually a process failure from which I hope all involved have learned (I certainly have).   The slower process is the price we pay for doing things the way we do, but please don't make the mistake of thinking that we get nothing for that price.

The bottom line is that I think the reason you have given for not making DTLS MTI is a really bad one.   There is a perfectly good DTLS implementation out there, which is quite easy to use as far as I can tell, and if people really think that they don't need to be thinking about security of network protocols in this day and age, then it's best that they fail quickly at minimal cost, and don't drag the network down with them.  I am really tired of crappy embedded network devices with no security, no upgrade path and no thought to system design.   We should not support the proliferation of such devices.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[e-mail]