geoff@suneast.uucp (Geoff Arnold) (03/18/86)
I'm interested in feedback on the question of license violation
detection for networking software. We're putting together a product
in which (1) we have access to only UDP/IP (and not much memory) and (2)
we need to enforce some kind of copy protection. Now we all know where
the industry is (rightly) heading on obnoxious forms of copy protection
(hard disk installations which rely on hardware bugs, key disks with
laser burns, etc.), but with a networking product we have the problem
that the product itself provides the means for facilitating its own
rip-off! So....
Our first thought was to create our own protocol, but that seemed like
an instant loser... Then scanning the stuff from SRI, I noticed RFC863,
the Discard Protocol. Anything coming in on UDP port 9 gets dropped,
right? Well, is there anything wrong with us taking a peek at it first?
Sooo.....
What we're planning to do is broadcast a packet with our serial number
(plus a suitably recognizable string) to UDP port 9. Any copy of our
product that gets a Discard packet checks it: if it's one of ours, and
if the serial number matches its own, it (i) displays a "License
Violation Detection" message, and (ii) if the packet was a broadcast, it
fires off a non-broadcast copy to the originator, who will also display
a message. We'll do this just once, after our software has been
installed. Obviously we only hit systems on our local Ethernet, but in
most cases that should prove adequate.
Questions:
(1) How do the protocol gurus feel about this kind of use of
the Discard Protocol?
(2) How would you, as a user, feel about the scheme?
(3) Is a one-time warning (probabilistic only - this is UDP) as
tough as we should get? Obvious escalations include repeating
the message at (decreasing) intervals, disabling our product
(but not the system), or bringing the system to a grinding
halt? One problem: we can't tell the original from the copy,
so we can't choose a single victim. We're planning to report
the IP and Ethernet address of the system running the "other"
copy, so system administrators can chase down renegade users...
(4) Vendors: is there a place for a formally-defined protocol
for doing this kind of license enforcement within Internet networks?
Vendors writing for Un*x have other options open to them, such
as broadcast RPC using Sun's (public domain) protocols. Are
these sufficient?
(5) A sudden thought - does anybody NOT implement the Discard
Protocol? Any(?) 4.2-based system should include it in
/etc/services, but how about others? Am I going to get hit up
with lots of ICMP as a result of broadcasting a Discard datagram?
I think there are enough issues involved that followups are more
appropriate than the usual "Reply by mail; I'll summarize" approach.
--
"To disclaim, or not to disclaim... "
<<<<<< Geoff Arnold, Sun Microsystems Inc. (East Coast Division) >>>>>>
SnailMail: One Cranberry Hill, Lexington, MA 02173; 617-863-8870 x136
UUCP: {hplabs,ihnp4,nsc,pyramid,decwrl}!sun!suneast!geofffair@styx.UUCP (Erik E. Fair) (03/24/86)
Fundamental question to ask: what happens to a UDP packet recieved on a port for which there is no process listening? Answer: packet gets thrown away. So in effect, everyone implements UDP discard (because of the way that UDP is specified) if they implement UDP at all. What you should do is pick another port number, and get it registered so that no one else will use it. Erik E. Fair styx!fair fair@lll-tis-b.arpa
mar@mit-eddie.MIT.EDU (Mark Rosenstein) (03/25/86)
In article <20520@styx.UUCP> fair@styx.UUCP (Erik E. Fair) writes: >So in effect, everyone implements UDP discard (because of the way that >UDP is specified) if they implement UDP at all. Not true! If they do a compelete implementation of the IP protocol suite, then they will send an ICMP destination port unreachable message back for each received UDP packet without a listener on that port. Granted hosts should not send ICMP messages in response to broadcast packets, but many do. This could cause a flood of packets if one broadcasts UDP packets on a network with many hosts which do this. -Mark
ron@brl-sem.ARPA (Ron Natalie <ron>) (03/26/86)
In article <20520@styx.UUCP>, fair@styx.UUCP (Erik E. Fair) writes: > Fundamental question to ask: > what happens to a UDP packet recieved on a port for which there is > no process listening? > Answer: packet gets thrown away. Guess again, chucko. You may get an ICMP Destination Port Unreachable message in return (you do on the VAX). =Ron
andre@nrcvax.UUCP (Andre Hut) (04/02/86)
In article <136@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >In article <20520@styx.UUCP>, fair@styx.UUCP (Erik E. Fair) writes: >> Fundamental question to ask: >> what happens to a UDP packet recieved on a port for which there is >> no process listening? >> Answer: packet gets thrown away. > >Guess again, chucko. You may get an ICMP Destination Port Unreachable >message in return (you do on the VAX). "Chucko" ???? You are BOTH right. The packet is thrown away, and an ICMP message should be sent back. -- ----------------------------------------------------------------------------- ihnp4-\ sdcsvax-\ \ Andre' Hut sdcrdcf!psivax!nrcvax!andre hplabs--/ / ucbvax!calma-/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 -----------------------------------------------------------------------------
romkey@mit-vax.UUCP (John Romkey) (04/08/86)
In article <612@nrcvax.UUCP> andre@nrcvax.UUCP (Andre Hut) writes: >In article <136@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >>In article <20520@styx.UUCP>, fair@styx.UUCP (Erik E. Fair) writes: >>> Fundamental question to ask: >>> what happens to a UDP packet recieved on a port for which there is >>> no process listening? >>> Answer: packet gets thrown away. >> >>Guess again, chucko. You may get an ICMP Destination Port Unreachable >>message in return (you do on the VAX). > >"Chucko" ???? > >You are BOTH right. The packet is thrown away, and an ICMP message should >be sent back. Hang on there a minute. Normally an ICMP port or protocol unreachable would be generated, HOWEVER, this conversation originated from a message about *broadcasting* a packet to the UDP Discard port. Good IP implementations should NEVER send ICMP errors in response to broadcast packets. John Romkey FTP Software, Inc. (617) 868-4878 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@borax.lcs.mit.edu Boston, MA, 02142
andre@nrcvax.UUCP (Andre Hut) (04/18/86)
In article <117@mit-vax.UUCP> romkey@mit-vax.UUCP (John Romkey) writes: >In article <612@nrcvax.UUCP> andre@nrcvax.UUCP (Andre Hut) writes: >>In article <136@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >>>In article <20520@styx.UUCP>, fair@styx.UUCP (Erik E. Fair) writes: >>>> Fundamental question to ask: >>>> what happens to a UDP packet recieved on a port for which there is >>>> no process listening? >>>> Answer: packet gets thrown away. >>> >>>Guess again, chucko. You may get an ICMP Destination Port Unreachable >>>message in return (you do on the VAX). >> >>"Chucko" ???? >> >>You are BOTH right. The packet is thrown away, and an ICMP message should >>be sent back. > >Hang on there a minute. Normally an ICMP port or protocol unreachable >would be generated, HOWEVER, this conversation originated from a message >about *broadcasting* a packet to the UDP Discard port. Good IP >implementations should NEVER send ICMP errors in response to broadcast >packets. Right. But where in the "Fundamental question to ask" does it say anything about a *broadcast* packet? Also, remember that not all link-layers support the broadcast notion, so you would have to be assuming something about the type of medium you are dealing with to make that statement. -- ----------------------------------------------------------------------------- ihnp4-\ sdcsvax-\ \ Andre' Hut sdcrdcf!psivax!nrcvax!andre hplabs--/ / ucbvax!calma-/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 -----------------------------------------------------------------------------