[Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting

[[e-mail] (Joe Touch)]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig00A31756B6731166C9A76BBC
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Miika Komu wrote:

> Some question were raised in the hipsec-rg meeting in San Diego and I'd
> like comment them briefly:
> 
> 
>>2.  HIP Native API (Julien Laganier)
>>
>>Lars Eggert:  Why are you binding to a src interface rather than
>>address?
>>
>>Julien:  Ask Miika for motivation.
>>
>>Joe Touch:  Binding to interfaces doesn't make sense.  Interfaces have
>>multiple IP addresses.  A single host identity must be able to bind to a
>>particular IP address, for policy reasons.
> 
> Actually, the binding is done on the source endpoint descriptor. The
> resolver communicates the descriptor to the HIP module and associates it
> with a (given) interface.

You can bind to the endpoint descriptor, but the association must be 
with an interface/address pair. Otherwise, there's no way to control:

	1- when you have one interface with multiple addresses:
		which address to use (under app, transport, or net
		control)

	2- when you have one address on multiple interfaces:
		which interface to use (again under app, transport,
		or net control

(1) is aliasing, and (2) s more common with multicast addresses, but can 
also occur with unicast.

> The main motivation for preferring IP addresses instead of interfaces is
> related to the probable life time of the identifiers. IP addresses are
> more unstable than interfaces, so interfaces were preferred. It is still
> possible to use a specific IP address by specifying the protocol family
> (and prefix) of the IP address to the resolver.

Neither interfaces nor addresses have a lifetime of meaning with respect 
ot endpoint IDs. Both can change - e.g., inserting PCMCIA cards, USB 
interfaces, etc.

> (Btw, usually client apps do not bind explicitly and server applications
> bind to INADDR_ANY or IN6ADDR_ANY, so this question may not be so
> important.)

In conventional multihomed situations, apps can want control over which 
IP address is used as the source. The corrollary in this case is control 
over which interface/IP address pair is used. I.e., _both_ are required.

> Other opinions? Does anyone think that using interfaces instead of
> IP-addresses is a better approach? Or a no-go?
> 
> Another question to all: do you prefer "endpoint descriptors" instead
> of HITs as the AID and why?
> 
> 
>>Andrew McGregor:  Agree about not binding to an interface.  You may want
>>to bind to a HIT and use a setsockopt() to associate a locator with it.
> 
> 
> Resolver does the setsockopt() on the behalf of the user. The difference
> is that the HI-to-IP mapping is "global" instead of socket specific. The
> security issues are dealt by tagging the mapping with the UID and GID.
> 
> 
>>Tim Shepard:  What if no DNS?  Nervous about building in dependencies on
>>DNS.
>>
>>Julien:  use /etc/hosts.  Can fall back to opportunistic mode too.
> 
> 
> The other alternative for DNS is the DHT, but it remains to be seen if we
> ever get there. In the mean time, we should rely on DNS, as there are no
> real alternatives currently available.

As far as lookups go, DNS==DHT. Different routing, but still requires 
some sort of global infrastructure to bootstrap.

> Maybe the resolver should should support DHT queries too. With a new
> resolver, this should not be a problem. I'll have to look at this topic
> when I get my hands on a DHT DNS replacement implementation...
> 

--------------enig00A31756B6731166C9A76BBC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBIYY5E5f5cImnZrsRAgAXAJ0XZ/TXkitPEbpg0r7ZlgLvbNA9IQCfYOBz
Id8oP4KA5OE6qs07y5iMK5c=
=wRXC
-----END PGP SIGNATURE-----

--------------enig00A31756B6731166C9A76BBC--