Subject: RE: To address or NAT to address?

From: Dan Kohn <[email-masked]>
Date: Wed, 1 Dec 1999 17:30:03 -0800

>>It seems to me that we may be able to recapture some aspects of end-to-end
>>transparency at the application level if addressing issues are focused on
>>host FQDNs, rather than IP addresses.

>this works to some extent.  it specifically doesn't work for applications
>that need to rendezvous with specific processes on specific hosts
>(or which need to use specific interface addresses, say for performance
>reasons), since a single FQDN often corresponds to multiple hosts.
>(or, less frequently, to multiple addresses on a single host).

Specific processes can be and almost always are identified by a port number.
Just as TCP connections are identified as a 4-tuple of sender and receiver
IP address and port number, an application layer session would be identified
by a 4-tuple of sender and receiver FQDN and port.

Each interface has a different IP number, does it not?  So each can have
it's own FQDN if they need to be distinguished.  

>note also that DNS is often slow, and seems less reliable than IP.
>by increasing the reliance on DNS you increase the probability of failure. 

Yes, so DNS can occasionally fail.  But embedding addresses as a name in a
protocol is guaranteed to fail in increasingly common situations.

Finally, some have argued that DNS is less secure, but it seems that IP
numbers can be spoofed as easily as FQDNs, and an FQDN can always be
double-checked with a DNSSEC lookup if critical.

		- dan

P.S.  And now I'll embarrass myself with a silly idea.  Could one create an
automatic tunneling mode to securely send encrypted IPsec streams through a
NAT by adding an IP option which also identifies the FQDN of the destination
host?  That is, the IP address would get the packet to the NAT, and the NAT
would use the embedded FQDN to forward the packet to the correct destination
host, using IP in IP encapsulation.  The destination host would need to have
knowledge of its external address, but the NAT would not need access to the
destination host's encryption keys and so security would not be compromised.

--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-519-7968  fax:+1-425-602-6223
http://www.dankohn.com

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 2 Dec 1999 12:39:41 -0800 (PST)

--- Brian E Carpenter <[email-masked]> wrote:
> "David R. Conrad" wrote:
> > 
> > Christian,
> > 
> > > Increasing our reliance on the DNS is definitely not a good idea.
> > 
> > Hmmm.  This would appear to be the exact opposite of what the IETF has done
> > with IPv6.
> > 
> > Rgds,
> > -drc
> 
> Well now. There is some truth in that (A6 records are quite complex...)
> but NAT has generated some serious and complex dependencies on DNS too,
> not to mention various load sharing techniques.
> 
>   Brian

Brian, 

I am aware of the problems DNS-ALG has w.r.t. DNSSEC. But, what are the DNS 
Load-sharing problems you are refering to here? 

regards,
suresh 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:23:53 +0100

>by a 4-tuple of sender and receiver FQDN and port.

Don't forget that NAT changes port numbers too.
(Most NAT boxes are Portmapper NATs.)

                      Harald A
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:23:53 +0100

Harald A

---

From: Walt Lazear <[email-masked]>
Date: Mon, 06 Dec 1999 10:39:04 -0500

At 09:40 PM 12/02/1999 -0800, Bill Manning wrote:
>> My point was that suggesting that reliance
>> should not be placed on the DNS has been, is, and most likely will be
contrary
>> to what happens in the real world.
>> 
>> Rgds,
>> -drc
>
>Someone who used to work here at ISI had a saying, "There are no urgent
>DNS problems."  I did not believe then and am finding less reason to
>do so as time progresses.  An interesting viewpoint is espoused in the
>recent draft by Akien et.al. on Middleware.  According to that draft,
>we are headed into an Infrastructure that will not work w/o available
>support services e.g. policy db, CA/key servers, DHCP/DNS, ad.nausea.
>
>
>-- 
>--bill
>

The Army's efforts to use COTS Internet technology in a tactical
environment has run straight into the critical support services
issues.  Without the functioning servers that Bill mentions, 
the network of applications is hung.  Funny, they don't use cell
phones because you have to build an infrastructure, but we 
keep trying to use fixed-plant technology for data networking.

For the public Internet, it seems that we're building a set
of critical services that, if attacked and disrupted, could 
crpple e-commerce, phone service, and other applications
dependent on the 'Net.

This came up in a discussion of "convergence" of voice,
video, and data.  Someone woke up to the fact that if we put
all those services on one LAN infrastructure, then that LAN
MUST BE UP all the time.  What is the cost to keep up all
the infrastructure pieces 7x24 and never let them go down?
Remember, you can't even call the Help Desk if the LAN is 
down (assuming phone service depends on it)! 

The anti-convergence part of me remembers when Richmond, VA
had an ice storm that took out electricity for a week last 
Xmas.  It was very interesting to note that we still had 
phone service, natural gas delivery, and water pressure.  
Each infrastructure piece had separate delivery mechanisms 
and their own backup apparatus.  The loss of any one had
almost no effect on the others.  Is this what convergence
would get us?

Careful what you wish for...  :-)

	Walt