Re: TCP Options/Copy Protect


terry@DEC-VAX-11-750.ARPA
Wed, 02 Mar 88 13:33:35 EST


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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT