Subject: Re: [arch-d] draft-iab-filtering-considerations

From: Alissa Cooper <[email-masked]>
Date: Sat, 23 Feb 2013 06:47:59 -0500

Hi Patrik,

We have posted a new version: <http://www.ietf.org/id/draft-iab-filtering-considerations-02.txt>. Some comments are inline below.

On Oct 26, 2012, at 1:58 PM, Patrik Fältström wrote:

> 
> On 26 okt 2012, at 13:32, Alissa Cooper <[email-masked]> wrote:
> 
>> The IAB is working on a document about "Technical Considerations for Internet Service Filtering," <http://tools.ietf.org/html/draft-iab-filtering-considerations-01>. Feedback and discussion are welcome on this list.
> 
> Thanks for the pointer to this document that I have missed earlier.
> 
> First, what is the intended goal with this document? I do not really see any recommendations in it. Is the idea to come with recommendations on how to do blocking given there is consensus on what to block?

I don't think we plan to do much more than clarify the technical implications and trade-offs of various blocking strategies. Since different entities that want to block things have different constraints and motivations, I think it would be hard to make meaningful recommendations with wide applicability. With that said, I think there is a clear conclusion in the draft that endpoint-based blocking comes into the least conflict with the Internet architecture.

> 
> Secondly, I think you should try to remove lots and lots of words. It is very long at the moment and I think / feel it would be more crisp if you manage later on to not be repetitive, and be more "to the point".

Agreed. We did not do this yet given that the text is still changing quite a bit. Hopefully on the next round we can cut it down.

> 
> Thirdly, even if this is a technical document, I think it is valuable to explain why it is a *technical* paper. From my point of view it is because IAB has not intention on walking down the path of describing the other half of "good blocking" which is "how to decide what to block". I would like you at least say this, so the reader do understand this "other piece" is also needed.

We tried to clarify this in section 1.

> 
> Lastly, please have a look at the just released SSAC document SAC056 (and the earlier SAC050) that you can find on <http://www.icann.org/en/groups/ssac/documents>. I think you find some ideas there that can help you when you do future versions of this document.

Thanks, and we have added a pointer to this.

Best,
Alissa

>   Regards, Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 24 Feb 2013 14:56:22 +0100

Thanks for this new version. It is definitely from my perspective a great improvement.

But, of course the world has moved on since the last version :-P Specifically we had the WCIT in dec 2012 where filtering and security issues once again was discussed.

I am looking at this text, which might have to be changed a bit:

> Both blocking and
> filtering can be effectuated at the level of "services" (web hosting
> or video streaming, for example) or at the level of particular
> "content."

One sensitive issue that did come up in the WCIT discussions where whether "responsibilities to act" (or responsibility for communication) requires inspection of "content" or not. As you say in this document, it is of course a question of how one look at the definition of "content". Some people for example do only view the body of an email message as content, while other might include the full SMTP conversation as content while the traditional 5-tuple identifying the flow of communication as non-content.

This came up in the discussion related to "spam" where there was a strong view from specifically some member states that did not sign the proposed treaty that "content issues should not be included in the treaties".

Because of this, the reader might *today* (as compared to before the meeting in December) look for clues where IAB do believe the blocking is the result of inspection of content, or whether the blocking is not so.

My personal view is that what is content is in the eyes of the inspector. Someone that operate at some layer in the value chain do view everything above that layer as content. And what in reality parties where discussing was whether a player that is responsible for moving for example IP packets (deals with routing etc) treat various contents of the IP packet as content or not. What they are allowed to do and not.

With that now on the table, I ask myself whether not "blocking" implies that someone that operates at a certain layer in the value chain does NOT look what that party believe is content while "filtering" do imply inspection of content.

I.e. that what you say here about "blocking" and "filtering" in reality is connected with specifically section 2.2 about layering. Together with the locality that also we in SSAC wrote about (impact on third party) -- with the addition that if one talk about enterprises for example, locality can be administrative (contractual) and not only based on AS.

One thing I would like to have more clear in the earlier part of the document and not only in last paragraph of 4.1.1, and that is what I personally divide into three different things:

A. Decision making process on what is to be blocked
B. Inspection of traffic (which is described in 4.1.1) whether it falls into the class of things that should be blocked
C. The blocking action itself

In some cases the action (A+B+C) because of weakness in [A], in other cases [B] due to privacy laws is not allowed, and finally one have to ask where the most effective action [C] is to be implemented so that number of impact is minimized.

   Patrik

---

From: John Day <[email-masked]>
Date: Sun, 24 Feb 2013 12:20:09 -0500

I would take the view that content is anything in 
the Application Layer, i.e. anything above TCP.

From there down can be regulated by communication 
regulators, e.g. the FCC, anything above that is 
either private and nobodies business or business 
which is regulated by the usual kinds of trade 
ministries, e.g. in the US, Dept of Commerce, 
Federal Trade Commission, etc.  To use your WCIT 
example, the web is outside their scope.  It may 
be inside the WTO scope.

One can't use what sorts of standards various 
SGOs produce as a guide.  SGOs are driven bottom 
up.  If enough people agree to do something, it 
is done.

Another way to get at the same thing is to use 
the distinction I use for distinguishing 
application protocols from data transfer 
protocols:  Application protocols act on objects 
(or modifies state) outside the protocol, e.g. 
FTP, SMTP, HTTP, SNMP, OSPF, etc. Whereas data 
transfer protocols act on objects (or modifies 
state) inside the protocol, e.g. TCP, Ethernet, 
IP, SCTP, etc.  OSPF is an interesting example of 
an application that has a layer management role 
within the layer.

Only data transfer protocols fall within the 
domain of WCIT might be concerned with.

I believe this is a rather clean distinction and 
can be related to first principles, whereas 
others are as you indicate more less clear.  I 
would also strongly suggest that not taking a 
strong position along these lines leads to 
situations we would like to avoid.

Take care,
John Day

At 2:56 PM +0100 2/24/13, Patrik Fältström wrote:
>But, of course the world has moved on since the 
>last version :-P Specifically we had the WCIT in 
>dec 2012 where filtering and security issues 
>once again was discussed.
>
>One sensitive issue that did come up in the WCIT 
>discussions where whether "responsibilities to 
>act" (or responsibility for communication) 
>requires inspection of "content" or not. As you 
>say in this document, it is of course a question 
>of how one look at the definition of "content". 
>Some people for example do only view the body of 
>an email message as content, while other might 
>include the full SMTP conversation as content 
>while the traditional 5-tuple identifying the 
>flow of communication as non-content.
>
>This came up in the discussion related to "spam" 
>where there was a strong view from specifically 
>some member states that did not sign the 
>proposed treaty that "content issues should not 
>be included in the treaties".
>
>Because of this, the reader might *today* (as 
>compared to before the meeting in December) look 
>for clues where IAB do believe the blocking is 
>the result of inspection of content, or whether 
>the blocking is not so.
>
>
>My personal view is that what is content is in 
>the eyes of the inspector. Someone that operate 
>at some layer in the value chain do view 
>everything above that layer as content. And what 
>in reality parties where discussing was whether 
>a player that is responsible for moving for 
>example IP packets (deals with routing etc) 
>treat various contents of the IP packet as 
>content or not. What they are allowed to do and 
>not.
>
>With that now on the table, I ask myself whether 
>not "blocking" implies that someone that 
>operates at a certain layer in the value chain 
>does NOT look what that party believe is content 
>while "filtering" do imply inspection of content.
>
>I.e. that what you say here about "blocking" and 
>"filtering" in reality is connected with 
>specifically section 2.2 about layering. 
>Together with the locality that also we in SSAC 
>wrote about (impact on third party) -- with the 
>addition that if one talk about enterprises for 
>example, locality can be administrative 
>(contractual) and not only based on AS.
>
>One thing I would like to have more clear in the 
>earlier part of the document and not only in 
>last paragraph of 4.1.1, and that is what I 
>personally divide into three different things:
>
>B. Inspection of traffic (which is described in 
>4.1.1) whether it falls into the class of things 
>that should be blocked
>In some cases the action (A+B+C) because of 
>weakness in [A], in other cases [B] due to 
>privacy laws is not allowed, and finally one 
>have to ask where the most effective action [C] 
>is to be implemented so that number of impact is 
>minimized.
>
>    Patrik
>
>>  We have posted a new version: 
>><http://www.ietf.org/id/draft-iab-filtering-considerations-02.txt>. 
>>Some comments are inline below.
>>
>>>>  The IAB is working on a document about 
>>>>"Technical Considerations for Internet 
>>>>Service Filtering," 
>>>><http://tools.ietf.org/html/draft-iab-filtering-considerations-01>. 
>>>>Feedback and discussion are welcome on this 
>>>>list.
>>>
>>>  First, what is the intended goal with this 
>>>document? I do not really see any 
>>>recommendations in it. Is the idea to come 
>>>with recommendations on how to do blocking 
>>>given there is consensus on what to block?
>>
>>  I don't think we plan to do much more than 
>>clarify the technical implications and 
>>trade-offs of various blocking strategies. 
>>Since different entities that want to block 
>>things have different constraints and 
>>motivations, I think it would be hard to make 
>>meaningful recommendations with wide 
>>applicability. With that said, I think there is 
>>a clear conclusion in the draft that 
>>endpoint-based blocking comes into the least 
>>conflict with the Internet architecture.
>>
>>>
>>>  Secondly, I think you should try to remove 
>>>lots and lots of words. It is very long at the 
>>>moment and I think / feel it would be more 
>>>crisp if you manage later on to not be 
>>>repetitive, and be more "to the point".
>>
>>  Agreed. We did not do this yet given that the 
>>text is still changing quite a bit. Hopefully 
>>on the next round we can cut it down.
>>
>>>
>>>  Thirdly, even if this is a technical 
>>>document, I think it is valuable to explain 
>>>why it is a *technical* paper. From my point 
>>>of view it is because IAB has not intention on 
>>>walking down the path of describing the other 
>>>half of "good blocking" which is "how to 
>>>decide what to block". I would like you at 
>>>least say this, so the reader do understand 
>>>this "other piece" is also needed.
>>
>>>  Lastly, please have a look at the just 
>>>released SSAC document SAC056 (and the earlier 
>>>SAC050) that you can find on 
>>><http://www.icann.org/en/groups/ssac/documents>. 
>>>I think you find some ideas there that can 
>>>help you when you do future versions of this 
>>>document.
>>
>_______________________________________________
>Architecture-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: "cdel.firsthand.net" <[email-masked]>
Date: Mon, 25 Feb 2013 17:39:59 +0100

So you are proposing a list of "data transfer" protocols that are fair game to "wire" regulators? Or the other way round? 

Best

Christian de Larrinaga

On 24 Feb 2013, at 18:20, John Day <[email-masked]> wrote:

> I would take the view that content is anything in the Application Layer, i.e. anything above TCP.
> 
> From there down can be regulated by communication regulators, e.g. the FCC, anything above that is either private and nobodies business or business which is regulated by the usual kinds of trade ministries, e.g. in the US, Dept of Commerce, Federal Trade Commission, etc.  To use your WCIT example, the web is outside their scope.  It may be inside the WTO scope.
> 
> One can't use what sorts of standards various SGOs produce as a guide.  SGOs are driven bottom up.  If enough people agree to do something, it is done.
> 
> Another way to get at the same thing is to use the distinction I use for distinguishing application protocols from data transfer protocols:  Application protocols act on objects (or modifies state) outside the protocol, e.g. FTP, SMTP, HTTP, SNMP, OSPF, etc. Whereas data transfer protocols act on objects (or modifies state) inside the protocol, e.g. TCP, Ethernet, IP, SCTP, etc.  OSPF is an interesting example of an application that has a layer management role within the layer.
> 
> Only data transfer protocols fall within the domain of WCIT might be concerned with.
> 
> I believe this is a rather clean distinction and can be related to first principles, whereas others are as you indicate more less clear.  I would also strongly suggest that not taking a strong position along these lines leads to situations we would like to avoid.
> 
> Take care,
> John Day
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 09:03:37 -0800

Hi, John, et al.,

> I would take the view that content is anything in the Application Layer,

For the purposes of this doc, IMO "content" ought to be anything above 
the layer of the service I pay you for.

There are no other distinctions; what you call an application protocol I 
might call a transport or network, esp. when I tunnel TCP or IP over it.

I.e., if I pay for IP access, then TCP and other transports are content, 
and you have no business looking at it - and can't look at it if I 
encrypt it.

If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not direct IP 
forwarding - then "content" is whatever those protocols carry. HTTP 
might carry web pages, but it might also carry any other service over 
HTTP (there are many).

IMO, the regulators ought to require service providers to explain the 
service they are providing and be held to that.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 11:15:39 -0800

Some other comments:

- content-based usage restrictions go back to long before 1988; the 
NSFNet prohibited commercial use. Granted this isn't an historical 
summary, but it should be noted that this issue has been with us for a 
very long time

- we do have a definition of what it means to be on the Internet (RFCs 
1122/1123, from a host viewpoint, e.g.); many "access providers" don't 
provide Internet service because they block critical signalling (some 
ICMP messages) or limit what can be in an IP packet

The whole point of IP is an internetworking layer. *ANYTHING* that 
limits what can be in an IP packet except by length is interfering with 
that. IMO, filtered access simply isn't the Internet, and shouldn't be 
passed off as such. But until we have compliance certification, the 
point seems moot.

- blocking on ports ought to be pointed out as useless. a port is both a 
point of demux and an indicator of a service, but ONLY between 
cooperating endpoints. port numbers have no meaning outside that of a 
"flow" outside the two endpoints of a connection. assigning meaning to 
those numbers only creates a situation where users WILL remap the 
correlation between ports and services

The net effect is to require more Internet infrastructure (e.g., dynamic 
service discovery). Assuming that a port means a service ought to be 
highlighted as the nonsense it is.

- short of introducing compliance certification, I don't think its 
useful for the IAB to try to explain any of this or even take a position 
on it.

JOe

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 11:20:57 -0800

PS - my view of what's required is here:

http://www.isi.edu/touch/internet-rights/

It takes into account the desire to avoid being spammed/DOS attacked, 
but ensures that communication can be established between cooperating 
endpoints.

Any service provider offering Internet service ought to held to abide by 
this list, IMO.

Joe

---

From: John Day <[email-masked]>
Date: Tue, 26 Feb 2013 14:35:19 -0500

At 9:03 AM -0800 2/25/13, Joe Touch wrote:
>For the purposes of this doc, IMO "content" ought to be anything 
>above the layer of the service I pay you for.

So if my provider provides email, and bundles it in what I pay, even 
if I don't use it, then email is not "content."  That doesn't work.

>
>There are no other distinctions; what you call an application 
>protocol I might call a transport or network, esp. when I tunnel TCP 
>or IP over it.

Not the way I defined it.  It has nothing to do with what is 
encapsulated in what.

>
>I.e., if I pay for IP access, then TCP and other transports are 
>content, and you have no business looking at it - and can't look at 
>it if I encrypt it.
>
>If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not 
>direct IP forwarding - then "content" is whatever those protocols 
>carry. HTTP might carry web pages, but it might also carry any other 
>service over HTTP (there are many).

Defining "data" in HTTP may be a bit difficult.

Take care,
John

>
>
>IMO, the regulators ought to require service providers to explain 
>the service they are providing and be held to that.
>
>Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 Feb 2013 11:55:06 -0800

Hi, John (et al.)

On 2/26/2013 11:35 AM, John Day wrote:
> So if my provider provides email, and bundles it in what I pay, even if
> I don't use it, then email is not "content."  That doesn't work.

If you pay for IP, then the fact that the packet is email vs. file 
transfer is content. As is anything above that, including the email or 
file content.

If you pay for email access, then the fact that you're doing email isn't 
content, but the content of the email is.

>> There are no other distinctions; what you call an application protocol
>> I might call a transport or network, esp. when I tunnel TCP or IP over
>> it.
>

You referred directly to protocols, but those protocols don't exist at 
exactly one layer in a stack.

>> content, and you have no business looking at it - and can't look at it
>> if I encrypt it.
>>
>> If I pay for "portal" access - e.g., HTTP, IMAP, etc., but not direct
>> IP forwarding - then "content" is whatever those protocols carry. HTTP

HTTP data is the response to a GET or "enclosed" with a PUT or PATCH.

The stuff you send to make that happen inside the HTTP protocol messages 
isn't data; it's control.

I.e., data is the part of an HTTP message that interpreters don't parse.

Joe

---

From: John Day <[email-masked]>
Date: Tue, 26 Feb 2013 15:18:09 -0500

At 11:55 AM -0800 2/26/13, Joe Touch wrote:
>transfer is content. As is anything above that, including the email 
>or file content.
>
>If you pay for email access, then the fact that you're doing email 
>isn't content, but the content of the email is.

Ahhh, so you agree with me.  Email performs operations external to 
the protocol.

>You referred directly to protocols, but those protocols don't exist 
>at exactly one layer in a stack.

I never said they did.  I spoke of a class of protocols defined by 
their characteristics.  Not where they are in the stack.  Where in 
the stack is irrelevant.

Take care,
John

>The stuff you send to make that happen inside the HTTP protocol 
>messages isn't data; it's control.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 Feb 2013 12:54:46 -0800

On 2/26/2013 12:18 PM, John Day wrote:
>>>>> I would take the view that content is anything in the Application
>>>>> Layer,
>>>>> i.e. anything above TCP.
>>>>
> Ahhh, so you agree with me.  Email performs operations external to the
> protocol.

TCP does it by reading/writing byte streams. IP does it by 
reading/writing buffers.

Those operations are just the upper layer API, and most protocols have - 
or could have - one.

> I never said they did.  I spoke of a class of protocols defined by their
> characteristics.  Not where they are in the stack.  Where in the stack
> is irrelevant.

You gave examples in each category. My point is that the examples fit in 
either category depending on how they're used.

Joe