Dear MtFBwU, 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 "protection". 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 not 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, assuming 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 sent with 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 is not legal, and I wouldn't encourage anyone to act illegally. Out-of-band communications schemes such as have been mentioned are likely to be focussed on by authorities. Participation in particular schemes could get someone in trouble. 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 based 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 available. Regardless of the focus of a protocol (routing, privacy or reliability), it's not 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 willy nilly, ideology of participants aside. Sincerely, Greg Daley _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf