[iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]

It's IETF stuff. Operator sanity check would probably be appreciated. :slight_smile:

-- Jeff

----- Forwarded message from IAB Chair <iab-chair@iab.org> -----

Speaking as a member of the IAB but not for the IAB, I would certainly
appreciate that review.


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:

The Call for Review will last until 26 February 2014.
Please send comments to iab@iab.org.


Some initial thoughts:

I'm not sure about the difference between network blocking and
endpoint blocking, but I think differences between the three major
types of network blocking are at least as significant as the
difference between network blocking and rendezvous blocking. If the
document calls out rendezvous blocking, it should call out all three
types of network blocking as well. Each has very different
characteristics which would be more effectively graded on the
document's criteria if discussed separately.

The three major types of networking blocking are:

packet blocking - only packets meeting certain criteria are allowed,
(e.g. IP destination address, inbound TCP with the ACK flag

stateful connection blocking - only packets belonging to layer-4
connections meeting certain criteria are allowed (e.g. TCP initiated
to port 80 outbound, TCP initiated to port 443 outbound)

protocol blocking - only connections containing specific known
protocols (e.g. http, ssl) are allowed, or alternately specific
identifiable protocols are blacklisted

The latter is a relatively new (within the last half decade) thing
that has become widely implemented in large enterprises. It started
out as deep packet inspection but has become much more.

Also, section 4.1.3 treats asymmetric routing as if it was usually or
always outside the control of the blocking entity. That's not
reasonable. There are as many network blocking scenarios where the
blocking authority can enforce symmetric routing as there are
scenarios where it can't. The efficacy discussion should recognize
that you have those two groups of scenarios and that the efficacy of
network blocking varies in each.

Further, the user's ability to tunnel around such blocks depends
heavily on the type of network blocking. Packet blocking can generally
be tunneled around given cooperating endpoints. When protocol blocking
is active, that proves far more challenging.

Bill Herrin

It's IETF stuff. Operator sanity check would probably be appreciated. :slight_smile:

Jeff, maybe run this past grow@ietf?