ietf
[Top] [All Lists]

Random Network Endpoint Technology (RNET)

2008-04-09 07:51:56

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>