If upsetting the hosts was a consideration then we should cancel
Beijing. But is isn't so we shouldn't.
No, the real reason not to build anti-censorship schemes into the
standards is that it is doomed to failure. From a technical point of
view, there are three types of censorship. The first is the type the
Internet is highly resistant to. It is not possible for any one
country to dominate the Internet and control what is visible in the
territory of another. The second is control of the borders of a
territory. The third, control within a territory. The second two are
something the Internet can't address as a structural issue.
We can deploy a censorship-proof Internet in the parts where
governments share our objectives. We do not dominate the Internet, we
cannot force governments with counter objectives to allow deployment
of the censorship-proofing technology.
Counter-censorship within a territory where the censor controls the
infrastructure requires tactical measures. The problem with tactics is
that they only work so long as they are a surprise. With all due
respect to MtFBwU, I would hope that he would want us to avoid giving
away information to the opposition.
On Mon, Mar 22, 2010 at 2:24 AM, Greg Daley
Please excuse my weasel words.
My country is apparently about to adopt an internet censorship scheme.
I'm not happy about it, but I'm unlikely to build a system to circumvent the
I would actually not encourage IETF to work on such a technology as this,
particularly in the lead-up to IETF Beijing. That would be a serious affront
to our hosts. It is quite important to ensure that the IETF particularly is
subject to any external party's agenda in the lead-up to the meeting.
In purely technical terms, there is a conflict with IETF's existing
routing practices which are shortest (routing) path oriented, so that
communications between pairs of devices will send most or all channels
of data down the same path.
Any form of communications which sends multiple elements down the same routing
path is subject to collation and correlation by an intermediate agency,
that they use the same correlation mechanisms as the end-nodes.
So that means using diverse data paths, or creating some sort of protected
payload is required to ensure that only the parties to a conversation can
receive the data.
If there is a portion of the data which can be exchanged out-of-band, then a
protection scheme can be negotiated there, or the sensitive content can be
the remnant providing only innocuous context.
Alternatively, a system which can send data out-of-band which the parties
can use to shuffle the data so that sensitivity is reduced.
In some environments use of such shuffle techniques and out-of-band channels
not legal, and I wouldn't encourage anyone to act illegally.
Out-of-band communications schemes such as have been mentioned are likely to
focussed on by authorities. Participation in particular schemes could get
Systems which increase the apparent entropy of a communication path could
even be detected,
and local endpoints (for example within a protected zone) could be identified
on the increased entropy.
This would be dangerous for the participants, especially if they thought that
the channel they had was unidentifiable.
IETF's job is to make Standards, which are reliable, stable and widely
Regardless of the focus of a protocol (routing, privacy or reliability), it's
sufficient to create a system which is good-enough for today, but could be
dangerously ineffective tomorrow.
I believe this is something which is not something IETF should rush into
ideology of participants aside.
Ietf mailing list
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
Ietf mailing list