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:
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.
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. -- | ===================================================================:)
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 //
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
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".
participants (11)
-
abostick＠netcom.com -
Christopher J. Shaulis -
Declan McCullagh -
Jeff Barber -
Marshall Clow -
Perry E. Metzger -
Scott Brickner -
shamrock＠netcom.com -
Simon Spero -
Sten Drescher -
Steve Reid