Re: sockets APIs extensions for Host Identity Protocol

Keith Moore <moore@cs.utk.edu> Fri, 11 May 2007 14:03 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmViZ-0001fV-Ix; Fri, 11 May 2007 10:03:35 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmViY-0001fP-Hg for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 10:03:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmViY-0001fH-86 for discuss@apps.ietf.org; Fri, 11 May 2007 10:03:34 -0400
Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmViW-0005bj-RJ for discuss@apps.ietf.org; Fri, 11 May 2007 10:03:34 -0400
Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 6950CCB3C5; Fri, 11 May 2007 10:03:32 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GGkhnDj9bi9; Fri, 11 May 2007 10:03:13 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 10531CB3D9; Fri, 11 May 2007 10:03:12 -0400 (EDT)
Message-ID: <4644779F.60805@cs.utk.edu>
Date: Fri, 11 May 2007 10:03:11 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Miika Komu <miika@iki.fi>
Subject: Re: sockets APIs extensions for Host Identity Protocol
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <Pine.LNX.4.64.0705091449360.26169@hermes-1.csi.cam.ac.uk> <4641D94C.9070304@cs.utk.edu> <Pine.SOL.4.64.0705102013550.10049@kekkonen.cs.hut.fi> <46436B10.5090706@cs.utk.edu> <Pine.SOL.4.64.0705102159020.10049@kekkonen.cs.hut.fi> <4643F873.3000501@cs.utk.edu> <Pine.SOL.4.64.0705110851440.24038@kekkonen.cs.hut.fi> <46442588.7020405@cs.utk.edu> <Pine.SOL.4.64.0705111344130.16213@kekkonen.cs.hut.fi>
In-Reply-To: <Pine.SOL.4.64.0705111344130.16213@kekkonen.cs.hut.fi>
X-Enigmail-Version: 0.95.0
OpenPGP: id=E1473978
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

>> I don't know why a HIP-aware app would use sockaddr_in* for any socket
>> on which it wanted to use HIP.  Such an app might want to use
>> sockaddr_in for some sockets if it had a reason to not use HIP on
>> specific sockets.  (say for diagnostic purposes)
>
> Sorry, I meant sockaddr_in6 in this case.
the same argument applies.  If I want to specify that I'm connecting to
a HIT, I don't want to use a sockaddr_in6 structure to do that and have
it somehow magically know the difference between a HIT and an IPv6
address.  I want to use a sockaddr_hit structure for that.  That way, I
get a clean separation of layers, with all that that implies - better
ability to distinguish errors from different layers and handle each
appropriately, clearer visibility to the programmer as to what's
happening underneath the API, etc.
>> I must have missed the point of locally-scoped identifiers.  I thought
>> it was so that you could fit a pseudo-HIT into 32 bits and pretend it
>> was an IPv4 address for the sake of backward compatibility.
>
> Yes. There can be two types of "pseudo-HITs":
>
> Local Scope Identifier (HIP legacy apps draft):
> * Looks like an IPv4 address
> * Might even have a locally configured prefix to separate between a LSI
>   and non-LSI address
>
> Endpoint descriptor (HIP native apps draft):
> * Looks more like a FD (increasing or random number)
> * No prefix  
I don't immediately see the purpose of the latter type of pseudo-HIT?  
(guess I should go dig up the draft...)
>> But if your application was written to be HIP-aware, it would be
>> cleaner to use HIP-specific sockaddrs.  And in that case, why use a
>> locally-scoped identifier when you can use a globally-scoped one? 
>> (and if your application wasn't originally written to use HIP it's
>> probably the case that the best you can hope for with small mods to
>> your code is opportunistic HIP anyway.)
>
> Yes, but how to do opportunistic mode in a new application that wants
> to use opportunistic mode for some connections and normal mode for
> others?
well, the setsockopt() mechanism for enabling opportunistic HIP that
would be useful for modifying legacy apps could also be used for new apps.

if you wanted to have a mechanism to do the same thing with
sockaddr_hit, say by setting the HIT field to HIT_UNKNOWN or some such,
that could be defined also.  though the details would be interesting to
work out.
>> for starters, the addrinfo structure doesn't have a field for a HIT, and
>> in a HIP aware app you'd certainly want to specify which HIT you wanted
>> to talk to.   neither does addrinfo have any way of representing things
>> that are quite reasonable - like a single DNS name mapping to multiple
>> HITs, each of which maps to multiple IP addresses, where some of those
>> addresses are addresses at which the peer might reasonably be found, and
>> others are for redirect servers.
>
> The addrinfo structure has the generic sockaddr *ai_addr field which
> can be used for encapsulating a HIT, LSI or ED.
ah yes, good point.
> One of reasons for the local-scope identifier was to hide the "which
> HIT maps to which IP" complexity from the application. This does not
> prevent the application rearranging the identifiers behind the
> locally-scoped
> identifiers using a separate function call.
at this level of API, hiding the "which HIT maps to which IP" complexity
seems misguided.   let the high-level API do that.  you need an API that
exposes this stuff.
> What kind of redirect servers are we talking about?
I haven't keep track of the HIP discussions on this topic, so I don't
know what they're being called.  but at one time there was an idea that
you could have a server that could be associated with a HIT that would
securely be updated with current IP addresses for that HIT, and which
could securely tell peers of that HIT when the host associated with the
HIT had moved.  (those servers would need to be located at relatively
stable addresses).  you'd want to be able to discover those servers
through DNS or a similar mechanism.
>> more generally, getaddrinfo() sucks so bad that any excuse to get rid of
>> it is worth considering.
>
> How would a new resolver work in your opinion? I guess there has not
> been any prior work on this in the IETF.
it will take more than an email message to answer that question.
>> it's certainly the case that DNS-to-HIT mapping might change
>> independently of a HIT-to-IP mapping.  that, and when there are multiple
>> HITs associated with a single DNS name, a single routine might end up
>> doing several different lookups for the HIT-to-IP mappings, which could
>> take a lot of time.   so on reflection I agree that it makes sense to do
>> the lookups separately.
>
> Ok, but what do you think about exposing the IP address to the
> applications in a sockaddr_hip structure? My point was not really
> about the lookup process, but more like what is going to happen after
> initial contact between two hosts. After establishing communications,
> a host moves to another network, detects that its IP address has
> changed and communicates its new location to the peer. At this point,
> the IP address that was originally received from the resolver is
> depracated.
we're a very long way from being able to trust a kernel to make
effective address selection across a wide variety of network
environments and application requirements.  until we get there, the
addresses need to be exposed to the application, and the application
needs to be able to specify which addresses are allowed to be used.  if
nothing else, you're going to need that for diagnostics.  if some user
tells his sysadmin that his program can't connect to HIT xxxx, the
sysadmin has no way to know how to debug the problem.  if instead the
message is "cannot connect to HIT xxxx at address yyyy", a traceroute to
yyyy might yield some useful information.

granted, however, that the sockaddr_hit structure can only communicate
the IP addresses at which the peer with that HIT might initially be
found.   once the connection is established, all assumptions about the
HIT-to-IP bindings that were established in sockaddr_hit are invalid.

Keith