Subject: RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

From: "Christian Huitema" <[email-masked]>
Date: Mon, 31 Mar 2003 09:25:48 -0800

> > Applications will have to deal with that, yet there is no hint
> > unless we provide a well-known flag.
> 
> applications cannot be expected to deal with filters in any way other
than
> to report that the communication is prohibited.  the "well known" flag
> exists and is called ICMP.

Well, that is emphatically *NOT* what application developers do. They do
not just observe that it does not work, they try to work around, e.g.
routing messages to a different address, at a different time, through a
third party, or through a different protocol. 

Silently dropping packets is certainly not the right way to get an
application to stop trying. ICMP messages won't achieve that either:
since ICMP is insecure, it is routinely ignored.

Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application actually contacted the peer and obtained an explicit
statement that the planned exchange should not take place -- the
equivalent of a 4XX or 5XX error in SMTP or HTTP. 

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 12:55:29 -0500

> > applications cannot be expected to deal with filters in any way
> > other than to report that the communication is prohibited.  the
> > "well known" flag exists and is called ICMP.
> 
> Well, that is emphatically *NOT* what application developers do. They
> do not just observe that it does not work, they try to work around,
> e.g. routing messages to a different address, at a different time,
> through a third party, or through a different protocol. 

that's because (a) customers demand that apps work even in the presence
of NAT, no matter how unreasonable this is, and (b) the way most
filters are implemented, there's no good way for an app to tell whether
a communications failure is due to a network or host failure or to a
prohibition.  ICMP is the only mechanism we have to do this, and it's
not widely used.

> since ICMP is insecure, it is routinely ignored.

ICMP may be routinely ignored, but on false premises.  ICMP is no
less secure than anything else in TCP or IP that is routinely trusted.

> Which actually poses an interesting question: when should an
> application just give up? IMHO, there is only one clear-cut case, i.e.
> when the application actually contacted the peer and obtained an
> explicit statement that the planned exchange should not take place --
> the equivalent of a 4XX or 5XX error in SMTP or HTTP. 

I'd claim that ICMP prohibited is another case for giving up.

note that a 4xx error is an explicit "it's okay to retry" indication.

Keith

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 31 Mar 2003 20:11:29 +0200

Christian Huitema wrote:

> Well, that is emphatically *NOT* what application developers 
> do. They do not just observe that it does not work, they try
> to work around, e.g. routing messages to a different address,
> at a different time, through a third party, or through a
> different protocol. 

Indeed, correctly coded applications will use a getaddrinfo()
and then a connect() in a loop until succesful. This will
also overcome filtering as all possibilities will be tried
on the remote side. Note that 'succesful' here means that
it was able to setup a tcp connection. UDP is totally out
of the question here. Some applications could also modify
'succesful' to include a 2xx smtp reply etc. and absolute
failure to be defined by a 5xx error.

The problem is that this doesn't account for the locally-bound
IP though. Thus if a host has a 'site-local' and a 'global'
IP how does it know how to use which one?
Also note that getaddrinfo() is only in use since a couple
of years and most programmers are not even aware of it.

I would suggest that the applications never bind() to a
local address, this is possible for most applications.
Then the stack can figure out which address to use for
the outgoing connection. Most stacks will currently base
this on longest prefix matching. Thus if there is a 'local'
scope and the destination address is also in the same
'local' prefix, this address will be used for the connection.

Greets,
 Jeroen

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 31 Mar 2003 11:15:03 -0700 (MST)

> From: "Christian Huitema" <[email-masked]>

> ...
> Well, that is emphatically *NOT* what application developers do.

Speak for yourself.

> equivalent of a 4XX or 5XX error in SMTP or HTTP. 

I've written application code that shuts up for a while when it
receives an errno value that indicates that the kernel has received
an ICMP Unreachable.

The code I'm thinking of is fairly portable, and so I've also had to
#ifdef it to ignore error numbers that ought to indicate an Unreachable
but don't on some UNIX-like systems or are not reported.

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 16:23:56 -0500

> and then a connect() in a loop until succesful. 

it's perfectly reasonable to connect to an address without first
doing a DNS lookup.  even when you need to do a DNS lookup,
getaddrinfo() doesn't always do what you need.

Keith

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 31 Mar 2003 23:45:11 +0200

Keith Moore wrote:

> doing a DNS lookup.

I think nobody can't help you if you are using hardcoded IP's.
The only case you have an IP without DNS is when you get it
passed from another layer/entity (eg in a FTP from the server).
In any other way if you have multiple targets you can also
try all of those in a loop similar to getaddrinfo().

> even when you need to do a DNS lookup,

Can you identify those so that getaddrinfo() can be expanded
to fix these cases?

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 16:56:17 -0500

> passed from another layer/entity (eg in a FTP from the server).

uh, no.   you can get IP addresses from any number of sources other than
DNS, including from other processes that exist on other nodes.  It's a
perfectly reasonable thing to do.

> Can you identify those so that getaddrinfo() can be expanded

getaddrinfo() cannot be fixed.  it's major premise - that the host has
the knowledge to make decisions about which of several addresses is best
to use - is fundamentally flawed, except in a few corner cases.

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 1 Apr 2003 00:23:15 +0200

Keith Moore [mailto:[email-masked]] wrote:

> uh, no.   you can get IP addresses from any number of sources 
> other than DNS, including from other processes that exist on
> other nodes.  It's a perfectly reasonable thing to do.

Note the line about other layer/entity :)
Which is also one of the reasons why multi-faced dns isn't
the solution to this problem.

> the knowledge to make decisions about which of several 
> addresses is best to use - is fundamentally flawed, except in a
> few corner cases.

Effectively this could be resolved by having one globally
unique identifier per node. The underlying protocols should
then take care that messages are delivered to the host
described by the unique locator. The underlying protocols
could then, in case of your so called corner cases, or routing
troubles, based on all kinds of external information change
the underlying protocols so that the connection stays active
and messages can still be sent from A to B. Enter SCTP and
multihoming ? :)

This has nothing to do with sitelocal but more with the
fact that a host can have multiple paths from A to B: internet ;)

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2003 17:28:43 -0500

> fact that a host can have multiple paths from A to B: internet ;)

multiple paths does not imply multiple addresses.

---

From: [email-masked]
Date: Mon, 31 Mar 2003 17:44:45 -0500

> unique identifier per node. The underlying protocols should

Paging Noel Chiappa.... Paging Noel Chiappa.... ;)

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 1 Apr 2003 00:54:47 +0200

> Paging Noel Chiappa.... Paging Noel Chiappa.... ;)

Based on a quick Google I think I've just hit the flamepit...
Reading the, interresting on first sight, documents...

Greets,
 Jeroen