Random Network Endpoint Technology (RNET)

My name is Chad Christopher Giffin.  My nickname is "typo".  I have been a memeber of the internet community since 1994.  

The following posting is a proposal for a protocol that would allow anonynimity to a user on the internet.  Please evaluate the proposal and provide any and all feedback.

------------------

Random Network Endpoint Technology (RNET)

RNET provides anonymity to those who need it.  To wit; one is assigned a static IPV6 address (out of a block of IPV6 addresses set aside for this purpose, possibly a subnet for this purpose.)  The assigned address may only be communicated with by hosts that it the assigned address initiated contact with.

Routing to this address is setup by the RNET Host by first having transmitted an RNET Route Request, with encrypted component (by the RNET Global Key), direct to the Target Host (The host with which it wishes to communicate with.)  All routers in between the RNET Host and the Target Host verify the key used by the RNET Host generating the request.  If the key is found to be valid, the route is added to the routers' route table.

RNET Route Entries are comprised of RNET Host Address, Target Address and (per individual router) Gateway Address.   They also include a Route Decay.

An RNET Route allows ONLY traffic between the RNET Host and the Target Host.

Upon instantiation of an RNET Route, a Route Decay timer is assigned to the RNET Route entry in the routing table.  This timer is reset upon each reception of a packet upon this route path.  If the timer expires, the RNET Route entry is discarded.

Two errors may occur:  (1)  The RNET Host has used an invalid key, or (2) the RNET Host requested a route entry that conflicts with a previously made route entry.

Error 1:  If an invalid key is detected, an error message of INVALID KEY is sent to the RNET Host.  Any routers in the path of that error message (that obviously supported the route registeration) have their RNET Global Key invalidated.  Each othese routers will discard the RNET Route entry.

Error 2: If a conflict is found in RNET Route entries, an error of DUPLICATE ROUTE is generated.  It is transmitted to the RNET Hosts involved in the incident.  All routers between the router that generated the error and the RNET Hosts involved in the incident (including the router that generated the error) will drop any and all routes for the RNET Host address.  A packet will be transmitted to the RNET Centralized Server that details the RNET Host Address, Target Address and Gateway Address by any and all routers who receive or generate a DUPLICATE ROUTE error.  THIS ERROR IS CONSIDERED SERIOUS:  The result is that the RNET Centralized Server will initiate a cascade reaction in the network resulting in the invalidation of the RNET Global Key.  This is accomplished by having the RNET Centralized Server send an INVALID KEY message to any and all connected routers.  Each router that receives an INVALID KEY error is to forward such error to any attached routers (with exception to the one it received the error from.)  The result is simple.  All routers will eventually received the propogated INVALID KEY message.  All routers will invalidate their RNET Global Key.

A router or RNET Host that receives an INVALID KEY error message is required to contact the RNET Centralized Server to aquire the newly generated RNET Global Key.

All memebers of RNET, be they a router or host are registered with RNET.  They each have an individual key used to comfirm their identity.  Each member of RNET has his name, key and contact information registered with RNET.

RNET Global Keys will only be given to RNET members who can be verified.

All RNET Hosts will be allowed to generate RNET Route enrtries to the RNET Centralized Server wether or not they have the valid RNET Global Key. (This allows all RNET Hosts to aquire a key.  Without this exception, an RNET Host would not be able to communicate with anyone.)

All DUPLICATE ROUTE errors and the Global Key changes they inccur result in an email being sent to all RNET Members (Routers and Hosts) that detail the date, time, RNET Host address, Target Address and all gateways involved.

It is expected that all members in RNET cooperate and participate, where required, to assist in the detection of any entity who attempts to hijack an RNET Host address (the only reason why a DUPLICATE ROUTE error would occur.)  For this reason, all relevant information that results in a Global Key change is sent to all RNET Members.

----------------

The following changes need be made to the IP Version 6 Protocol Logic, in routers, in order to impliment this technology:

  1) encryption routines
  2) recognization of RNET Route Requests
  3) generation and recognization of RNET errors
  4) routing table modifications
      NB:  the RNET Host address may be stored in the host address of the route
             entry.  The Target Host address may be stored in the Netmask of the
             route entry.  The Gateway address may be stored in the gateway of
             route entry.  The Route Decay may be stored in the Metric or be
             implimented through some system timer.
  5) routines to aquire keys from the RNET Centralized Server
  6) storage of the IP address of the RNET Centralized Server
  7) storage of the router's unique key
  8) storage of the RNET Global Key
  9) an additional flag for route entries marking them as RNET Route entries

The following changes need be made to the IP Version 6 Protocol Logic, in hosts, in order to impliment this technology:

  1) encryption routines
  2) generation of RNET Route requests
  3) recognization of RNET errors
  4) routines to aquire keys from the RNET Centralized Server
  5) storage of the IP address of the RNET Centralized Server
  6) storage of the host's unique key
  7) storage of the RNET Global Key
  8) an additional flag in the IP Stack to identify the assigned host address
      as being an RNET Host address so that the IP Stack is aware of the
      protocol to follow in initiating connections.  This allows differentiation from
      RNET Host addressess and regular IPs

----------------

I hope this email has been clear and consice.  

I'm sure allot of people would be very intrested in seeing this technology implimented in the Internet.  

Ethical and moral conserns may arise from the abuse of this technology, of course.  When this happens, we obviously need to devise a way to detect people abusing RNET and remove their membership from it.

Sincerely,

Chad Christopher Giffin
T-Net Information Systems
(a.k.a. typo)

_________________________________________________________________
Enter today for your chance to win $1000 a day—today until May 12th. Learn more at SignInAndWIN.ca
http://g.msn.ca/ca55/215
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf