Re: [Ilc] Welcome to the ILC list

[Kyle Rose <[e-mail]>]

What problem class were you thinking of? If (relative to the other thread
from this morning) we wanted internet-level consensus on a voluntary basis,
such that different entities could join different consortia for determining
consensus, what classes of problems require this consensus to be real-time
and automated as opposed to scheduled ("On this date...") or determined
top-down (admin configures things directly)?

One of the examples I've brought up with Mirja, Brian, and Stephen in
discussions on PLUS was around dynamically disabling the acceptance of
hijacked or squatted code points, option numbers, etc., if they've been
hijacked for nefarious purposes. One of the critical privacy issues with
extensible protocols is that they provide hooks that can be hijacked by
nation-states and others for purposes of user tracking with the property
that this information survives end-to-end over the general internet.
Without these hooks, nation-states are forced to add or remove this
information at the borders of their own networks, an operation that is
infrastructure-heavy, and is at least likely to run into compatibility
problems with commodity hardware, raising costs for their own users. The
downside for internet users is that without these hooks the protocols are
less able to evolve without wholesale replacement.

It also turns out to be really hard to define a protocol with no available
space for squatters. A single bit can be misused, and designing a protocol
without any subliminal channels is very difficult, and again would probably
result in protocols that can't be extended to meet the needs of new
applications or of constantly-evolving network technologies.

What if we could produce extensible protocols but provide a mechanism for
disabling arbitrary subsets of that protocol based on abuse by network
actors? E.g., if some nation-state starts squatting on a TCP option,
inserting user identifying information into the payload, what if the
internet community at large had the ability to reconfigure all (or a
critical mass of) devices to drop all packets with that option? In some
sense this is kind of a big red button for the internet: it's a mechanism
that might never need to be used because the mere threat of a network
partition could be sufficient to prevent this kind of thing.

The problem with something like a machine-readable registry at a predefined
URL is that it can be hijacked by said nation-states and reconfigured to
suit their whims. But (at least my Rorschach test-conception of) ILC would
be a lot harder to hijack. The consensus could even just be for the URL of
the object describing the protocol restrictions.

I imagine something like this could also be used for evil, but nothing is
currently stopping network operators from doing bad things on their own,
and of course individual device configuration would still be subject to the
desires of the owner and of governments with jurisdiction, just as today.

Kyle


On Mon, Feb 13, 2017 at 3:24 PM, <[e-mail]> wrote:

> Thanks for subscribing to the Internet-level consensus mailing list.
> Now that we've got 50+ people on the mailing list, let's start the
> discussion.
>
> Consensus is the task of a agreeing on a particular value among
> multiple valid inputs in a distributed system.  This problem is at the
> heart of fault-tolerant replication and distributed transaction
> processing.
>
> An Internet-level consensus mechanism is one that accommodates the
> decentralized nature of the Internet to agree on values without
> relying on a centralized authority for configuration.  Specifically,
> the goal is to achieve consensus in settings where there may be
> Internet-wide benefit from agreement, yet the security concerns of
> participants and the multi-national nature of the network preclude any
> globally-acceptable consortium in which to concentrate trust.
>
> We created this mailing list on the hypothesis that there's an unmet
> need for this kind of Internet-level consensus.  So if you have
> applications for such a technology, please speak up.
>
> Other good questions to discuss:  What kind of properties do you think
> Internet-level consensus should have?  What is the best form for an IETF
> contribution in the area (i.e., a single global service, vs. a protocol
> with many instances)?  Are there enhancements/improvements to other
> Internet technologies that would make it easier or more efficient to
> achieve consensus?  And finally, of course, what other questions would
> you like to see discussed on the list?
>
> David
>
> _______________________________________________
> Ilc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ilc
>