|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
[Hipsec] More about LSIs
Date: Mon Mar 17 2003 - 12:20:19 EST
Last night I had a chat with some people about LSIs. There we came up with some interesting issues that I try to summarize here for everbody's benefit.
Right now the draft makes the implicit assumption that there is no syntactic difference between an LSI and an IPv4 address. That is, given a four octet string, e.g. 130.233.1.2, you can't tell just by inspecting the string whether it is an IPv4 address or happens to be an LSI. This is a problem for applications that want to communicate both with HIP enabled hosts and old legacy hosts.
To illustrate the point, let me take an extreme example with a legacy web browser running on an HIP enabled host. Consider the following web page:
<html><body>
<img src="http://hiphost.org/picture.gif" />
<img src="http://legacyhost.org/picture.gif" />
</body></html>
To display the web page, the web browser would first ask its local resolver library to resolve "hiphost.org" into an IP address. Since the remote host happens to be an HIP enabled host, the resolver would return an LSI instead of the real IP address. According to the current draft, the host should start assigning LSIs starting from a random number, and therefore the LSI can be anything. For the purpose of this convoluted example, let the resulting LSI be 131.233.10.1.
To display the second image, the web browser would then ask the resolver to resolve "legacyhost.org". Since that host does not support HIP, the resolver returns the IP address, which might well be equal with the previous LSI, i.e., 131.233.10.1.
We have a collision here. When the application uses the LSI or the IP address in the legacy IPv4 API, the library and the kernel have no way to tell whether the value given is the LSI or the IP address.
There seems to be (at least) three different ways of solving this problem.
- Use only a limited fraction of the IPv4 address space for LSIs. I was told that my suggestion, 127.0.0.0/8, is not a good choice. However, maybe 0.0.0.0/8 or 255.0.0.0/8 might be better?
- Configure each application to either use LSIs or IPv4 addresses only. This would not work for all applications, since many applications would want to be able to talk to both HIP enabled and legacy hosts.
- Return always an LSI, even if the remote host is a legacy host. Normally the returned LSI would be the real IP address of a legacy host, but in the case of a collision with an already existing LSI a fake address would be returned.
This approach has the huge drawback that some
applications would be broken or require application
level NATting. For example, if a FTP server
would get an LSI instead of the real IP address
of a FTP client, that would mean that the real
IP address of the client is currently used as an
LSI for another host. Now, when the client sends
a PORT command, it would contain the real IP address
of the client. The server would take it, and
use it in a connect system call, which would then
try to connect to the wrong host, the one represented
by the LSI.
What is worse, however, is that since some protocols
implement TLS within the application process, there
are cases where it would not even be possible to
do application level NATting. Furthermore, one of
the goals behind the current LSI design is to avoid
the need for application level NATting in the first
place.
Thoughts?
--Pekka Nikander
Hipsec mailing list
Hipsec@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/hipsec Received on Mon Mar 17 13:09:36 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:58 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |