Re: Protocols at the Point of a Gun

At 9:48 4/10/96, Duncan Frissell wrote:
[...]
>We know that governments would like to impose things like the Simple
>Tax Transfer Protocol on the Net as well as Is A Person (and Is A Minor)
>Protocols.

There is one thing about the proposed minor flag addition to IP that I
don't understand. [No, I am not surprised by this. Mandatory authorization
to establish a connection and an "Internet Driver License", probably in the
form or a smart card are coming].

If my computer creates the IP packet, what is there to prevent me from
modifying the value of the "Minor/Adult" flag at my leisure?


-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.

Lucky Green writes:
> There is one thing about the proposed minor flag addition to IP that I
> don't understand. [No, I am not surprised by this. Mandatory authorization
> to establish a connection and an "Internet Driver License", probably in the
> form or a smart card are coming].
> 
> If my computer creates the IP packet, what is there to prevent me from
> modifying the value of the "Minor/Adult" flag at my leisure?

Nothing prevents you from doing that, not that there is any place to
put such a flag. Moreover, it is highly unclear what the semantics are
in general, or how an application would know about them, or what you
do in tunnelling such packets, or what it means in a TCP stream if
some packets are flagged and some aren't, etc, etc. The whole thing is
a crock of shit. (Normally, I wouldn't say that but I'm trying to
violate the CDA as often as possible these days.) Its yet another case
of idiots who don't know technology pretending that technical people
are magicians who can just do anything by waving a wand, and if we say
something can't be done it must mean that we are being stubborn or
some such. Reminds me of the train disaster section of "Atlas
Shrugged". Ah, well.

Perry

Lucky Green writes:
>At 9:48 4/10/96, Duncan Frissell wrote:
>[...]
>>We know that governments would like to impose things like the Simple
>>Tax Transfer Protocol on the Net as well as Is A Person (and Is A Minor)
>>Protocols.
>
>There is one thing about the proposed minor flag addition to IP that I
>don't understand. [No, I am not surprised by this. Mandatory authorization
>to establish a connection and an "Internet Driver License", probably in the
>form or a smart card are coming].
>
>If my computer creates the IP packet, what is there to prevent me from
>modifying the value of the "Minor/Adult" flag at my leisure?

Yikes!  Don't lend it the credibility of calling it "proposed".
Someone might think you're serious.  "Suggested" is as far as I'd go.

Anyway, you computer creates the IP packet, but then sends it to your
ISP's router.  That router *always* makes changes to the packet header
because it must decrement the time-to-live field and recompute the
header checksum.  The ISP's router software would (in the scenario I
suggested, but deplore), based on to whom it's connected, set the
drivers licence flag as it sees fit.  When a PPP account of a "minor"
sends a packet, the router always inserts "minor".  When the account of
an adult sends it, it inserts "adult".  When the account of a partner
who has contractually accepted liability for the flag's setting sends a
packet, it leaves it alone.

Scott Brickner writes:
> Anyway, you computer creates the IP packet, but then sends it to your
> ISP's router.  That router *always* makes changes to the packet header
> because it must decrement the time-to-live field and recompute the
> header checksum.

There is a trivial trick for making the decrement TTL/change checksum
operation very fast, based on noting how a decrement would change the
checksum. Most very high speed routers attempt to avoid doing ANY
processing of the packets at all beyond this, and IPv6 has no header
checksum partially in order to reduce this overhead further. Forcing
routers to do more work is a Very Very Bad Idea.

Perry

"Perry E. Metzger" writes:
>Scott Brickner writes:
>> Anyway, you computer creates the IP packet, but then sends it to your
>> ISP's router.  That router *always* makes changes to the packet header
>> because it must decrement the time-to-live field and recompute the
>> header checksum.
>
>There is a trivial trick for making the decrement TTL/change checksum
>operation very fast, based on noting how a decrement would change the
>checksum. Most very high speed routers attempt to avoid doing ANY
>processing of the packets at all beyond this, and IPv6 has no header
>checksum partially in order to reduce this overhead further. Forcing
>routers to do more work is a Very Very Bad Idea.

As I pointed out in a private note to Perry, it's not the high-speed
routers that have to change the packets.  They typically are between
the sort of ISPs that would get "network common carrier" status, and
could rely on the options added (or not) by the other side.  It's only
when the packet crosses the border from outside the "common carrier"
net to inside that the header needs changed, and that's usually at a
terminal server, not a "very high speed router".

>Lucky Green writes:
>>At 9:48 4/10/96, Duncan Frissell wrote:
>>[...]
>>>We know that governments would like to impose things like the Simple
>>>Tax Transfer Protocol on the Net as well as Is A Person (and Is A Minor)
>>>Protocols.
>>
>>There is one thing about the proposed minor flag addition to IP that I
>>don't understand. [No, I am not surprised by this. Mandatory authorization
>>to establish a connection and an "Internet Driver License", probably in the
>>form or a smart card are coming].
>>
>>If my computer creates the IP packet, what is there to prevent me from
>>modifying the value of the "Minor/Adult" flag at my leisure?
>
>Yikes!  Don't lend it the credibility of calling it "proposed".
>Someone might think you're serious.  "Suggested" is as far as I'd go.
>
>Anyway, you computer creates the IP packet, but then sends it to your
>ISP's router.  That router *always* makes changes to the packet header
>because it must decrement the time-to-live field and recompute the
>header checksum.  The ISP's router software would (in the scenario I
>suggested, but deplore), based on to whom it's connected, set the
>drivers licence flag as it sees fit.  When a PPP account of a "minor"
>sends a packet, the router always inserts "minor".  When the account of
>an adult sends it, it inserts "adult".  When the account of a partner
>who has contractually accepted liability for the flag's setting sends a
>packet, it leaves it alone.
>
How would this work in my case?
I have a Pipeline 25 ISDN router in my house.
I have several computers, used by myself, my wife, and my kids, connected
via Ethernet to the p25. The router talks to my provider. I have _one_
account at my provider.

Multiple IP #s, multiple machines, multiple users, ONE account.
Which router will insert the "suggested" flag, and how will it decide which
packets to tag?

I suspect the people who thought this up haven't thought it through. :-)
They are confusing "ISP accounts" with "e-mail" addresses, maybe?

My setup may be unusual, but it's certainly not unique.

-- Marshall

Marshall Clow     Aladdin Systems   <mailto:mclow@mailhost2.csusm.edu>

"Eternal vigilance is the price of PostScript"
-- MacUser Jan 96 DTP and Graphics column

Marshall Clow writes:
>>Anyway, you computer creates the IP packet, but then sends it to your
>>ISP's router.  That router *always* makes changes to the packet header
>>because it must decrement the time-to-live field and recompute the
>>header checksum.  The ISP's router software would (in the scenario I
>>suggested, but deplore), based on to whom it's connected, set the
>>drivers licence flag as it sees fit.  When a PPP account of a "minor"
>>sends a packet, the router always inserts "minor".  When the account of
>>an adult sends it, it inserts "adult".  When the account of a partner
>>who has contractually accepted liability for the flag's setting sends a
>>packet, it leaves it alone.
>>
>How would this work in my case?
>I have a Pipeline 25 ISDN router in my house.
>I have several computers, used by myself, my wife, and my kids, connected
>via Ethernet to the p25. The router talks to my provider. I have _one_
>account at my provider.
>
>Multiple IP #s, multiple machines, multiple users, ONE account.
>Which router will insert the "suggested" flag, and how will it decide which
>packets to tag?

The way I envision it (in my nightmares), you'd have two options:  have
the account configured as "kid safe", and live in a cyberspace playground,
or have it configured as "adult", and accept responsibility for your kids'
use.  As I see it, with the censorship support at the network layer that
I outlined, the ISP can have "common carrier" status.  They sold the account
to an adult, so all packets delivered to the account are delivered to that
adult, as owner of the ISDN router.  If the adult chooses to then deliver
that packet to a child, it's no different than if the adult buys a copy
of "Debbie Does Dallas" and shows it to the kid.

>I suspect the people who thought this up haven't thought it through. :-)
>They are confusing "ISP accounts" with "e-mail" addresses, maybe?

Well, I don't know that the CDA supporters are thinking of.  I just
responded to the charge of "technically infeasible" with an outlined
technical solution.

I *do* think that the separation between ISP account and email address
isn't quite as black and white as you seem to think.

>My setup may be unusual, but it's certainly not unique.

Actually, I expect configurations like yours to become more widespread
in the near future.  There are a lot of cable-modem designs that
basically put an ethernet port on your cable box.  There's little
practical difference (from a network topology perspective) between that
and your ISDN setup.

> Multiple IP #s, multiple machines, multiple users, ONE account.
> Which router will insert the "suggested" flag, and how will it decide which
> packets to tag?
> I suspect the people who thought this up haven't thought it through. :-)
> They are confusing "ISP accounts" with "e-mail" addresses, maybe?

Well, this was originally suggested by the CDA supporters, out of the 
mouth of their LAWYER. And, for sure, it's just legal posturing, saying
it's possible, but not understanding the details.

Really, the apropriate place for content filtering is at the application 
layer. It *could* be done at the transport layer, but that's really not 
the place for it.

Analogy: It would be like putting a license plate on the engine of a car. 
It *could* be done that way, if you redesign the car so that the engine
protrudes out from the back with a place for the license plate (let the
technical people handle the technical details of that). But the best place
for a license plate is on the outside body of the car, and the best place
for content filtering is at the application layer. 

All of this, of course, is Just My Humble Opinion.


=====================================================================
| Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/)    |
| Email: steve@edmweb.com   Home Page: http://www.edmweb.com/steve/ |
| PGP Fingerprint: 11 C8 9D 1C D6 72 87 E6  8C 09 EC 52 44 3F 88 30 |
|              -- Disclaimer: JMHO, YMMV, IANAL. --                 |
===================================================================:)

Steve Reid writes:
>Really, the apropriate place for content filtering is at the application 
>layer. It *could* be done at the transport layer, but that's really not 
>the place for it.

Izzat so?  So explain to me what the difference between the PICS type
ratings and security classifications is.  If something is labelled "Top
Secret" with some compartments, it means "do not deliver this to a
principal which hasn't been authorized to receive it".  If something is
labelled "Not suitable for minors", it means "do not deliver this to a
minor".  "Age of majority" is really no different than a security
clearance to receive certain information in the CDA context.

Clearly the IETF believed that the network layer was an appropriate
place for general classification when they developed IPv4.  I haven't
verified it, but I suspect that IPv6 has (or will have) an appropriate
mechanism for indicating security classification.  The identical
mechanism may be used for packet labelling, with the broad
classification indicating the distinctions between "G", "PG", "PG-13",
"R", and "NC-17", and the compartments available for such things as
"violence", "nudity", "adult language", "sexual content",
"advertising", and so forth.

>Analogy: It would be like putting a license plate on the engine of a car. 
>It *could* be done that way, if you redesign the car so that the engine
>protrudes out from the back with a place for the license plate (let the
>technical people handle the technical details of that). But the best place
>for a license plate is on the outside body of the car, and the best place
>for content filtering is at the application layer. 

Of course, putting it at the application layer is like requiring that
every driver create his own license plate and hold it out the window
while driving.

Scott Brickner writes:
> 
> Steve Reid writes:
> >Really, the apropriate place for content filtering is at the application 
> >layer. It *could* be done at the transport layer, but that's really not 
> >the place for it.
> 
> Izzat so?  So explain to me what the difference between the PICS type
> ratings and security classifications is.

> Clearly the IETF believed that the network layer was an appropriate
> place for general classification when they developed IPv4.  I haven't
> verified it, but I suspect that IPv6 has (or will have) an appropriate
> mechanism for indicating security classification.

That's not at all clear.  The IETF did not sit down in committee and
"develop IPv4" (thank god).  And I've not seen any evidence that it was
designed with support for security labels in mind.

Personally, I agree with Steve that, even though IP *may* be used to
propagate security options, it isn't the "right" place.

One problem with labeling things at the transport level is that this
requires support for the labels throughout the operating system(s) on
which the "content" is generated (at least for a "real" multi-user system
with a potentially mixed adult/child user base) or through which it flows.
The operating system has to carry labels around in conjunction with each
and every process and file on the system in order that the low-level
software will be able to accurately label IP datagrams.  And this OS
support is both difficult to implement and onerous to the users and
applications running on that platform -- otherwise, we'd all be running
on TCSEC B-level operating systems right now.

Fundamentally, the decision boils down to whether you want the labeling
to be mandatory (as with DoD security labels) or voluntary as with PICS.


-- Jeff

Jeff Barber writes:
>Scott Brickner writes:
>> Steve Reid writes:
>> >Really, the apropriate place for content filtering is at the application 
>> >layer. It *could* be done at the transport layer, but that's really not 
>> >the place for it.
>> 
>> Izzat so?  So explain to me what the difference between the PICS type
>> ratings and security classifications is.
>
>> Clearly the IETF believed that the network layer was an appropriate
>> place for general classification when they developed IPv4.  I haven't
>> verified it, but I suspect that IPv6 has (or will have) an appropriate
>> mechanism for indicating security classification.
>
>That's not at all clear.  The IETF did not sit down in committee and
>"develop IPv4" (thank god).  And I've not seen any evidence that it was
>designed with support for security labels in mind.

Nevertheless, security labels *already* exist in IPv4.

>Personally, I agree with Steve that, even though IP *may* be used to
>propagate security options, it isn't the "right" place.
>
>One problem with labeling things at the transport level is that this

Actually, we're talking about the network level.  The transport level
is where TCP and UDP reside, not IP, which has the security labels.

>requires support for the labels throughout the operating system(s) on
>which the "content" is generated (at least for a "real" multi-user system
>with a potentially mixed adult/child user base) or through which it flows.
>The operating system has to carry labels around in conjunction with each
>and every process and file on the system in order that the low-level
>software will be able to accurately label IP datagrams.  And this OS
>support is both difficult to implement and onerous to the users and
>applications running on that platform -- otherwise, we'd all be running
>on TCSEC B-level operating systems right now.

I'm beginning to agree with the CDA supporter who claimed that "you're
just trying to protect your pornography by saying it's impossible when
we all know otherwise."  Of course, that person really didn't know
otherwise, but I do.  The abstract model of the Internet network layer
thinks of all transport entities as equivalent, as are all link
entities.  In the real world, such mixed user bases are unusual.  If my
scheme were implemented, service providers would probably have to
segregate shell account access onto "childproof" and "adult" machines,
or acquire a TCSEC B level system.  Either approach works, and most
would likely choose the former, since its cheaper.  It's still not
really that many machines.

>Fundamentally, the decision boils down to whether you want the labeling
>to be mandatory (as with DoD security labels) or voluntary as with PICS.

I don't want the labelling to exist at all.  But I note that even PICS
labelling is not strictly voluntary.  A content provider who fails to
label adult material as "unsuitable for minors" is fully liable for
legal penalties should such material be transmitted to a minor.  The CDA
has nothing to do with it.  It's the same situation as when a bookstore
sells Playboy to a minor or a liquor store sells him beer.

As I outlined the scheme, network layer labels are just as "voluntary".
They really are in the DoD security world, too.  If you create a file in
an editor, you're responsible for making sure the right classification
goes on it, and *you're* going to be held accountable if the information
is leaked because you put the wrong label on it.

In article <199604172021.QAA01638@universe.digex.net>,
Scott Brickner <sjb@universe.digex.net> wrote:

> I'm beginning to agree with the CDA supporter who claimed that "you're
> just trying to protect your pornography by saying it's impossible when
> we all know otherwise."  Of course, that person really didn't know
> otherwise, but I do.  The abstract model of the Internet network layer
> thinks of all transport entities as equivalent, as are all link
> entities.  In the real world, such mixed user bases are unusual.  If my
> scheme were implemented, service providers would probably have to
> segregate shell account access onto "childproof" and "adult" machines,
> or acquire a TCSEC B level system.  Either approach works, and most
> would likely choose the former, since its cheaper.  It's still not
> really that many machines.

Don't forget: There are lots of colleges and universities on the net,
and most of these universities have undergraduates, and a significant
fraction of these undergraduates are minors.  The potential user base is
going to be mixed and must be presumed to be so.  (That, I'm told, is
the chief justification of the Carnegie-Mellon ban on the alt.sex.*
Usenet newsgroups.) *Lots* of systems are affected by this problem.

(Remember, as far as the CDA is concerned, a seventeen-year-and-eleven-
month-old downloading nekkid pictures is every bit as bad as a
six-year-old doing so.)

-- 
Alan Bostick               | They say in online country there is no middle way
mailto:abostick@netcom.com | You'll either be a Usenet man or a thug for the CDA
news:alt.grelb             |    Simon Spero (after Tom Glazer)
http://www.alumni.caltech.edu/~abostick

On Thu, 18 Apr 1996, Alan Bostick wrote:

> Don't forget: There are lots of colleges and universities on the net,
> and most of these universities have undergraduates, and a significant
> fraction of these undergraduates are minors.  The potential user base is
> going to be mixed and must be presumed to be so.  (That, I'm told, is
> the chief justification of the Carnegie-Mellon ban on the alt.sex.*
> Usenet newsgroups.) *Lots* of systems are affected by this problem.


This is an excellent point, and one worth repeating. The Chronicle of
Higher Education has been quite diligent in covering the CDA hearings in
Philadelphia since their readership is concerned about this issue. 

As for CMU's justification for censoring USENET newsgroups, the legal
justification for protecting minors is non-existent -- the
administration's reasons are financial and PR. Check out this February
1996 thread on the fight-censorship list: 

http://fight-censorship.dementia.org/fight-censorship/dl?thread=CMU+basks+in+favorable+publicity+from+Rimm+study,+Usenet+censorship&after=1323
  The attached excerpt from a Carnegie Mellon University PR newsletter
  shows how top administrators are basking in the publicity sparked by the
  Rimm study and CMU's CompuServe-esque censorship of sexual discussion
  groups in November 1994. The Warner Hall bureaucrats are smug in
  claiming they were justified in "limiting the access of pornography on
  our campus computers." 

Of course, that's not to say that CMU administrators aren't prudes as well.

For more info:
  http://www.cs.cmu.edu/~declan/rimm/
  http://www.cs.cmu.edu/~kcf/censor/
  http://joc.mit.edu/cmu.html

-Declan


// declan@eff.org // I do not represent the EFF // declan@well.com //

> >Really, the apropriate place for content filtering is at the application 
> >layer. It *could* be done at the transport layer, but that's really not 
> >the place for it.

> Clearly the IETF believed that the network layer was an appropriate
> place for general classification when they developed IPv4.  I haven't
> verified it, but I suspect that IPv6 has (or will have) an appropriate
> mechanism for indicating security classification.  The identical
> mechanism may be used for packet labelling, with the broad

Security classification and "decent/indecent" ratings are rather
different, IMHO. With security, the author of the data has to decide the
best rating for his/her own security. With decent/indecent filtering, the
author has to decide what is best for _other_people_. I suppose it's not 
as bad as that with the third-party ratings in PICS, but there will still 
be inconsistancies.

The main reason I think decent/indecent filtering should be done at the
application level is, if they create a ratings system and later decide
that they've screwed up and another system would be better (which is quite
possible, if you understand the previous paragraph), all that's really
required is re-writing the application software. OTOH, if they did it at
the transport layer and later decided to switch to something else, they
would have to change the protocol, which is very difficult. And, depending
on the changes, they may have to re-write the apps again anyways. 

Also, at the application layer, ANYONE could create their own ratings
system, and the market could decide which is best. (The downside of that 
is that there would be nonstandardized chaos for a while).

Just My Humble Opinion.

=====================================================================
| Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/)    |
| Email: steve@edmweb.com   Home Page: http://www.edmweb.com/steve/ |
| PGP Fingerprint: 11 C8 9D 1C D6 72 87 E6  8C 09 EC 52 44 3F 88 30 |
|              -- Disclaimer: JMHO, YMMV, IANAL. --                 |
===================================================================:)

>>>>> Steve Reid writes:

SR> Analogy: It would be like putting a license plate on the engine of
SR> a car.  It *could* be done that way, if you redesign the car so
SR> that the engine protrudes out from the back with a place for the
SR> license plate (let the technical people handle the technical
SR> details of that). But the best place for a license plate is on the
SR> outside body of the car, and the best place for content filtering
SR> is at the application layer.

	No, the best place for content filtering is in that grey lump
mounted between the shoulders of most humans.  But that relys too much
on personal responsibility for the NetNannies to accept.  Besides the
fact that most of the NetNannies don't seem to use that grey lump that
often.

-- 
#include <disclaimer.h>                               /* Sten Drescher */
ObCDABait:      For she doted upon their paramours, whose flesh is as the
flesh of asses, and whose issue is like the issue of horses.  [Eze 23:20]
Unsolicited email advertisements will be proofread for a US$100/page fee.

SR> the best place for content filtering is at the application layer.

> 	No, the best place for content filtering is in that grey lump
> mounted between the shoulders of most humans.  But that relys too much
> on personal responsibility for the NetNannies to accept.  Besides the
> fact that most of the NetNannies don't seem to use that grey lump that
> often.

It *should* be at the "noodle layer", but I think it will be a lot more 
practical to install it at the application layer, unfortunately. :-/

[Note: What follows is a rant, but I think it's an important rant.]

I think parents probably are expecting the internet to be a babysitter
like they expect TV to be. A certain elected official (Exon?) tried to
explain the net, and said it was "like a telephone"... <sigh> In a world 
where TV is about as high-tech as most people get, people don't even 
understand the potential of a single unlinked computer, nevermind the 
potential of the internet and crypto.

Maybe the average person is trying to learn these things without learning
the basics, and thus ends up clueless about everything... If people don't
understand how text, programs, images, sound, video, and eventually ALL
THINGS can be described as a series of ones and zeros, how can they
understand the potential of the internet? It would be like trying to
understand light bulbs without knowing what electricity is. 

=====================================================================
| Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/)    |
| Email: steve@edmweb.com   Home Page: http://www.edmweb.com/steve/ |
| PGP Fingerprint: 11 C8 9D 1C D6 72 87 E6  8C 09 EC 52 44 3F 88 30 |
|              -- Disclaimer: JMHO, YMMV, IANAL. --                 |
===================================================================:)

> At 9:48 4/10/96, Duncan Frissell wrote:
> [...]
> >We know that governments would like to impose things like the Simple
> >Tax Transfer Protocol on the Net as well as Is A Person (and Is A Minor)
> >Protocols.
> 
> There is one thing about the proposed minor flag addition to IP that I
> don't understand. [No, I am not surprised by this. Mandatory authorization
> to establish a connection and an "Internet Driver License", probably in the
> form or a smart card are coming].
> 
> If my computer creates the IP packet, what is there to prevent me from
> modifying the value of the "Minor/Adult" flag at my leisure?

In the future, you will have to sign all packets (with a key
conveniently available from verisign and noone else).

Just kidding. =) 

Christopher

On Wed, 10 Apr 1996, Christopher J. Shaulis wrote:
> 
> In the future, you will have to sign all packets (with a key
> conveniently available from verisign and noone else).

No - the company that will bring it to you: AT&T :)

Seriously - putting this sort of stuff at the IP layer is not doable; 
confidentiality and encryption, at least on a host-to-host basis is 
sensible (we know a protocol about that, don't we children)

Application AND user level authentication doesn't fit so well below the 
application level. 

Simon
p.s.

Am I the only one to find it really wierd that the Unabomber had a 
pen-pal? Guess they don't last long..

 ---
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO