From: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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: pekka.nikander@nomadiclab.com (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: <41218639.8060303@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41218639.8060303@isi.edu> Message-ID: >> 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: mkomu@niksula.hut.fi (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: <41260CBB.90200@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> <41260CBB.90200@isi.edu> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: touch@ISI.EDU (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> Message-ID: <41260CBB.90200@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBJgzAE5f5cImnZrsRAjN7AJ436O25zkgbXXH9+TW7oKiZMIWrhgCdHg+q 42/2WDjgUFkJPBYCcaEsfJ8= =ahrg -----END PGP SIGNATURE----- --------------enig59215F12241C9731B7D6547C-- From: touch@ISI.EDU (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: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> Message-ID: <41252460.5040509@isi.edu> 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:touch@ISI.EDU] >>Sent: Monday, August 16, 2004 9:20 PM >>To: Tim Shepard >>Cc: Lars Eggert; Miika Komu; hipsec-rg@honor.trusecure.com; 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBJSRgE5f5cImnZrsRAml0AJ40pHXcIQhqfS0fEyRxBz2qqia9gQCfVftU A874VDG60CGoYr5nyGIpN0U= =BjZD -----END PGP SIGNATURE----- --------------enigE73D5E40BB122B37FD1BE3D1-- From: thomas.r.henderson@boeing.com (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: <6938661A6EDA8A4EA8D1419BCE46F24C0406080C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, August 20, 2004 7:38 AM > To: Miika Komu > Cc: Henderson, Thomas R; Tim Shepard; Lars Eggert; > hipsec-rg@honor.trusecure.com; 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: mkomu@niksula.hut.fi (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: <41252460.5040509@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (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: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Monday, August 16, 2004 9:20 PM > To: Tim Shepard > Cc: Lars Eggert; Miika Komu; hipsec-rg@honor.trusecure.com; 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: touch@ISI.EDU (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: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing .com> <41211AD3.6080306@netlab.nec.de> <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]> Message-ID: <41237FB6.6080403@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBI3+7E5f5cImnZrsRApCZAKDQJIET3dGjaUTsKNK/rK3EHfj+2gCfRygm Fd28vxjPvLNNzrXB/suMYZU= =hFXH -----END PGP SIGNATURE----- --------------enigABAEEE7E50074E68B99A6CC5-- From: andrew@indranet.co.nz (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing .com> <41211AD3.6080306@netlab.nec.de> Message-ID: <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]> --On Wednesday, 18 August 2004 12:25 a.m. +0300 Miika Komu 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. > >> >> 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: touch@ISI.EDU (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: References: Message-ID: <41218763.60307@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYdjE5f5cImnZrsRAso/AJwJY112ckbwNcAu1KKJhC2N4SyYkwCgkuU1 A6tRJI9tCs2NedkQ87bY3Hk= =FOhd -----END PGP SIGNATURE----- --------------enigE99FF82FB3DBB9D4529409AE-- From: touch@ISI.EDU (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: <41211AD3.6080306@netlab.nec.de> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41211AD3.6080306@netlab.nec.de> Message-ID: <4121869B.10806@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYacE5f5cImnZrsRAgSdAKCdQxsFQcCWPAEnDdg+7mlpYboezwCglFPF Kn7yLI4DEOZCVcBTUO637gg= =Gkr8 -----END PGP SIGNATURE----- --------------enig9EBDEB70A4F1BDEC99148D14-- From: touch@ISI.EDU (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: <41218639.8060303@isi.edu> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00A31756B6731166C9A76BBC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Miika Komu wrote: > Some question were raised in the hipsec-rg meeting in San Diego and I'd > like comment them briefly: > > >>2. HIP Native API (Julien Laganier) >> >>Lars Eggert: Why are you binding to a src interface rather than >>address? >> >>Julien: Ask Miika for motivation. >> >>Joe Touch: Binding to interfaces doesn't make sense. Interfaces have >>multiple IP addresses. A single host identity must be able to bind to a >>particular IP address, for policy reasons. > > Actually, the binding is done on the source endpoint descriptor. The > resolver communicates the descriptor to the HIP module and associates it > with a (given) interface. You can bind to the endpoint descriptor, but the association must be with an interface/address pair. Otherwise, there's no way to control: 1- when you have one interface with multiple addresses: which address to use (under app, transport, or net control) 2- when you have one address on multiple interfaces: which interface to use (again under app, transport, or net control (1) is aliasing, and (2) s more common with multicast addresses, but can also occur with unicast. > The main motivation for preferring IP addresses instead of interfaces is > related to the probable life time of the identifiers. IP addresses are > more unstable than interfaces, so interfaces were preferred. It is still > possible to use a specific IP address by specifying the protocol family > (and prefix) of the IP address to the resolver. Neither interfaces nor addresses have a lifetime of meaning with respect ot endpoint IDs. Both can change - e.g., inserting PCMCIA cards, USB interfaces, etc. > (Btw, usually client apps do not bind explicitly and server applications > bind to INADDR_ANY or IN6ADDR_ANY, so this question may not be so > important.) In conventional multihomed situations, apps can want control over which IP address is used as the source. The corrollary in this case is control over which interface/IP address pair is used. I.e., _both_ are required. > Other opinions? Does anyone think that using interfaces instead of > IP-addresses is a better approach? Or a no-go? > > Another question to all: do you prefer "endpoint descriptors" instead > of HITs as the AID and why? > > >>Andrew McGregor: Agree about not binding to an interface. You may want >>to bind to a HIT and use a setsockopt() to associate a locator with it. > > > Resolver does the setsockopt() on the behalf of the user. The difference > is that the HI-to-IP mapping is "global" instead of socket specific. The > security issues are dealt by tagging the mapping with the UID and GID. > > >>Tim Shepard: What if no DNS? Nervous about building in dependencies on >>DNS. >> >>Julien: use /etc/hosts. Can fall back to opportunistic mode too. > > > The other alternative for DNS is the DHT, but it remains to be seen if we > ever get there. In the mean time, we should rely on DNS, as there are no > real alternatives currently available. As far as lookups go, DNS==DHT. Different routing, but still requires some sort of global infrastructure to bootstrap. > Maybe the resolver should should support DHT queries too. With a new > resolver, this should not be a problem. I'll have to look at this topic > when I get my hands on a DHT DNS replacement implementation... > --------------enig00A31756B6731166C9A76BBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYY5E5f5cImnZrsRAgAXAJ0XZ/TXkitPEbpg0r7ZlgLvbNA9IQCfYOBz Id8oP4KA5OE6qs07y5iMK5c= =wRXC -----END PGP SIGNATURE----- --------------enig00A31756B6731166C9A76BBC-- From: mkomu@niksula.hut.fi (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: <41211AD3.6080306@netlab.nec.de> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41211AD3.6080306@netlab.nec.de> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: shep@alum.mit.edu (Tim Shepard) Date: Mon Aug 16 21:51:00 2004 Subject: [Hipsec-rg] hash functions Message-ID: 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 shep@alum.mit.edu From: shep@alum.mit.edu (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. <41211AD3.6080306@netlab.nec.de> Message-ID: > >>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 shep@alum.mit.edu From: lars.eggert@netlab.nec.de (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: <41211AD3.6080306@netlab.nec.de> 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA4MTYyMDM2MzVaMCMGCSqGSIb3DQEJBDEWBBQFAPwYB7HkHLV7UJwYk4LYU5O9azBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQAV2sc2vjfDiI38wXebRpt/hjh4YgCXGDD19YZViFAVZijM +1Z0468Y06ugQmcAhpm7bbQIcyLWJV51sywUAY19s7c3Li5VrS2P059yzUEyaypAy+Fbsdt3 WGvTFiPpXQYpdVWkmyIG02wWdrFc1/gzFvJYHvFAA43QkP5WY8KL2Ep/ak6S2c1uIfdjgEyw UxBSuRHbnZlYSy8PiTAjIWnfz7ut9z8rsB9qhGhGUwV6IyHd2HW6jKuNLBobY9u2UqDNEd7f JoVhhiwgctmnr6B2ra3z/CPLWk+ocLIojyQByzMjn5wl7KWlo2IoAs8f2Eh+HLRwJOfeCMPC +YOQ/DmsAAAAAAAA --------------ms010206080801030809060509-- From: shep@alum.mit.edu (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. Message-ID: > > 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 shep@alum.mit.edu From: mkomu@niksula.hut.fi (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: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Aug 12 20:40:00 2004 Subject: [Hipsec-rg] meeting minutes from HIP-RG meeting Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Aug 9 19:44:14 2004 Subject: [Hipsec-rg] FW: [e2e] IP puzzle paper Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452238A@xch-nw-27.nw.nos.boeing.com> FYI, for those of you interested in the HIP puzzle. -----Original Message----- From: Wu-chang Feng [mailto:wuchang@cse.ogi.edu]=20 Sent: Friday, August 06, 2004 3:00 PM To: end2end-interest@postel.org 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: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Aug 4 22:55:01 2004 Subject: [Hipsec-rg] HIP test server online In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> Message-ID: <5A2476DE-E693-11D8-8C46-000393CE1E8C@nomadiclab.com> > 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Aug 4 16:26:00 2004 Subject: [Hipsec-rg] HIP test server online Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Aug 4 01:33:00 2004 Subject: [Hipsec-rg] Friday's updated hiprg agenda Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607CB@xch-nw-27.nw.nos.boeing.com> 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 Pekka Nikander =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 From: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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: pekka.nikander@nomadiclab.com (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: <41218639.8060303@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41218639.8060303@isi.edu> Message-ID: >> 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: mkomu@niksula.hut.fi (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: <41260CBB.90200@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> <41260CBB.90200@isi.edu> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: touch@ISI.EDU (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> Message-ID: <41260CBB.90200@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBJgzAE5f5cImnZrsRAjN7AJ436O25zkgbXXH9+TW7oKiZMIWrhgCdHg+q 42/2WDjgUFkJPBYCcaEsfJ8= =ahrg -----END PGP SIGNATURE----- --------------enig59215F12241C9731B7D6547C-- From: touch@ISI.EDU (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: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> Message-ID: <41252460.5040509@isi.edu> 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:touch@ISI.EDU] >>Sent: Monday, August 16, 2004 9:20 PM >>To: Tim Shepard >>Cc: Lars Eggert; Miika Komu; hipsec-rg@honor.trusecure.com; 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBJSRgE5f5cImnZrsRAml0AJ40pHXcIQhqfS0fEyRxBz2qqia9gQCfVftU A874VDG60CGoYr5nyGIpN0U= =BjZD -----END PGP SIGNATURE----- --------------enigE73D5E40BB122B37FD1BE3D1-- From: thomas.r.henderson@boeing.com (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: <6938661A6EDA8A4EA8D1419BCE46F24C0406080C@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Friday, August 20, 2004 7:38 AM > To: Miika Komu > Cc: Henderson, Thomas R; Tim Shepard; Lars Eggert; > hipsec-rg@honor.trusecure.com; 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: mkomu@niksula.hut.fi (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: <41252460.5040509@isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> <41252460.5040509@isi.edu> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (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: <6938661A6EDA8A4EA8D1419BCE46F24C04060809@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Monday, August 16, 2004 9:20 PM > To: Tim Shepard > Cc: Lars Eggert; Miika Komu; hipsec-rg@honor.trusecure.com; 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: touch@ISI.EDU (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: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing .com> <41211AD3.6080306@netlab.nec.de> <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]> Message-ID: <41237FB6.6080403@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBI3+7E5f5cImnZrsRApCZAKDQJIET3dGjaUTsKNK/rK3EHfj+2gCfRygm Fd28vxjPvLNNzrXB/suMYZU= =hFXH -----END PGP SIGNATURE----- --------------enigABAEEE7E50074E68B99A6CC5-- From: andrew@indranet.co.nz (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing .com> <41211AD3.6080306@netlab.nec.de> Message-ID: <469BC1CB99DA5BE2AC85D5FB@[192.168.1.248]> --On Wednesday, 18 August 2004 12:25 a.m. +0300 Miika Komu 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. > >> >> 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: touch@ISI.EDU (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: References: Message-ID: <41218763.60307@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYdjE5f5cImnZrsRAso/AJwJY112ckbwNcAu1KKJhC2N4SyYkwCgkuU1 A6tRJI9tCs2NedkQ87bY3Hk= =FOhd -----END PGP SIGNATURE----- --------------enigE99FF82FB3DBB9D4529409AE-- From: touch@ISI.EDU (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: <41211AD3.6080306@netlab.nec.de> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41211AD3.6080306@netlab.nec.de> Message-ID: <4121869B.10806@isi.edu> 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYacE5f5cImnZrsRAgSdAKCdQxsFQcCWPAEnDdg+7mlpYboezwCglFPF Kn7yLI4DEOZCVcBTUO637gg= =Gkr8 -----END PGP SIGNATURE----- --------------enig9EBDEB70A4F1BDEC99148D14-- From: touch@ISI.EDU (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: <41218639.8060303@isi.edu> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00A31756B6731166C9A76BBC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Miika Komu wrote: > Some question were raised in the hipsec-rg meeting in San Diego and I'd > like comment them briefly: > > >>2. HIP Native API (Julien Laganier) >> >>Lars Eggert: Why are you binding to a src interface rather than >>address? >> >>Julien: Ask Miika for motivation. >> >>Joe Touch: Binding to interfaces doesn't make sense. Interfaces have >>multiple IP addresses. A single host identity must be able to bind to a >>particular IP address, for policy reasons. > > Actually, the binding is done on the source endpoint descriptor. The > resolver communicates the descriptor to the HIP module and associates it > with a (given) interface. You can bind to the endpoint descriptor, but the association must be with an interface/address pair. Otherwise, there's no way to control: 1- when you have one interface with multiple addresses: which address to use (under app, transport, or net control) 2- when you have one address on multiple interfaces: which interface to use (again under app, transport, or net control (1) is aliasing, and (2) s more common with multicast addresses, but can also occur with unicast. > The main motivation for preferring IP addresses instead of interfaces is > related to the probable life time of the identifiers. IP addresses are > more unstable than interfaces, so interfaces were preferred. It is still > possible to use a specific IP address by specifying the protocol family > (and prefix) of the IP address to the resolver. Neither interfaces nor addresses have a lifetime of meaning with respect ot endpoint IDs. Both can change - e.g., inserting PCMCIA cards, USB interfaces, etc. > (Btw, usually client apps do not bind explicitly and server applications > bind to INADDR_ANY or IN6ADDR_ANY, so this question may not be so > important.) In conventional multihomed situations, apps can want control over which IP address is used as the source. The corrollary in this case is control over which interface/IP address pair is used. I.e., _both_ are required. > Other opinions? Does anyone think that using interfaces instead of > IP-addresses is a better approach? Or a no-go? > > Another question to all: do you prefer "endpoint descriptors" instead > of HITs as the AID and why? > > >>Andrew McGregor: Agree about not binding to an interface. You may want >>to bind to a HIT and use a setsockopt() to associate a locator with it. > > > Resolver does the setsockopt() on the behalf of the user. The difference > is that the HI-to-IP mapping is "global" instead of socket specific. The > security issues are dealt by tagging the mapping with the UID and GID. > > >>Tim Shepard: What if no DNS? Nervous about building in dependencies on >>DNS. >> >>Julien: use /etc/hosts. Can fall back to opportunistic mode too. > > > The other alternative for DNS is the DHT, but it remains to be seen if we > ever get there. In the mean time, we should rely on DNS, as there are no > real alternatives currently available. As far as lookups go, DNS==DHT. Different routing, but still requires some sort of global infrastructure to bootstrap. > Maybe the resolver should should support DHT queries too. With a new > resolver, this should not be a problem. I'll have to look at this topic > when I get my hands on a DHT DNS replacement implementation... > --------------enig00A31756B6731166C9A76BBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIYY5E5f5cImnZrsRAgAXAJ0XZ/TXkitPEbpg0r7ZlgLvbNA9IQCfYOBz Id8oP4KA5OE6qs07y5iMK5c= =wRXC -----END PGP SIGNATURE----- --------------enig00A31756B6731166C9A76BBC-- From: mkomu@niksula.hut.fi (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: <41211AD3.6080306@netlab.nec.de> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <41211AD3.6080306@netlab.nec.de> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: shep@alum.mit.edu (Tim Shepard) Date: Mon Aug 16 21:51:00 2004 Subject: [Hipsec-rg] hash functions Message-ID: 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 shep@alum.mit.edu From: shep@alum.mit.edu (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. <41211AD3.6080306@netlab.nec.de> Message-ID: > >>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 shep@alum.mit.edu From: lars.eggert@netlab.nec.de (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: References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: <41211AD3.6080306@netlab.nec.de> 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA4MTYyMDM2MzVaMCMGCSqGSIb3DQEJBDEWBBQFAPwYB7HkHLV7UJwYk4LYU5O9azBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQAV2sc2vjfDiI38wXebRpt/hjh4YgCXGDD19YZViFAVZijM +1Z0468Y06ugQmcAhpm7bbQIcyLWJV51sywUAY19s7c3Li5VrS2P059yzUEyaypAy+Fbsdt3 WGvTFiPpXQYpdVWkmyIG02wWdrFc1/gzFvJYHvFAA43QkP5WY8KL2Ep/ak6S2c1uIfdjgEyw UxBSuRHbnZlYSy8PiTAjIWnfz7ut9z8rsB9qhGhGUwV6IyHd2HW6jKuNLBobY9u2UqDNEd7f JoVhhiwgctmnr6B2ra3z/CPLWk+ocLIojyQByzMjn5wl7KWlo2IoAs8f2Eh+HLRwJOfeCMPC +YOQ/DmsAAAAAAAA --------------ms010206080801030809060509-- From: shep@alum.mit.edu (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. Message-ID: > > 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 shep@alum.mit.edu From: mkomu@niksula.hut.fi (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: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> Message-ID: 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 miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Aug 12 20:40:00 2004 Subject: [Hipsec-rg] meeting minutes from HIP-RG meeting Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Aug 9 19:44:14 2004 Subject: [Hipsec-rg] FW: [e2e] IP puzzle paper Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452238A@xch-nw-27.nw.nos.boeing.com> FYI, for those of you interested in the HIP puzzle. -----Original Message----- From: Wu-chang Feng [mailto:wuchang@cse.ogi.edu]=20 Sent: Friday, August 06, 2004 3:00 PM To: end2end-interest@postel.org 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: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Aug 4 22:55:01 2004 Subject: [Hipsec-rg] HIP test server online In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> Message-ID: <5A2476DE-E693-11D8-8C46-000393CE1E8C@nomadiclab.com> > 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Aug 4 16:26:00 2004 Subject: [Hipsec-rg] HIP test server online Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> 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: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Aug 4 01:33:00 2004 Subject: [Hipsec-rg] Friday's updated hiprg agenda Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607CB@xch-nw-27.nw.nos.boeing.com> 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 Pekka Nikander =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 From: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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: joseph-so@gmx.net (Joseph So) Date: Wed Aug 25 22:40:01 2004 Subject: [HIPSec-rg] About IP and HIP relationship and SIP Message-ID: <5114.1093491767@www11.gmx.net> 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