Random Network Endpoint Technology (RNET)

[Chad Giffin <[e-mail]>]

 My name is Chad Christopher Giffin.  My nickname is (typo).  I have been a member 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 registration) 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 propagated 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 acquire the newly generated RNET Global Key.

 All members of RNET, be they a router or host are registered with RNET.  They each have an individual key used to confirm 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 entries to the RNET Centralized Server wether or not they have the valid RNET Global Key. (This allows all RNET Hosts to acquire 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 incur 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 acquire 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 acquire 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)

_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf