Patrik Falstrom comments

[alissa@…]

First, thanks for writing this draft. As you know, I have been sort of
working in this area for a while. Most significantly I as chair of SSAC
moved the SSAC documents on blocking, [SAC050] and [SAC056] through the
machinery. I have also worked on one of the inputs to a report by
Council of Europe on the topic: "Consolidated report on the cross-border
flow of Internet traffic and interference which may have an impact on
access to content, services and applications":

<​http://www.coe.int/t/dghl/standardsetting/media/cdmsi/CDMSI(2013)misc20_en.pdf>

Now to this document of yours, and my view on this... :-)

In [SAC-056], ICANN's Security and Stability Advisory Committee
(SSAC) assessed the aspects of blocking using the DNS.

:-)

2. Filtering Examples

I think it is important here that you explain on what layer in the value
chain you are talking. I think you are talking about the IP layer,
filtering of certain IP traffic, right? In some cases the question on
"right to way" (or requirement to be open) is as you say in the
introduction also close to various contractual obligations. For example
to pay for a certain service. This involves identifying whether markets
are one-sided or two-sided and can also involve other layers of the
value chain than the IP/Internet layer.

Example: A city owned fibre network in southern part of Sweden do not
allow any customer rent the dark fibre wholesale product. Only various
IP based tunnel mechanisms. The platform they use do though only allow
IPv4 packets to flow through their network. Because of this, even if
they are only selling a wholesale "bistream" product, none of their
customers (the ISPs) can deliver IPv6 packets to their end customers
(the end users of Internet Access).

This is something the regulator is looking at, and is just one example
where what I call a "disturbance" in competition on one layer in the
value chain do have impact on the openness of the Internet Access that
ultimately the end user do believe their have procured. I.e. the
disturbance itself is not on the Internet layer.

It is the de-facto monopolist that blocks (by not supporting) IPv6 in
this case. Not the Internet Access provider.

Firewalls: Firewalls are a very common tool used for service
blocking, employed at many points in today's Internet [RFC2979].
Typically, firewalls block according to content-neutral rules, e.g.,
blocking all inbound connections or outbound connections on certain
ports, protocols and network layer addresses. More advanced
configurations perform deep packet inspection or traffic flow
analysis and filter or block based on rich (content-specific) rules
and policies. Many firewalls include web filtering capabilities (see
below). Firewalls can be deployed either on end hosts (under user or
administrator control), or at network boundaries.

Very good you do NOT mention NAT here.

Spam filters
are typically either installed on user devices (e.g., in a mail
client) or operated by a mail domain on behalf of users.

It is more and more common to also outsource the "cleaning" of the email
to a third party that act as intermediate MX proxy.

The reason why I mention this explicitly have to do with recent
discussion whether wiretap that might end up at a country border might
impact the trust in email as a transport mechanism. If for example a
company in Sweden uses a company in UK for email laundry, then the email
will twice cross the border of Sweden even if the email is sent from a
user in Sweden to the recipient also in Sweden.

Domain name seizure: In recent years, US law enforcement authorities
have been issuing legal orders to domain name registries to seize
domain names associated with the distribution of counterfeit goods
and other alleged illegal activity [US-ICE]. When domain names are
seized, DNS queries for the seized names are typically redirected to
resolve to U.S. government IP addresses that host information about
the seizure.

Decide whether you should write US or U.S.

Further, it would be good if you looked at not directly US incidents or
accidents in this part of the text. This domain name blocking happens
not only in the US. At least make up your mind how much examples you
should have here, and give similar amount/number of examples for each case.

It also fairly often happens by registries that themselves decide to
remove domain names (look at .CH, .ORG etc) or they cooperate in
groups/processes like APWG.

Also look at the court case in NL that recently did override a lower
court decision to block the domain name for the pirate bay.

o Restricting objectionable content or services. Certain

communications may be viewed as undesirable, harmful, or illegal
by particular governments, enterprises, or users (e.g., parents).

Not necessary to point out "parents" there. I feel that is a too US
centric view.

Governments may seek to block communications that are deemed to be
defamation, hate speech, obscenity, intellectual property
infringement, or otherwise objectionable. Enterprises may seek to
restrict employees from accessing content that is not deemed to be
work appropriate. Parents may restrict their children from
accessing content or services targeted for adults.

I think when you talk about "Governments may seek to" should remember
that governments in many cases implies some agency acting just because
there is a law that state what can be allowed or not. The other cases I
view as blocking based on norms. If that law is created based on a
democratic process, that is to me something very difficult to do
something about. Specifically if that law is not harmonized with laws in
other countries.

I.e. a law is not really a government or individual acting on their own.
It is the government acting on behalf of the people that elected them.

Very very difficult.

Consider, for example, an HTTP transaction fetching the content of
the URI <​http://example.com/index.html>. The client endpoint is an
end host running a browser. The client uses the DNS as a rendezvous
service when it performs a AAAA query to obtain the IP address for
the server name "example.com". The client then establishes a
connection to the server, and sends the actual HTTP request. The
server then responds to the HTTP request.

Here I would say explicitly "The server end point then responds..." so
that it is very clear you really do have two end points.

I also think it is important you do through out the text talk about "the
DNS" as a service (in singular) while the number of transactions using
the DNS protocol is many, and many DNS application layer hosts are
interacted with.

Same with "the web". A web page is very rarely one HTTP transaction
nowadays, and not to one host either btw. See the CoE paper I reference.

o [Endpoint] Preventing the client from making the request
o [Endpoint] Preventing the server from responding to the request
o [Endpoint] Preventing the client from making a DNS request for

example.com

...from making the DNS requests needed...

In general, change to plural where needed please!

o [Network] Preventing the request from reaching the server
o [Network] Preventing the response from reaching the client
o [Network] Preventing the client from reaching the DNS server

See above.

o [Network] Preventing the DNS response from reaching the client
o [Rendezvous] Preventing the DNS server from providing the client

the correct IP address of the server

Blocking systems are generally
viewed as less objectionable if the scope of their impact is as
narrow as possible while still being effective.

And, as long as the impact of the blocking is within the administrative
realm whoever makes the decision is responsible for. Side effects are bad.

Design flaws in blocking systems may also cause the effects of
blocking to be overbroad. For example, web filtering systems in
India and China have been shown to cause "collateral damage" by
unwittingly blocking users in Oman and the US from accessing web
sites in Germany and Korea
[IN-OM-filtering][CCS-GFC-collateral-damage].

Politically better if you manage to find over-blocking actions (notice
and take down) in the US or Europe.

4.1.4. Security: How does the blocking impact existing trust

infrastructures?

Modern security mechanisms rely on trusted hosts communicating via a
secure channel without intermediary interference. Protocols such as
TLS and IPsec [RFC5246][RFC4301] are designed to ensure that each
endpoint of the communication knows the identity of the other
endpoint, and that only the endpoints of the communication can access
the secured contents of the communication. For example, when a user
connects to a bank's web site, TLS ensures that the user's banking
information is securely communicated to the bank and nobody else,
ensuring the data remains confidential while in transit.

Be careful with this example. Some people, including myself, see the CA
that issued the cert as a third party proxy regarding the trust
relationship between the two parties. And this is also where we see
weaknesses in SSL/TLS, when CA's "fold" in various ways and false certs
do get exposed on the market.

Similar issues now happens when internal name certificates suddenly will
have DNs that include domain names that actually are real domain names
as rooted in the root we all trust.

Some blocking strategies require intermediaries to insert themselves
within the end-to-end communications path, potentially breaking
security properties of Internet protocols [RFC4924]. In these cases
it can be difficult or impossible for endpoints to distinguish
between attackers and "authorized" entities conducting blocking.

Very very important point!

Intermediary systems used for blocking are often not far from the
edge of the network.

Well, they SHOULD be as close to the edge as possible... But some of
them are absolutely in the core at large ISPs.

For residential or consumer networks with many egress points, the
first challenge to obtaining this traffic is simply gaining access to
the constituent packets. The Internet is designed to deliver packets
hop-by-hop from source to destination -- not to any particular point
along the way.

I suggest you somewhere explain what "one hop" is.

Indeed, in the face of IP-based
blocking in some networks, services such as The Pirate Bay are now
using cloud hosting services so that their IP addresses are difficult
for intermediaries to predict [BT-TPB][TPB-cloud].

I think you should be careful with "just" mentioning The Pirate Bay. You
should qualify the reason why you use that as an example.

If application content is encrypted with a security protocol such as
IPsec or TLS, then the intermediary will require the ability to
decrypt the packets to examine application content.

...or use statistical methods to guess what the content is.

If the intermediary is unable to decrypt the security protocol, then
its blocking determinations for secure sessions can only be based on
unprotected attributes, such as IP addresses, protocol IDs and port
numbers.

...or packet sizes, timing and whatever else that can be gathered.

See for example the products Procera has: <​http://www.proceranetworks.com/>

Some blocking systems today still attempt to block based on
these attributes, for example by blocking TLS traffic to known
proxies that could be used to tunnel through the blocking system.
However, as the Telex project recently demonstrated, if an endpoint
cooperates with a relay in the network (e.g., a Telex station), it
can create a TLS tunnel that is indistinguishable from legitimate
traffic [Telex]. For example, if an ISP used by a banking website
were to operate a Telex station at one of its routers, then a
blocking system would be unable to distinguish legitimate encrypted
banking traffic from Telex-tunneled traffic (potentially carrying
content that would have been filtered).

Yes, but, reference to the Telex project?

Did I miss that earlier in the text?

4.4.4. Summary

Out of the three design patterns, endpoint-based blocking is the
least likely to cause collateral damage to Internet services or the
overall Internet architecture. Endpoint-based blocking systems can
see into all layers involved in a communication, allowing blocking to
be narrowly targeted.

Please talk explicitly about "secondary effects" here again. Like
"...and minimizes secondary effects". It makes the statement stronger.

4.4.5. Server Endpoints

In this discussion of endpoint-based blocking, the focus has been on
the consuming side of the end-to-end communication, mostly the client
side of a client-server type connection. However, similar
considerations apply to the content-producing side of end-to-end
communications, regardless of whether that endpoint is a server in a
client-server connection or a peer in a peer-to-peer type of
connection.
For instance, for blocking of web content, narrow targeting can be
achieved through whitelisting methods like password authentication
whereby passwords are available only to authorized clients. For
example, a web site might only make adult content available to users
who provide credit card information, which is assumed to be a proxy
for age.
The fact that content-producing endpoints do not take it upon
themselves to block particular forms of content in response to
requests from governments or other parties can sometimes motivate
those latter parties to engage in blocking elsewhere within the
Internet.

You should also point out that if for example a service is to be
blocked, the best way of doing that is to go to the server endpoint and
simply turning the service off.

[nordmark@…]

Don't know what to do with the request: " I think it is important here that you explain on what layer in the value
chain you are talking. I think you are talking about the IP layer,
filtering of certain IP traffic, right? In some cases the question on
"right to way" (or requirement to be open) is as you say in the
introduction also close to various contractual obligations. For example
to pay for a certain service. This involves identifying whether markets
are one-sided or two-sided and can also involve other layers of the
value chain than the IP/Internet layer."

[nordmark@…]

I've tried to capture all the suggested edits apart for the above comment about the value-chain.