Subject: [HIPSec-rg] About IP and HIP relationship and SIP
From: [email-masked] (Joseph So)
Date: Wed Aug 25 22:40:01 2004

Dear All,
  I am a new subscribe of this list. I'm a research student in Mobiltiy
Management. I just know the HIP and found it is interesting. After reading
the Internet-Draft, I still don't understand very well about how HIP map
with IP address, is it by DST of SPI only? How can HIP know the DST? What
happened if IP address changed?
  Futhermore, can current SIP work with HIP?
  Thanks a lot.
Yours faithfully,
Joseph

-- 
Supergünstige DSL-Tarife + WLAN-Router für 0,- EUR*
Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

From: [email-masked] (Pekka Nikander)
Date: Mon Aug 23 09:46:00 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> Some question were raised in the hipsec-rg meeting in San Diego and 
>> I'd
>> like comment them briefly:
>>>
>>> Lars Eggert:  Why are you binding to a src interface rather than
>>> address?...
>
> 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.

I like this argument.

>  Both can change - e.g., inserting PCMCIA cards, USB interfaces, etc.

Right.  But see below.

> 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.

Right.  But in the mobile multi-homed situation, where at least I would
consider HIP very useful, the interfaces are more stable than the
addresses.  Hence our motivation for binding locally to interfaces,
not addresses.

However, thinking more widely, yes, you need both.  Furthermore,
you need a notification API that tells your application whenever there
is a change in the available interfaces and/or addresses.

--Pekka

From: [email-masked] (Miika Komu)
Date: Sat Aug 21 15:50:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 20 Aug 2004, Joe Touch wrote:

> A hostile host can just lookup the host it wants to impersonate and use
> its HIP ID anyway.

HIP ID equals to the public key of a host (or a hash of it).
Impersonating the real host means that hostile host has cracked the public
key, which is computationally a very difficult task.

> If you go to the DNS, presumably the entry there was signed - if you
> need to validate that the endpoint is who the DNS says it was, you MUST
> use the same signing authority as validation anyway;  the HIP ID doesn't
> add any information.

The entry in the DNS is the public key of the host (or a hash of it), so
it does not require to be signed. The HIP base exchange fails if the key
received from the DNS does not match with the one communicated in the base
exchange.

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

From: [email-masked] (Joe Touch)
Date: Sat Aug 21 12:35:03 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

Miika Komu wrote:

> On Thu, 19 Aug 2004, Joe Touch wrote:
> 
> 
>>We already have a DNS which provides a global resolution structure. What
>>is the gain in having a global ID space?
>>
>>Far as I can tell, you need the DNS (or a copy that's just as
>>complicated and global) to give you the rendezvous points. If the dest
>>IS the rendezvous point, you're done. Why bother putting the ID in the
>>DNS and ensuring that it's global?
> 
> 
> If you don't know the ID of the peer before connection establishment, it
> is called "HIP opportunistic mode". A hostile host can DoS the peer and
> pretend to be the peer for you.
> 
> On the other hand, you can detect that another host has replaced the real
> peer if you can first lookup the ID of the peer from the DNS.

A hostile host can just lookup the host it wants to impersonate and use 
its HIP ID anyway. If you go to the DNS, presumably the entry there was 
signed - if you need to validate that the endpoint is who the DNS says 
it was, you MUST use the same signing authority as validation anyway; 
the HIP ID doesn't add any information.

Joe

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

--------------enig59215F12241C9731B7D6547C--

From: [email-masked] (Joe Touch)
Date: Sat Aug 21 12:35:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

Henderson, Thomas R wrote:

> 
>>-----Original Message-----
>>From: Joe Touch [mailto:[email-masked]]
>>Sent: Monday, August 16, 2004 9:20 PM
>>To: Tim Shepard
>>Cc: Lars Eggert; Miika Komu; [email-masked]; Andrew
>>McGregor
>>Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg
>>meeting
> 
> 
>>I always thought of HIP has having two uses:
>>
>>	1. given global IDs and a rendezvous IP address, start a
>>	connection with that ID via the rendezvous. either the
>>	rendezvous point forwards the connection request, or replies
>>	with further info on how to find that ID
>>
>>	2. given an initial IP address, go there and get an ID
>>	that is unique only to you and that end; allow the endpoints
>>	to move once established, based on keeping that ID
>>
>>I always though of HIP as focusing on (2); (1) is somewhat 
>>nonsensical, 
>>as Tim points out above. 
>>
> 
> 
> If HIP focused on (2), then it would seem to just be a heavyweight 
> version of purpose built keys or TCP-migrate or similar proposals.
> 
> I've always thought of HIP of having most applicability when upper 
> layer protocols including applications would prefer to name end 
> systems by a global ID.  In general, this requires a resolution
> infrastructure, but one can get part of the way there perhaps
> by using DNS and/or certificate chains.
> 
> Tom

We already have a DNS which provides a global resolution structure. What 
is the gain in having a global ID space?

Far as I can tell, you need the DNS (or a copy that's just as 
complicated and global) to give you the rendezvous points. If the dest 
IS the rendezvous point, you're done. Why bother putting the ID in the 
DNS and ensuring that it's global?

Joe

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

--------------enigE73D5E40BB122B37FD1BE3D1--

From: [email-masked] (Henderson, Thomas R)
Date: Fri Aug 20 13:45:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, August 20, 2004 7:38 AM
> To: Miika Komu
> Cc: Henderson, Thomas R; Tim Shepard; Lars Eggert;
> [email-masked]; Andrew McGregor
> Subject: Re: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg
> meeting
>=20
>=20
>=20
>=20
> Miika Komu wrote:
>=20
> > On Thu, 19 Aug 2004, Joe Touch wrote:
> >=20
> >=20
> >>We already have a DNS which provides a global resolution=20
> structure. What
> >>is the gain in having a global ID space?
> >>
> >>Far as I can tell, you need the DNS (or a copy that's just as
> >>complicated and global) to give you the rendezvous points.=20
> If the dest
> >>IS the rendezvous point, you're done. Why bother putting=20
> the ID in the
> >>DNS and ensuring that it's global?
> >=20
> >=20
> > If you don't know the ID of the peer before connection=20
> establishment, it
> > is called "HIP opportunistic mode". A hostile host can DoS=20
> the peer and
> > pretend to be the peer for you.
> >=20
> > On the other hand, you can detect that another host has=20
> replaced the real
> > peer if you can first lookup the ID of the peer from the DNS.
>=20
> A hostile host can just lookup the host it wants to=20
> impersonate and use=20
> its HIP ID anyway.=20

Only the holder of the private key can properly sign the HIP messages.

>If you go to the DNS, presumably the entry=20
> there was=20
> signed - if you need to validate that the endpoint is who the=20
> DNS says=20
> it was, you MUST use the same signing authority as validation anyway;=20
> the HIP ID doesn't add any information.
>=20

It is possible to implement protocol extensions that have some HIP=20
properties without using a new global namespace.  TCP Migrate is a=20
good example based on FQDNs and DNSSEC.  But such solutions end up=20
overloading existing names and mechanisms, and don't have quite the=20
same security properties.  The HIP architecture draft has a=20
discussion of this. =20

The HIP RG is chartered to study whether the costs of deploying
HIP infrastructure are worth the benefits that HIP might bring.
So I think that this is a valid debate.  In particular, a new
resolution infrastructure will be expensive and complicated.
But we have heard concern not to load too many HIP-like=20
responsibilities onto DNS as well, and concern also about=20
HIP dependencies on DNS.

We should also consider that, even if HIP infrastructure were
to be built out, humans typically prefer to deal with FQDNs or=20
other human-readable names to name hosts, and therefore, we need=20
to still consider how bindings between such names=20
(aliases) and HI(T)s are secured in many usage scenarios. =20

Tom

From: [email-masked] (Miika Komu)
Date: Fri Aug 20 02:08:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 19 Aug 2004, Joe Touch wrote:

> We already have a DNS which provides a global resolution structure. What
> is the gain in having a global ID space?
>
> Far as I can tell, you need the DNS (or a copy that's just as
> complicated and global) to give you the rendezvous points. If the dest
> IS the rendezvous point, you're done. Why bother putting the ID in the
> DNS and ensuring that it's global?

If you don't know the ID of the peer before connection establishment, it
is called "HIP opportunistic mode". A hostile host can DoS the peer and
pretend to be the peer for you.

On the other hand, you can detect that another host has replaced the real
peer if you can first lookup the ID of the peer from the DNS.

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

From: [email-masked] (Henderson, Thomas R)
Date: Thu Aug 19 00:07:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Monday, August 16, 2004 9:20 PM
> To: Tim Shepard
> Cc: Lars Eggert; Miika Komu; [email-masked]; Andrew
> McGregor
> Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg
> meeting

>=20
> I always thought of HIP has having two uses:
>=20
> 	1. given global IDs and a rendezvous IP address, start a
> 	connection with that ID via the rendezvous. either the
> 	rendezvous point forwards the connection request, or replies
> 	with further info on how to find that ID
>=20
> 	2. given an initial IP address, go there and get an ID
> 	that is unique only to you and that end; allow the endpoints
> 	to move once established, based on keeping that ID
>=20
> I always though of HIP as focusing on (2); (1) is somewhat=20
> nonsensical,=20
> as Tim points out above.=20
>

If HIP focused on (2), then it would seem to just be a heavyweight=20
version of purpose built keys or TCP-migrate or similar proposals.

I've always thought of HIP of having most applicability when upper=20
layer protocols including applications would prefer to name end=20
systems by a global ID.  In general, this requires a resolution
infrastructure, but one can get part of the way there perhaps
by using DNS and/or certificate chains.

Tom

 =20

From: [email-masked] (Joe Touch)
Date: Thu Aug 19 00:04:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]>
References: <[email-masked] .com> <[email-masked]> <[email-masked]> <[email-masked]> <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]>
Message-ID: <[email-masked]>

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

Andrew McGregor wrote:

...
>>> Additionally, as Joe pointed out, interfaces can have aliases, and
>>> furthermore, those aliases may move from one interface to another during
>>> the lifetime of a connection. Binding to IP addresses instead of
>>> interfaces avoids all this update mess.
>>
>>
>> I have to admit that I haven't thought about interface aliases. Still, if
>> the interface alias changes, it creates an event that can be detected in
>> the HIP module. The HIP module can sort out the "mess".
>>
>> But is it really a mess? By changing the alias, you could signal that "I
>> want to take all of my HIP connections from wlan0 to eth0 to get faster
>> connectivity". Can you provide a counter example?
> 
> 
> Interfaces can be transient, for instance I have a system that brings up 
> and tears down tunnels on a regular basis.  At least most of the time, 
> the default route is over one of those tunnels.  To which do I bind by 
> default?
> 
> As well, the subnet containing the other endpoint of those tunnels is 
> host routed by AODV and the routes get updated frequently (sometimes 
> route persistence is only a couple of seconds).  The outgoing interface 
> may change.  To which interface do I bind now?
> 
> Binding (either in the bind() sense or in the associate sense) to an 
> interface just does not make sense.  An endpoint descriptor should be 
> associated with either an IP address (in which case we presume that it 
> is short lived, static, being handled by tunneling or MobileIP, or in 
> another way not a problem) or an HI (in which case it is not a problem 
> either).

As I already posted, it is necessary to bind to an interface/IP address 
pair. Neither one alone is sufficient.

Joe

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

--------------enigABAEEE7E50074E68B99A6CC5--

From: [email-masked] (Andrew McGregor)
Date: Wed Aug 18 04:30:00 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked] .com> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]>

--On Wednesday, 18 August 2004 12:25 a.m. +0300 Miika Komu 
<[email-masked]> wrote:

> On Mon, 16 Aug 2004, Lars Eggert wrote:
>
>> Miika,
>>
>> Miika Komu wrote:
>> >>
>> >> Lars Eggert:  Why are you binding to a src interface rather than
>> >> address?
>> >>
>> >> 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.
>> >
>> > 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.
>> >
>> > (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.)
>> >
>> > Other opinions? Does anyone think that using interfaces instead of
>> > IP-addresses is a better approach? Or a no-go?
>>
>> now I'm confused. The slides in San Diego showed a binding from HITs to
>> interfaces. Yet this email talks about binding HITs to IP addresses.
>> Which is it? Were the slides in San Diego wrong?
>
> Ah, you were not talking about binding to a socket (as in the bind system
> call). But yes, the source HI is associated (bound) to an interface.
>
>> The issue we raised in San Diego was that *nothing* in the current
>> sockets API ever binds to interfaces. Everything binds to IP addresses.
>> Even INADDR_ANY just means "any IP address."
>
> Agree, but we're extending the sockets API anyway by introducing a
> new namespace and a new layer. Why not go a step even further?
>
>> A HIP API would do well to follow this approach. The reason is that an
>> outgoing interface is determined for each packet independently based on
>> a routing lookup at transmission time. Which means that when the routing
>> table changes, implementations don't have to go through all bindings to
>> change their interfaces.
>
> Could you elaborate the last sentence (with an example perhaps)?

Think about a wireless host that is doing mesh routing on several 
interfaces.  Route persistence will be very short, and sometimes a 
neighbour will change adjacency.  Therefore the outgoing interface is going 
to change.  Often.  Like, perhaps every couple of seconds.

>
>> Additionally, as Joe pointed out, interfaces can have aliases, and
>> furthermore, those aliases may move from one interface to another during
>> the lifetime of a connection. Binding to IP addresses instead of
>> interfaces avoids all this update mess.
>
> I have to admit that I haven't thought about interface aliases. Still, if
> the interface alias changes, it creates an event that can be detected in
> the HIP module. The HIP module can sort out the "mess".
>
> But is it really a mess? By changing the alias, you could signal that "I
> want to take all of my HIP connections from wlan0 to eth0 to get faster
> connectivity". Can you provide a counter example?

Interfaces can be transient, for instance I have a system that brings up 
and tears down tunnels on a regular basis.  At least most of the time, the 
default route is over one of those tunnels.  To which do I bind by default?

As well, the subnet containing the other endpoint of those tunnels is host 
routed by AODV and the routes get updated frequently (sometimes route 
persistence is only a couple of seconds).  The outgoing interface may 
change.  To which interface do I bind now?

Binding (either in the bind() sense or in the associate sense) to an 
interface just does not make sense.  An endpoint descriptor should be 
associated with either an IP address (in which case we presume that it is 
short lived, static, being handled by tunneling or MobileIP, or in another 
way not a problem) or an HI (in which case it is not a problem either).

A system process, not necessarily the resolver, should then maintain the 
HI/locator associations.  This requires an API of its own, one that an 
application should be permitted to use in the (hopefully rare) case that it 
needs to.

<snip>

>
>> >> 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.
>>
>> I don't recall Andrew's exact question, and the above doesn't mean
>> anything to me. Could you please elaborate?
>
> Hmm... maybe Andrew misunderstood too the bind() vs. association. I was
> not in the meeting, so I was guessing Andrew's thoughts... Andrew?

My point was specifically about maintenance of HI to IP mappings, and Miika 
answered it fine.  I'd like to add: applications should be allowed to 
assert their own mappings (especially diagnostic tools, but things like web 
servers will frequently want to do this for application security reasons, 
just like they do with IP addresses now).

Andrew

From: [email-masked] (Joe Touch)
Date: Tue Aug 17 23:19:05 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

Tim Shepard wrote:

>>See Tim's email. I agree with him that finding a way to use HIP without 
>>a deployed DNS would be very useful. How do you bootstrap communication 
>>if someone hands you just a HIT?
> 
> You don't.   When I hear that question (and I've heard it many times)
> it sounds to me like a question equivalent to:
> 
>    How do you bootstrap an ssh connection if someone hands you (only)
>    the ssh host key of a machine?
> 
> Another equivalent question might be:
> 
>    How am I supposed to be able to begin a postal correspondence with
>    Alyssa P. Hacker  when the only think you've told me is her name?
> 
> A referral requires a name *and* an address.  I don't see anyway
> around that.  Directories can be useful, but no directory will ever
> have everything or everyone in it.

I always thought of HIP has having two uses:

	1. given global IDs and a rendezvous IP address, start a
	connection with that ID via the rendezvous. either the
	rendezvous point forwards the connection request, or replies
	with further info on how to find that ID

	2. given an initial IP address, go there and get an ID
	that is unique only to you and that end; allow the endpoints
	to move once established, based on keeping that ID

I always though of HIP as focusing on (2); (1) is somewhat nonsensical, 
as Tim points out above. Both end up requiring a rendezvous; (1) also 
requires global uniqueness of IDs and a global lookup infrastructure. 
(2) relies on the existing infrastructure (e.g., DNS) to get you to the 
rendezvous point, at which point the ID is between you and the other 
end, very much like a TCP ISN.

Joe

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

--------------enigE99FF82FB3DBB9D4529409AE--

From: [email-masked] (Joe Touch)
Date: Tue Aug 17 23:19:03 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

Lars Eggert wrote:

> now I'm confused. The slides in San Diego showed a binding from HITs to 
> interfaces. Yet this email talks about binding HITs to IP addresses. 
> Which is it? Were the slides in San Diego wrong?
> 
> The issue we raised in San Diego was that *nothing* in the current 
> sockets API ever binds to interfaces. Everything binds to IP addresses. 
> Even INADDR_ANY just means "any IP address."

Actually, there is a way to bind to an interface - used in multicast 
addresses, notably. It may also be required where a single unicast 
address is used on multiple interfaces; although that's possible, I 
don't know how well it's supported.

Joe

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

--------------enig9EBDEB70A4F1BDEC99148D14--

From: [email-masked] (Joe Touch)
Date: Tue Aug 17 23:19:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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"

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

From: [email-masked] (Miika Komu)
Date: Tue Aug 17 16:23:00 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 16 Aug 2004, Lars Eggert wrote:

> Miika,
>
> Miika Komu wrote:
> >>
> >>Lars Eggert:  Why are you binding to a src interface rather than
> >>address?
> >>
> >>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.
> >
> > 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.
> >
> > (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.)
> >
> > Other opinions? Does anyone think that using interfaces instead of
> > IP-addresses is a better approach? Or a no-go?
>
> now I'm confused. The slides in San Diego showed a binding from HITs to
> interfaces. Yet this email talks about binding HITs to IP addresses.
> Which is it? Were the slides in San Diego wrong?

Ah, you were not talking about binding to a socket (as in the bind system
call). But yes, the source HI is associated (bound) to an interface.

> The issue we raised in San Diego was that *nothing* in the current
> sockets API ever binds to interfaces. Everything binds to IP addresses.
> Even INADDR_ANY just means "any IP address."

Agree, but we're extending the sockets API anyway by introducing a
new namespace and a new layer. Why not go a step even further?

> A HIP API would do well to follow this approach. The reason is that an
> outgoing interface is determined for each packet independently based on
> a routing lookup at transmission time. Which means that when the routing
> table changes, implementations don't have to go through all bindings to
> change their interfaces.

Could you elaborate the last sentence (with an example perhaps)?

> Additionally, as Joe pointed out, interfaces can have aliases, and
> furthermore, those aliases may move from one interface to another during
> the lifetime of a connection. Binding to IP addresses instead of
> interfaces avoids all this update mess.

I have to admit that I haven't thought about interface aliases. Still, if
the interface alias changes, it creates an event that can be detected in
the HIP module. The HIP module can sort out the "mess".

But is it really a mess? By changing the alias, you could signal that "I
want to take all of my HIP connections from wlan0 to eth0 to get faster
connectivity". Can you provide a counter example?

> > Another question to all: do you prefer "endpoint descriptors" instead
> > of HITs as the AID and why?
>
> Are there other kinds of endpoint descriptors than HITs? If yes, use the
> generic term. If no, just use "HITs" to be clear. (My two cents.)

Yes there is in native HIP API proposal. The endpoint descriptor is the
userspace AID and it acts like a "handle" or "reference" to the
corresponding HI. For the application, the descriptor seems like a random
number, but the HIP module knows the mapping from the descriptor value to
the HI.

One motivation for the endpoint descriptor is to separate application
layer identifiers from the transport layer identifiers. Seems like reusing
the same identifiers in each layer gets us into trouble always when the
networking requirements change; recall that HIP is trying to solve the
problem where the transport layer reuses the network layer identifiers
thus making mobility/multihoming difficult to achieve. Native HIP API
tries to avoid falling into the same pitfall.

See sections 4.1.1-4.1.4 from the API design chapter:

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

> >>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.
>
> I don't recall Andrew's exact question, and the above doesn't mean
> anything to me. Could you please elaborate?

Hmm... maybe Andrew misunderstood too the bind() vs. association. I was
not in the meeting, so I was guessing Andrew's thoughts... Andrew?

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

From: [email-masked] (Tim Shepard)
Date: Mon Aug 16 21:51:00 2004
Subject: [Hipsec-rg] hash functions
Message-ID: <[email-masked]>

Many important hash functions appear to be falling.
(e.g.  http://www.freedom-to-tinker.com/archives/000661.html )

When the dust settles, how many good hash functions will be left standing?

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Tim Shepard)
Date: Mon Aug 16 19:11:00 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: Your message of Mon, 16 Aug 2004 13:36:35 -0700. <[email-masked]>
Message-ID: <[email-masked]>

> >>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.
> > 
> > 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...
> 
>
> See Tim's email. I agree with him that finding a way to use HIP without 
> a deployed DNS would be very useful. How do you bootstrap communication 
> if someone hands you just a HIT?

You don't.   When I hear that question (and I've heard it many times)
it sounds to me like a question equivalent to:

   How do you bootstrap an ssh connection if someone hands you (only)
   the ssh host key of a machine?

Another equivalent question might be:

   How am I supposed to be able to begin a postal correspondence with
   Alyssa P. Hacker  when the only think you've told me is her name?

A referral requires a name *and* an address.  I don't see anyway
around that.  Directories can be useful, but no directory will ever
have everything or everyone in it.

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Lars Eggert)
Date: Mon Aug 16 15:35:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms010206080801030809060509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Miika,

Miika Komu wrote:
>>
>>Lars Eggert:  Why are you binding to a src interface rather than
>>address?
>>
>>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.
> 
> 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.
> 
> (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.)
> 
> Other opinions? Does anyone think that using interfaces instead of
> IP-addresses is a better approach? Or a no-go?

now I'm confused. The slides in San Diego showed a binding from HITs to 
interfaces. Yet this email talks about binding HITs to IP addresses. 
Which is it? Were the slides in San Diego wrong?

The issue we raised in San Diego was that *nothing* in the current 
sockets API ever binds to interfaces. Everything binds to IP addresses. 
Even INADDR_ANY just means "any IP address."

A HIP API would do well to follow this approach. The reason is that an 
outgoing interface is determined for each packet independently based on 
a routing lookup at transmission time. Which means that when the routing 
table changes, implementations don't have to go through all bindings to 
change their interfaces.

Additionally, as Joe pointed out, interfaces can have aliases, and 
furthermore, those aliases may move from one interface to another during 
the lifetime of a connection. Binding to IP addresses instead of 
interfaces avoids all this update mess.

> Another question to all: do you prefer "endpoint descriptors" instead
> of HITs as the AID and why?

Are there other kinds of endpoint descriptors than HITs? If yes, use the 
generic term. If no, just use "HITs" to be clear. (My two cents.)

>>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.

I don't recall Andrew's exact question, and the above doesn't mean 
anything to me. Could you please elaborate?

>>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.
> 
> 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...

See Tim's email. I agree with him that finding a way to use HIP without 
a deployed DNS would be very useful. How do you bootstrap communication 
if someone hands you just a HIT?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms010206080801030809060509
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

--------------ms010206080801030809060509--

From: [email-masked] (Tim Shepard)
Date: Mon Aug 16 09:28:01 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: Your message of Mon, 16 Aug 2004 15:48:20 +0300. <[email-masked]>
Message-ID: <[email-masked]>

> > 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.
> 
> 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...
> 

What I mean is that it should be possible to install and use HIP in a
meaningful way without requiring that you get your site administrator
to update the DNS servers.  (If additional records in the DNS enhance
the usefulness and/or security of HIP, that's OK.)

I don't think SSH would have ever seen much deployment if in order to
use it you would have had to get special SSH keys distributed by the
DNS servers.   That would have made it as difficult to install and use
as the kerberos-based encrypted rlogin (which I was using for many
years until ssh came along and made it so much easier).

The web would have never gotten very far if a new record type had to
be put in the DNS to support http.

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Miika Komu)
Date: Mon Aug 16 07:46:01 2004
Subject: [Hipsec-rg] Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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.

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.

(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.)

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.

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...

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

From: [email-masked] (Henderson, Thomas R)
Date: Thu Aug 12 20:40:00 2004
Subject: [Hipsec-rg] meeting minutes from HIP-RG meeting
Message-ID: <[email-masked]>

Please provide any revisions to the below minutes which
will be posted to the Proceedings before the deadline.
We'll also post copies of the slides.

Thanks to Andrew McGregor, Tim Shepard, and Julien
Laganier for note taking.

**************************************

Minutes of HIP-RG meeting, August 6, 2004. =20
(83 people signed pink sheets)

0.  Agenda bashing
- Move Jari Arkko to end of session

1.  HIP RG overview (Tom Henderson)

(see slides for presentation)

Tom:  any questions?... (none)

2.  HIP Native API (Julien Laganier)

Lars Eggert:  Why are you binding to a src interface rather than =
address?

Julien:  Ask Miika for motivation.

Kevin Fall:  Have you thought about running apps over a non-IP =
environment?  Will we have the transport to plug into this? =20

Julien:  Pseudoheaders in HIP use the HITs.

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.

Tim Shepard:  What if no DNS?  Nervous about building in dependencies on =
DNS.

Julien:  use /etc/hosts.  Can fall back to opportunistic mode too.

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.

Kevin:  Thought of a better way to ask my previous question.  Can HIP =
run on other networks?

Julien:  haven't thought about this.  (no discussion)

??:  Why are you using DNS to bootstrap this system?  How to find the =
DNS server?  I think that using DNS is a bad idea.

More questions?   See http://hipl.hiit.fi/hipl/

3.  HIP over NATs (Martin Stiemerling)

-- main changes since last time-- added section on HIP-unaware NATs

Tim Shepard:  Suggest that you look at RFC 3056/3068 approach for 6-to-4 =
NATting as an approach for HIP NATs.  Use IPv4 anycast to traverse.  =
This approach is not HIP-specific.  Would be happy to point author to =
the relevant RFCs.

Tom:  Does this provide mechanism to learn your public address?

Tim:  Inside hosts just do IPv6.  Embedded in the /48 prefix is the IPv4 =
address.

4.  HIP and Rendezvous Servers (Lars Eggert)

-- Most significant change is location privacy ideas due to Marco =
Liebsch.

Lars:  Should we keep this draft together or split apart (maybe split =
the privacy concepts out)?  Draft is getting kind of big.

Julien:  In favor of splitting documents.

Andrew:  Observation:  Location privacy is about the only sane reason =
for using a NAT. =20

5.  Delegation (Mike Walfish)

- this is a position paper being presented at ACM Sigcomm in a few =
weeks.

Joe Touch:  Names resolve to delegates?  Aren't they really talking to =
the host?  If names resolve to delegates, are the delegates not the =
endpoint? The=20
indirection here has no real meaning.

Mike:  need to have delegation in the architecture..

Lars:  In your picture of cascading NATs, what if NAT translates the =
identity?

Hannes Tschofenig:  Look at the literature on this topic.

Mike:  Do you mean the MIDCOM stuff?

Hannes:  Yes, and ...

Melinda Shore:  the main problem with NAT is that it doesn't translate =
an address.  NATs don't have presence on the Internet ...

Mike:  we are advocating that we explicitly put NAT in the resolution =
step

Melinda:  decoupling service identifier helps a lot (better than port =
numbers), so this would be a positive step.

Hannes:  Security problems of NAT firewall signaling.  Since there is a =
separate protocol for this, it might cause security problems.

Mike:  We have a tech report coming out in December that is explicitly =
concerned with security.

Julien:  Why not use application IDs instead of service level IDs?  Why =
do you have two?

Mike:  Might be misunderstanding? (Yes).  Proposing that same resolution =
system use to serve both name spaces.

Kevin Fall:  IP addresses and names went hierarchical in the 1980s.  Why =
flat now?  Is this overkill? =20

Mike:  So can have persistence irrespective of moves.

Kevin:  Hierarchical spaces easier to administer.

Mike:  Granted.  But I don't think that humans should administer this.
Kevin:  Indirection is presently useful.  Your indirection point is your =
mail server and the identifier is the address. The time needed for =
delivery is greater than for I3 (...)

6.  i3 project (Karthik Lakshminarayanan)

Jari Arkko:  What about security aspects of this?  Do you have =
assumption of security between a host and an I3 server

Karthik:  eavesdropping in i3 is easy.  For this an other reasons, we =
need to secure the infrastructure.  There are a number of crypto =
primitives in a project known as secure i3-- written up in a UCB =
Technical Report.  The ID's is derived from the key, so you can =
trivially establish SA (Id is a hash of the key).

6.  Hi3 architecture (HIP and secure-i3) (Jari Arkko)

Lars:  Hidden IP addresses don't only provide location privacy-- they =
protect attackers

Jari:  Yes, but do you care as much if you are able to deflect attacks?

Joe:  Previous speaker pointed out DataRouter project.  In that project, =
we provide a way to implement, via IP options, strings and string =
substitution rules.  Gives you an overlay with the performance of the =
network layer.  I'll send a pointer to the list.

(editor's note:  see http://www.isi.edu/touch/pubs/iwan2003/)

Karthik:  Why do you need middleboxes when you have i3?

Jari:  May be possible to combine the two.

Hannes:  I like this I-D because it reuses HIP and applies it to =
overlays
You can see from some papers that P2P folkd try to reuse HIP work so I =
think
you're on the right track.  Interesting thing: New Internet architecture =
looks a lot like MPLS-type things.=20

George Jones:  I'm putting my black hat on now.  Thinking of how to =
break this. i) if you are going through middleboxes, these are =
opportunities for attack
ii) you are offloading DoS protection onto the core of the network.  Are =
they going to want to pay for and maintain such infrastructure?  Some of =
these solutions just seem to be shifting the problem around.

Jari:  i) the middleboxes functions can be distributed to lower the =
impact of attack on a single one

Hannes:  (in support of Jari) this improves the situation without trying =
to solve all problems. The puzzle-cookie can provide some resilience, =
and I3 also by hiding IP addresses.

Martin:  ?  (something about NAT)

Tom (chair):  We've had three presentations now on richer architecture =
concepts that make more use of overlays, indirection, privacy.  Is the =
RG interested in prioritizing this work?  Or should other issues (like =
APIs and NATs) take priority.  (Some show of hands in support of =
focusing on these architectural issues now).

7. Open mike

Aaron Falk:  Speaking of applications, it may be useful to talk to the =
SIP people, who are using IP addresses to identify infrastructure, and =
see if HIP might be of use to them.

Tom:  Yes, have had some discussions this week-- would be interesting to =
see what aspects of HIP functionality that SIP has already implemented, =
and what of HIP that SIP would use if HIP service were available.

Tom (chair):  Any interest in participating in a HIP research workshop =
prior to next IETF meeting (on Saturday)?  (about 20-30 hands).  =
Interest in presenting? (maybe 5-8 hands)

Joe:  Tacking onto IETF is generally bad because the week is very long =
already.

Tim, Andrew, others?:  Yes, but many of us have travel budgets and time =
constraints that make it convenient.

Avri Doria:  We are also talking about such things in our RG and might =
want to consider coordinating these type of things.

From: [email-masked] (Henderson, Thomas R)
Date: Mon Aug  9 19:44:14 2004
Subject: [Hipsec-rg] FW: [e2e] IP puzzle paper
Message-ID: <[email-masked]>

FYI, for those of you interested in the HIP puzzle.

-----Original Message-----
From: Wu-chang Feng [mailto:[email-masked]]=20
Sent: Friday, August 06, 2004 3:00 PM
To: [email-masked]
Subject: [e2e] IP puzzle paper

To follow up on a thread from late last year, the following techreport=20
describes a constant-state, high-speed implementation of network layer=20
puzzles.

Wu-chang Feng, Ed Kaiser, Wu-chi Feng, Antoine Luu
"The Design and Implementation of Network Layer Puzzles"
OGI CSE Technical Report 04-003, August 2004.
http://www.cse.ogi.edu/sysl/projects/puzzles/04-003.pdf

Source code release forthcoming....

Wu

From: [email-masked] (Pekka Nikander)
Date: Wed Aug  4 22:55:01 2004
Subject: [Hipsec-rg] HIP test server online
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> We have made available a HIP test server online.  It is at
> http://hipserver.mct.phantomworks.org.  It runs the base
> exchange and IPsec as defined by the current base spec.

This is great news!  Thanks, Tom, for the hard work!!

We are planning to get a new release of our FreeBSD code out.
That should happen in a couple of weeks, probably once we've
made sure that it works on FreeBSD 5.3 (beta or final).

--Pekka Nikander

From: [email-masked] (Henderson, Thomas R)
Date: Wed Aug  4 16:26:00 2004
Subject: [Hipsec-rg] HIP test server online
Message-ID: <[email-masked]>

We have made available a HIP test server online.  It is at
http://hipserver.mct.phantomworks.org.  It runs the base
exchange and IPsec as defined by the current base spec.

At the meeting this week, we have successfully interoperated
with both Ericsson (IPv4 and IPv6) and HIPL (IPv6) implementations,
according to the new base spec. =20

We will plan on keeping the hipserver online semi-permanently
now, for use as a testing target by others wishing to test
their implementations.

Tom

From: [email-masked] (Henderson, Thomas R)
Date: Wed Aug  4 01:33:00 2004
Subject: [Hipsec-rg] Friday's updated hiprg agenda
Message-ID: <[email-masked]>

The below times are recommended but not firm requirements-- we
should have plenty of time.

We will need scribes, as usual.

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]>
         =20
Session chairs:  Tom Henderson, Andrei Gurtov=20

AGENDA:

  o Administrivia/Agenda                     Tom Henderson   (5 minutes)

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

  o HIP rendezvous concepts                  L. Eggert       (15 =
minutes)
    - draft-eggert-hip-rendezvous-01

  o Host Identity Indirection Infrastructure (Hi3) J. Arkko  (20 =
minutes)
    - draft-nikander-hiprg-hi3-00.txt
   =20
  o A Layered Naming Architecture for the Internet
    - =
http://www.acm.org/sigs/sigcomm/sigcomm2004/papers.html#A_Layered_Naming
    - Combining HIP and i3                  K. Lakshminarayanan    (10 =
min)
    - Flat Names in a Delegation-Oriented Architecture  M. Walfish (10 =
min)
   =20
  o Open mike