josephlhall
commented
5 years ago The above is by @seamustuohy in #30
Closed josephlhall closed 4 years ago
josephlhall
commented
5 years ago The above is by @seamustuohy in #30
stanadams
commented
5 years ago These were tougher to address.
tech-prescrip - I don't know enough to add something in about byte-stream based identification
deep packet inspection - I was fine with our sub-splits, but changed the SNI section to be a sub-part of the DPI section (only change is in the header). Also tried to add a few citations in, with mixed results. Forgot to put dates in first time around, was unsuccessful in adding them later. I guess you have to add the citation details all in one shot, or start over?
tcp/ip - changed the heading on this section to "shallow packet inspection" and the first line to indicate that the section will focus primarily on tcp/ip header identification. I agree that we need an empirical section here, but fear I won't add enough substance if I try to summarize the Syrian study suggested above. added a place holder, but no text.
protocol identification - I don't know enough to help on this one. Again with the bytestream matching?
performance degradation and the rest - same as protocol ID, seems worthy of inclusion, I just don't know enough
josephlhall
commented
5 years ago Awesome! Thanks for taking a shot
On Wed, Mar 6, 2019 at 15:12 Stan Adams notifications@github.com wrote:
These were tougher to address.
tech-prescrip - I don't know enough to add something in about byte-stream based identification
deep packet inspection - I was fine with our sub-splits, but changed the SNI section to be a sub-part of the DPI section (only change is in the header). Also tried to add a few citations in, with mixed results. Forgot to put dates in first time around, was unsuccessful in adding them later. I guess you have to add the citation details all in one shot, or start over?
tcp/ip - changed the heading on this section to "shallow packet inspection" and the first line to indicate that the section will focus primarily on tcp/ip header identification. I agree that we need an empirical section here, but fear I won't add enough substance if I try to summarize the Syrian study suggested above. added a place holder, but no text.
protocol identification - I don't know enough to help on this one. Again with the bytestream matching?
performance degradation and the rest - same as protocol ID, seems worthy of inclusion, I just don't know enough
— You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/josephlhall/rfc-censorship-tech/issues/38#issuecomment-470258411, or mute the thread https://github.com/notifications/unsubscribe-auth/AFl6ZOMIWmQTVC_maVdRDjFJuetwC1Keks5vUCEkgaJpZM4bDGTU .
-- 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
commented
4 years ago I think we've addressed as much as we could here
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.
{#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.
Originally posted by @seamustuohy in https://github.com/josephlhall/rfc-censorship-tech/issues/30#issuecomment-238968216