From: miika@iki.fi (Miika Komu) Date: Thu Jul 29 09:37:01 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607AB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607AB@xch-nw-27.nw.nos.boeing.com> Message-ID: On Wed, 28 Jul 2004, Henderson, Thomas R wrote: > We should probably be more precise on terminology here. Rather than > "things", aren't we talking about names? I tried to emphasize with "thing" that the application does not really care what the endpoint looks like. > Applications need a name to bind a descriptor, and then they need the > bound descriptor to perform I/O. The name that is often used presently > to bind the descriptor is the sockaddr_in (address + port), and it has > semantics such that the address is routable. In the future, it could be > something like (host_identifier + port). > I think we are debating what the possible semantics are of the > host_identifier. It seems that you are suggesting applications not be > burdened with dealing explicitly with the endpoint identifiers > themselves, or avoid them for forward compatibility reasons. Maybe a > less confusing term is a "local identity alias"? "Local" can be be confusing too (consider local vs. remote identities), but maybe application layer identity alias is better. Or application layer { reference | handle | descriptor }. > Also, I don't know what you mean by a "protocol specific endpoint > identifier"-- aren't endpoint identifiers independent of protocol > in general? Or do you mean protocol family as in HIP vs HIPv2 vs > AF_INET (etc.)? I meant HIP vs. HIPv2 identifier. Sorry for the choice of words... > If we are talking about RFC1958-compliant applications, referrals > should be based on names and not addresses. In the future, IMO, > HIP potentially provides the flexibility to do referrals based > on HITs or HIs in addition to (instead of) FQDNs, so I don't > know whether it is safe to assume that these are only corner cases. > For example, humans might casually use FQDNs to refer other > people to web sites (since passing HIs or HITs will be cumbersome), > but machine-to-machine applications or secure (e.g., bank transaction) > applications may indeed want to skip the reliance on FQDN and use > the HIT or HI specifically in a referral, where the HI is obtained > over a secure channel or is backed up by certificate chains. Right. > p.s. applications have to move eventually to IPv6. Does your > framework translate also to IPv6-- i.e., systems could provide > IPv4-sized "LSI"s and hide the IPv6 addresses from applications? The framework provides handles for the applications. An application can query the HIT (or LSI) corresponding to the handle via a separate function call. > Why or why not is this a good/bad analogy? ? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Jul 29 08:43:00 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607A7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607A7@xch-nw-27.nw.nos.boeing.com> Message-ID: <41A08031-E165-11D8-9324-000393CE1E8C@nomadiclab.com> > I don't see how HIT-128 vs HIT-256 is much different from applications > being able to handle either IPv4 or IPv6 addresses. The getaddrinfo > (struct addrinfo) seems to be flexible/extensible enough to > accommodate. I agree that this is a minor point, but changing the HIT side may require recompilation, depending on how the app has been written. I agree that well written apps would be ok. >> Secondly, passing handles between processes requires a new >> system call while a mere HIT can be passed around as a binary >> value. As we can envision a handle to be bound to an active >> HIP association and not just to a HIT, the added security can >> be beneficial. > > I am not following this point-- could you elaborate? What added > security do I get by passing the handle rather than the HIT > (considering that we are just passing this around locally on > the machine)? Are everybody forgetting about multi-user machines these days? :-) Sarcasm aside, I was thinking along the lines Mach 3 implements ports and allows ports to be transferred between tasks. They are like capabilities. In a similar way, one could imagine that HIP handles would act, in a limited sense, as capabilities. There could even be several HIP associations between two hosts, each associated with a different set of rights. Or maybe just one HIP association, but several SAs. Or something like that. Making the handle separate from HIT allows you to represent these more easily and more transparently. --Pekka From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Jul 29 08:39:01 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607AB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607AB@xch-nw-27.nw.nos.boeing.com> Message-ID: >> The handle would make it possible to implement HI mobility > > I guess this is why I said that I don't see the motivation. HI > mobility > seems to be the antithesis of HIP concept (where HIP is designed to > provide strong authentication that who you are talking to is who you > think it is, and that you continue to talk to the same endpoint > across multihoming or mobility events). But consider the case where you use, at the same time, - delegation, and - HI "mobility" In that way you could allow transport connections to survive context transfer from one physical device to another, without needing to pass the private key between the devices.... BTW, see our Cambridge 2002 paper, Pekka Nikander and Jari Arkko, "Delegation of Signalling Rights," in Security Protocols, 10th International Workshop, Cambridge, UK, April 16-19, 2002, LCNS 2845, pp. 203-212, Springer, 2003. That covers the general idea and some simple examples, though I don't know whether the process migration idea is covered there or not. --Pekka From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 28 17:54:01 2004 Subject: [Hipsec-rg] native HIP API Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607AB@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Wednesday, July 28, 2004 2:43 PM > To: Henderson, Thomas R > Cc: Pekka Nikander; hipsec-rg@honor.trusecure.com > Subject: RE: [Hipsec-rg] native HIP API >=20 >=20 > On Wed, 28 Jul 2004, Henderson, Thomas R wrote: >=20 > > It seems to me that there are two possible options for handling > > endpoint identifiers in the HIP-aware applications-- handles, > > and explicitly via extensible structures. Miika's API seems > > to allow an application to deal with either, so it is flexible > > in that regard. Since explicit handling is needed at least > > to support referral-type apps, I am still wondering about the > > need for handles also. >=20 > Let me further illustrate the point on the handles. >=20 > Native HIP API assumes that most applications generally need=20 > a "thing" to > reference the endpoint. The applications don't care what the=20 > thing looks > like. The handle is a kind of a minimal representation of an endpoint > reference thing. For the application, the handle is just a=20 > magic number > that the stack can associate to the protocol specific=20 > endpoint identifier. > The handle has also the nice property that it is a=20 > collision-free AID for > the applications. >=20 We should probably be more precise on terminology here. Rather than "things", aren't we talking about names? Applications need a name to bind a descriptor, and then they need the bound descriptor to=20 perform I/O. The name that is often used presently to bind the=20 descriptor is the sockaddr_in (address + port), and it has semantics=20 such that the address is routable. In the future, it could be=20 something like (host_identifier + port). I think we are debating=20 what the possible semantics are of the host_identifier. It seems=20 that you are suggesting applications not be burdened with dealing=20 explicitly with the endpoint identifiers themselves, or avoid them for forward compatibility reasons. Maybe a less confusing term=20 is a "local identity alias"?=20 Also, I don't know what you mean by a "protocol specific endpoint=20 identifier"-- aren't endpoint identifiers independent of protocol=20 in general? Or do you mean protocol family as in HIP vs HIPv2 vs=20 AF_INET (etc.)? > The native API assumes that "advanced" network applications, such as > applications using referrals, will be modified to accomodate=20 > the new API. > In the case of referrals, the application should be modified to make a > separate function call to find the current IP address=20 > corresponding to the > handle (note that it is the same case with HIT as the AID). >=20 > (Btw, it would be nice to have a survey on the number and utilization > level of publicly available referral applications to understand the > real importance of the referrals.) If we are talking about RFC1958-compliant applications, referrals should be based on names and not addresses. In the future, IMO, HIP potentially provides the flexibility to do referrals based on HITs or HIs in addition to (instead of) FQDNs, so I don't know whether it is safe to assume that these are only corner cases. For example, humans might casually use FQDNs to refer other people to web sites (since passing HIs or HITs will be cumbersome), but machine-to-machine applications or secure (e.g., bank transaction) applications may indeed want to skip the reliance on FQDN and use the HIT or HI specifically in a referral, where the HI is obtained over a secure channel or is backed up by certificate chains. >=20 > The handle would make it possible to implement HI mobility=20 > (i.e. changing > HI for a transport layer connection on the fly without breaking it) in > future because the handle isolates the application layer from=20 > the details > of HIs. I don't directly see a direct need for HI mobility, but maybe > somebody can think up a nice use case. In any case, the=20 > handle approach is > more modular than the HIT approach. >=20 I guess this is why I said that I don't see the motivation. HI mobility seems to be the antithesis of HIP concept (where HIP is designed to=20 provide strong authentication that who you are talking to is who you think it is, and that you continue to talk to the same endpoint across multihoming or mobility events).=20 This discussion suggests to me that it might be useful to write up some use cases of a HIP-enhanced architecture that describes what happens at each step (e.g., anonymous web browsing, secure web browsing to your bank, middleware machine-to-machine applications,=20 peer-to-peer applications, etc.) and what implications that has on=20 the API, exchanging and disseminating host identities, and how HIP=20 should operate. Tom=20 p.s. applications have to move eventually to IPv6. Does your framework translate also to IPv6-- i.e., systems could provide IPv4-sized "LSI"s and hide the IPv6 addresses from applications? =20 Why or why not is this a good/bad analogy? From: miika@iki.fi (Miika Komu) Date: Wed Jul 28 16:43:00 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607A7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607A7@xch-nw-27.nw.nos.boeing.com> Message-ID: On Wed, 28 Jul 2004, Henderson, Thomas R wrote: > It seems to me that there are two possible options for handling > endpoint identifiers in the HIP-aware applications-- handles, > and explicitly via extensible structures. Miika's API seems > to allow an application to deal with either, so it is flexible > in that regard. Since explicit handling is needed at least > to support referral-type apps, I am still wondering about the > need for handles also. Let me further illustrate the point on the handles. Native HIP API assumes that most applications generally need a "thing" to reference the endpoint. The applications don't care what the thing looks like. The handle is a kind of a minimal representation of an endpoint reference thing. For the application, the handle is just a magic number that the stack can associate to the protocol specific endpoint identifier. The handle has also the nice property that it is a collision-free AID for the applications. The native API assumes that "advanced" network applications, such as applications using referrals, will be modified to accomodate the new API. In the case of referrals, the application should be modified to make a separate function call to find the current IP address corresponding to the handle (note that it is the same case with HIT as the AID). (Btw, it would be nice to have a survey on the number and utilization level of publicly available referral applications to understand the real importance of the referrals.) The handle would make it possible to implement HI mobility (i.e. changing HI for a transport layer connection on the fly without breaking it) in future because the handle isolates the application layer from the details of HIs. I don't directly see a direct need for HI mobility, but maybe somebody can think up a nice use case. In any case, the handle approach is more modular than the HIT approach. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 28 13:37:02 2004 Subject: [Hipsec-rg] native HIP API Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607A7@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, July 27, 2004 3:55 AM > To: Henderson, Thomas R > Cc: Miika Komu; hipsec-rg@honor.trusecure.com > Subject: Re: [Hipsec-rg] native HIP API >=20 >=20 > [Getting back to old e-mail] >=20 > Tom, >=20 > >> * Is the EID approach an overkill? It is quite easy to > >> replace the EID with a HIT in the API, if some people > >> prefer HITs as the AID. > > > > I don't think the EID approach is well motivated. At least I > > don't see the benefit of adding another layer of indirection to > > the architecture. If I remove EID concept from your API and just > > deal only with HITs, HIs, and IP addresses, what is lost? >=20 > Let me disagree with all respect. Firstly, a few IETF meetings > ago we (I don't remember who, maybe you were there, maybe not) > had a discussion of what to do if the 120+ bits currently used > in HITs becomes too short. We quickly noticed that it would be > fairly easy to change the HITs in the protocol to larger ones, > e.g., 256 bits long. However, implementing the corresponding > change at the API level is much harder. Hence, this is one of > the reasons why I asked Miika to use separate handles. I don't see how HIT-128 vs HIT-256 is much different from applications being able to handle either IPv4 or IPv6 addresses. The getaddrinfo (struct addrinfo) seems to be flexible/extensible enough to accommodate. >=20 > Secondly, passing handles between processes requires a new > system call while a mere HIT can be passed around as a binary > value. As we can envision a handle to be bound to an active > HIP association and not just to a HIT, the added security can > be beneficial. I am not following this point-- could you elaborate? What added security do I get by passing the handle rather than the HIT=20 (considering that we are just passing this around locally on the machine)? >=20 > But I agree with you that the terminology may not be the best > one. >=20 It seems to me that there are two possible options for handling endpoint identifiers in the HIP-aware applications-- handles,=20 and explicitly via extensible structures. Miika's API seems to allow an application to deal with either, so it is flexible in that regard. Since explicit handling is needed at least=20 to support referral-type apps, I am still wondering about the need for handles also. Tom =20 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Jul 28 11:52:01 2004 Subject: [Hipsec-rg] revised hiprg agenda Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040607A5@xch-nw-27.nw.nos.boeing.com> See below, room assignment, and an additional draft by=20 Martin Stiemerling. There may be a few more additions-- I will send out a revised agenda next week. Tom Host Identity Protocol Research Group (hiprg) Friday, August 6 at 0900-1130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Harbor I IRTF hiprg Host Identity Protocol Research Group CHAIR(s): Tom Henderson Pekka Nikander AGENDA: o Administrivia/Agenda Tom Henderson o Review of HIPRG charter and work plan Tom Henderson =20 o HIP native API Julien = Laganier/Miika Komu - http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf =20 o HIP over Network Address Translators Martin = Stiemerling - draft-stiemerling-hip-nat-01 o HIP rendezvous concepts Lars Eggert - draft-eggert-hip-rendezvous-01 o Host Identity Indirection Infrastructure (Hi3) Jari Arkko - draft-nikander-hiprg-hi3-00.txt From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Jul 27 10:43:01 2004 Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt] In-Reply-To: <983B8B50-DFB9-11D8-9324-000393CE1E8C@nomadiclab.com> References: <4100B573.8020009@netlab.nec.de> <983B8B50-DFB9-11D8-9324-000393CE1E8C@nomadiclab.com> Message-ID: <410677E8.2080501@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms070605010006080603080307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, thanks for the feedback! Comments below. Pekka Nikander wrote: > >> Transparent communication between HIP and non-HIP nodes places >> additional restrictions on the lookup mechanisms. For example, >> non-HIP nodes expect DNS lookups to return IP addresses, requiring >> the HI->IP mapping (or a representation thereof) to remain in the >> DNS. Section 4 discusses communication between HIP and non-HIP nodes >> and describes different alternatives that support it. > > I think that you want to say that backward compatibility requires > the FQDN->IP mapping to (or a representation of it) to remain in > the DNS, not HI->IP mapping. Correct, my original paragraph is poorly worded. Legacy hosts need the FQDN->IP information in the DNS. However, the paragraph before the one you quoted explains that although the FQDN->HI map must remain in the DNS for HIP-HIP communication, the HI->IP lookup in this case could occur in a second step. For communication with legacy hosts, removing the IP addresses from the DNS in not an option, and this means that the HIs will have to stay there as well. (Unless you replicate this information inside the DNS and the other lookup mechanism, which is something we have not described yet.) >> HIP decouples domain names from IP addresses. Because transport >> protocols bind to host identities, they remain unaware if the set of >> IP addresses associated with a host identity changes. This change >> can have various reasons, including, but not limited to, mobility and >> multi-homing. > > I find the paragraph above confusing. At minimum, I think the > last sentence is irrelevant and can be deleted. Also, I don't > quite understand the role of the first sentence, either. The second sentence is meant to give some examples for why a node's IP addresses could change. I'm not sure what you mean by "role of the first sentence." It describes one key aspect of HIP, no? >> If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP >> table, nodes can dynamically update their DNS entry in a secure >> fashion [5][6]. The DNS server maintaining the information will then >> sign and distribute the updated zone. > > IMHO, the first sentence above is too terse. It would require > some explanation. i.e., "using secured, dynamic DNS updates [5][6]"? >> The HIP architecture tries to greatly reduce the frequency of Dynamic >> DNS updates by introducing rendezvous servers [2]. Instead of >> registering its current set of IP addresses in its HI->IP entry in >> the DNS, a HIP node may instead register the IP addresses of its > > Instead of "HI->IP" I would say "HI-IP or FQDN->IP" Here, and maybe in some other places, the problem of what the DNS actually stores comes into play. Instead of containing one map from FQDN->HI and a second one from HI->IP, it has one that maps FQDNs into pairs of [HI, IP] (see Section 2.) Logically, you can construct one from the other, but there is a difference. When writing this, I was always trying to look at the logical level - maybe this is confusing? (I found it more confusing, however, to switch between talking about FQDN->HI->IP and FQDN->[HI, IP].) >> are assumed to change only infrequently, this approach can >> significantly reduce the load on DNS servers. > > s/load/update load/ ?? Yes. >> This approach changes the role of the IP addresses stored in a DNS >> entry. Traditionally, nodes were directly reachable at the IP >> addresses listed in their DNS entry. HIP rendezvous server change >> this basic property by replacing the IP addresses of their client >> nodes in the DNS with their own. The IP addresses in a DNS entry >> hence no longer directly designate interfaces of an endpoint. >> Instead, they identify interfaces of a node that can relay packets to >> the endpoint. > > As far as I can understand, the text above is also more or less true > for Mobile IP, with the exception that Mobile IP Home Agent may need > to use proxy ARP or proxy ND in addition, depending on how it has > been implemented. Maybe we want to mention this architectural similarity > with Mobile IP Home Agents? HIP here is actually distinctly different from MobileIP. The HIP draft argued that a node would put the address of its rendezvous server into its DNS entry, i.e., an address at which it is not directly reachable. With MobileIP, the node would use its home address here, at which it is directly reachable. (The -06 revision of the HIP arch ID actually removed the text this paragraph was based on, following our discussions in Seoul, so this section requires a revision.) >> Rendezvous servers may establish some of HIP's benefits even if one >> of the endpoints does not support it. Rendezvous servers live at >> static IP addresses. They can maintain ongoing transport-layer >> connections by acting as a relays for HIP nodes whose IP addresses >> may change. The discussion in the remainder of this section assumes >> that HIP nodes utilize rendezvous servers to maintain the HI->IP >> information as described in Section 3. > > Instead of talking about rendezvous servers, I would talk about > "nodes acting as rendezvous servers" or "nodes providing rendezvous > service". The reason for this is that I'd like to keep the > rendezvous and proxy functions separate. I think that it would > be much easier to understand if a rendezvous server merely provides > a pure HIP-only rendezvous server for HIP-to-HIP communication, > and we would call a node providing HIP mobility etc. benefits > for non-HIP nodes as an IP proxy or HIP proxy, depending on the > kind of service it provides. Terminology-wise, we've used three distinct terms for specific examples of general rendezvous mechanisms: rendezvous server, broker and agent. We specifically use three different terms to avoid confusion when we compare the different examples. When we talk about rendezvous servers, we mean the HIP-to-HIP mechanisms worked on in the WG, and possible extensions of that specific mechanism to the HIP-to-non-HIP case. Rendezvous brokers are HIP-to-non-HIP mechanisms that are similar to tunnel brokers (hence the name) and also MobileIP home agents. Rendezvous agents are a third mechanism that enable location privacy. These are obviously all related in that they're all rendezvous mechanisms. I'm open for suggestions on better terminology, and will check that we use the correct terms (including the generalization "rendezvous service") throughout. > I would also change the rest of the text accordingly, talking more > about "rendezvous service" than "rendezvous servers". Accordingly, > I would change the text in Section 4 to talk about "proxy service", > not rendezvous servers. What is the definition of "proxy service"? > I don't currently have any strong opinion about the term > "rendezvous broker", used in Section 5. However, since it provides > also other services than just rendezvous, I think that it would > probably be better to change it, too. > > I don't think it is too useful for me to comment the rest of the > draft before we've clarified these terminology issues. Lars -- Lars Eggert NEC Network Laboratories --------------ms070605010006080603080307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 NDA3MjcxNTQyMzJaMCMGCSqGSIb3DQEJBDEWBBR1YTTfI9sQ/rolCvNvLrJn5bTzdDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQAUK056fhASe6/hX5AW2gaRFEUSJPnuH59JSd+6+aUx9/kr 1jONvB4oRBX5Tdaz8WCyixGGyyD0pcANm/wEIXE+qiGusNChVx3UP7IqE0zta+SYY5G8Y8Dm bTDW0c2ycXopFtRo/zmplaT+rYUcd8Pt93Yh9/Y+QUBxv7zo/T5XDhY9w5+CAo+CUVU6C+bN 5D4mUxOyUIILAbQg+WnJ9GBHF5joi/jmkTGfSmjyflSGxrMojX4YM7xos7Nvb7xklZNig6vE eluFbAyKcsELZljMJx/ezV4GmbXNxXRie6Eh5BAADoLJect81siAV240tDtRPvE2hdFcJydN BkNwylFRAAAAAAAA --------------ms070605010006080603080307-- From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Jul 27 06:22:01 2004 Subject: [Hipsec-rg] Using HITs or HIs in the native API In-Reply-To: <57EC0363-DFBD-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> <38F6F1BE-DF34-11D8-9324-000393CE1E8C@nomadiclab.com> <57EC0363-DFBD-11D8-A131-000D93ACD0FE@it.uc3m.es> Message-ID: <252BC96C-DFBF-11D8-9324-000393CE1E8C@nomadiclab.com> [Moving discussion from multi6 to here.] > If we design a solution that provides CGAs, we are providing the apps > with a secure-enough AID, so they can start using it as an identifier > to authorization and so on. This doesn't seems very aligned with the > goal of having apps deal with the EID directly > > [I mean if we move to the hip plane, HITs are suitable to be used as > identity tokens to perform authorization by apps, do you think that > appd will start using the HIT or they will move to the HI directly?] > > Bottom line, is that if we provide a transition tool such as the CGA > (which provides security to some degree), this may be an obstacle to > moving towards the "real" identifier later on. The way the current proposal for a native HIP API has been written (see previous messages by Miika) is such that it uses handles to represent peer identity. These handles can then be thought as being references to the actual HIs. --Pekka From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Jul 27 05:55:06 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060785@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060785@xch-nw-27.nw.nos.boeing.com> Message-ID: <6740FA5E-DFBB-11D8-9324-000393CE1E8C@nomadiclab.com> [Getting back to old e-mail] Tom, >> * Is the EID approach an overkill? It is quite easy to >> replace the EID with a HIT in the API, if some people >> prefer HITs as the AID. > > I don't think the EID approach is well motivated. At least I > don't see the benefit of adding another layer of indirection to > the architecture. If I remove EID concept from your API and just > deal only with HITs, HIs, and IP addresses, what is lost? Let me disagree with all respect. Firstly, a few IETF meetings ago we (I don't remember who, maybe you were there, maybe not) had a discussion of what to do if the 120+ bits currently used in HITs becomes too short. We quickly noticed that it would be fairly easy to change the HITs in the protocol to larger ones, e.g., 256 bits long. However, implementing the corresponding change at the API level is much harder. Hence, this is one of the reasons why I asked Miika to use separate handles. Secondly, passing handles between processes requires a new system call while a mere HIT can be passed around as a binary value. As we can envision a handle to be bound to an active HIP association and not just to a HIT, the added security can be beneficial. But I agree with you that the terminology may not be the best one. > So EID is purely a handle like > a file descriptor to the identities stored in the kernel? Yes, that is the intention. But maybe not only to the identities, maybe directly to an active HIP association. In that way you could have several parallel HIP associations between two hosts, if that ever becomes necessary. (I realise that the API issues here are not enough and protocol changes would be needed, but IMHO it is good if the API can *potentially* represent such an extension.) --Pekka From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Jul 27 05:42:01 2004 Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt] In-Reply-To: <4100B573.8020009@netlab.nec.de> References: <4100B573.8020009@netlab.nec.de> Message-ID: <983B8B50-DFB9-11D8-9324-000393CE1E8C@nomadiclab.com> Lars and Marco, > attached is an update of draft-eggert-hip-rendezvous. Thanks for submitting this draft. Below some comments to the draft. The last one is most serious, since I think that we should change some of the terminology used in the draft, in order to make it more understandable. > Transparent communication between HIP and non-HIP nodes places > additional restrictions on the lookup mechanisms. For example, > non-HIP nodes expect DNS lookups to return IP addresses, requiring > the HI->IP mapping (or a representation thereof) to remain in the > DNS. Section 4 discusses communication between HIP and non-HIP > nodes > and describes different alternatives that support it. I think that you want to say that backward compatibility requires the FQDN->IP mapping to (or a representation of it) to remain in the DNS, not HI->IP mapping. > HIP decouples domain names from IP addresses. Because transport > protocols bind to host identities, they remain unaware if the set of > IP addresses associated with a host identity changes. This change > can have various reasons, including, but not limited to, mobility > and > multi-homing. I find the paragraph above confusing. At minimum, I think the last sentence is irrelevant and can be deleted. Also, I don't quite understand the role of the first sentence, either. > If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP > table, nodes can dynamically update their DNS entry in a secure > fashion [5][6]. The DNS server maintaining the information will > then > sign and distribute the updated zone. IMHO, the first sentence above is too terse. It would require some explanation. > The HIP architecture tries to greatly reduce the frequency of > Dynamic > DNS updates by introducing rendezvous servers [2]. Instead of > registering its current set of IP addresses in its HI->IP entry in > the DNS, a HIP node may instead register the IP addresses of its Instead of "HI->IP" I would say "HI-IP or FQDN->IP" > are assumed to change only infrequently, this approach can > significantly reduce the load on DNS servers. s/load/update load/ ?? > This approach changes the role of the IP addresses stored in a DNS > entry. Traditionally, nodes were directly reachable at the IP > addresses listed in their DNS entry. HIP rendezvous server change > this basic property by replacing the IP addresses of their client > nodes in the DNS with their own. The IP addresses in a DNS entry > hence no longer directly designate interfaces of an endpoint. > Instead, they identify interfaces of a node that can relay packets > to > the endpoint. As far as I can understand, the text above is also more or less true for Mobile IP, with the exception that Mobile IP Home Agent may need to use proxy ARP or proxy ND in addition, depending on how it has been implemented. Maybe we want to mention this architectural similarity with Mobile IP Home Agents? > Rendezvous servers may establish some of HIP's benefits even if one > of the endpoints does not support it. Rendezvous servers live at > static IP addresses. They can maintain ongoing transport-layer > connections by acting as a relays for HIP nodes whose IP addresses > may change. The discussion in the remainder of this section assumes > that HIP nodes utilize rendezvous servers to maintain the HI->IP > information as described in Section 3. Instead of talking about rendezvous servers, I would talk about "nodes acting as rendezvous servers" or "nodes providing rendezvous service". The reason for this is that I'd like to keep the rendezvous and proxy functions separate. I think that it would be much easier to understand if a rendezvous server merely provides a pure HIP-only rendezvous server for HIP-to-HIP communication, and we would call a node providing HIP mobility etc. benefits for non-HIP nodes as an IP proxy or HIP proxy, depending on the kind of service it provides. I would also change the rest of the text accordingly, talking more about "rendezvous service" than "rendezvous servers". Accordingly, I would change the text in Section 4 to talk about "proxy service", not rendezvous servers. I don't currently have any strong opinion about the term "rendezvous broker", used in Section 5. However, since it provides also other services than just rendezvous, I think that it would probably be better to change it, too. I don't think it is too useful for me to comment the rest of the draft before we've clarified these terminology issues. --Pekka From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Jul 26 13:46:08 2004 Subject: [Hipsec-rg] draft hiprg agenda Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045222BE@xch-nw-27.nw.nos.boeing.com> As of July 26, this is the draft agenda for the hiprg meeting. =20 I will post revisions to this as more things are confirmed. Tom =20 Host Identity Protocol Research Group (hiprg) Friday, August 6 at 0900-1130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIR(s): Tom Henderson Pekka Nikander AGENDA: o Administrivia/Agenda Tom Henderson o Review of HIPRG charter and work plan Tom Henderson =20 o HIP native API Miika Komu o HIP rendezvous concepts (Lars Eggert) - draft-eggert-hip-rendezvous-01 o Host Identity Indirection Infrastructure (Hi3) Jari Arkko - draft-nikander-hiprg-hi3-00.txt From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Fri Jul 23 01:52:00 2004 Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-01.txt] Message-ID: <4100B573.8020009@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms040500090301060700060609 Content-Type: multipart/mixed; boundary="------------030904030200060109020308" This is a multi-part message in MIME format. --------------030904030200060109020308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, attached is an update of draft-eggert-hip-rendezvous. Unlike its companion document (draft-eggert-hip-rvs), this one takes a higher-level look at rendezvous options for HIP. The -01 version mainly adds a chapter on mechanisms for HIP location privacy by a new co-author, Marco Liebsch. Lars -- Lars Eggert NEC Network Laboratories --------------030904030200060109020308 Content-Type: message/rfc822; name="I-D ACTION:draft-eggert-hip-rendezvous-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-eggert-hip-rendezvous-01.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from atlas.office (atlas.office [10.1.1.15]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 113B814C3F1 for ; Thu, 22 Jul 2004 22:30:32 +0200 (CEST) Received: by atlas.office (Postfix) id 46A121FCB7; Thu, 22 Jul 2004 22:35:32 +0200 (CEST) Delivered-To: quittek@atlas.office Received: by atlas.office (Postfix, from userid 502) id 2C77D1FCFF; Thu, 22 Jul 2004 22:35:32 +0200 (CEST) Received: from tokyo.netlab.nec.de (neptune.office [10.1.1.83]) by atlas.office (Postfix) with ESMTP id 394EF1EB4B for ; Thu, 22 Jul 2004 22:35:29 +0200 (CEST) Received: by tokyo.netlab.nec.de (Postfix) id DC5407D121; Thu, 22 Jul 2004 22:30:28 +0200 (CEST) Delivered-To: quittek@netlab.nec.de Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 2CD2D7D11D; Thu, 22 Jul 2004 22:30:28 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnjdf-00045H-4w; Thu, 22 Jul 2004 15:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnjL0-0005dC-GV for i-d-announce@megatron.ietf.org; Thu, 22 Jul 2004 15:34:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19225 for ; Thu, 22 Jul 2004 15:34:40 -0400 (EDT) Message-Id: <200407221934.PAA19225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Jul 2004 15:34:40 -0400 Subject: I-D ACTION:draft-eggert-hip-rendezvous-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on atlas.office X-Spam-Level: X-Spam-Status: No, hits=-103.2 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_WHITELIST autolearn=no version=2.63 X-Sanitizer: This message has been sanitized! --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identity Protocol (HIP) Rendezvous Mechanisms Author(s) : L. Eggert, M. Liebsch Filename : draft-eggert-hip-rendezvous-01.txt Pages : 27 Date : 2004-7-22 This document discusses rendezvous mechanisms for the Host Identity Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous Servers, improve operation when HIP nodes are multi-homed or mobile. They can also facilitate communication between HIP and non-HIP nodes. Possible rendezvous mechanisms differ in performance, compatibility, and impact on the HIP and Internet architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-hip-rendezvous-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eggert-hip-rendezvous-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-eggert-hip-rendezvous-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eggert-hip-rendezvous-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-eggert-hip-rendezvous-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145236.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------030904030200060109020308-- --------------ms040500090301060700060609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 NDA3MjMwNjUxMzFaMCMGCSqGSIb3DQEJBDEWBBRtORYOQgccgCahM38ZiMndFqpkIzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQBW3dDaryeXnng+kxo4EQrZyRtksbxbegftGLA8FaPHcgeq i8S8cfVTvVmQ/EgsVXIiWo/ezyxRd7FpDHFIyW/oIdnBZqybcg6q4z4TCReK/MLA7Sz++ZFj EpuYf1N5yp8KSpM2qTOg9WxzFw5IClVS6CLp/24OGnK6zJKdZ11AjbqdyYxEdQbUFtEK/lgM H+EVP9g2jF4kOu21BfurjK5i193Zce7Kz7+BAOFMspesfU0BroDR48JBP94hARmE6XLN680Q ZeO4C1TWx0YTbnuHRRFhTcjfgytlkvWI5UONKujh4F6c9JY2jqqT3G6ugL1E0Ba0T2hrUkdG e6p5YYD8AAAAAAAA --------------ms040500090301060700060609-- From: miika@iki.fi (Miika Komu) Date: Wed Jul 21 02:24:01 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406078B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406078B@xch-nw-27.nw.nos.boeing.com> Message-ID: On Tue, 20 Jul 2004, Henderson, Thomas R wrote: > > I did not understand this. Did my previous correction on the mappings > > clear this out? > > > > OK, this makes more sense to me now. So you are saying that the > HIP applications need both a file descriptor for the socket (sockfd) > using PF_HIP, and also one for host identities (eid) that refer > the sockfd to the right host identity? So EID is purely a handle like > a file descriptor to the identities stored in the kernel? Yes. > I think I see your point about the extensibility/flexibility now > if representations of host identities (including HITs) were to > change in the future. I think it depends on that and whether > applications in future would rather handle descriptors or actual > identities themselves. Maybe HIT will be enough. Perhaps the EID concept could be useful for other protocols with id/locator split, as I mentioned in text. The same sockaddr_eid structure could be reused in the other protocols, and just filled with a different protocol family. Perhaps the benefit is still quite minimal, because you can always define a new protocol specific sockaddr structure. The HITs also have the property that they can be compared with each other. Depending on how the descriptors are defined, they may or may not be compared with each other (the latter approach was chosen in the native HIP API). -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 20 21:22:01 2004 Subject: [Hipsec-rg] native HIP API Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406078B@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Tuesday, July 20, 2004 1:18 PM > To: Henderson, Thomas R > Cc: hipsec-rg@honor.trusecure.com > Subject: RE: [Hipsec-rg] native HIP API >=20 >=20 > On Tue, 20 Jul 2004, Henderson, Thomas R wrote: >=20 > > It is also somewhat confusing to be dealing with "endpoints" and > > "hosts" and saying that the mapping of EIDs to host IDs is=20 > one to many > > (p.33). >=20 > You are referring to section 4.1.4 "Socket Bindings"? There=20 > is typo in the > text of that section: >=20 > "The source EID is associated to multiple source HIs and the=20 > destination > EID is associated to multiple destination HIs." >=20 > The EID-to-HI mapping should be many-to-one, not one-to-many=20 > as the text > implies. The mappings are correct in the figure 4.3. >=20 > > I think what you are getting at is that a physical machine=20 > may have many > > keys, so it can be said to embody many "hosts", but you=20 > actually have > > one physical endpoint? But in that case, it seems to be more > > straightforward to say that an application just affiliates=20 > with one of > > possibly several local host identities? >=20 > I did not understand this. Did my previous correction on the mappings > clear this out? >=20 OK, this makes more sense to me now. So you are saying that the HIP applications need both a file descriptor for the socket (sockfd) using PF_HIP, and also one for host identities (eid) that refer the sockfd to the right host identity? So EID is purely a handle like a file descriptor to the identities stored in the kernel? I think I see your point about the extensibility/flexibility now if representations of host identities (including HITs) were to change in the future. I think it depends on that and whether applications in future would rather handle descriptors or actual identities themselves. Maybe HIT will be enough. Tom From: miika@iki.fi (Miika Komu) Date: Tue Jul 20 15:19:01 2004 Subject: [Hipsec-rg] native HIP API In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060785@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060785@xch-nw-27.nw.nos.boeing.com> Message-ID: On Tue, 20 Jul 2004, Henderson, Thomas R wrote: > > Questions: > > > > * Is the EID approach an overkill? It is quite easy to > > replace the EID > > with a HIT in the API, if some people prefer HITs as the AID. > > I don't think the EID approach is well motivated. At least I > don't see the benefit of adding another layer of indirection to > the architecture. If I remove EID concept from your API and just > deal only with HITs, HIs, and IP addresses, what is lost? Forward compatibility is lost with the HIT approach. The size of HIT is fixed and there may be some need to change it later. The EID approach was chosen in the beginning of the project. In the end, I am not totally convinced that the EID approach is superior to the HIT approach. > It is also somewhat confusing to be dealing with "endpoints" and > "hosts" and saying that the mapping of EIDs to host IDs is one to many > (p.33). You are referring to section 4.1.4 "Socket Bindings"? There is typo in the text of that section: "The source EID is associated to multiple source HIs and the destination EID is associated to multiple destination HIs." The EID-to-HI mapping should be many-to-one, not one-to-many as the text implies. The mappings are correct in the figure 4.3. > I think what you are getting at is that a physical machine may have many > keys, so it can be said to embody many "hosts", but you actually have > one physical endpoint? But in that case, it seems to be more > straightforward to say that an application just affiliates with one of > possibly several local host identities? I did not understand this. Did my previous correction on the mappings clear this out? > The EID does not seem to be exposed outside of the box, so in that sense > it doesn't seem to need to be called an "endpoint identifier" instead of > simply an alias or handle. Seems to me that the EID term is a bit misleading. In the scope of the thesis, it means "Endpoint Identifier Descriptor" (as in File Descriptor). > > * Opinions on the PF_HIP family? > > > > Overall, the use of a separate family makes sense to me and > should provide the desired commonality with existing sockets > yet allow for HIP-specific messaging to be defined. Right. > - you might want to look at the recent multi6 list where there seems > to have been some adoption of terms/concepts such as "application > identifier" (AID), "context identifier" (CID), and "context identifier > tag" (CIDT). Thanks. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Jul 20 11:52:00 2004 Subject: [Hipsec-rg] native HIP API Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060785@xch-nw-27.nw.nos.boeing.com> Mikka, thanks for providing the draft, some responses to your questions below... > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Thursday, July 08, 2004 3:40 AM > To: hipsec-rg@honor.trusecure.com > Cc: hipsec@honor.trusecure.com > Subject: [Hipsec-rg] native HIP API >=20 >=20 > There were some people interested in the HIP userspace API=20 > issues and I > promised to get back to the topic later by providing some background > information. >=20 > My master's thesis proposes a new API for HIP aware=20 > applications. It is > fully not completed yet but you can download a snapshot from the url > below: >=20 > http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf >=20 >=20 > Questions: >=20 > * Is the EID approach an overkill? It is quite easy to=20 > replace the EID > with a HIT in the API, if some people prefer HITs as the AID. I don't think the EID approach is well motivated. At least I don't see the benefit of adding another layer of indirection to=20 the architecture. If I remove EID concept from your API and just=20 deal only with HITs, HIs, and IP addresses, what is lost? It is also somewhat confusing to be dealing with "endpoints" and "hosts" and saying that the mapping of EIDs to host IDs is one to many (p.33). I think what you are getting at is that a physical machine may have many keys, so it can be said to embody many "hosts", but you actually have one physical endpoint? But in that case, it seems to be more straightforward to say that an application just affiliates with one of possibly several local=20 host identities? The EID does not seem to be exposed outside of the box, so in that sense it doesn't seem to need to be called an "endpoint identifier" instead of simply an alias or handle. Your thesis raised some interesting questions as to what exactly applications should be exposed to, and what they should have control over selecting, such as: - in what cases should/must an application select a source=20 host identity to use? - should applications be exposed to interface sets (or as you point out, interfaces on the source side and IP addresses on the destination side)? - should configuration parameters such as which ESP_TRANSFORM to use be set as socket options or as policy options via some kind of SPD interface? >=20 > * Opinions on the PF_HIP family? >=20 Overall, the use of a separate family makes sense to me and should provide the desired commonality with existing sockets yet allow for HIP-specific messaging to be defined. some other comments: p.32: s/difference to between/difference between p.33: s/associated to/associated with (many places) p.36: HIP_HI_ANY_PUB repeated twice (many places) - you might want to look at the recent multi6 list where there seems to have been some adoption of terms/concepts such as "application identifier" (AID), "context identifier" (CID), and "context identifier tag" (CIDT). =20 From: miika@iki.fi (Miika Komu) Date: Thu Jul 15 14:11:01 2004 Subject: [Hipsec-rg] native HIP API Message-ID: There were some people interested in the HIP userspace API issues and I promised to get back to the topic later by providing some background information. My master's thesis proposes a new API for HIP aware applications. It is fully not completed yet but you can download a snapshot from the url below: http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf I suggest that we continue the discussion on the hipsec research mailing list although I crossposted this email. Summary: The purpose of the native HIP API is to provide an explicit interface for HIP aware applications. It provides two new features compared to the "legacy HIP API". Applications are given the opportunity to control HIP connection attributes. Applications can also provide their own Host Identities to the host. The native HIP API is based on the BSD sockets API. The sockets API design is extended with two significant changes: a new protocol family (PF_HIP) and a new application identifier (EID). The new family requires a new HIP specific socket handler. The socket handler acts as a EID-to-HI address translator. It also allows setting and querying of HIP specific socket options. The new socket handler isolates the HIP sockets from the IPv4/IPv6 sockets. The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It hides the details of the variable length HIs and the associated ephemeral locators. The EID cannot be used as a referral, but there are interfaces for retrieving the HIs and locators corresponding to the EID. The EID is preferred as the AID instead of HIT for a few reasons. It provides forward compatibility with the HIP protocol. If the length of HIT were to change, the changes needed in the userspace would be minimal. The EID concept can also be beneficial for other protocols with the id/locator split. The API provides a new endpoint resolver, which is syntactically similar to the sockets API resolver. Basically, the resolver inputs a hostname and returns the EIDs corresponding to the hostname. The resolver makes the HI-to-locators mapping management transparent to the "typical" applications. However, the API allows the "advanced" applications to configure the mappings manually. The API supports explicit controlling of opportunistic HIP mode. Falling back to plain TCP/IP is also possible if the DNS does not contain the HIs of the peer. I implemented the socket handler into the networking stack, It supports the basic functionality of the API. It acts as a wrapper to IPv6 socket handler and it was not very difficult to implement. I also ported a telnet client and server to use the API with little effort. I writing an IETF draft for API proposal, but first, I would like receive some feedback and open a free discussion on the topic. I have already some specific questions in mind, but feel free to comment on anything. Questions: * Is the EID approach an overkill? It is quite easy to replace the EID with a HIT in the API, if some people prefer HITs as the AID. * Opinions on the PF_HIP family? P.S. I am on a holiday next week and cannot read my email (expect a delay on the replys). -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Jul 12 13:30:01 2004 Subject: [Hipsec-rg] Agenda requests for HIP RG meeting in San Diego Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060755@xch-nw-27.nw.nos.boeing.com> (cross-posted to HIP WG list) The HIP IRTF RG plans to meet in San Diego. We haven't yet heard back from the IETF on a time slot, but I will announce it when the agenda is eventually updated. Please send any proposed agenda items to me and Pekka. Thanks, Tom From: miika@iki.fi (Miika Komu) Date: Thu Jul 8 05:55:01 2004 Subject: [Hipsec-rg] native HIP API Message-ID: There were some people interested in the HIP userspace API issues and I promised to get back to the topic later by providing some background information. My master's thesis proposes a new API for HIP aware applications. It is fully not completed yet but you can download a snapshot from the url below: http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf I suggest that we continue the discussion on the hipsec research mailing list although I crossposted this email. Summary: The purpose of the native HIP API is to provide an explicit interface for HIP aware applications. It provides two new features compared to the "legacy HIP API". Applications are given the opportunity to control HIP connection attributes. Applications can also provide their own Host Identities to the host. The native HIP API is based on the BSD sockets API. The sockets API design is extended with two significant changes: a new protocol family (PF_HIP) and a new application identifier (EID). The new family requires a new HIP specific socket handler. The socket handler acts as a EID-to-HI address translator. It also allows setting and querying of HIP specific socket options. The new socket handler isolates the HIP sockets from the IPv4/IPv6 sockets. The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It hides the details of the variable length HIs and the associated ephemeral locators. The EID cannot be used as a referral, but there are interfaces for retrieving the HIs and locators corresponding to the EID. The EID is preferred as the AID instead of HIT for a few reasons. It provides forward compatibility with the HIP protocol. If the length of HIT were to change, the changes needed in the userspace would be minimal. The EID concept can also be beneficial for other protocols with the id/locator split. The API provides a new endpoint resolver, which is syntactically similar to the sockets API resolver. Basically, the resolver inputs a hostname and returns the EIDs corresponding to the hostname. The resolver makes the HI-to-locators mapping management transparent to the "typical" applications. However, the API allows the "advanced" applications to configure the mappings manually. The API supports explicit controlling of opportunistic HIP mode. Falling back to plain TCP/IP is also possible if the DNS does not contain the HIs of the peer. I implemented the socket handler into the networking stack, It supports the basic functionality of the API. It acts as a wrapper to IPv6 socket handler and it was not very difficult to implement. I also ported a telnet client and server to use the API with little effort. I writing an IETF draft for API proposal, but first, I would like receive some feedback and open a free discussion on the topic. I have already some specific questions in mind, but feel free to comment on anything. Questions: * Is the EID approach an overkill? It is quite easy to replace the EID with a HIT in the API, if some people prefer HITs as the AID. * Opinions on the PF_HIP family? P.S. I am on a holiday next week and cannot read my email (expect a delay on the replys). -- Miika Komu miika@iki.fi http://www.iki.fi/miika/