Subject: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"

From: IAB Chair <[email-masked]>
Date: Wed, 29 Jan 2014 11:16:56 -0500

This is a call for review of "Technical Considerations for Internet
Service Blocking and Filtering" prior to potential approval as an
IAB stream RFC.

The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/

The Call for Review will last until 26 February 2014.
Please send comments to [email-masked]. 

On behalf of the IAB,
  Russ Housley
  IAB Chair

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Jan 2014 19:52:53 +0100

> https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/

Albeit it purports to keep clear of (un)ethical considerations, the
document seems to be oriented toward government-imposed restrictions,
recounting how it would be better to move filtering to collaborative
endpoints rather than disrupting Internet operation, since bad actors
can circumvent filtering anyway.  I fully agree, but I think that a
general purpose document on this subject might have touched on such
points as password management, user identification, and outbound port
25 blocking.

Some minor comments, in top-down order:

1. *Introduction*, par 3

                          As noted in [RFC4084], some Internet service
   providers impose restrictions on which applications their customers
   may use and which traffic they allow on their networks.

To avoid confusion, I'd s/impose restrictions/perform filtering/,
since RFC 4084 says about Firewalled Internet Connectivity:

                  It is distinguished from the models above by the
   fact that any filtering or blocking services are ultimately
   performed at customer request, rather than being imposed as
   service restrictions.

Alternatively, that snippet could refer to "Section 3 of [RFC4084]".

2. *Filtering Examples*, par 3 (Web Filtering)

The second half of that paragraph is rather lengthy and obscure --the
explanation in Section 5 is much clearer.  It could be shortened for
readability, for example:

OLD:
   To block access to content made accessible via HTTPS, filtering
   systems thus must either block based on network- and
   transport-layer headers (IP address and/or port), or else obtain a
   trust anchor certificate that is trusted by endpoints (and thus act
   as a man in the middle).  These filtering systems often take the
   form of "portals" or "enterprise proxies."  These portals present
   their own HTTPS certificates that are invalid for any given domain
   according to normal validation rules, but may still be trusted if
   the user installs a security exception.  (See further discussion in
   Section 5.)

NEW:
   To block access to content made accessible via HTTPS, filtering
   systems thus must either block based on network- and
   transport-layer headers (IP address and/or port), or act as a man
   in the middle by requiring the user to install security exceptions.
   The latter filtering systems often take the form of "portals" or
   "enterprise proxies", presenting their own, dynamically generated
   HTTPS certificates.  (See further discussion in Section 5.)

3.1. *Entities that set blocking policies*

   Parties that institute blocking policies include governments,
   enterprises, network operators, application providers, and
   individual end users.

Which of those terms includes Spamhaus?  I'd propose to add
"reputation trackers".

3.4. *Components used for blocking*, par 1

   Broadly speaking, the process of a delivering an Internet service
   involves three different components:

s/a delivering/delivering/

4.3.5. *Examples*, par 3

s/e-mail/email/

6. *Conclusion*

s/Because it least/Because it is least/

Ale

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 30 Jan 2014 13:17:25 -0800

Hi Alessandro,

Thanks for your comments. I have one question below.

>points as password management, user identification, and outbound port

Could you expand a bit about what you feel is missing as regards to
password management and user identification?

Thanks,
Alissa

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 31 Jan 2014 12:35:16 +0100

Hi

> password management and user identification?

Blocking dictionary attacks is an obvious requirement for any server
endpoint.  Perhaps that topic is not really /missing/, since it is so
obvious and apparently overworked.  However, most of the applications
which log authentication failures don't support tracking the number of
failed attempts against a given password.  Thus, policies blindly
require passwords to be changed after T days, irrespectively of the
entropy that a password had and the amount of it that could have been
eroded by failed attempts.  So maybe that topic is not as overworked
as it may appear.

Upon authentication, a user-id qualifies an endpoint.  Together with a
realm-id, it makes a global identifier.  Email address confirmation
can be considered a kind of rendezvous service, which users can block
by discarding the request.  The exchange of marketing profile data
between unscrupulous operators, often based on email addresses, is a
kind of abusive or objectionable communication.  Disposable addresses
are an example of a mechanism to block that indirectly.  They require
endpoint-based support at both ends, which is rather uncommon.

Thank you for your interest
Ale

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Jan 2014 08:30:03 -0800

Hello,
>Service Blocking and Filtering" prior to potential approval as an

 From Section 4.1.3 of draft-iab-filtering-considerations-06:

   "If voice communication based on SIP [RFC3261] is blocked,
    users are likely to use proprietary protocols that allow them to talk
    to each other.  Some filtering systems are only capable of
    identifying IPv4 traffic and therefore by shifting to IPv6 users may
    be able to evade filtering.  Using IPv6 with header options, using
    multiple layers of tunnels, or using encrypted tunnels can also make
    it more challenging for blocking systems to find transport ports
    within packets, making port-based blocking more difficult.  Thus
    distribution and mobility can hamper efforts to block communications
    in a number of ways."

There is a case of SIP being blocked at 
http://www.onsip.com/blog/2013/07/02/in-depth-verizon-blocks-sip-traffic-using-alg 
I gather that the argument in the first sentence 
(see quoted text) is that users will use 
Skype.  For what it i worth, there is an article 
at 
http://www.itwebafrica.com/telecommunications/335-africa/229496-skype-is-not-banned-in-ethiopia 
about a country which discussed a draft 
legislation allegedly affecting Skype.    There 
is a case of a provider charging more money to 
unblock VoIP ( 
http://forum.vodafone.co.uk/t5/Pay-monthly-services/VoIP-SIP-Skype-Etc/td-p/729923 
).  In my opinion, blocking voice traffic 
nowadays does not necessarily cause a shift to 
proprietary protocols as a proprietary service 
can still use a non-proprietary protocol.

Section 4.1.3 is about efficacy and how easy is 
it to avoid being blocked.  In 2003, it was the 
view of the then-IAB that [filtering] or 
[preventing] the transmission of traffic based on 
the service identification within the traffic 
flow will have a limited effect.  As mentioned in 
the quoted text, the adversary, the user in this 
case, can use "non-well-knownness" ports to evade 
filtering.  It was also mentioned that SIP can 
use dynamically allocated service identifiers.

Thinking aloud, I would say that the first 
paragraph in Section 4.1.3 discusses about 
efficacy from a service end-point 
perspective.  The second paragraph might be more 
about the efficacy of blocking by 
intermediaries.  It is argued that the adversary 
will use a different port or encrypt the 
traffic.  As a side-note, the user cannot shift 
to IPv6 or the user would be using IPv6 as a 
tunnel.  The question is how effective is port 
blocking.  I would use the following description:

    "Services may be tunneled within other services, proxied by a
     collaborating external host (e.g., an anonymous redirector),
     or simply run over an alternate port (e.g., port 8080 vs port
     80 for HTTP).  Another means of circumvention is alteration of
     the service behavior to use a dynamic port negotiation phase,
     in order to avoid use of a constant port address."

and have the encryption discussion in a separate paragraph.

What the people with the authority would like to 
have is an affective blocking mechanism.  Are 
there any references about attempts to side-step 
what is being discussed in that paragraph?

 From Section 4.2.1:

   "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.  In practice, inter-network routing is often
    asymmetric, and for sufficiently complex local networks, intra-
    network traffic flows can be asymmetric as well [asymmetry]."

As the "asymmetry" reference is to a pay-to-view 
paper I was unable to read it.  I suggest finding 
a reference which the reader can access for free.

The first sentence mentions the challenge of 
gaining access to the user's packets.  The second 
sentence discusses about the Internet being 
designed for hop-by-hop delivery, and it is 
followed by a mention of the asymmetry of 
inter-network routing.  There is a (old) visual 
illustration of connectivity for North America at 
http://infosthetics.com/archives/cybergeography_book6.jpg 
My guess is that a visual illustration for the 
rest of the world would show a lower number of egress points.

I'll use 
http://www.renesys.com/wp-content/uploads/2013/09/Sudan_Internet.png 
as an example.  It's not that difficult to gain 
access access to the packets as the in-country 
network is not that complex.  Is the discussion 
in Section 4.2.1 using a "cliché" [1]?  I would 
look at (network-based blocking) scope from a 
collateral damage [2] vantage point.

 From Section 4.2.4:

   "In sum, network-based blocking is only effective in a fairly
    constrained set of circumstances.  First, the traffic needs to flow
    through the network in such a way that the intermediary device has
    access to any communications it intends to block."

Is network-based blocking good enough to do the 
job?  Given the extent of deployment of such 
measures I find it difficult to argue that it is 
only effective in a fairly constrained set of circumstances.

 From the Conclusion section:

   "Because it least likely to create technical or architectural
    problems, endpoint-based blocking is the form of Internet service
    blocking that is least harmful to the Internet."

What are the architectural problems?  I am asking 
the question as it is the sort of question that 
comes up in discussions about blocking traffic.  Section 3.4 mentions that:

   "In the next section, blocking systems designed according to each of
    the three patterns -- network services, rendezvous services, and
    endpoints -- are evaluated for their technical and architectural
    implications."

A quick glance through Section 4 shows the following:

   "From an architectural perspective, however, they may create many of
    the same problems as network-based filtering conducted without
    consent."

   "If cooperation can be achieved, endpoint-based blocking can be much
    more effective than other approaches because it is so coherent with
    the Internet's architectural principles."

As a note, the document does not reference RFC 1958.

Regards,
S. Moonesamy

1. a phrase or opinion that is overused and betrays a lack of original thought.
2. 
http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf