[comp.protocols.tcp-ip] TCP Options/Copy Protect

terry@DEC-VAX-11-750.ARPA (03/03/88)

All,

If there is an update to this, feel free to flame me, but please
be gentle.

****----

Brian Lloyd,

Mil-Std-1778, 12-Aug-1983, Page 92:

    There are two cases for the format of an option:

         a) A single octet of option-kind.

         b) An octet of option-kind, an octet of option-length,
            and the actual option-data octets.

The option-kind field determines the option being processed.  This
option-kind MUST be known, otherwise there is no way to tell whether
the next octet is a new option, or the length of the current option.

Therefore, further option processing cannot occur. 

Your Question: Will this upset any TCP implementations?
My Answer:     YES

In MY TCP implementation, an unknown option will cause a
message to be placed in a log file along with all of the 
remaining bytes in the TCP header.  If a valid option, such as 
maximum segment size, occurred after the unknown option the 
valid option would be ignored.  This could be serious.

I would take a guess and say that ALL TCP implementations are probably
not as gracious as mine.  Some probably would ignore the packet, others
might curl up and die, or worse.

*****-----

Non-TCP-Related-Topic:

There is a place for copy protection schemes in the world.  However,
your scheme only prevents your TCP from talking to itself, not to other
TCP implementations.  Besides the problem I stated above, it seems to
me that if you want to copy protect your software, do it right.  Don't
do it halfway.  There are several methods of controlling software execution
available.  Pick One.  If your company doesn't have the people to do the
job, hire someone.

****----

 Terry Robb

STJOHNS@SRI-NIC.ARPA (03/03/88)

Terry,  Jon  Postel  has  decreed  that  for both TCP and IP, any
additional options will be of  the  second  type...   I.e.   self
encoding the length.

Mike