Re: New Internet Draft on automatic (end-user) tunneling for SSM

[Pieter Liefooghe <pieter@info.vub.ac.be>]

Jeremy Hall wrote:

> now THIS sounds interesting.

Ah, thanks ;-)

> marmaduke:~$ whois 208.197.171.112/28@radb.ra.net
> [whois.radb.net]
> route:         208.192.0.0/10
> descr:         UUNET, An MCI Worldcom Company
>                3060 Williams Drive
>                Fairfax
>                VA 22031 USA
> origin:        AS701
> mnt-by:        MAINT-AS701
> changed:       juzer@uu.net 19990104
> source:        RADB
> marmaduke:~$

> now if we could say:
>
> 208.192/10 points to UUNET's database server, then UUNET has a bit more
> control of who can use what tunnel server from its own space.

> but be careful, it isn't always easy to know where a person is based on IP

> address.  The ISP might know how it allocates addresses, but it might not
> be willing to announce that to the world.  There is probably something I
> am overlooking, but feel free to point it out. :)

The client application is manually configured with the country where the
client is located. it is not infered from the location information in the DNS
system!
For the second part of your remark... are you alluding to situations where
some NATs/Firewalls are being deployed at the ISP who could "mask" the real IP
address?
In the current status of the architecture, we use the source IP address of the
HTTP query as parameter to the longest prefix match. In most Corporate and
probably many ISP cases this will be the IP address of the Firewall (NAT)
through which the HTTP query went. Hence, the query will yield ALL tunnel
database servers available in the Corporate/ISP domain. As a result of the
path characterization you will see that the "optimal" tunnel database server
will be used.
Although in an ISP with a large amount of Tunnel Servers this could mean a big
amount of Path characterisation overhead!
Maybe we need to think about an hierarchical system of tunnel database
servers. Where you have a root Tunnel Database server who can perform a HTTP
redirect towards a Tunnel database server located in the ISP domain (if one is
available ofcourse otherwise we continue to work as before!). The nice thing
about the redirection is that this redirected query remains within the ISP
domain and that it will "reveal" its real internal IP address. This real IP
address can then be used in the Tunnel Database query to better manage the
distribution of clients over the ISP's topology. In very complex ISP
architectures we could even deploy multiple "levels" of Tunnel Database
servers. And it is clear that these "private" Tunnel Database servers register
themselves dynamically with the central Tunnel Database server and that there
is some form of keep-alive checking.

This is my "quickly engineered" solution to the problem you raised....Is this
any good?


Thanks for the input,


Pieter
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pieter Liefooghe
Research Assistant
Vrije Universiteit Brussel (INFO/TW)
Digital Telecom Dept.
Pleinlaan 2
1050 Brussel
BELGIUM
Tel: +32-2-629.29.77
Fax: +32-2-629.28.70
pieter@info.vub.ac.be
http://www.castguide.com

Quote of the day:

Any program that runs right is obsolete.