Subject: [hrpc] cases - IP

From: Will Scott <[email-masked]>
Date: Fri, 9 Oct 2015 11:28:37 -0700

Hi all,

Below is an initial discussion on tradeoffs at the IPv4 level, and
specifically harms associated with RFC791. Again, if there are other
protocol related harms you'd like to see flagged, feedback is welcome!

--Will

IP
=====
The Internet Protocol version 4, known as ‘layer 3’ of the internet, and
specified as a common encapsulation and protocol header, is defined by RFC
791. The evolution of Internet communications have led to continued
development in this area, encapsulated in the development of version 6 of
the protocol in RFC 2460. In spite of this updated protocol, we find that
25 years after the specification of version 6 of the protocol, the older v4
standard continues to account for a sizable majority of internet traffic.

The internet was designed as a platform for free and open communication,
most notably encoded in the end-to-end principle, and that philosophy is
also present in the technical implementation of the Internet Protocol. [1]
While the protocol was designed to exist in an environment where
intelligence is at the end hosts, it has proven to provide sufficient
information that a more intelligent network core can make policy decisions
and enforce policy shaping and restricting the communications of end hosts.
These capabilities for network control and limitations of the freedom of
expression by end hosts can be traced back to the IPv4 design, helping us
understand which technical protocol decisions have led to harm of these
human rights.

Two major shifts have occurred to harm freedom of expression through misuse
of the Internet Protocol. The first is the network’s exploitation of the
public visibility of the host pairs for all communications, and the
corresponding ability to discriminate and block traffic as a result of that
metadata. The second is the selective development of IP options, so that
protocol extensions promoting assembly and expression like Mobility and
Multicasting can fail to receive support from IP compatible devices. This
lack of forward compatibility where extensions can receive a baseline level
of support needed to extend the design has stymied forms of expression
which could have been extended to support these human rights.

[1] https://www.ietf.org/rfc/rfc3724.txt

Network visibility of Source and Destination
-----
The IPv4 protocol header contains fixed location fields for both the source
and destination IP addresses [1]. These addresses identify both the host
sending and receiving each message, and allow the core network to
understand who is talking to whom, and to practically limit communication
selectively between pairs of hosts. Blocking of communication based on the
pair of source and destination is one of the most common limitations on the
ability for hosts to communicate today, [2] and can be seen as a
restriction of the ability for those hosts to assemble or to consensually
express themselves.

We have seen from other instantiations of protocols, even those comparable
to IPv4, that other designs are possible. IPv4 even encodes a defined
option and specification for source routing of packets, where the source
can specify or suggest a routing path, and as the message passes through
those paths, the part of the path it has completed are removed from the
path. This design has the potential to make it much more difficult for an
individual router in the network to stifle speech, since it will cannot do
the same level of differentiation on the source of the messages.
Unfortunately, many networks prevent the use of source routing, and the
protocol is not designed such that support of that ability is required in
order for the protocol to be implemented.

Documentation of this form of harm:
[1] https://tools.ietf.org/html/rfc791
[2]
http://www.caida.org/publications/papers/2014/outages_censorship/outages_censorship.pdf
[3]
http://www.ipjustice.org/digital-rights/internet-infrastructure-and-ip-censorship-by-david-post/

Protocols
-----
The other major feature of the IP protocol header is that it specifies the
protocol encapsulated in each message in an easily observable form, and
does not encourage a design where the encapsulated protocol is not
available to a network observer.  This design has resulted in a
proliferation of routers which inspect the inner protocol, and has resulted
in a stagnation where only the TCP and UDP protocols are widely supported
across the Internet. While the IP protocol was designed as the entire set
of metadata needed for routing, subsequent enhanced routers have found
value on making policy decisions based on the contents of TCP and UDP
headers as well, and are encoded with the assumption that only these
protocols will be used for data transfer. [1] This has prevented
development of more secure protocols, since there’s a need to provide
sufficient metadata with each message for routers to make positive policy
decisions if you hope the protocol will be available to all users.

Documentation of this form of harm:
[1] https://www.chromium.org/spdy/spdy-whitepaper
[2] https://www.chromium.org/quic
[3] https://tools.ietf.org/html/rfc4960

Address Translation and Mobility
-----
A major structural shift in the Internet which has undermined the protocol
design of IPv4, and has significantly reduced the freedom of end users to
communicate and assemble in the introduction network address translation.
[1] Network address translation is a process whereby organizations and
autonomous systems to connect two networks by translating the IPv4 source
and destination addresses between the two. This process puts the router
performing the translation into a privileged position, where it can decide
which subset of communications are worthy of translation, and whether an
unknown request for communication will be correctly forwarded to a host on
the other network.

This process of translation has widespread adoption despite promoting a
process that goes against the stated end-to-end process of the underlying
protocol [2]. In contrast, the proposed mechanism to provide support for
mobility and forwarding to clients which may move, encoded instead as an
option in the IP protocol [3], has failed to gain traction. This situation
again suggests that the compromise made in design of the protocol has
resulted in a technology which failed to technical encode the freedom of
expression goals it was designed to promote.

Documentation of this form of harm:
[1] https://tools.ietf.org/html/rfc1631
[2] http://www.icsi.berkeley.edu/pubs/networking/NATusage11.pdf
[3] https://tools.ietf.org/html/rfc5944

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 14:04:21 +0200

On Fri, Oct 09, 2015 at 11:28:37AM -0700,
 Will Scott <[email-masked]> wrote 
 a message of 260 lines which said:

> The second is the selective development of IP options, so that
> protocol extensions promoting assembly and expression like Mobility
> and Multicasting can fail to receive support from IP compatible
> devices.

Strong disagreement here. Not on the unfortunate state of IP options
(we agree here) but on the fact that IP mobility or multicasting
enable "assembly and expression". I fear you go to far in technical
determinism here.

IP mobility, first. Technically, it is a bad idea from the beginning,
assuming layer has to handle mobility. Actually, most of the time,
mobility is better managed by applications (Pidgin for IM, all Twitter
clients for Twitter, all email clients, rsync and BitTorrent nodes for
file transfer, mosh for ssh, etc).

Multicasting, second. Again, a bad idea from the beginning:
multicasting is only beneficial when everybody access the same content
at the very same time. Except religious ceremonies like the SuperBowl,
it is less and less common. Most interactions are not synchronous and
therefore do not depend on multicasting.

> IPv4 even encodes a defined option and specification for source
> routing of packets, where the source can specify or suggest a
> routing path, and as the message passes through those paths, the
> part of the path it has completed are removed from the path. This
> design has the potential to make it much more difficult for an
> individual router in the network to stifle speech,

You lost me here. Filtering based on the pair source<->destination is
most of the time done by a router which is close from the two
communicating machines. Source routing wouldn't help since you have no
choice of the edge routers. In countries where there is widespread IP
address filtering, there are only a few communcation points with the
outside and, again source routing would not help.

A better solution, Tor, does not depend on source routing.

> Unfortunately, many networks prevent the use of source routing,

They are absolutely right, given the security risks of source routing.

> The other major feature of the IP protocol header is that it
> specifies the protocol encapsulated in each message in an easily
> observable form, and does not encourage a design where the
> encapsulated protocol is not available to a network observer.

There is an IETF-sanctioned solution, ESP. Little deployment, I
know. But any encrypting tunnel can do the same.

---

From: Will Scott <[email-masked]>
Date: Wed, 14 Oct 2015 08:33:37 -0700

Thanks, Stephane for the feedback.

I've updated this section, the patch can be seen here:
https://github.com/nllz/IRTF-HRPC/compare/master...willscott:abdcc13?expand=1

--Will

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Oct 2015 16:58:30 +0200

On Wed, Oct 14, 2015 at 08:33:37AM -0700,
 Will Scott <[email-masked]> wrote 

> https://github.com/nllz/IRTF-HRPC/compare/master...willscott:abdcc13?expand=1

The patch is empty "There isn’t anything to compare.  nllz:master is
up to date with all commits from willscott:abdcc13. Try switching the
base for your comparison." draft-varon-hrpc-methodology-01 still uses
the very same text (that I find objectionable) about mobility and
multicasting.