Subject: RE: DNS discovery thoughts

From: [email-masked]
Date: Wed, 5 Jun 2002 14:02:29 +0300

> -----Original Message-----
> From: ext Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 6:29 PM
> To: [email-masked]
> Subject: DNS discovery thoughts
> 
> 
> 
> I've been thinking about the DNS discovery, as well as the larger 
> "service discovery with no 3rd party dependencies" issue, for a while.

The same problem has been in my mind. And I think I solved it. The solution seems so outrageously simple that there must be something that I have missed...

Anyway, my problem appears in 3GPP networks. A roaming mobile may connect to a visited network without any idea of its service configuration. The service discovery and client configuration mechanism shouldn't use extra messages to 3rd parties, because each packet over the air carries a price tag. What I wanted is an architecture that can deliver all services - past, present, and future - without first having to configure the mobile end.

The solution: ask the Janitor.

* If I visit a strange building and want to know how the plumbing works, what will I do? I'll go and ask the Janitor. The network analogy would be a Virtual Janitor that knows which server provides which service(s). The visitor needs only the address of the Janitor, which can be preconfigured. No "discovery" needed.

* For example, the visitor wants the IP address of something. The DNS request goes to the Janitor address, and the Janitor responds with the number. In fact it was the local DNS service who responded, but the visitor doesn't care.

* The Janitor isn't a 3rd party. It is implemented as a well-known anycast address that every server listens at. They read the Janitor packets, and if the packet belongs to a service that the server is configured to provide, it responds to it. It is up to the network admin to make sure that one and only one server responds - the usual anycast management requirement.

That wraps up the basic idea. The Janitor service provides built-in possibility of resilience and load balancing. It doesn't need any changes to existing application protocols or clients. They just configure the Janitor as the default server.

The Janitor address should be from the IANA range (RFC2526). There is no other need to allocate identifiers. The servers that participate in the Janitor service will use the existing protocol and port numbers as triggers. Even application layer triggers can be used, because the servers (and applications) will decide themselves which packets they react to.

I haven't done any serious security analysis yet. One potential problem comes from load balancing. If a stateful application is supported by several hosts, the client needs to know the real address of the host that keeps the state. The service address changes from the Janitor address to the real address, and that obviously opens the possibility of session hijack and spoofing attacks.

Giving the real address would also act as an optimization. For example, the DNS client could cache the source address of the first DNS response, and use it in stead of the anycast address, saving the other servers some trouble.

My two cents so far...

-- Lassi

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------