Subject: [Hipsec-rg] native HIP API
From: [email-masked] (Miika Komu)
Date: Thu Jul 29 09:37:01 2004

On Wed, 28 Jul 2004, Henderson, Thomas R wrote:

> We should probably be more precise on terminology here.  Rather than
> "things", aren't we talking about names?

I tried to emphasize with "thing" that the application does not really
care what the endpoint looks like.

> Applications need a name to bind a descriptor, and then they need the
> bound descriptor to perform I/O.  The name that is often used presently
> to bind the descriptor is the sockaddr_in (address + port), and it has
> semantics such that the address is routable.  In the future, it could be
> something like (host_identifier + port).

> I think we are debating what the possible semantics are of the
> host_identifier.  It seems that you are suggesting applications not be
> burdened with dealing explicitly with the endpoint identifiers
> themselves, or avoid them for forward compatibility reasons.  Maybe a
> less confusing term is a "local identity alias"?

"Local" can be be confusing too (consider local vs. remote identities),
but maybe application layer identity alias is better. Or application
layer { reference | handle | descriptor }.

> Also, I don't know what you mean by a "protocol specific endpoint
> identifier"-- aren't endpoint identifiers independent of protocol
> in general?  Or do you mean protocol family as in HIP vs HIPv2 vs
> AF_INET (etc.)?

I meant HIP vs. HIPv2 identifier. Sorry for the choice of words...

> If we are talking about RFC1958-compliant applications, referrals
> should be based on names and not addresses.  In the future, IMO,
> HIP potentially provides the flexibility to do referrals based
> on HITs or HIs in addition to (instead of) FQDNs, so I don't
> know whether it is safe to assume that these are only corner cases.
> For example, humans might casually use FQDNs to refer other
> people to web sites (since passing HIs or HITs will be cumbersome),
> but machine-to-machine applications or secure (e.g., bank transaction)
> applications may indeed want to skip the reliance on FQDN and use
> the HIT or HI specifically in a referral, where the HI is obtained
> over a secure channel or is backed up by certificate chains.

Right.

> p.s. applications have to move eventually to IPv6.  Does your
> framework translate also to IPv6-- i.e., systems could provide
> IPv4-sized "LSI"s and hide the IPv6 addresses from applications?

The framework provides handles for the applications. An application can
query the HIT (or LSI) corresponding to the handle via a separate function
call.

> Why or why not is this a good/bad analogy?

?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Pekka Nikander)
Date: Thu Jul 29 08:43:00 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I don't see how HIT-128 vs HIT-256 is much different from applications
> being able to handle either IPv4 or IPv6 addresses.  The getaddrinfo
> (struct addrinfo) seems to be flexible/extensible enough to 
> accommodate.

I agree that this is a minor point, but changing the HIT side
may require recompilation, depending on how the app has been
written.  I agree that well written apps would be ok.

>> Secondly, passing handles between processes requires a new
>> system call while a mere HIT can be passed around as a binary
>> value.  As we can envision a handle to be bound to an active
>> HIP association and not just to a HIT, the added security can
>> be beneficial.
>
> I am not following this point-- could you elaborate?  What added
> security do I get by passing the handle rather than the HIT
> (considering that we are just passing this around locally on
> the machine)?

Are everybody forgetting about multi-user machines these days?  :-)
Sarcasm aside, I was thinking along the lines Mach 3 implements
ports and allows ports to be transferred between tasks.  They
are like capabilities.  In a similar way, one could imagine
that HIP handles would act, in a limited sense, as capabilities.
There could even be several HIP associations between two hosts,
each associated with a different set of rights.  Or maybe
just one HIP association, but several SAs.  Or something
like that.  Making the handle separate from HIT allows you to
represent these more easily and more transparently.

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Thu Jul 29 08:39:01 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>> The handle would make it possible to implement HI mobility
>
> I guess this is why I said that I don't see the motivation.  HI 
> mobility
> seems to be the antithesis of HIP concept (where HIP is designed to
> provide strong authentication that who you are talking to is who you
> think it is, and that you continue to talk to the same endpoint
> across multihoming or mobility events).

But consider the case where you use, at the same time,
   - delegation, and
   - HI "mobility"
In that way you could allow transport connections to
survive context transfer from one physical device
to another, without needing to pass the private key
between the devices....

BTW, see our Cambridge 2002 paper,  Pekka Nikander and Jari Arkko,
"Delegation of Signalling Rights," in Security Protocols, 10th
International Workshop, Cambridge, UK, April 16-19, 2002, LCNS 2845,
pp. 203-212, Springer, 2003.

That covers the general idea and some simple examples,
though I don't know whether the process migration idea
is covered there or not.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jul 28 17:54:01 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]
> Sent: Wednesday, July 28, 2004 2:43 PM
> To: Henderson, Thomas R
> Cc: Pekka Nikander; [email-masked]
> Subject: RE: [Hipsec-rg] native HIP API
>=20
>=20
> On Wed, 28 Jul 2004, Henderson, Thomas R wrote:
>=20
> > It seems to me that there are two possible options for handling
> > endpoint identifiers in the HIP-aware applications-- handles,
> > and explicitly via extensible structures.  Miika's API seems
> > to allow an application to deal with either, so it is flexible
> > in that regard.  Since explicit handling is needed at least
> > to support referral-type apps, I am still wondering about the
> > need for handles also.
>=20
> Let me further illustrate the point on the handles.
>=20
> Native HIP API assumes that most applications generally need=20
> a "thing" to
> reference the endpoint. The applications don't care what the=20
> thing looks
> like. The handle is a kind of a minimal representation of an endpoint
> reference thing. For the application, the handle is just a=20
> magic number
> that the stack can associate to the protocol specific=20
> endpoint identifier.
> The handle has also the nice property that it is a=20
> collision-free AID for
> the applications.
>=20

We should probably be more precise on terminology here.  Rather than
"things", aren't we talking about names?  Applications need a
name to bind a descriptor, and then they need the bound descriptor to=20
perform I/O.  The name that is often used presently to bind the=20
descriptor is the sockaddr_in (address + port), and it has semantics=20
such that the address is routable.  In the future, it could be=20
something like (host_identifier + port).  I think we are debating=20
what the possible semantics are of the host_identifier.  It seems=20
that you are suggesting applications not be burdened with dealing=20
explicitly with the endpoint identifiers themselves, or avoid
them for forward compatibility reasons.  Maybe a less confusing term=20
is a "local identity alias"?=20

Also, I don't know what you mean by a "protocol specific endpoint=20
identifier"-- aren't endpoint identifiers independent of protocol=20
in general?  Or do you mean protocol family as in HIP vs HIPv2 vs=20
AF_INET (etc.)?

> The native API assumes that "advanced" network applications, such as
> applications using referrals, will be modified to accomodate=20
> the new API.
> In the case of referrals, the application should be modified to make a
> separate function call to find the current IP address=20
> corresponding to the
> handle (note that it is the same case with HIT as the AID).
>=20
> (Btw, it would be nice to have a survey on the number and utilization
> level of publicly available referral applications to understand the
> real importance of the referrals.)

If we are talking about RFC1958-compliant applications, referrals
should be based on names and not addresses.  In the future, IMO,
HIP potentially provides the flexibility to do referrals based
on HITs or HIs in addition to (instead of) FQDNs, so I don't
know whether it is safe to assume that these are only corner cases.
For example, humans might casually use FQDNs to refer other
people to web sites (since passing HIs or HITs will be cumbersome),
but machine-to-machine applications or secure (e.g., bank transaction)
applications may indeed want to skip the reliance on FQDN and use
the HIT or HI specifically in a referral, where the HI is obtained
over a secure channel or is backed up by certificate chains.

>=20
> The handle would make it possible to implement HI mobility=20
> (i.e. changing
> HI for a transport layer connection on the fly without breaking it) in
> future because the handle isolates the application layer from=20
> the details
> of HIs. I don't directly see a direct need for HI mobility, but maybe
> somebody can think up a nice use case. In any case, the=20
> handle approach is
> more modular than the HIT approach.
>=20

I guess this is why I said that I don't see the motivation.  HI mobility
seems to be the antithesis of HIP concept (where HIP is designed to=20
provide strong authentication that who you are talking to is who you
think it is, and that you continue to talk to the same endpoint
across multihoming or mobility events).=20

This discussion suggests to me that it might be useful to write up
some use cases of a HIP-enhanced architecture that describes what
happens at each step (e.g., anonymous web browsing, secure web
browsing to your bank, middleware machine-to-machine applications,=20
peer-to-peer applications, etc.) and what implications that has on=20
the API, exchanging and disseminating host identities, and how HIP=20
should operate.

Tom=20

p.s. applications have to move eventually to IPv6.  Does your
framework translate also to IPv6-- i.e., systems could provide
IPv4-sized "LSI"s and hide the IPv6 addresses from applications? =20
Why or why not is this a good/bad analogy?

From: [email-masked] (Miika Komu)
Date: Wed Jul 28 16:43:00 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 28 Jul 2004, Henderson, Thomas R wrote:

> It seems to me that there are two possible options for handling
> endpoint identifiers in the HIP-aware applications-- handles,
> and explicitly via extensible structures.  Miika's API seems
> to allow an application to deal with either, so it is flexible
> in that regard.  Since explicit handling is needed at least
> to support referral-type apps, I am still wondering about the
> need for handles also.

Let me further illustrate the point on the handles.

Native HIP API assumes that most applications generally need a "thing" to
reference the endpoint. The applications don't care what the thing looks
like. The handle is a kind of a minimal representation of an endpoint
reference thing. For the application, the handle is just a magic number
that the stack can associate to the protocol specific endpoint identifier.
The handle has also the nice property that it is a collision-free AID for
the applications.

The native API assumes that "advanced" network applications, such as
applications using referrals, will be modified to accomodate the new API.
In the case of referrals, the application should be modified to make a
separate function call to find the current IP address corresponding to the
handle (note that it is the same case with HIT as the AID).

(Btw, it would be nice to have a survey on the number and utilization
level of publicly available referral applications to understand the
real importance of the referrals.)

The handle would make it possible to implement HI mobility (i.e. changing
HI for a transport layer connection on the fly without breaking it) in
future because the handle isolates the application layer from the details
of HIs. I don't directly see a direct need for HI mobility, but maybe
somebody can think up a nice use case. In any case, the handle approach is
more modular than the HIT approach.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jul 28 13:37:02 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Tuesday, July 27, 2004 3:55 AM
> To: Henderson, Thomas R
> Cc: Miika Komu; [email-masked]
> Subject: Re: [Hipsec-rg] native HIP API
>=20
>=20
> [Getting back to old e-mail]
>=20
> Tom,
>=20
> >>   * Is the EID approach an overkill? It is quite easy to
> >>     replace the EID with a HIT in the API, if some people
> >>     prefer HITs as the AID.
> >
> > I don't think the EID approach is well motivated.  At least I
> > don't see the benefit of adding another layer of indirection to
> > the architecture.  If I remove EID concept from your API and just
> > deal only with HITs, HIs, and IP addresses, what is lost?
>=20
> Let me disagree with all respect.  Firstly, a few IETF meetings
> ago we (I don't remember who, maybe you were there, maybe not)
> had a discussion of what to do if the 120+ bits currently used
> in HITs becomes too short.  We quickly noticed that it would be
> fairly easy to change the HITs in the protocol to larger ones,
> e.g., 256 bits long.  However, implementing the corresponding
> change at the API level is much harder.  Hence, this is one of
> the reasons why I asked Miika to use separate handles.

I don't see how HIT-128 vs HIT-256 is much different from applications
being able to handle either IPv4 or IPv6 addresses.  The getaddrinfo
(struct addrinfo) seems to be flexible/extensible enough to accommodate.

>=20
> Secondly, passing handles between processes requires a new
> system call while a mere HIT can be passed around as a binary
> value.  As we can envision a handle to be bound to an active
> HIP association and not just to a HIT, the added security can
> be beneficial.

I am not following this point-- could you elaborate?  What added
security do I get by passing the handle rather than the HIT=20
(considering that we are just passing this around locally on
the machine)?

>=20
> But I agree with you that the terminology may not be the best
> one.
>=20

It seems to me that there are two possible options for handling
endpoint identifiers in the HIP-aware applications-- handles,=20
and explicitly via extensible structures.  Miika's API seems
to allow an application to deal with either, so it is flexible
in that regard.  Since explicit handling is needed at least=20
to support referral-type apps, I am still wondering about the
need for handles also.

Tom  =20

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jul 28 11:52:01 2004
Subject: [Hipsec-rg] revised hiprg agenda
Message-ID: <[email-masked]>

See below, room assignment, and an additional draft by=20
Martin Stiemerling.

There may be a few more additions-- I will send out a revised
agenda next week.

Tom

Host Identity Protocol Research Group (hiprg)

Friday, August 6 at 0900-1130
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Harbor I    IRTF  hiprg     Host Identity Protocol Research Group

CHAIR(s): Tom Henderson <[email-masked]>
          Pekka Nikander <[email-masked]>

AGENDA:

  o Administrivia/Agenda                                Tom Henderson

  o Review of HIPRG charter and work plan               Tom Henderson
=20
  o HIP native API                                      Julien =
Laganier/Miika Komu
    - http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf
=20
  o HIP over Network Address Translators                Martin =
Stiemerling
    - draft-stiemerling-hip-nat-01

  o HIP rendezvous concepts                             Lars Eggert
    - draft-eggert-hip-rendezvous-01

  o Host Identity Indirection Infrastructure (Hi3)      Jari Arkko
    - draft-nikander-hiprg-hi3-00.txt

From: [email-masked] (Lars Eggert)
Date: Tue Jul 27 10:43:01 2004
Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070605010006080603080307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

thanks for the feedback! Comments below.

Pekka Nikander wrote:
> 
>>    Transparent communication between HIP and non-HIP nodes places
>>    additional restrictions on the lookup mechanisms.  For example,
>>    non-HIP nodes expect DNS lookups to return IP addresses, requiring
>>    the HI->IP mapping (or a representation thereof) to remain in the
>>    DNS.  Section 4 discusses communication between HIP and non-HIP nodes
>>    and describes different alternatives that support it.
> 
> I think that you want to say that backward compatibility requires
> the FQDN->IP mapping to (or a representation of it) to remain in
> the DNS, not HI->IP mapping.

Correct, my original paragraph is poorly worded. Legacy hosts need the 
FQDN->IP information in the DNS. However, the paragraph before the one 
you quoted explains that although the FQDN->HI map must remain in the 
DNS for HIP-HIP communication, the HI->IP lookup in this case could 
occur in a second step. For communication with legacy hosts, removing 
the IP addresses from the DNS in not an option, and this means that the 
HIs will have to stay there as well. (Unless you replicate this 
information inside the DNS and the other lookup mechanism, which is 
something we have not described yet.)

>>    HIP decouples domain names from IP addresses.  Because transport
>>    protocols bind to host identities, they remain unaware if the set of
>>    IP addresses associated with a host identity changes.  This change
>>    can have various reasons, including, but not limited to, mobility and
>>    multi-homing.
> 
> I find the paragraph above confusing.  At minimum, I think the
> last sentence is irrelevant and can be deleted.  Also, I don't
> quite understand the role of the first sentence, either.

The second sentence is meant to give some examples for why a node's IP 
addresses could change. I'm not sure what you mean by "role of the first 
sentence." It describes one key aspect of HIP, no?

>>    If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP
>>    table, nodes can dynamically update their DNS entry in a secure
>>    fashion [5][6].  The DNS server maintaining the information will then
>>    sign and distribute the updated zone.
> 
> IMHO, the first sentence above is too terse.  It would require
> some explanation.

i.e., "using secured, dynamic DNS updates [5][6]"?

>>    The HIP architecture tries to greatly reduce the frequency of Dynamic
>>    DNS updates by introducing rendezvous servers [2].  Instead of
>>    registering its current set of IP addresses in its HI->IP entry in
>>    the DNS, a HIP node may instead register the IP addresses of its
> 
> Instead of "HI->IP" I would say "HI-IP or FQDN->IP"

Here, and maybe in some other places, the problem of what the DNS 
actually stores comes into play. Instead of containing one map from 
FQDN->HI and a second one from HI->IP, it has one that maps FQDNs into 
pairs of [HI, IP] (see Section 2.) Logically, you can construct one from 
the other, but there is a difference. When writing this, I was always 
trying to look at the logical level - maybe this is confusing? (I found 
it more confusing, however, to switch between talking about FQDN->HI->IP 
and FQDN->[HI, IP].)

>>    are assumed to change only infrequently, this approach can
>>    significantly reduce the load on DNS servers.
> 
> s/load/update load/  ??

Yes.

>>    This approach changes the role of the IP addresses stored in a DNS
>>    entry.  Traditionally, nodes were directly reachable at the IP
>>    addresses listed in their DNS entry.  HIP rendezvous server change
>>    this basic property by replacing the IP addresses of their client
>>    nodes in the DNS with their own.  The IP addresses in a DNS entry
>>    hence no longer directly designate interfaces of an endpoint.
>>    Instead, they identify interfaces of a node that can relay packets to
>>    the endpoint.
> 
> As far as I can understand, the text above is also more or less true
> for Mobile IP, with the exception that Mobile IP Home Agent may need
> to use proxy ARP or proxy ND in addition, depending on how it has
> been implemented.  Maybe we want to mention this architectural similarity
> with Mobile IP Home Agents?

HIP here is actually distinctly different from MobileIP. The HIP draft 
argued that a node would put the address of its rendezvous server into 
its DNS entry, i.e., an address at which it is not directly reachable. 
With MobileIP, the node would use its home address here, at which it is 
directly reachable.

(The -06 revision of the HIP arch ID actually removed the text this 
paragraph was based on, following our discussions in Seoul, so this 
section requires a revision.)

>>   Rendezvous servers may establish some of HIP's benefits even if one
>>    of the endpoints does not support it.  Rendezvous servers live at
>>    static IP addresses.  They can maintain ongoing transport-layer
>>    connections by acting as a relays for HIP nodes whose IP addresses
>>    may change.  The discussion in the remainder of this section assumes
>>    that HIP nodes utilize rendezvous servers to maintain the HI->IP
>>    information as described in Section 3.
> 
> Instead of talking about rendezvous servers, I would talk about
> "nodes acting as rendezvous servers" or "nodes providing rendezvous
> service".  The reason for this is that I'd like to keep the
> rendezvous and proxy functions separate.  I think that it would
> be much easier to understand if a rendezvous server merely provides
> a pure HIP-only rendezvous server for HIP-to-HIP communication,
> and we would call a node providing HIP mobility etc. benefits
> for non-HIP nodes as an IP proxy or HIP proxy, depending on the
> kind of service it provides.

Terminology-wise, we've used three distinct terms for specific examples 
of general rendezvous mechanisms: rendezvous server, broker and agent. 
We specifically use three different terms to avoid confusion when we 
compare the different examples.

When we talk about rendezvous servers, we mean the HIP-to-HIP mechanisms 
worked on in the WG, and possible extensions of that specific mechanism 
to the HIP-to-non-HIP case.

Rendezvous brokers are HIP-to-non-HIP mechanisms that are similar to 
tunnel brokers (hence the name) and also MobileIP home agents.

Rendezvous agents are a third mechanism that enable location privacy.

These are obviously all related in that they're all rendezvous 
mechanisms. I'm open for suggestions on better terminology, and will 
check that we use the correct terms (including the generalization 
"rendezvous service") throughout.

> I would also change the rest of the text accordingly, talking more
> about "rendezvous service" than "rendezvous servers".  Accordingly,
> I would change the text in Section 4 to talk about "proxy service",
> not rendezvous servers.

What is the definition of "proxy service"?

> I don't currently have any strong opinion about the term
> "rendezvous broker", used in Section 5.  However, since it provides
> also other services than just rendezvous, I think that it would
> probably be better to change it, too.
> 
> I don't think it is too useful for me to comment the rest of the
> draft before we've clarified these terminology issues.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms070605010006080603080307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

BkNwylFRAAAAAAAA
--------------ms070605010006080603080307--

From: [email-masked] (Pekka Nikander)
Date: Tue Jul 27 06:22:01 2004
Subject: [Hipsec-rg] Using HITs or HIs in the native API
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

[Moving discussion from multi6 to here.]

> If we design a solution that provides CGAs, we are providing the apps 
> with a secure-enough AID, so they can start using it as an identifier 
> to authorization and so on. This doesn't seems very aligned with the 
> goal of having apps deal with the EID directly
>
> [I mean if we move to the hip plane, HITs are suitable to be used as 
> identity tokens to perform authorization by apps, do you think that 
> appd will start using the HIT or they will move to the HI directly?]
>
> Bottom line, is that if we provide a transition tool such as the CGA 
> (which provides security to some degree), this may be an obstacle to 
> moving towards the "real" identifier later on.

The way the current proposal for a native HIP API has been written
(see previous messages by Miika) is such that it uses handles to
represent peer identity.  These handles can then be thought as
being references to the actual HIs.

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Tue Jul 27 05:55:06 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[Getting back to old e-mail]

Tom,

>>   * Is the EID approach an overkill? It is quite easy to
>>     replace the EID with a HIT in the API, if some people
>>     prefer HITs as the AID.
>
> I don't think the EID approach is well motivated.  At least I
> don't see the benefit of adding another layer of indirection to
> the architecture.  If I remove EID concept from your API and just
> deal only with HITs, HIs, and IP addresses, what is lost?

Let me disagree with all respect.  Firstly, a few IETF meetings
ago we (I don't remember who, maybe you were there, maybe not)
had a discussion of what to do if the 120+ bits currently used
in HITs becomes too short.  We quickly noticed that it would be
fairly easy to change the HITs in the protocol to larger ones,
e.g., 256 bits long.  However, implementing the corresponding
change at the API level is much harder.  Hence, this is one of
the reasons why I asked Miika to use separate handles.

Secondly, passing handles between processes requires a new
system call while a mere HIT can be passed around as a binary
value.  As we can envision a handle to be bound to an active
HIP association and not just to a HIT, the added security can
be beneficial.

But I agree with you that the terminology may not be the best
one.

> So EID is purely a handle like
> a file descriptor to the identities stored in the kernel?

Yes, that is the intention.  But maybe not only to the identities,
maybe directly to an active HIP association.  In that way you
could have several parallel HIP associations between two hosts,
if that ever becomes necessary.  (I realise that the API issues
here are not enough and protocol changes would be needed, but IMHO
it is good if the API can *potentially* represent such an extension.)

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Tue Jul 27 05:42:01 2004
Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Lars and Marco,

> attached is an update of draft-eggert-hip-rendezvous.

Thanks for submitting this draft.  Below some comments to the draft.
The last one is most serious, since I think that we should change
some of the terminology used in the draft, in order to make it
more understandable.

>    Transparent communication between HIP and non-HIP nodes places
>    additional restrictions on the lookup mechanisms.  For example,
>    non-HIP nodes expect DNS lookups to return IP addresses, requiring
>    the HI->IP mapping (or a representation thereof) to remain in the
>    DNS.  Section 4 discusses communication between HIP and non-HIP 
> nodes
>    and describes different alternatives that support it.

I think that you want to say that backward compatibility requires
the FQDN->IP mapping to (or a representation of it) to remain in
the DNS, not HI->IP mapping.

>    HIP decouples domain names from IP addresses.  Because transport
>    protocols bind to host identities, they remain unaware if the set of
>    IP addresses associated with a host identity changes.  This change
>    can have various reasons, including, but not limited to, mobility 
> and
>    multi-homing.

I find the paragraph above confusing.  At minimum, I think the
last sentence is irrelevant and can be deleted.  Also, I don't
quite understand the role of the first sentence, either.

>    If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP
>    table, nodes can dynamically update their DNS entry in a secure
>    fashion [5][6].  The DNS server maintaining the information will 
> then
>    sign and distribute the updated zone.

IMHO, the first sentence above is too terse.  It would require
some explanation.

>    The HIP architecture tries to greatly reduce the frequency of 
> Dynamic
>    DNS updates by introducing rendezvous servers [2].  Instead of
>    registering its current set of IP addresses in its HI->IP entry in
>    the DNS, a HIP node may instead register the IP addresses of its

Instead of "HI->IP" I would say "HI-IP or FQDN->IP"

>    are assumed to change only infrequently, this approach can
>    significantly reduce the load on DNS servers.

s/load/update load/  ??

>    This approach changes the role of the IP addresses stored in a DNS
>    entry.  Traditionally, nodes were directly reachable at the IP
>    addresses listed in their DNS entry.  HIP rendezvous server change
>    this basic property by replacing the IP addresses of their client
>    nodes in the DNS with their own.  The IP addresses in a DNS entry
>    hence no longer directly designate interfaces of an endpoint.
>    Instead, they identify interfaces of a node that can relay packets 
> to
>    the endpoint.

As far as I can understand, the text above is also more or less true
for Mobile IP, with the exception that Mobile IP Home Agent may need
to use proxy ARP or proxy ND in addition, depending on how it has
been implemented.  Maybe we want to mention this architectural 
similarity
with Mobile IP Home Agents?

>   Rendezvous servers may establish some of HIP's benefits even if one
>    of the endpoints does not support it.  Rendezvous servers live at
>    static IP addresses.  They can maintain ongoing transport-layer
>    connections by acting as a relays for HIP nodes whose IP addresses
>    may change.  The discussion in the remainder of this section assumes
>    that HIP nodes utilize rendezvous servers to maintain the HI->IP
>    information as described in Section 3.

Instead of talking about rendezvous servers, I would talk about
"nodes acting as rendezvous servers" or "nodes providing rendezvous
service".  The reason for this is that I'd like to keep the
rendezvous and proxy functions separate.  I think that it would
be much easier to understand if a rendezvous server merely provides
a pure HIP-only rendezvous server for HIP-to-HIP communication,
and we would call a node providing HIP mobility etc. benefits
for non-HIP nodes as an IP proxy or HIP proxy, depending on the
kind of service it provides.

I would also change the rest of the text accordingly, talking more
about "rendezvous service" than "rendezvous servers".  Accordingly,
I would change the text in Section 4 to talk about "proxy service",
not rendezvous servers.

I don't currently have any strong opinion about the term
"rendezvous broker", used in Section 5.  However, since it provides
also other services than just rendezvous, I think that it would
probably be better to change it, too.

I don't think it is too useful for me to comment the rest of the
draft before we've clarified these terminology issues.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jul 26 13:46:08 2004
Subject: [Hipsec-rg] draft hiprg agenda
Message-ID: <[email-masked]>

As of July 26, this is the draft agenda for the hiprg meeting. =20
I will post revisions to this as more things are confirmed.

Tom
 =20

Host Identity Protocol Research Group (hiprg)

Friday, August 6 at 0900-1130
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

CHAIR(s): Tom Henderson <[email-masked]>
          Pekka Nikander <[email-masked]>

AGENDA:

  o Administrivia/Agenda                                Tom Henderson

  o Review of HIPRG charter and work plan               Tom Henderson
=20
  o HIP native API                                      Miika Komu

  o HIP rendezvous concepts                             (Lars Eggert)
    - draft-eggert-hip-rendezvous-01

  o Host Identity Indirection Infrastructure (Hi3)      Jari Arkko
    - draft-nikander-hiprg-hi3-00.txt

From: [email-masked] (Lars Eggert)
Date: Fri Jul 23 01:52:00 2004
Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt]
Message-ID: <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms040500090301060700060609
Content-Type: multipart/mixed;
 boundary="------------030904030200060109020308"

This is a multi-part message in MIME format.
--------------030904030200060109020308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

attached is an update of draft-eggert-hip-rendezvous. Unlike its 
companion document (draft-eggert-hip-rvs), this one takes a higher-level 
look at rendezvous options for HIP.

The -01 version mainly adds a chapter on mechanisms for HIP location 
privacy by a new co-author, Marco Liebsch.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------030904030200060109020308
Content-Type: message/rfc822;
 name="I-D ACTION:draft-eggert-hip-rendezvous-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-eggert-hip-rendezvous-01.txt"

To: [email-masked]
From: [email-masked]
Date: Thu, 22 Jul 2004 15:34:40 -0400
Subject: I-D ACTION:draft-eggert-hip-rendezvous-01.txt
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Host Identity Protocol (HIP) Rendezvous Mechanisms
	Author(s)	: L. Eggert, M. Liebsch
	Filename	: draft-eggert-hip-rendezvous-01.txt
	Pages		: 27
	Date		: 2004-7-22
	
This document discusses rendezvous mechanisms for the Host Identity
   Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous
   Servers, improve operation when HIP nodes are multi-homed or mobile.
   They can also facilitate communication between HIP and non-HIP nodes.
   Possible rendezvous mechanisms differ in performance, compatibility,
   and impact on the HIP and Internet architectures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eggert-hip-rendezvous-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-eggert-hip-rendezvous-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-eggert-hip-rendezvous-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-eggert-hip-rendezvous-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-eggert-hip-rendezvous-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------030904030200060109020308--

--------------ms040500090301060700060609
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040500090301060700060609--

From: [email-masked] (Miika Komu)
Date: Wed Jul 21 02:24:01 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 20 Jul 2004, Henderson, Thomas R wrote:

> > I did not understand this. Did my previous correction on the mappings
> > clear this out?
> >
>
> OK, this makes more sense to me now.  So you are saying that the
> HIP applications need both a file descriptor for the socket (sockfd)
> using PF_HIP, and also one for host identities (eid) that refer
> the sockfd to the right host identity?  So EID is purely a handle like
> a file descriptor to the identities stored in the kernel?

Yes.

> I think I see your point about the extensibility/flexibility now
> if representations of host identities (including HITs) were to
> change in the future.  I think it depends on that and whether
> applications in future would rather handle descriptors or actual
> identities themselves.  Maybe HIT will be enough.

Perhaps the EID concept could be useful for other protocols with
id/locator split, as I mentioned in text. The same sockaddr_eid structure
could be reused in the other protocols, and just filled with a different
protocol family. Perhaps the benefit is still quite minimal, because you
can always define a new protocol specific sockaddr structure.

The HITs also have the property that they can be compared with each other.
Depending on how the descriptors are defined, they may or may not be
compared with each other (the latter approach was chosen in the native HIP
API).

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Henderson, Thomas R)
Date: Tue Jul 20 21:22:01 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]=20
> Sent: Tuesday, July 20, 2004 1:18 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [Hipsec-rg] native HIP API
>=20
>=20
> On Tue, 20 Jul 2004, Henderson, Thomas R wrote:
>=20
> > It is also somewhat confusing to be dealing with "endpoints" and
> > "hosts" and saying that the mapping of EIDs to host IDs is=20
> one to many
> > (p.33).
>=20
> You are referring to section 4.1.4 "Socket Bindings"? There=20
> is typo in the
> text of that section:
>=20
> "The source EID is associated to multiple source HIs and the=20
> destination
> EID is associated to multiple destination HIs."
>=20
> The EID-to-HI mapping should be many-to-one, not one-to-many=20
> as the text
> implies. The mappings are correct in the figure 4.3.
>=20
> > I think what you are getting at is that a physical machine=20
> may have many
> > keys, so it can be said to embody many "hosts", but you=20
> actually have
> > one physical endpoint?  But in that case, it seems to be more
> > straightforward to say that an application just affiliates=20
> with one of
> > possibly several local host identities?
>=20
> I did not understand this. Did my previous correction on the mappings
> clear this out?
>=20

OK, this makes more sense to me now.  So you are saying that the
HIP applications need both a file descriptor for the socket (sockfd)
using PF_HIP, and also one for host identities (eid) that refer
the sockfd to the right host identity?  So EID is purely a handle like
a file descriptor to the identities stored in the kernel?

I think I see your point about the extensibility/flexibility now
if representations of host identities (including HITs) were to
change in the future.  I think it depends on that and whether
applications in future would rather handle descriptors or actual
identities themselves.  Maybe HIT will be enough.

Tom

From: [email-masked] (Miika Komu)
Date: Tue Jul 20 15:19:01 2004
Subject: [Hipsec-rg] native HIP API
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 20 Jul 2004, Henderson, Thomas R wrote:

> > Questions:
> >
> >   * Is the EID approach an overkill? It is quite easy to
> > replace the EID
> >     with a HIT in the API, if some people prefer HITs as the AID.
>
> I don't think the EID approach is well motivated.  At least I
> don't see the benefit of adding another layer of indirection to
> the architecture.  If I remove EID concept from your API and just
> deal only with HITs, HIs, and IP addresses, what is lost?

Forward compatibility is lost with the HIT approach. The size of HIT is
fixed and there may be some need to change it later.

The EID approach was chosen in the beginning of the project. In the end, I
am not totally convinced that the EID approach is superior to the HIT
approach.

> It is also somewhat confusing to be dealing with "endpoints" and
> "hosts" and saying that the mapping of EIDs to host IDs is one to many
> (p.33).

You are referring to section 4.1.4 "Socket Bindings"? There is typo in the
text of that section:

"The source EID is associated to multiple source HIs and the destination
EID is associated to multiple destination HIs."

The EID-to-HI mapping should be many-to-one, not one-to-many as the text
implies. The mappings are correct in the figure 4.3.

> I think what you are getting at is that a physical machine may have many
> keys, so it can be said to embody many "hosts", but you actually have
> one physical endpoint?  But in that case, it seems to be more
> straightforward to say that an application just affiliates with one of
> possibly several local host identities?

I did not understand this. Did my previous correction on the mappings
clear this out?

> The EID does not seem to be exposed outside of the box, so in that sense
> it doesn't seem to need to be called an "endpoint identifier" instead of
> simply an alias or handle.

Seems to me that the EID term is a bit misleading. In the scope of the
thesis, it means "Endpoint Identifier Descriptor" (as in File Descriptor).

> >   * Opinions on the PF_HIP family?
> >
>
> Overall, the use of a separate family makes sense to me and
> should provide the desired commonality with existing sockets
> yet allow for HIP-specific messaging to be defined.

Right.

> - you might want to look at the recent multi6 list where there seems
> to have been some adoption of terms/concepts such as "application
> identifier" (AID), "context identifier" (CID), and "context identifier
> tag" (CIDT).

Thanks.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Henderson, Thomas R)
Date: Tue Jul 20 11:52:00 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

Mikka, thanks for providing the draft, some responses to your
questions below...

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]=20
> Sent: Thursday, July 08, 2004 3:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Hipsec-rg] native HIP API
>=20
>=20
> There were some people interested in the HIP userspace API=20
> issues and I
> promised to get back to the topic later by providing some background
> information.
>=20
> My master's thesis proposes a new API for HIP aware=20
> applications. It is
> fully not completed yet but you can download a snapshot from the url
> below:
>=20
> http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf
>=20

<snip>

>=20
> Questions:
>=20
>   * Is the EID approach an overkill? It is quite easy to=20
> replace the EID
>     with a HIT in the API, if some people prefer HITs as the AID.

I don't think the EID approach is well motivated.  At least I
don't see the benefit of adding another layer of indirection to=20
the architecture.  If I remove EID concept from your API and just=20
deal only with HITs, HIs, and IP addresses, what is lost?

It is also somewhat confusing to be dealing with "endpoints" and
"hosts" and saying that the mapping of EIDs to host IDs is one
to many (p.33).  I think what you are getting at is that a physical
machine may have many keys, so it can be said to embody many
"hosts", but you actually have one physical endpoint?  But in
that case, it seems to be more straightforward to say that an
application just affiliates with one of possibly several local=20
host identities?  The EID does not seem to be exposed outside of
the box, so in that sense it doesn't seem to need to be called
an "endpoint identifier" instead of simply an alias or handle.

Your thesis raised some interesting questions as to what exactly
applications should be exposed to, and what they should have
control over selecting, such as:
- in what cases should/must an application select a source=20
host identity to use?
- should applications be exposed to interface sets (or as you
point out, interfaces on the source side and IP addresses on
the destination side)?
- should configuration parameters such as which ESP_TRANSFORM
to use be set as socket options or as policy options via some
kind of SPD interface?

>=20
>   * Opinions on the PF_HIP family?
>=20

Overall, the use of a separate family makes sense to me and
should provide the desired commonality with existing sockets
yet allow for HIP-specific messaging to be defined.

some other comments:
p.32: s/difference to between/difference between
p.33: s/associated to/associated with  (many places)
p.36:  HIP_HI_ANY_PUB repeated twice (many places)

- you might want to look at the recent multi6 list where there seems
to have been some adoption of terms/concepts such as "application
identifier" (AID), "context identifier" (CID), and "context identifier
tag" (CIDT). =20

From: [email-masked] (Miika Komu)
Date: Thu Jul 15 14:11:01 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

There were some people interested in the HIP userspace API issues and I
promised to get back to the topic later by providing some background
information.

My master's thesis proposes a new API for HIP aware applications. It is
fully not completed yet but you can download a snapshot from the url
below:

http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf

I suggest that we continue the discussion on the hipsec research mailing
list although I crossposted this email.

Summary:

  The purpose of the native HIP API is to provide an explicit interface
  for HIP aware applications. It provides two new features compared to the
  "legacy HIP API". Applications are given the opportunity to control HIP
  connection attributes. Applications can also provide their own Host
  Identities to the host.

  The native HIP API is based on the BSD sockets API. The sockets API
  design is extended with two significant changes: a new protocol family
  (PF_HIP) and a new application identifier (EID).

  The new family requires a new HIP specific socket handler. The socket
  handler acts as a EID-to-HI address translator. It also allows  setting
  and querying of HIP specific socket options. The new socket handler
  isolates the HIP sockets from the IPv4/IPv6 sockets.

  The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It
  hides the details of the variable length HIs and the associated
  ephemeral locators. The EID cannot be used as a referral, but there are
  interfaces for retrieving the HIs and locators corresponding to the EID.

  The EID is preferred as the AID instead of HIT for a few reasons. It
  provides forward compatibility with the HIP protocol. If the length of
  HIT were to change, the changes needed in the userspace would be
  minimal. The EID concept can also be beneficial for other protocols with
  the id/locator split.

  The API provides a new endpoint resolver, which is syntactically similar
  to the sockets API resolver. Basically, the resolver inputs a hostname
  and returns the EIDs corresponding to the hostname. The resolver makes
  the HI-to-locators mapping management transparent to the "typical"
  applications. However, the API allows the "advanced" applications to
  configure the mappings manually.

  The API supports explicit controlling of opportunistic HIP mode.
  Falling back to plain TCP/IP is also possible if the DNS does not
  contain the HIs of the peer.

  I implemented the socket handler into the networking stack, It supports
  the basic functionality of the API. It acts as a wrapper to IPv6 socket
  handler and it was not very difficult to implement. I also ported a
  telnet client and server to use the API with little effort.

I writing an IETF draft for API proposal, but first, I would like receive
some feedback and open a free discussion on the topic. I have already some
specific questions in mind, but feel free to comment on anything.

Questions:

  * Is the EID approach an overkill? It is quite easy to replace the EID
    with a HIT in the API, if some people prefer HITs as the AID.

  * Opinions on the PF_HIP family?

P.S. I am on a holiday next week and cannot read my email (expect a delay
     on the replys).

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jul 12 13:30:01 2004
Subject: [Hipsec-rg] Agenda requests for HIP RG meeting in San Diego
Message-ID: <[email-masked]>

(cross-posted to HIP WG list)

The HIP IRTF RG plans to meet in San Diego.  We haven't
yet heard back from the IETF on a time slot, but I will
announce it when the agenda is eventually updated.

Please send any proposed agenda items to me and Pekka.

Thanks,
Tom

From: [email-masked] (Miika Komu)
Date: Thu Jul  8 05:55:01 2004
Subject: [Hipsec-rg] native HIP API
Message-ID: <[email-masked]>

There were some people interested in the HIP userspace API issues and I
promised to get back to the topic later by providing some background
information.

My master's thesis proposes a new API for HIP aware applications. It is
fully not completed yet but you can download a snapshot from the url
below:

http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf

I suggest that we continue the discussion on the hipsec research mailing
list although I crossposted this email.

Summary:

  The purpose of the native HIP API is to provide an explicit interface
  for HIP aware applications. It provides two new features compared to the
  "legacy HIP API". Applications are given the opportunity to control HIP
  connection attributes. Applications can also provide their own Host
  Identities to the host.

  The native HIP API is based on the BSD sockets API. The sockets API
  design is extended with two significant changes: a new protocol family
  (PF_HIP) and a new application identifier (EID).

  The new family requires a new HIP specific socket handler. The socket
  handler acts as a EID-to-HI address translator. It also allows  setting
  and querying of HIP specific socket options. The new socket handler
  isolates the HIP sockets from the IPv4/IPv6 sockets.

  The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It
  hides the details of the variable length HIs and the associated
  ephemeral locators. The EID cannot be used as a referral, but there are
  interfaces for retrieving the HIs and locators corresponding to the EID.

  The EID is preferred as the AID instead of HIT for a few reasons. It
  provides forward compatibility with the HIP protocol. If the length of
  HIT were to change, the changes needed in the userspace would be
  minimal. The EID concept can also be beneficial for other protocols with
  the id/locator split.

  The API provides a new endpoint resolver, which is syntactically similar
  to the sockets API resolver. Basically, the resolver inputs a hostname
  and returns the EIDs corresponding to the hostname. The resolver makes
  the HI-to-locators mapping management transparent to the "typical"
  applications. However, the API allows the "advanced" applications to
  configure the mappings manually.

  The API supports explicit controlling of opportunistic HIP mode.
  Falling back to plain TCP/IP is also possible if the DNS does not
  contain the HIs of the peer.

  I implemented the socket handler into the networking stack, It supports
  the basic functionality of the API. It acts as a wrapper to IPv6 socket
  handler and it was not very difficult to implement. I also ported a
  telnet client and server to use the API with little effort.

I writing an IETF draft for API proposal, but first, I would like receive
some feedback and open a free discussion on the topic. I have already some
specific questions in mind, but feel free to comment on anything.

Questions:

  * Is the EID approach an overkill? It is quite easy to replace the EID
    with a HIT in the API, if some people prefer HITs as the AID.

  * Opinions on the PF_HIP family?

P.S. I am on a holiday next week and cannot read my email (expect a delay
     on the replys).

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/