Re: [Ilc] Welcome to the ILC list

Kyle Rose <> Thu, 16 February 2017 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B7DD12969B for <>; Thu, 16 Feb 2017 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AHfXteV38zZn for <>; Thu, 16 Feb 2017 10:23:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD50B129691 for <>; Thu, 16 Feb 2017 10:23:18 -0800 (PST)
Received: by with SMTP id u25so23499550qki.2 for <>; Thu, 16 Feb 2017 10:23:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mf7uFXfEov5fbc3e3r2dvPlH2fWpiK41meDv3UPjLb4=; b=YooRS65BEBqoE+4lIBRNyLRdEzPtihc2c56FIL60Wf4z3NtCPIooJF9dndFR7WVEEk 6sZi42rY56yRTeQx+xgtCumaJSLpr7goUZNM3eH0dxhKCDCdQ8bKOhu4rh+fwiBSs7fG oHCCYEx7w8gYdyGLBeKubtz4rz0vWc6i86V1I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mf7uFXfEov5fbc3e3r2dvPlH2fWpiK41meDv3UPjLb4=; b=CgXy/0q3xLtIz0apxpqtpzy7+AQBmNW9exD8tUiNRqvGjfAPDI7E8lBin31AhwUe7A vnb3JhBYHMlFs990Rkdq57/q6PaKdPyhhz53t0s9ijk4T6Hhzmrg6LGsoK46YGFbkvq7 XzAayLze7NzzjeGhOTWbROrj3Sf0FiDRFF34qtO0j5mDRB/ON5q4n/16p9sFLt7qhW/k aWvLH095oEsFd5i65MWBSemETd25Yf2w6IcL5t5BMpZcXZsvC3nAhtfR/W/bjxBk0loO VDGNJOqt8C5L8385Anxo+MQyx4J933YCGZ/lyGLThSGTr4RI2qrhaCLExXV0z00VdWZr meRw==
X-Gm-Message-State: AMke39l4oopkt06TPkC4lxV6lif82Rj/ToEE7LVc5WttLojJXHJwgz7pk7lsZGC3txncwhqeFw/77wMSVnvk0A==
X-Received: by with SMTP id l23mr3264761qki.247.1487269397587; Thu, 16 Feb 2017 10:23:17 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Feb 2017 10:23:17 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Kyle Rose <>
Date: Thu, 16 Feb 2017 13:23:17 -0500
Message-ID: <>
To: David Mazieres expires 2017-05-14 PDT <>
Content-Type: multipart/alternative; boundary=001a1149cdc6212e820548a9e47d
Archived-At: <>
Subject: Re: [Ilc] Welcome to the ILC list
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 18:23:39 -0000

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.


On Mon, Feb 13, 2017 at 3:24 PM, <> 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