brian@wb6rqn.UUCP (Brian Lloyd) (02/26/88)
Here at Sirius Systems we have been discussing a means to protect our
TCP/IP software without placing undue strain on the users. The primary
concern is that someone might purchase one copy of the package and then
copy it to all his/her systems. The concept that we came up with is to
exchange serial number information as part of the options field in the
TCP header when two TCP's exchange SYNs at session establishment. TCP
resets the connection and returns a protocol error if both versions of
the software have the same serial number.
Our reading of MIL-1778 and RFC-793 leads us to believe that the only
predefined option types are 0 (End of option list), 1 (No-op), and 2
(MSS). We propose a fourth option (type 3) for exchanging serial
numbers. The option type would be 3, the length would be 8, the next
two octets would be a vendor code, and the last four octets would be the
serial number.
The separate vendor code and serial number permits vendors to have
identical serial numbers but still allow the overall value of the
combined fields to be unique. This would prevent potential conflicts
when communicating between different vendors' software/hardware.
Now comes the reason for this letter: is a strange option in a TCP
header likely to break others' TCP implementations or will other TCPs
ignore an unrecognized option?
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!CERF@A.ISI.EDU (02/27/88)
If you plan to break if you get the same serial number as you sent, you will fail to provide service to processes that call themselves. The TCP protocol specifically allows this (supports it as a simultaneous initiation of connection case). The idea is to allow processes, whereever situated, to use the TCP/IP as a way of communicating. It sounds to me as if your serial number checking plan will break that feature... Vint P.S. I just realized that your plan would break communications between distinct processes in the same host should they try to communicate via TCP/IP. In applications for which software is moved from one place to another during or prior to execution, a process might well call another in the same host without realizing it. Furthermore, you might want that feature so as to avoid having to do something special to distinguish inter-host and intra-host communication. Vint
CERF@A.ISI.EDU (02/27/88)
What if your host has two interfaces into the Internet with different Internet addresses - more checks for OK sources/sinks for a particular serial number? As a practical matter, if the checking causes enough difficulty, either you will dry up your market or someone will find a way to disable the check and then propagate copies of the "denatured" versions... The idea, while having some surface appeal, feels a lot like copy protect schemes which drove away the market. Vint
brian@wb6rqn.UUCP (Brian Lloyd) (02/28/88)
I am sorry that some of you think that the concept of exchanging serial
numbers is a poor one. I agree that it provides only limited protection
but it is a concern of the principles of the corporation.
In the environment where it will run most frequently, i.e. in a LAN
consisting of Convergent 'S' series UNIX boxes and Convergent NGen
workstations, the scheme will be relatively effective. NGens run a
distributed operating system called CTOS so the serial number exchange
will be effective.
I appreciate the feedback and I understand that some of you would not
choose such a mechanism. On the other hand it will work and it will not
impact operations with other, dissimilar systems. I reiterate my
original request: will exchange of serial numbers in the TCP options
field cause problems with the other TCP implementations?
Thanks again.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!leonid@TAURUS.BITNET (02/28/88)
In article <8802251906.AA04676@wb6rqn.UUCP> brian@wb6rqn.UUCP writes: >Here at Sirius Systems we have been discussing a means to protect our >TCP/IP software without placing undue strain on the users. ... May I mention a very much similar solution done by Sun Microsystems in their PS-NFS 2.0 product, and please excuse me if this has already been mentioned. They just used ICMP discard packets to broadcast the serial number of each booting system. All non-PC-NFS system dropped those packets as they should, while all PC-NFS's look at this broadcast, make some sanity check and compare it to their own. If a violation has been detcted, the punishment is to stop both systems with the same number and print an appropriate message to the screen. To tell you the truth, I'm not really sure weather they use ICMP discard or UDP discard packets, but all are better than try to twist TCP for one's particular needs. Also, if a serial number problem would cause a TCP connection to fail, how a user would know that there is a problem hah? It seems that some vendors that really need a serial number protection scheme, should try to define a new UDP service which would very conveniently handle this and maybe other problems. Leonid
brian@wb6rqn.UUCP (Brian Lloyd) (02/29/88)
Thanks for the responses. Most of the responses have been of a
philosophical rather than a technical nature but I appreciate them
anyway. I guess that a further comment on the proposed serial number
exchange system is warrented.
The intention behind exchanging serial numbers is very simple: to keep
the software from being useful if it is copied. It protects by
preventing an operator from gaining an advantage from the copy while the
original is still running. In this way it is definitely a form of copy
protection. The intention is to provide a scheme that will help protect
our software in a manner that is totally transparent to the user. Any
protection system that in any way impedes the operations of a legitimate
user is not acceptable to us (I don't like copy protection schemes
either but I do want to protect our software).
We accept this scheme as being imperfect but useful and, as such, worth
our time to implement. In the environment where we operate (Convergent
Technologies workstations) this will be an effective protection scheme.
As for two clients running in the same host, we have dealt with that
problem. In our implementation of the protection scheme we bother to
exchange serial numbers only of the source and destination addresses are
different. Should the remote system fail to return the serial number
option the connection is permitted. The remote system has identified
that it is not one of our software implementations simply by the
omission of the serial number option in the TCP options field.
We have never bothered to deal with multi-homed hosts since our software
assumes a 1-to-1 correspondence between a host and an IP address.
Although that is not the case with all systems in the Internet, it is
with our software.
Now I will ask my original question again. Will the appearance of a
strange option in the TCP header cause a problem for other
implementations of TCP? I want to know if my serial number exchange
will confuse other TCP implementations or will they just ignore and
discard the information as I suspect they should. As I stated in my
second paragraph, we want the protection to be transparent and if it
prevents connectivity we won't use it.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!Mills@UDEL.EDU (03/01/88)
Brian, With all due respect, this is a terrible idea and is not worth even the effort to determine if other implementations will/will not break if the option is used. The IP Security Option is a much better mechanism and understood by most implementations known to me. If your scheme is less than ubiquitous using this option, the Protocol Police would even be expected to cooperate, since there are a lot of folks who are concerned about the issue. If the option does not satisfy your needs and you have a concrete proposal to add another, ubiquitous option that does, then please honk and I expect the INENG and/or INARC Task Forces will take it seriously. As it is, a copy-protect option that works only at TCP initial- connection time will not be taken seriously. Notwithstanding my view taken here, I would very much like to encourage you to pursue the issue vigorously. In particular, I suggest you take it up with Steve Kent's Privacy Task Force and with Deborah Estrin's Autonomous Networks Task force. I will certainly keep it nearby in the INARC Task Force. Dave
bzs@BU-CS.BU.EDU (Barry Shein) (03/02/88)
>The intention behind exchanging serial numbers is very simple: to keep >the software from being useful if it is copied. It protects by >preventing an operator from gaining an advantage from the copy while the >original is still running. In this way it is definitely a form of copy >protection. The intention is to provide a scheme that will help protect >our software in a manner that is totally transparent to the user. >Now I will ask my original question again. Will the appearance of a >strange option in the TCP header cause a problem for other >implementations of TCP? >Brian Lloyd, President >Sirius Systems, Inc. What I don't understand is given as you feel so comfortable with the idea of imposing various copy protection schemes to ensure maximizing profits etc (or your prediction that it will maximize profits, whether it will make your software fundamentally undesireable is argueable) why do you expect free advice to further your profits on this network? To respond in kind, many of us charge good money for consultations to provide the information you desire, I suggest you change your request to a help-wanted ad and put it somewhere appropriate. If it's not worth anything to you it's surely not worth anything to us. Check. Your move. -Barry Shein, Boston University
STJOHNS@SRI-NIC.ARPA (03/02/88)
From the ENTIRE IETF: "Applause!" Mike
geoff@eagle_snax.UUCP ( R.H. coast near the top) (03/04/88)
In article <669@taurus.BITNET>, leonid@TAURUS.BITNET writes: > In article <8802251906.AA04676@wb6rqn.UUCP> brian@wb6rqn.UUCP writes: > >Here at Sirius Systems we have been discussing a means to protect our > >TCP/IP software without placing undue strain on the users. ... > > May I mention a very much similar solution done by Sun Microsystems in their > PS-NFS 2.0 product, and please excuse me if this has already been mentioned. > They just used ICMP discard packets to broadcast the serial number of each [...] > To tell you the truth, I'm not really sure weather they use ICMP discard or > UDP discard packets... We use UDP discard packets (UDP port 9), and we wind up sending one about once an hour (depending on usage pattern). It hasn't broken any nets yet, as far as I know (and I'm sure the flames would have come thick and fast :-). And like Leonid I'd prefer an "official" solution. Anyone interested in talking about it? > > Leonid Geoff Arnold PC-NFS architect -- Geoff Arnold, Sun Microsystems | "Universes are just one of those things SPD at ECD (home of PC-NFS) | that happen from time to time..." UUCP:{ihnp4,decwrl...}!sun!garnold | [Dunno who said it - if you know, pass it ARPA:garnold@sun.com | on. G.A.]