Joining the draft e-mail list

[seamustuohy]

It seems that there is significant overlap between the work that I was doing for CAPEC and the work being done in this internet draft. Is there a process for joining the e-mail list so that I can contribute to the discussion of design issues and suggest possible additions or design changes?

[josephlhall]

Hi Seamus, more than happy to add you as an author if you'd like to suggest changes. We're hoping to get Security AD sponsorship of the draft so massive changes to the structure may be hard, but if it makes it more useful for protocol designers or implementers that will be very welcome. I'm going to add some feedback to the issues that I received today and then we should schedule an editor call for someone in August to consolidate next steps. Does that sound like a good way to proceed? I've looked briefly at the CAPEC work you point to but need to spend more time with it in the meantime.

On Thursday, July 21, 2016, Seamus Tuohy notifications@github.com wrote:

It seems that there is significant overlap between the work that I was doing for CAPEC and the work being done in this internet draft. Is there a process for joining the e-mail list so that I can contribute to the discussion of design issues and suggest possible additions or design changes?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/josephlhall/rfc-censorship-tech/issues/30, or mute the thread https://github.com/notifications/unsubscribe-auth/AFl6ZCQOaXeFJ-tkwUZit-fh5f8WmthEks5qX6jHgaJpZM4JSBL0 .

Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871

[josephlhall]

@seamustuohy I should mention that there's not a lot of action on the email list for the Internet Draft. There has been some discussion (although limited) on the IRTF HRPC list and the IETF SAAG list. If you want to contribute to the draft in some way, do you want to outline how you would change the text?

[seamustuohy]

Hey Joseph,

Sorry about the recent silence. It has been a bit hectic over here. I took my lunch today to put forth some of my thoughts. Let me know if any of these threads seem interesting and I would be happy to try to churn out some of the required content for inclusion into the draft.

I have put the individual header item links in to split up the comments.

{#tech-prescrip}

This does not include service / protocol blocking which blocks based upon byte-streams matching. While there is a move towards heuristic censorship for blocking protocols and specific services, byte-stream matching is by-far the most prevalent.

{#dpi}

There is drift into surveillance implications (e.g. Hepting-2011) that pop up throughout the document. Is this intentional? In my exploration I spent a lot of time separating out surveillance components because of the taxonomy concerns. How close to the topic do you need to stay to have this accepted?

{#sni}

Since "Server Name Indication" is identified using deep packet inspection why is it its own category? Would it not simply be one of the many ways that DPI can be used?

{#sec_tcpid}

Why is this TCP/IP header identification instead of " shallow packet inspection" which includes TCP/IP header identification? While you mention that this uses DPI, with DPI as it's own category in the layer above, it seems to make taxonomic sense to name the transport layer equivalent after the common parlance for this method and not the most common protocol's that it is used on. While I can't think of a nation-state UDP header targeted censorship event I have read dozens of rules for it in various NIDS.

• The {#sec_tcpid} section is missing an empirical example. Odd, since this is such a common case. One possible empyrical example is internet filtering in Syria. Censorship in the Wild: Analyzing Internet Filtering in Syria

{#prot-id}

I am curious to why active probing was chosen here instead of bytestream matching? Active probing is one of, if not the, most exotic methods of identifying a protocol. And, while I can see why it was put in the protocol identification section, in my mind it makes more sense to put this as its own item under the app layer. If I remember correctly one of the issues that the pluggable transport folks had was that China was identifying Tor bridges that ran their PT's even though they were not generic bridges running the Tor protocol. So, it seems that it is more about the application Tor than the specific protocol that Tor uses. A bit pedantic, I know, but I think there are enough examples for both.

{Performance Degradation // Packet Dropping}

I would add time delimited access in here as well. It could be added as a sub-component of either of these examples or as its own example. I did a brief summary which includes a link to an empirical example when I was working on the CAPEC definitions.

{#dns-mangling}

It might make sense to use "above/below recursive" as a way to differentiate between the DNS poisoning examples. I found it useful when trying to separate the different ways it is done.

{#discon}

This does not seem to include BGP tampering and BGP route leaks. Would this be something that you would like added?

{#nontechint}

I would add generic disabling of network hardware in here. e.g. the NSA accidental take-down of Syrian network hardware.

[seamustuohy]

Just checking in on this. It looks like the project went into hiatus or switched channels. Do you have thoughts on these comments?

[josephlhall]

Sorry, it has not gone on hiatus... I'm currently trying to consolidate all of these into a plan to produce a good final draft by mid-october. You are welcome to propose text edits by PR, as that will help move it along. But I hope to plan a call in early October for authors and interested folks.

(I am down a staff member so this should have happened two weeks ago, and I'm traveling (w3c, nspw.org) until 30 Sep., but I'm hopeful we should have a "vision" for seeing this published soon... we do have both Security ADs willing to sponsor this draft, so we should get it finalized!)

On Tue, Sep 20, 2016 at 1:03 PM, Seamus Tuohy notifications@github.com wrote:

Just checking in on this. It looks like the project went into hiatus or switched channels. Do you have thoughts on these comments?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/josephlhall/rfc-censorship-tech/issues/30#issuecomment-248281583, or mute the thread https://github.com/notifications/unsubscribe-auth/AFl6ZN_Tn0ZzQdAcBfqO4g20xXblzwvCks5qr8ucgaJpZM4JSBL0 .

Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871

Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner

[josephlhall]

Just a note that I'm doing triage on issues for this draft later today... Seamus, I may tag you for specific additions based on your feedback (I'll also give a timeline for what I think makes sense to make the 31-Oct 23:59 UTC IETF drafts deadline).

[seamustuohy]

Tag away and I will try to spend some quality time with the document to get them added in the timeline.