IntraIntraDraft1 - SeattleWireless

(Changes to this document should be made at the IntraIntra WIKI.

Wireless Network Hacking Group

DRAFT REQUEST FOR COMMENTS

MatthewAsham
MattWestervelt
Seattle Wireless et al

December 17, 2000

INTRA INTRA NETWORK ROUTING PROTOCOL

Status of this Memo

This is a Request For Comments DRAFT document intended for feedback from the
Internet community.

Overview

As wireless networking devices become cheaper and more popular, we expect to see
more and more wireless local area networks (WLANs) to appear. These networks will
often use address spaces defined in RFC1918. In order to connect similarly-
addressed wireless networks, a standard method of avoiding address conflicts is
required. To this end, we propose using a combination of directory services
(DNS), tunneling, and specialised address rewriting systems in the tunnel
routers.

The goals of this specification are to:

* Provide interconnectivity with similiarly assigned RFC1918 networks
* Provide a dynamic routing system between gateway nodes in independant WLANs
* Provide redundant links over multiple paths
* Provide transparent remote operation for end-clients on the local WLAN
* Be upwards compatible with IPv6
* Keeping it simple for end-users

Network Toplogies share a common concept of local clients and "gateways" to
foreign networks. On the average Ethernet LAN, a dedicated router acts as the
"Default Gateway" and knows how to route traffic from local networks to foreign
networks such as the Internet.

In the case of Wireless LAN topologies, the scope of the LAN is limited
by line-of-site and addressing. Multiple WLAN's in a large rural area (such as
a city) may be configured using the same IP Address ranges thus causing
conflicting assignments and other administrative headaches.

It is expected that independent groups within a local geographical area will
have the ability to coloborate and resolve local assignment issues. In some
cases coordination groups may exist to manage IP assignments in a City.

At a national level however, coordination may be problematic and requires
manual manipulation of routing tables to pass traffic between networks as
well as the possibility of re-numbering should two large citys happen to
be using the same address space.

The IntraIntra-Network Routing Protocol (IINRP) is designed to allow
existing networks to communicate by passing traffic over an intermediary
network.

The Inter Intra network consists of regional controllers who:
* Perform Remote Network Lookup Services
* Perform IP masquardaing, translation and tunneling
* May perform miscellaenous utilitarian tasks (Email, Network bulletins, diagnostics, half-life server, etc.)

Each Regional Controller is homed into her local WLAN, and external network(s)
where foreign Regional Controllers exist. External networks may consist
of the Internet, Wireless Long-Haul links and other private networks.

The addressing of each RC is dependant on the addressing scheme of the
interconnect network being used to pass traffic.

In most cases, Regional Controllers will be assigned as the default route
during client negotiation with the local DHCP server. Multiple Regional
Controllers may exist within the same WLAN to provide additional bandwidth
and redundancy for the WLAN.

In addition, dedicated RC's may be used to direct traffic for specific
destinations. Multiple routes would be assigned via DHCP or ICMP
redirection (not suggested).

CONVENTIONS USED IN THIS DOCUMENT

"regional.<locality>.wireless" inidicates a regional gateway controller with
knowledge of local WLAN clients and external gateways

"<nodename>.locality.wireless" indicates an individual client computer
connected on the local WLAN of "regional.<locality>.wireless".

"Aliased Remote Address" is a locally visible IP address corresponding with a
remote RFC1918 individual client computer.

PROOF OF CONCEPT SCENARIO

The two localities of Seattle WA (Network A) and Vancouver BC (Network B) have
two well-known W-LAN's in place.

The client 'nitrous.vancouver.bcwireless.net' has been assigned the IP address
10.10.10.23 by a local gateway, 10.10.10.1 (regional.vancouver.bcwireless.net)

Nitrous.vancouver.bcwireless.net then wishes to communicate with
oxide.caphill.seattlewireless.net, and makes a DNS request to regional.vancouver.bcwireless.net.

Regional.vancouver.bcwireless.net asks its directory services for an the authoritive
Regional Controller for 'caphill.seattlewireless.net' and proceeds to ask
'regional.caphill.seattlewireless.net' for information on 'oxide.caphill.seattlewireless.net'.

'regional.caphill.seattlewireless.net' returns 10.10.10.55 as the IP address of
oxide.caphill.seattlewireless.net as it knows it to be on its local network.

regional.vancouver.bcwireless.net then virtualizes 172.16.5.123 from its forwarding
pool, aliases 10.10.10.55 to 172.16.5.123 and notifies nitrous.vancouver.bcwireless.net
that the IP address of oxide.caphill.seattlewireless.net is the masquaraded 172.16.5.123
address.

Nitrous.vancouver.bcwireless.net having received the aliased remote IP address
attempts to establish a connection through her regional controller.

Both regional.vancouver.bcwireless.net and regional.caphill.seattlewireless.net maintain the
Aliased Remote Address and forward the packet data from nitrous and oxide over
a built up tunnel.

Masquarding daemons on both regional controllers handle the IP header re-
writing and forwarding thus creating a transparent IP session.

IP ADDRESSING

172.16.0.0-172.31.255.255 is to be used for local aliasing by gateways and
SHOULD NOT be assigned to clients on the local network.

10.0.0.0-10.255.255.255 SHOULD BE used for dynamic IP assignments to clients on
the LAN (via DHCP)

192.168.0.0-192.168.255.255 has no use at this time and MAY BE used for whatever
it used for.

NETWORK NAMING CONVENTIONS (UPDATED)
RC's communicate to remote RC's authoritive for a remote client's zone much
like DNS propogates from the root-servers to authoritive NS records.

An obvious naming scheme for wireless networks is:

<node_name>.<locality>.<state>.<country>.wireless

ie: nitrous.vancouver.bc.ca.wireless or nitrous.neurosis.vancouver.bc.ca.wireless

Another convention may be the use of private network names, such as

"nitrous.vancouverwireless"
"oxide.seattlewireless"

DIRECTORY SERVICE NAME RESOLUTION
Each Regional Controller will maintain hostname to local WLAN IP address mapping
based on information from DNS. DNS servers SHOULD implement DNSSEC for
DHCP->DNS mapping to prevent name hijacking.

TSIG will be used for DNS result authentication to the RC's.
(see AUTHENTICATION below)

TUNNELING
Each Regional Controller will use an encrypted tunnel for passing data from
itself to foreign RC's. The simplest method for this would IPSEC tunelling
with the potential of RC SA policy management. This would also provide
security over the public network the RC's communicate over.

REMOTE ADDRESS ALIASING / MASQUARADING
Regional Controllers will maintain an internal state table consisting of the
local WLAN client and foreign WLAN client as well as the local virtualized IP
address. This mapping will be used for translating traffic from the local WLAN
to the foreign WLAN. Existing natd/ipmasq code should be readily hackable
to implement this type of lookup.

Remote addresses are aliased from a local pool. We prepose the use of
172.16.0.0-172.31.255.255 for local pools. This addressing scheme
would allow for 967,725 simultaneous routes.
** This could be expanded quite nicely using IPv6 reserved space.

MAPPINGS
Mappings are created dynamically when a remote RC asks who is a client.
If the client exists in the local active database, the RC creates
a mapping containing the local client's true IP address, the remote client's
hostname.

VIRTUAL ROUTES
VR's are created dynamically when ip traffic is detected between the two
direct hosts. The initial routes are generated based in the RC's database.

PROTOCOL - SETUP
The client asks the RC via DNS for the remote client's hostname. The RC
scans a table of remote RC's for one authoritive for the remote client's
zone. Upon discovery of RC's, the local RC will query each RC sequentially
(round robin). The remote RC then queries its local database for the
recipient address and upon success, creates a temporary mapping for the
originating host (by name) and the local client's IP address and returns
the client's IP address to the originating RC.

The originating RC recieves the remote client's IP address and assigns
an IP address from the aliasing pool. The remote client's IP and the newly
assigned aliased address (as well as hostname) is inserted into the local map,
and the aliased IP is returned to the client.

PROTOCOL - CONNECTION
The client having recieved the aliased IP is then able to proceed with
an IP connection. The IP connection is sent to the aliased IP address
on the local RC, the local RC looks up the fake alias and the remote
address. It then sends the packet payload (with a modified destination
header to reflect the true IP of the remote client).

The remote RC recieves the packet payload, consults its map and forwards
the packet (with modified source address to that of the remote RC's
locally aliased address) to the remote client.

NAME CACHING
* TTL's will be employed by the lookup system to minimize intra-inter
communication of RC's. A "last seen" timestamp will be employed
and RC's will verify data upon demand. If a remote RC detects
detects a difference between a recieved payload's mapping and
a mapping locally the RC will respond with the new addressing information

NAME MAINTENANCE
*Virtual routes must be deconstructed in an intelligent manner to prevent
resource overload on a RC.

One virtual route will be used per remote host, obvious "upper limits"
exist to this method but 200 simultaneous connections would not be
hard for a 16MB router running Linux I imagine.

I propose that routes be torn down after 10 minutes of inactivity. a three
weight metric can be employed in the local db map for intelligent
forecasting a routes lifetime (everyone reading /. in the morning is a
prime of example of a route that shouldn't die after 10 minutes).

CLIENT AUTHENTICATION
(see TSIG above)
Clients authenticating against a local dhcp server will have there
host entry updated via TSIG. The (independant) RC will resolve from
the local WLAN name server during lookups. Having the RC run as
a secondary name server is a good idea to minimize over-air lookups.

DNSSEC will be used for dynamic zone updates.

* - Preliminary, needs serious thought and breaking

REFERENCES:

* An IRC chat on #seattlewireless

* dev @ seattlewireless.net Seattle Wireless Development list

* RFC1918 "Address Allocation for Private Internets"