From Gonzalo.Camarillo@ericsson.com Mon Nov 1 03:01:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Nov 1 03:01:00 2004 Subject: [Hipsec] Agenda Message-ID: <4185FDC5.1020608@ericsson.com> Folks, this is the preliminary agenda for the meeting in Washington. http://hip.piuha.net/meetings/ietf61/agenda.html Regards, Gonzalo HIP co-chair From hipsec@honor.trusecure.com, Pekka Nikander Mon Nov 1 04:47:03 2004 From: hipsec@honor.trusecure.com, Pekka Nikander (Pekka Nikander) Date: Mon Nov 1 04:47:03 2004 Subject: [Hipsec] Re: [Hipsec-rg] 128bit LSI -- why? In-Reply-To: <15227.1099305245@www35.gmx.net> References: <15227.1099305245@www35.gmx.net> Message-ID: [This questions belongs to the working group, not the research group. Please direct all future discussion there.] > I found that in the new ID (draft-ietf-hip-base-01), a 128 bits LSI > is > introduced. In my understanding, 32bits LSI is used in the IPv4 > headers to > replace IP4 addresses. HIT is already 128bits and can be used in the > IPv6 > Header. What is the purpose of the 128bits LSI? To make a difference between IPv6 addresses and HITs at the legacy IPv6 API, for those applications that can easily work without modifications both on HIP and on IPv6. The only difference between a HIT and a 128-bit LSI is that the upper most TBD bits of the value are fixed, while in HIT they come from the hash. Putting it in another way, we do not believe that we could reserve a 2-bit prefix from the IPv6 address space for HITs. On the other hand, from the HIP point of view it would be wasteful not to use the upper most bits of a HIT, on the protocol level. Interoperability is currently preserved by requiring that the host SHOULD ignore the top-most TBD bits when comparing HITs for equality. You may consider this as a transition mechanism, hopefully to be deprecated at some (distant) point of time. --Pekka From pekka.nikander@nomadiclab.com Mon Nov 1 04:49:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 1 04:49:01 2004 Subject: [Hipsec] Agenda In-Reply-To: <4185FDC5.1020608@ericsson.com> References: <4185FDC5.1020608@ericsson.com> Message-ID: <1B3987C3-2BF5-11D9-B982-000D9331AFB0@nomadiclab.com> > this is the preliminary agenda for the meeting in Washington. > http://hip.piuha.net/meetings/ietf61/agenda.html I'm afraid we need more time for rendezvous. IMHO it is less baked than the other drafts. OTHO, as we are, IMHO, unlikely to get it into WG LC after this meeting, it might be a good idea to put it to the end, and allocated whatever remains to it. --Pekka From shep@alum.mit.edu Mon Nov 1 05:16:01 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Mon Nov 1 05:16:01 2004 Subject: [Hipsec] Re: [Hipsec-rg] 128bit LSI -- why? In-Reply-To: Your message of Mon, 01 Nov 2004 12:57:20 +0200. Message-ID: > > I found that in the new ID (draft-ietf-hip-base-01), a 128 bits LSI > > is > > introduced. In my understanding, 32bits LSI is used in the IPv4 > > headers to > > replace IP4 addresses. HIT is already 128bits and can be used in the > > IPv6 > > Header. What is the purpose of the 128bits LSI? > > To make a difference between IPv6 addresses and HITs at > the legacy IPv6 API, for those applications that can > easily work without modifications both on HIP and on IPv6. > > The only difference between a HIT and a 128-bit LSI is that > the upper most TBD bits of the value are fixed, while in HIT > they come from the hash. > > Putting it in another way, we do not believe that we could > reserve a 2-bit prefix from the IPv6 address space for HITs. > On the other hand, from the HIP point of view it would be > wasteful not to use the upper most bits of a HIT, on the > protocol level. Also, we cannot be sure that 128 bits of hash value will remain secure, so HITs may need to be longer than 128 bits. I think that may be relevant for making a distinction between 128-bit LSIs which are used across APIs and the HITs themselves which may need to be variable length. (Should 128-bit hash values not be thought secure enough for HITs, then it may be necessary to think about whether 128-bit LSIs introduce any security risks.) -Tim Shepard shep@alum.mit.edu From Gonzalo.Camarillo@ericsson.com Wed Nov 3 05:53:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Nov 3 05:53:01 2004 Subject: [Hipsec] Agenda In-Reply-To: <1B3987C3-2BF5-11D9-B982-000D9331AFB0@nomadiclab.com> References: <4185FDC5.1020608@ericsson.com> <1B3987C3-2BF5-11D9-B982-000D9331AFB0@nomadiclab.com> Message-ID: <4188C915.40901@ericsson.com> Hi Pekka, I have done as you suggest and I have placed the rvs presentation at the end of the meeting. In any event, all the presenters have gotten slots way longer than they requested, so we should not have time-related problems during the meeting. Regarding WGLCs, the idea is to let people get implementation experience before performing any WGLC. Thanks, Gonzalo Pekka Nikander wrote: >> this is the preliminary agenda for the meeting in Washington. >> http://hip.piuha.net/meetings/ietf61/agenda.html > > > I'm afraid we need more time for rendezvous. IMHO it is > less baked than the other drafts. OTHO, as we are, IMHO, > unlikely to get it into WG LC after this meeting, it might > be a good idea to put it to the end, and allocated whatever > remains to it. > > --Pekka From pekka.nikander@nomadiclab.com Sun Nov 7 19:56:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Nov 7 19:56:01 2004 Subject: [Hipsec] Comments to rvs-00.txt Message-ID: Julien and Lars, I have a number of high level comments to the rendezvous draft. In general, I think that the desired mechanisms are there, but according to my understanding of the WG charter, based on what I remember from the discussions with the ADs during the chartering time, the draft still has a too wide scope. In my opinion, we should cut down the document contents quite a lot. More specifically, I would suggest the following: 1. Split the draft into two documents: a. A generic HIP "Registration" protocol that could be also used for other purposes but registering oneself to a rendezvous server. b. A rendezvous service document, relying on the generic registration protocol, and defining just some basic rendezvous services 2. Moving of many advanced rendezvous features either to an appendix or to a separate draft. As a first step, I suggest that the content is moved to an appendix, determining later whether it should be cut out altogether, left in an appendix, or moved to a separate draft. At the detail level, this could be accomplished in the following way: - Section 3, page 4, starting from "This section discusses the different approaches...", and ending at the end of Section 3 on page 6: Move to an appendix. - Section 4.1: Move to an appendix. - From Section 5.1, page 10, to end of Section 5.2.3 on page 13: Move to the generic registration draft. - Section 7: Move to the generic registration draft - Section 7, page 19, starting with "If a HIP node wants to associate...", ending at the end of Section 7: Move to an appendix. - Section 8.1: Remove or move to an appendix. - Section 8.3: Remove or move to an appendix. - Section 8.6: Move to an appendix. After these structural changes, I would suggest the following content changes: 1. In the generic registration protocol: - Rename the parameters to REGISTRATION_REQUEST and REGISTRATION_REPLY. - Rename the RVA Type field to Registration Type - Define a new parameter, REGISTRATION_INFO, which simply lists a number of registration types. The lifetime field denotes a maximum lifetime that the server is willing to server. This parameter MAY be included in an R1, and if it is, it MUST be protected by the signature. - Split the Registration Type (previous RVA type) field into two 8-bit fields, "Registration Type" and "Registration Subtype". The values of these fields are to be specified elsewhere. Define rules (Standards action?) for defining new types. - Specify that a HIP host that is willing to act as a server (of some kind), accepting registration, SHOULD send a REGISTRATION_INFO parameter in the R1 message, and that it MAY send REGISTRATION_INFO other HIP messages, including I1, I2 and UPDATE. - Remove the RVS_CAPABLE bit as it is no longer needed, i.e., delete Section 5.1. - In Section 7 on page 18, change the second paragraph to read as follows: A HIP node MAY register with its a server that supports registration while establishing a HIP association by adding an REGISTRATION_REQUEST parameter in an I2. A server replies with an R2 that contains an REGISTRATION_REPLY parameter specifying the characteristics of the provided registration (lifetime, type, etc.). Depending on the type of the registration, the server and the HIP node MAY delete most of the HIP Association state, retaining only the lifetime, Initiator's HIT and IP address(es), and the necessary keying material. - Write a new IANA considerations section. 2. In the slimmed down rendezvous document, - Specify the following Registration Type and Subtypes. Number Registration Type ------ ----------------- 1 Rendezvous service Subtypes for Rendezvous service Number Rendezvous Subtype ------ ------------------ 1 TUNNEL_I1 (Section 8.2) 2 REWRITE_I1 (Section 8.4) 3 BIDIRECTIONAL (Section 8.5) Remove the explanations of the rendezvous types on page 11 and 12, and simply add references to the appropriate sections where the actual behaviour is defined. - Section 8.2. Rewrite the section to be more generic, allowing different types of tunnelling. The server may tunnel the I1 over the HIP association, open an ESP association, or e.g. over UDP using STUN. The method used depends on which kind of association the server has with the HIP node. - Write a new IANA considerations section. 3. Finally, some minor edits: - Section 1, page 3: Join paragraphs 2, 3, 4. - Section 2, page 4: IMHO, relaying back R1 is not limited to opportunistic Initiators. Remove the word "opportunistic". - Section 4.2, page 8. First paragraph, line 5. Add a reference to [3] at the full stop. Last sentence on the page: Change the phrase "packets will directly flow" to "packets may directly flow" or "packets will typically flow directly" - Section 4.2, page 9. Second paragraph. I don't see any reason why a HIP node cannot include both its native and RVS addresses in the DNS. Please rephrase to reflect this. Third paragraph, fourth line. Add "In the typical case, " before "The remainder of the ..." --Pekka From thomas.r.henderson@boeing.com Mon Nov 8 07:52:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Nov 8 07:52:00 2004 Subject: [Hipsec] Comments to rvs-00.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C05F745CA@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, November 07, 2004 9:07 PM > To: Julien Laganier; Lars Eggert > Cc: hipsec@honor.trusecure.com > Subject: [Hipsec] Comments to rvs-00.txt >=20 > Julien and Lars, >=20 > I have a number of high level comments to the rendezvous draft. > In general, I think that the desired mechanisms are there,=20 > but according to my understanding of the WG charter, based on=20 > what I remember from the discussions with the ADs during the=20 > chartering time, the draft still has a too wide scope. In my=20 > opinion, we should cut down the document contents quite a lot. I have some similar concerns. In case I am not at WG meeting tomorrow when this is discussed, I would also suggest the following: - the Introduction could (should) be cut down substantially=20 by referring to the HIP architecture and base documents, and just=20 succintly state something like: =20 "The Host Identity Protocol (HIP) Architecture [arch] introduces=20 a new name space and protocol layer for Internet hosts. The Host=20 Identity Protocol [base] provides a rapid exchange of Host Identities=20 between two hosts and establishes a pair of IPsec Security Associations to be used with IPsec Encapsulated Security Payload (ESP) [ESP]." Then, introduce briefly what this document is about; namely, defining a HIP extension to allow for an infrastructure node called a Rendezvous Server to serve as a relay point for HIP messages. And then introduce the pieces (here I agree with Pekka to reduce the scope substantially): i) host registration to its rendezvous server (and associated state) ii) host update of its care-of IP address to the rendezvous server iii) how, if an initiator gets IP address of rendezvous server via=20 HIPRVS DNS record or other means, it can send I1 (and return R1)=20 through the rendezvous server If document is split, then i)+ii) can go into one document and iii) into another. - I agree with the need to generalize the means by which I1 (and R1) are sent between R-Server and its client (i.e., various tunneling techniques are possible). - should we define, at this time, how rendezvous servers help the double jump problem (by allowing RVS to also forward HIP UPDATE packets)? Right now, it only seems to deal with I1 and R1. We could describe suitable end host behavior in the hip-mm document. Tom From pekka.nikander@nomadiclab.com Mon Nov 8 08:20:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 8 08:20:00 2004 Subject: [Hipsec] Comments to rvs-00.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C05F745CA@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C05F745CA@xch-nw-27.nw.nos.boeing.com> Message-ID: > And then introduce the pieces (here I agree with Pekka to reduce > the scope substantially): > i) host registration to its rendezvous server (and associated state) As I already stated, I think that this should probably be a separate document, since such a registration function seems to be useful also in other contexts, like HIP NAT traversal. > ii) host update of its care-of IP address to the rendezvous server I agree that this should be there, and probably part of the registration protocol. Right now, the required mechanism is not that cleanly explained. There will probably be some dependencies to the mm draft. > iii) how, if an initiator gets IP address of rendezvous server via > HIPRVS DNS record or other means, it can send I1 (and return R1) > through the rendezvous server Right. And while there seem to be a lots of different ways of how to forward I1 (and R1), I think that we basically want to define only one or two. Maybe two, since I see a tunnelling based solution different enough from a header-rewriting solution so that you probably want both. > - should we define, at this time, how rendezvous servers help > the double jump problem (by allowing RVS to also forward > HIP UPDATE packets)? Right now, it only seems to deal with > I1 and R1. Yes, that is missing. > We could describe suitable end host behavior in the > hip-mm document. I agree. --Pekka From pekka.nikander@nomadiclab.com Mon Nov 8 17:01:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 8 17:01:02 2004 Subject: [Hipsec] HIP over STUN, or HIP NAT-traversal through legacy NATs Message-ID: Based on hallway conversations, there seems to be quite a lot of interest in producing a specification for how to run HIP through legacy NATs. Furthermore, people seem to agree that at least one way to go is to somehow integrate HIP rendezvous service and STUN. To get this forward, I would suggest that we have an ad hoc meeting on this. I would suggest Thursday morning at 9am, but I am also open to other alternatives. If you are interested, please let me know. If you are interested but the time is not good for you, feel free to suggest alternative times at the list. Anyway, I will collect a list of interested people and try to arrange a meeting at some point of time. And, of course, we need a good acronym for this. Here are some suggestions: HoS HIP over STUN HIPU HIP over UDP HTN HIP through NATs --Pekka From stiemerling@netlab.nec.de Tue Nov 9 10:21:01 2004 From: stiemerling@netlab.nec.de (Martin Stiemerling) Date: Tue Nov 9 10:21:01 2004 Subject: [Hipsec] HIP over STUN, or HIP NAT-traversal through legacy NATs In-Reply-To: References: Message-ID: <4BF31746F03A88D182287175@[130.129.135.108]> Hi all, Juergen Quittek and I have outlined some implications of HIP and NAT traversal in this draft Meeting for Thursday 9am is fine. Martin --On Montag, 8. November 2004 18:12 Uhr -0500 Pekka Nikander wrote: | Based on hallway conversations, there seems to be quite a | lot of interest in producing a specification for how to | run HIP through legacy NATs. Furthermore, people seem to | agree that at least one way to go is to somehow integrate | HIP rendezvous service and STUN. | | To get this forward, I would suggest that we have an ad | hoc meeting on this. I would suggest Thursday morning | at 9am, but I am also open to other alternatives. | | If you are interested, please let me know. If you are | interested but the time is not good for you, feel free | to suggest alternative times at the list. Anyway, I | will collect a list of interested people and try to arrange | a meeting at some point of time. | | And, of course, we need a good acronym for this. | Here are some suggestions: | HoS HIP over STUN | HIPU HIP over UDP | HTN HIP through NATs | | --Pekka | | _______________________________________________ | Hipsec mailing list | Hipsec@honor.trusecure.com | http://honor.trusecure.com/mailman/listinfo/hipsec From pekka.nikander@nomadiclab.com Tue Nov 9 12:21:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Nov 9 12:21:01 2004 Subject: [Hipsec] HIP over STUN, or HIP NAT-traversal through legacy NATs In-Reply-To: <4BF31746F03A88D182287175@[130.129.135.108]> References: <4BF31746F03A88D182287175@[130.129.135.108]> Message-ID: <9B53307C-327D-11D9-A88A-000D9331AFB0@nomadiclab.com> > Juergen Quittek and I have outlined some implications of HIP and NAT > traversal in this draft > > I have read the draft and while I think it has some value (see below), it is not really what I have in mind. I'd like to proceed more directly to a specific class of solutions, i.e., to see how to marry HIP with STUN in a reasonable way. Since that work is not currently chartered in any WG, this should probably go as individual work. Anyway, some comments to the draft: - In general, I think that the draft may act as a problem statement, but it definitely does not propose a suitable solution, even though it briefly discusses some. - Depending on what happens at the next HIP WG re-chartering, it might be useful to have a crystal clear problem statement for HIP middle box traversal. Perhaps this draft could act as a starting point for that. More detail: - In Section 4.1, the draft claims: > When IPv4 is used, HIP messages are transmitted as UDP payload. > (see Appendix E of [HIP-PROTO]). As (I think) I have previously said, this has never been true. App E was a placeholder for thought, and would never have worked. The intention has always been that the _preferable_ way for HIP is to run on the top of IP. And as of the newest base spec, the appendix is gone, or at least should be. As a consequence of this, Section 4.1.2 needs to be fixed, too. Now, we do need to get HIP to run on the top of UDP (and probably HTTP) to traverse NATs (and some other middle boxes). But that has not been defined. We still need to nail down the details. - In Section 4.1.1, the draft claims: > Another problem (that also applies to IPv4) is that HIP provides no > explicit means for transmitting the IP address used by a host other > than using the source IP address of the packet carrying HIP > messages. While that is true wrt the base spec, the mm spec explicitly defines a means to carry IP addresses, i.e., the readdressing payload. While that most probably is not quite enough for NAT traversal purposes, perhaps it could be made more generic to fit for that purpose. --Pekka From Julien.Laganier@Sun.COM Tue Nov 9 15:50:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Nov 9 15:50:01 2004 Subject: [Hipsec] Comments to rvs-00.txt In-Reply-To: References: Message-ID: <200411092303.32621.julien.laganier@sun.com> On Monday 08 November 2004 03:07, Pekka Nikander wrote: > Julien and Lars, > > I have a number of high level comments to the rendezvous draft. > In general, I think that the desired mechanisms are there, but > according to my understanding of the WG charter, based on what > I remember from the discussions with the ADs during the > chartering time, the draft still has a too wide scope. In my > opinion, we should cut down the document contents quite a lot. > More specifically, I would suggest the following: > > 1. Split the draft into two documents: > > a. A generic HIP "Registration" protocol that could > be also used for other purposes but registering > oneself to a rendezvous server. > > b. A rendezvous service document, relying on the > generic registration protocol, and defining just > some basic rendezvous services > > 2. Moving of many advanced rendezvous features either > to an appendix or to a separate draft. As a first > step, I suggest that the content is moved to an > appendix, determining later whether it should be > cut out altogether, left in an appendix, or moved > to a separate draft. Pekka and Tom, As I said during the WG meeting on monday, I think what you are proposing make perfect sense. Hence, I'll follow your recommendations and send soon to the ML updated versions of the two resulting I-Ds. Thanks, --julien From Julien.Laganier@Sun.COM Wed Nov 10 13:25:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Nov 10 13:25:00 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs Message-ID: <200411102038.15863.julien.laganier@sun.com> Hi folks, I suggest that we resolve this issue as Erik/Pekka suggested during the meeting: 1) Store multiple IPs and HIs in a 'flat' manner in the DNS. 2) If a DNS query returns several IPs and HIs, then the node should just pick one of the locator and initiate towards it, and then validate the HI returned in R1 against the set it queried the DNS. If everybody agrees, we need to work out the details, though... Suppose there's two nodes, node-A and node-B, using the same FQDN, but each one has an IP (resp. IP-A and IP-B) and a HIT (resp. HIT-A and HIT-B). An initiator querying DNS for FQDN will get: FQDN A IP-A FQDN A IP-B FQDN HIPHI HIT-A HI-A FQDN HIPHI HIT-B HI-B But then if it sends an I1 to (IP-B,HIT-A), node-B will receive this, but probably drop it as HIT-A doesn't belongs to it. An easy solution is to require an initiator to initiate in Opportunistic Mode when several HIs are returned in a DNS lookup, and then have it validate the Responder HIT returned in R1 against the set of returned HITs. In the previous example, that would means that initiator sends I1 to (IP-B, HIT-0), and gets back an R1 from (IP-B, HIT-B), then verifies that HIT-B belongs to the set of returned RRs. I believe such behavior belongs to the base spec document, not to the DNS extension spec, but I'm not 100% sure... What do you think? Thanks, --julien From lars.eggert@netlab.nec.de Wed Nov 10 13:50:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Wed Nov 10 13:50:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <200411102038.15863.julien.laganier@sun.com> References: <200411102038.15863.julien.laganier@sun.com> Message-ID: <41927387.9010600@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms080501090002090700020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julien Laganier wrote: > > I suggest that we resolve this issue as Erik/Pekka suggested during > the meeting: > > 1) Store multiple IPs and HIs in a 'flat' manner in the DNS. > > 2) If a DNS query returns several IPs and HIs, then the node should > just pick one of the locator and initiate towards it, and then > validate the HI returned in R1 against the set it queried the DNS. > > If everybody agrees, we need to work out the details, though... I need more time to digest all the implications of this proposal, but my gut feeling is that I don't like this scheme. Here's why. Basically, the mapping is from 1 FQDN into N HITs, each 1 of those HITs maps into M IP addresses. (I think this is what the outcome of the API discussion at the last IETF was, right?) The question now is how we fit these two bindings into the current DNS. The proposal you mention basically maps each FQDN into an unstructured set of both its associated IP addresses and HITs, and then uses a new protocol to figure out which HIT goes with which IP addresses. This seems awfully complex, especially considering that the RG currently seems to lean towards relocating the HIT-to-IP binding into a second resolution system, maybe based on DHTs. A much simpler stopgap may be to simple declare that until we have the support infrastructure in place, we mandate a 1:1 binding from FQDNs to HITs. Would we lose any critical functionality with this? Another more complex - but also more powerful - approach may be to create a second DNS tree for HITs, i.e., simulate the eventual DHT lookup service using the DNS. Under this approach, you'd go to the DNS twice to initiate communication, once to look up the HITs that go with a FQDN, and a second time to look up the IP addresses that go with the one HIT you picked from the first result. What does the group think of this? Lars -- Lars Eggert NEC Network Laboratories --------------ms080501090002090700020605 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 NDExMTAyMDAxMTFaMCMGCSqGSIb3DQEJBDEWBBQpkL4E9IllKCKjhf7k6sptlU67RTBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQB5nj7llvxNaRGKECAsKLCyUWYuVrl6wx8Xh/2doXb87Wkc AZuABQ4qLghhiNXqWAd7Eh2xqpF5YlyR124CVRudZft8j17WQGF+IdUR6yLLNUoTw9QqeBp6 2sdnA32AXdJdUHQ+pHjAuRKDHX1dHGM6IZKrojXmD8xbdlrOqOTBxVaZ8/D98jC5Tvap8ihj 33nASffjtx4O4/qAcAnTu2sut6h+bIAPRwdMWM8sLgXKAXcyLEj2oiEemEX+CyDGJmpioq55 ob4h7Fb6eir8JXO6+SUxwsfdh36f4b6fauV/HGDIztwreSyP7dmh4Svdchh/65zE77eKzRWD 0/V7002tAAAAAAAA --------------ms080501090002090700020605-- From pekka.nikander@nomadiclab.com Wed Nov 10 14:46:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 10 14:46:00 2004 Subject: [Hipsec] HIP over STUN ad hoc meeting on Thursday (tomorrow) at 9am Message-ID: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> As agreed before, the HIP over STUN ad hoc meeting will be tomorrow (Thursday) morning at 9am. I have asked for a room but I don't know yet if we will get one. Hence, let's meet at the IETF registration desk at 9am, and then go somewhere. I'll also send another message, with this distribution, as soon as I know what room it will be (or that we were not able to get a room at all). --Pekka From lars.eggert@netlab.nec.de Wed Nov 10 16:19:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Wed Nov 10 16:19:01 2004 Subject: [Hipsec] Re: HIP over STUN ad hoc meeting on Thursday (tomorrow) at 9am In-Reply-To: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <4192966F.4080201@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms060702070201030406010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > As agreed before, the HIP over STUN ad hoc meeting will be > tomorrow (Thursday) morning at 9am. Have we settled on STUN? Another option - and I'm not advocating it, just bringing it up for discussion - would be to run over teredo. Given that it's supposedly already in WinXP, this may ease HIP deployment. (I do not know if there are IPR issues associated with teredo.) http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx Lars -- Lars Eggert NEC Network Laboratories --------------ms060702070201030406010107 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 NDExMTAyMjMwMDhaMCMGCSqGSIb3DQEJBDEWBBQr8CLSmLwRo0uQ4j6dv8VfqOKJLzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQBsQWSx0Z/N1Xvq0dqEoVcek2S2DevuroTD70uw32Ykdlgv 81wmFQX9jG9uOBLgliiGZP5Pu35TSjRpCTLGRQIIRnV0DNo8kXZz172gjXBXwmdu9z/HA4wZ bYvJgJpEdl7bMMdnhdUVGeu5oOjLNRkHFhmfGa2a+gtcdQNKh/XeStZckmtGUI6sn22TWBVR zvzF6QSN1lX9iYx+U/6neUgnzYQPVLELHYNNiwez5puLhXG2kq1pxa07lCbBK8tufMPpe3V6 fP3WFeDmI78w3vopTStUWqaygWpYnwTNIQ1FvosJh3BcyVfDaZeoq4ipD6UFy4v0IAQsSZIX UYOXwZKcAAAAAAAA --------------ms060702070201030406010107-- From stiemerling@netlab.nec.de Wed Nov 10 19:29:00 2004 From: stiemerling@netlab.nec.de (Martin Stiemerling) Date: Wed Nov 10 19:29:00 2004 Subject: [Hipsec] HIP over STUN, or HIP NAT-traversal through legacy NATs In-Reply-To: <9B53307C-327D-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <4BF31746F03A88D182287175@[130.129.135.108]> <9B53307C-327D-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <5DF1007E54053831079992F0@[130.129.135.108]> Hi Pekka, --On Dienstag, 9. November 2004 13:31 Uhr -0500 Pekka Nikander wrote: |> Juergen Quittek and I have outlined some implications of HIP and NAT |> traversal in this draft |> |> | | I have read the draft and while I think it has some value | (see below), it is not really what I have in mind. I'd like | to proceed more directly to a specific class of solutions, | i.e., to see how to marry HIP with STUN in a reasonable way. | Since that work is not currently chartered in any WG, this | should probably go as individual work. Thanks for reading and giving comments! | | Anyway, some comments to the draft: | | - In general, I think that the draft may act as a problem | statement, but it definitely does not propose a suitable | solution, even though it briefly discusses some. Yes, indeed it is a problem statement and should only open the space for further discussions and activities. We've just reached the point of getting to a solution, which is great :) | | - Depending on what happens at the next HIP WG re-chartering, | it might be useful to have a crystal clear problem statement | for HIP middle box traversal. Perhaps this draft could act | as a starting point for that. I'll do my best to get this as clear as possible. | | More detail: | | - In Section 4.1, the draft claims: | |> When IPv4 is used, HIP messages are transmitted as UDP payload. |> (see Appendix E of [HIP-PROTO]). | | As (I think) I have previously said, this has never been true. | App E was a placeholder for thought, and would never have worked. | The intention has always been that the _preferable_ way for HIP | is to run on the top of IP. And as of the newest base spec, | the appendix is gone, or at least should be. | | As a consequence of this, Section 4.1.2 needs to be fixed, too. The statement made in the problem statement is misleading and should be clarified within the next revision. | | Now, we do need to get HIP to run on the top of UDP (and probably | HTTP) to traverse NATs (and some other middle boxes). But that | has not been defined. We still need to nail down the details. Running HIP base exchange over UDP is good start, but, as you've said, the whole things needs to nail down the details. I'm happy to help on this! | | - In Section 4.1.1, the draft claims: | |> Another problem (that also applies to IPv4) is that HIP provides no |> explicit means for transmitting the IP address used by a host other |> than using the source IP address of the packet carrying HIP |> messages. | | While that is true wrt the base spec, the mm spec explicitly defines | a means to carry IP addresses, i.e., the readdressing payload. | While that most probably is not quite enough for NAT traversal | purposes, perhaps it could be made more generic to fit for that | purpose. I've had in mind that the problem statement does mention the mm spec, referring to carrying the IP address between hip nodes. It may be that I have not put in the draft, but I'm having this in my mind. Looking forward for the HIP&NAT meeting on Thursday morning. Thanks, Martin From pekka.nikander@nomadiclab.com Wed Nov 10 19:32:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Nov 10 19:32:01 2004 Subject: [Hipsec] Re: HIP over STUN ad hoc meeting on Thursday (tomorrow) at 9am In-Reply-To: <4192966F.4080201@netlab.nec.de> References: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> <4192966F.4080201@netlab.nec.de> Message-ID: <22A6A4AF-3383-11D9-A88A-000D9331AFB0@nomadiclab.com> >> As agreed before, the HIP over STUN ad hoc meeting will be >> tomorrow (Thursday) morning at 9am. > > Have we settled on STUN? Not necessarily. To me it just looks simplest and most natural. Actually, what I am working now on is not quite STUN, but it just basically steals everything from STUN. But maybe I just don't know teredo well enough. --Pekka N. From Julien.Laganier@Sun.COM Thu Nov 11 09:33:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Nov 11 09:33:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <41927387.9010600@netlab.nec.de> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> Message-ID: <200411111646.37650.julien.laganier@sun.com> On Wednesday 10 November 2004 21:01, Lars Eggert wrote: > Julien Laganier wrote: > > I suggest that we resolve this issue as Erik/Pekka suggested > > during the meeting: > > > > 1) Store multiple IPs and HIs in a 'flat' manner in the DNS. > > > > 2) If a DNS query returns several IPs and HIs, then the node > > should just pick one of the locator and initiate towards it, and > > then validate the HI returned in R1 against the set it queried > > the DNS. > > > > If everybody agrees, we need to work out the details, though... > > I need more time to digest all the implications of this proposal, > but my gut feeling is that I don't like this scheme. Here's why. > > Basically, the mapping is from 1 FQDN into N HITs, each 1 of those > HITs maps into M IP addresses. (I think this is what the outcome of > the API discussion at the last IETF was, right?) > > The question now is how we fit these two bindings into the current > DNS. Actually I thought we can't fit Type 1 HIT to IP address mapping anywhere with the current WG charter; DNS doesn't allow to store flat identifiers, and DHT stuff belongs to the RG. > The proposal you mention basically maps each FQDN into an > unstructured set of both its associated IP addresses and HITs, and > then uses a new protocol to figure out which HIT goes with which IP > addresses. >From my personal perspective, this is not a new protocol, but rather the same opportunistic mode we already have, augmented/ameliorated by using stuff which was put in the DNS, buying us as much security as non-opportunistic mode. > This seems awfully complex, especially considering that the RG > currently seems to lean towards relocating the HIT-to-IP binding > into a second resolution system, maybe based on DHTs. I don't feel it is complex, rather I found this solution one of the simplest we can have with the current WG charter items. After all it is just saying to run opportunistic mode if several HIs/IPs are bound to a single FQDN. But perhaps I'm just plain wrong... Also notes that the current base spec allows to sends multiple I1 in parallel, so you MAY initiate to multiple locators, then presumably get multiple R1s from each of the available HIs, allowing you to pick the one you want. > Another more complex - but also more powerful - approach may be to > create a second DNS tree for HITs, i.e., simulate the eventual DHT > lookup service using the DNS. Under this approach, you'd go to the > DNS twice to initiate communication, once to look up the HITs that > go with a FQDN, and a second time to look up the IP addresses that > go with the one HIT you picked from the first result. This would work, but only for Type 2 HITs which you can lookup in the DNS (using the HIT.ARPA reverse tree). Others? --julien From pekkas@netcore.fi Thu Nov 11 12:18:00 2004 From: pekkas@netcore.fi (Pekka Savola) Date: Thu Nov 11 12:18:00 2004 Subject: [Hipsec] Re: HIP over STUN ad hoc meeting on Thursday (tomorrow) at 9am In-Reply-To: <4192966F.4080201@netlab.nec.de> References: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> <4192966F.4080201@netlab.nec.de> Message-ID: On Wed, 10 Nov 2004, Lars Eggert wrote: > Given that it's supposedly already in WinXP, this may ease HIP > deployment. (I do not know if there are IPR issues associated with > teredo.) > > http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx There's an IETF spec just past IETF LC on this, you know ;-) Microsoft has a patent application and has offered RF terms. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From lars.eggert@netlab.nec.de Thu Nov 11 12:18:03 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Nov 11 12:18:03 2004 Subject: [Hipsec] Re: HIP over STUN ad hoc meeting on Thursday (tomorrow) at 9am In-Reply-To: References: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> <4192966F.4080201@netlab.nec.de> Message-ID: <4192C466.3010108@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms050908030409030702020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Wed, 10 Nov 2004, Lars Eggert wrote: > >> Given that it's supposedly already in WinXP, this may ease HIP >> deployment. (I do not know if there are IPR issues associated with >> teredo.) >> >> http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx > > There's an IETF spec just past IETF LC on this, you know ;-) > Microsoft has a patent application and has offered RF terms. Yeah, sorry, I just copied the first link that came up in Google... Lars -- Lars Eggert NEC Network Laboratories --------------ms050908030409030702020109 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 NDExMTEwMTQ2MTRaMCMGCSqGSIb3DQEJBDEWBBRS/XAnkgQe5qV+2puyl6iSnRlYRDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQAnM0m+hL5KgK8nVn0Kqyd9rXMTKdxtONHwglzpmQyadbeZ CPtRvFux4M/KSXuid56kpnZJ+AGF9paAdReB6qUbvu6qlaRwr1xwmdF8hHDQnvsAGD0Cb6Tt C6iKmnI+Y38F1H1woxbWFY2pVP+f5jIl6OIElRcNYK1oyGgCtsUxv8U5BJVWwG9c/nIfJDm+ yqOsPaNE+heCN9VFzuE1t/kYhPejQoMDmi2bss4GwObXMZIPsxMlk50QbWedSH2pAlIn9Jpn TXtjYLz4XqySky8mmssyaVx0WqIehNg4gLj6m2VfqZDoGmqU1rGc+qJNFiBM1asC6NmSyhlP FZKtpo0nAAAAAAAA --------------ms050908030409030702020109-- From pekka.nikander@nomadiclab.com Thu Nov 11 12:18:05 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Nov 11 12:18:05 2004 Subject: [Hipsec] HIP over STUN at Monrow West In-Reply-To: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <259A2A1E-335B-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: > As agreed before, the HIP over STUN ad hoc meeting will be > tomorrow (Thursday) morning at 9am. I have asked for a room > but I don't know yet if we will get one. Hence, let's meet > at the IETF registration desk at 9am, and then go somewhere. We got Monroe West. You can go directly there, but I'll also pick up people from the registration desk. --Pekka From pekka.nikander@nomadiclab.com Thu Nov 11 14:45:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Nov 11 14:45:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <41927387.9010600@netlab.nec.de> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> Message-ID: <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> > The proposal you mention basically maps each FQDN into an unstructured > set of both its associated IP addresses and HITs, and then uses a new > protocol to figure out which HIT goes with which IP addresses. There is no need for a new protocol. Just trying out repeatedly or using opportunistic mode is enough. > This seems awfully complex, especially considering that the RG > currently seems to lean towards relocating the HIT-to-IP binding into > a second resolution system, maybe based on DHTs. Actually, IMHO, what Erik and I proposed is the *simplest* possible way of doing this without introducing new infrastructure. > A much simpler stopgap may be to simple declare that until we have the > support infrastructure in place, we mandate a 1:1 binding from FQDNs > to HITs. Would we lose any critical functionality with this? That was ruled out as wrong semantics at the WG meeting. > Another more complex - but also more powerful - approach may be to > create a second DNS tree for HITs, i.e., simulate the eventual DHT > lookup service using the DNS. That would be awfully complex, and IMHO not worth the effort. --Pekka From pekka.nikander@nomadiclab.com Thu Nov 11 14:47:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Nov 11 14:47:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <200411111646.37650.julien.laganier@sun.com> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> <200411111646.37650.julien.laganier@sun.com> Message-ID: <60574905-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> > Also notes that the current base spec allows to sends multiple I1 in > parallel, so you MAY initiate to multiple locators, then presumably > get multiple R1s from each of the available HIs, allowing you to pick > the one you want. Right. Alternatively, you can just send multiple I1s to the same IP, but with different HITs, if you please. --Pekka From lars.eggert@netlab.nec.de Thu Nov 11 15:04:00 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Nov 11 15:04:00 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <4193D660.8050708@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms080403040405020301010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka, don't get me wrong, I'm not strongly opposed to the proposed approach. I'm raising these questions - this one, as well as the one about teredo during the PATH discussion - to help us more fully evaluate all options as we go for forward. In my view, we as a group have a tendency to go for specific implementation approaches a little too quickly; some more vetting may be useful. Pekka Nikander wrote: >> The proposal you mention basically maps each FQDN into an unstructured >> set of both its associated IP addresses and HITs, and then uses a new >> protocol to figure out which HIT goes with which IP addresses. > > There is no need for a new protocol. Just trying out repeatedly or using > opportunistic mode is enough. It's a change not to the HIP protocol on the wire but to the state machines that exchange these messages. >> A much simpler stopgap may be to simple declare that until we have the >> support infrastructure in place, we mandate a 1:1 binding from FQDNs >> to HITs. Would we lose any critical functionality with this? > > That was ruled out as wrong semantics at the WG meeting. I'd agree that the semantics are *limited*, because the approach can't support hosts that have multiple identities, but I wouldn't call them wrong. Would we lose any critical functionality, i.e., would we lose support for a killer app without supporting multiple identities per host from the beginning? >> Another more complex - but also more powerful - approach may be to >> create a second DNS tree for HITs, i.e., simulate the eventual DHT >> lookup service using the DNS. > > That would be awfully complex, and IMHO not worth the effort. Well, we're creating a second tree for HIT-to-FQDN reverse lookups anyway... Lars -- Lars Eggert NEC Network Laboratories --------------ms080403040405020301010106 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 NDExMTEyMTE1MTJaMCMGCSqGSIb3DQEJBDEWBBQFlrBZIAmqFDTysefslFTSCyyzfTBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQBKksRVytnn+7NypcVYWkm17hwOGxGBKCFRMq84qWL7RZU+ 4mjL5fCcBPDNXIZIqL0QCV0kzNTPf0A08D8hgPKIQQbM+6qvIYJujOC4ictIXxfsnB8Kmwg2 MWjdx0lXRP4P65T0Xbn0g7RGtr2W+lSmnDdPMwBcmF43i6LnevcSG7ARbOoDi5FNYU7uPQ6D uA2EdwBBsPvQ0xVK5B4IHNZ9UQ+X35r76Ei6+68FlXHwPX6LXalB0AoxxyHxKV8QEtTbznRz 0Vxh/sz0PIY/xHnFinhYIj2JfNeNT73cJZNBrYyVQIeB81hAFpEKSUGqsVBdmZa2+9dLWC29 Eyb3aGnvAAAAAAAA --------------ms080403040405020301010106-- From pekka.nikander@nomadiclab.com Thu Nov 11 16:01:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Nov 11 16:01:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <4193D660.8050708@netlab.nec.de> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> <4193D660.8050708@netlab.nec.de> Message-ID: Lars, > I'm raising these questions - this one, as well as the one about > teredo during the PATH discussion - to help us more fully evaluate all > options as we go for forward. In my view, we as a group have a > tendency to go for specific implementation approaches a little too > quickly; some more vetting may be useful. Fair enough. But we must understand that such an attitude also slows you down, and I don't know if we need to slow down as long as we are doing experimental documents. IMHO, we are slow enough already now. But maybe I am more impatient that most people are. As long as we are not going for any standards track documents, I don't think that we have to be that specific what to "endorse", as we are not actually endorsing anything. In my mind, the most important things are - keep things simple, and - get things out to get operational experience. As we are chartered now, the only path to standards track documents is to complete the research group experiment report, and that requires real life data. I am hoping that we could get that data starting from the next year, and I still hope that we could complete the experiment in 2006. Or at least complete it in the sense that we get the experiment report written and submitted to the IESG. What comes to this particular case, I am all for *simplicity* here. >>> The proposal you mention basically maps each FQDN into an >>> unstructured set of both its associated IP addresses and HITs, and >>> then uses a new protocol to figure out which HIT goes with which IP >>> addresses. >> There is no need for a new protocol. > > It's a change not to the HIP protocol on the wire but to the state > machines that exchange these messages. Well, yes, but I don't see that as a large change. But it may require a change to the base spec, I agree. >>> A much simpler stopgap may be to simple declare that until we have >>> the support infrastructure in place, we mandate a 1:1 binding from >>> FQDNs to HITs. Would we lose any critical functionality with this? >> That was ruled out as wrong semantics at the WG meeting. > > I'd agree that the semantics are *limited*, because the approach can't > support hosts that have multiple identities, but I wouldn't call them > wrong. Well, it starts to sound like that you weren't in Monday's meeting. In the working group meeting on Monday I explicitly tried to propose that we mandate that there can be only one HIT per a domain name. Lots of folks, including Christian Huitema, Keith Moore, and 3-5 others whom I don't remember or whose name I don't know, objected. They explicitly told us that that would be the wrong semantics, that would have to be taken to the DNSEXT working group, and we just can't do that in the HIP WG. Actually we spend large fraction of the WG time on this. As far as I understood, the clear consensus in the room was the flat semantics. That is, if you have multiple HITs associated with the domain name, they must be understood as *equivalent*. It doesn't matter which one you use. You can use any. Hence, if you connect to one of the locators associated with the domain name, you must accept any of the HITs that you got. Of course, anything discussed at the face-to-face meeting is subject to further discussion on the mailing list, but in this particular case I don't see what we would get. If we define something else, it is highly likely that we get back to this at the next IETF, or at least when the document goes to the IESG. > Well, we're creating a second tree for HIT-to-FQDN reverse lookups > anyway... Are we? I wasn't aware of that. In which draft? --Pekka From lars.eggert@netlab.nec.de Thu Nov 11 16:28:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Nov 11 16:28:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> <4193D660.8050708@netlab.nec.de> Message-ID: <4193EA0F.5090105@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms020806050903030000000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka, Pekka Nikander wrote: > > Fair enough. But we must understand that such an attitude also slows > you down, and I don't know if we need to slow down as long as we are > doing experimental documents. IMHO, we are slow enough already now. > But maybe I am more impatient that most people are. > > As long as we are not going for any standards track documents, I don't > think that we have to be that specific what to "endorse", as we are not > actually endorsing anything. In my mind, the most important things are > > - keep things simple, and > - get things out to get operational experience. I agree, but I'd like to add that once a WG settles on things, they become hard(er) to change at a later time. Temporary solutions have a nasty tendency to become permanent. This is why I think we should try to be a little more deliberate in our decision-making, even though we "only" do experimental things at this time. ... > What comes to this particular case, I am all for *simplicity* here. On that, we fully agree, too. >>>> A much simpler stopgap may be to simple declare that until we have >>>> the support infrastructure in place, we mandate a 1:1 binding from >>>> FQDNs to HITs. Would we lose any critical functionality with this? >>> >>> That was ruled out as wrong semantics at the WG meeting. >> >> I'd agree that the semantics are *limited*, because the approach can't >> support hosts that have multiple identities, but I wouldn't call them >> wrong. > > Well, it starts to sound like that you weren't in Monday's meeting. In > the working group meeting on Monday I explicitly tried to propose that > we mandate that there can be only one HIT per a domain name. Lots of > folks, including Christian Huitema, Keith Moore, and 3-5 others whom I > don't remember or whose name I don't know, objected. They explicitly > told us that that would be the wrong semantics, that would have to be > taken to the DNSEXT working group, and we just can't do that in the HIP WG. I understood this differently. In my understanding, they were arguing that we cannot not force that the DNS contain only a single HIT entry per record, i.e., we cannot put constraints on the DNS, it has no mechanism to enforce this constraint, and should not. This is obviously true. However, within HIP, we can at this point declare that records with more than one HIT per record are *at this time* illegal *for HIP* and we will disregard them *for now*. This is *not* a change to the DNS. This is a HIP-local decision to interpret the results of DNS records in a specific way. Since they're "our" entries, we are free to make this decision. At a later time, we may *revoke* this restriction, i.e., allow multiple hits per FQDN in the DNS, and use whatever HIT-to-IP resolution we then have to figure out the set of IP addresses for a specific HIT chosen after a DNS lookup. > Actually we spend large fraction of the WG time on this. As far as I > understood, the clear consensus in the room was the flat semantics. > That is, if you have multiple HITs associated with the domain name, they > must be understood as *equivalent*. It doesn't matter which one you > use. You can use any. Hence, if you connect to one of the locators > associated with the domain name, you must accept any of the HITs that > you got. Ah, but once we do not use the IP addresses that the DNS returns to initiate communiction anymore but maybe use the HITs to look up IP addresses in a different resolution mechanism, that is no longer true, i.e., you can then expect to reach the host identity that you looked up at the IP address you picked. I'm not sure if I'm explaining this sensibly, and I need to run (meeting has ended.) Maybe we can discuss this in person later, else I will write something up tomorrow. > Of course, anything discussed at the face-to-face meeting is subject to > further discussion on the mailing list, but in this particular case I > don't see what we would get. If we define something else, it is highly > likely that we get back to this at the next IETF, or at least when the > document goes to the IESG. > >> Well, we're creating a second tree for HIT-to-FQDN reverse lookups >> anyway... > > Are we? I wasn't aware of that. In which draft? I thought in hip-dns, but I misinterpreted that one before. Let me re-read it carefully. Lars -- Lars Eggert NEC Network Laboratories --------------ms020806050903030000000309 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 NDExMTEyMjM5MTFaMCMGCSqGSIb3DQEJBDEWBBR+rXU5kqG5KwHtL6WHy/zTWlNccTBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQA5IDmOOt2M7KcK9jNibW8nXZIubVz7PG0KjTdwfflb20cI eO/EZHUqw88pfJgtVgx7vGrYe0XQjGD762hKmpYJTsmB7XAdpkeC4PovfNl2SIR5rSE++YVz 6MeSRhLVQNdz1eJad8ntc7TWONqyvCJqykEkcJp1lOk0hRsToF1LobxyNGglJcIKvi7SA/BU EZLN7/aHwR0X8RKNjwy0Whw7eBRIBHbUkXta8ZkGwuPca923UmWHs9JidkZpFWVNwyFeJILi KLy0qoZuw4atfz2VwhiBXIEx1Cir3s5HL902GA6DnhAeB5S/+bHAuYlgEa8qi9lb5xjj+LfB wxptxOnvAAAAAAAA --------------ms020806050903030000000309-- From pekka.nikander@nomadiclab.com Fri Nov 12 06:29:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Nov 12 06:29:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <4193EA0F.5090105@netlab.nec.de> References: <200411102038.15863.julien.laganier@sun.com> <41927387.9010600@netlab.nec.de> <310454B7-3424-11D9-A88A-000D9331AFB0@nomadiclab.com> <4193D660.8050708@netlab.nec.de> <4193EA0F.5090105@netlab.nec.de> Message-ID: <048CEC87-34A8-11D9-A88A-000D9331AFB0@nomadiclab.com> Lars, > I understood this differently. In my understanding, they were arguing > that we cannot not force that the DNS contain only a single HIT entry > per record, i.e., we cannot put constraints on the DNS, it has no > mechanism to enforce this constraint, and should not. This is > obviously true. Here we seem to agree. > However, within HIP, we can at this point declare that records with > more than one HIT per record are *at this time* illegal *for HIP* and > we will disregard them *for now*. This is *not* a change to the DNS. > This is a HIP-local decision to interpret the results of DNS records > in a specific way. Since they're "our" entries, we are free to make > this decision. Well, maybe so, but I certainly did not understand it so. Hence, it is certainly good to discuss this at the mailing list, if for nothing else to reconfirm. >> Actually we spend large fraction of the WG time on this. As far as I >> understood, the clear consensus in the room was the flat semantics. >> That is, if you have multiple HITs associated with the domain name, >> they must be understood as *equivalent*. It doesn't matter which one >> you use. You can use any. Hence, if you connect to one of the >> locators associated with the domain name, you must accept any of the >> HITs that you got. > > Ah, but once we do not use the IP addresses that the DNS returns to > initiate communiction anymore but maybe use the HITs to look up IP > addresses in a different resolution mechanism, that is no longer true, > i.e., you can then expect to reach the host identity that you looked > up at the IP address you picked. Yes and no. I agree that then you can expect to find the right IP for a given HIT directly. However, based on Monday's discussion, I still get the feeling that from an application point of view you should still consider the HITs to denote the same service, and therefore being equivalent in that sense. Considering implementation, I get the feeling that maybe we should go for somewhat loose language here, i.e., a number of SHOULD instead of MUSTs. I would suggest the following. It remains to be determined what of this belongs to the DNS draft, what to an appendix in the base spec. If a host receives multiple HITs in a response to a DNS query, those HITs MUST be considered to denote a single service, and be semantically equivalent from that point of view. When initiating a base exchange with the denoted service, the host SHOULD be prepared to accept any of HITs as the peer's identity. A host MAY implement this by using the opportunistic mode (destination HIT null in I1), or by sending multiple I1s, if needed. In particular, if a host receives multiple HITs and multiple IP addresses in response to a DNS query, the host cannot know how the HITs are reachable at the listed IP addresses. The mapping may be any, i.e., all HITs may be reachable at all of the listed IP addresses, some of the HITs may be reachable at some of the IP addresses, or there may even be one-to-one mapping between the HITs and IP addresses. In general, the host cannot know the mapping and MUST NOT expect any particular mapping. It is RECOMMENDED that if a host receives multiple HITs, the host SHOULD first try to initiate the base exchange by using the opportunistic mode. If the returned HIT does not match with any of the expected HITs, the host SHOULD retry by sending further I1s, one at time, trying out all of the listed HITs. If the host receives an R1 for any of the I1s, the host SHOULD continue to use the successful IP address until an R1 with a listed HIT is received, or the host has tried all HITs, and try the other IP addresses only after that. A host MAY also send multiple I1s in parallel, but sending such I1s MUST be rate limited to avoid flooding. How does that sound? Any comments? --Pekka From pekka.nikander@nomadiclab.com Mon Nov 15 05:29:04 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 15 05:29:04 2004 Subject: [Hipsec] Pekka Nikander's personal view on HIP related discussions at DC Message-ID: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> Folks, This collection of notes provides a _personal_ point of view to the discussions that I participated to during the DC meeting. Most probably contains some controversial issues; if you want to discuss those, PLEASE DO START A NEW THREAD and make sure that you redirect your responses to the appropriate list, either WG or RG. Thank you for keeping the mailing list discussions organised. Outline/Summary =============== - A lowest location-independent layer of identification - A and B, or the value of non-secure identifiers - What is core HIP? - DNS semantics - PATH, or HIP NAT traversal - Extending the idea of locator - Separation of signalling and data A lowest location-independent layer of identification ===================================================== In the good olde days, it was possible to use IPv4 addresses as universal identifiers for reaching *any* host in the Internet. As argued in more detail in the architecture document, this had a great value, just as such. Furthermore, this value has now been lost by the introduction of NATs, firewalls, IPv4 and IPv6 in parallel, mobility, address-based multi-homing, and a plethora of other things that break the "end-to-end", in some sense. Currently, people are trying to fix the situation by introducing new location-independent name spaces. Today, SIP identifiers are probably the most prominent example of this. However, these new identifiers tend to be located at the application layer, and tend to be, at least to an extent, application specific. If we could engineer and *deploy* a new *lowest* layer that provides universal, location-independent identifiers, that might re-establish the end-to-end connectivity that we used to have. While SIP provides such a service in a limited way, it might not be at the right place in the stack. On the other hand, there seems to be more momentum currently behind SIP, and in the usual Betamax vs. VHS fashion, SIP may be good enough so that few if any people bother even to try HIP. Punch line: Let's make HIP to go through current middle boxes at least as well as SIP does! A and B, or the value of non-secure identifiers =============================================== Right now, HIP seems to provide two "services" at its core. It aims to provide identifiers that A. have a cryptographically strong binding to a public key, and B. have a location-independent end-to-end semantics, at the lowest possible layer in the stack. There might be some value in separating A and B, and allowing upper layers to select either A+B or just B. B would provide enough security just to protect innocent bystanders from flooding and other related attacks that might be created by B itself. A+B, on the other hand, would provide the full package, i.e., that "You know whom you are talking to", where whom is defined by the public key. That is, you know that you are talking to whoever/whatever possesses (a copy of) the private key corresponding to the public key that you are using a reference. Punch line: Let's make sure that *someone* (multi6?) provides plain B, too. What is core HIP? ================= An important question raised on Saturday's workshop was that of what is "core" to HIP? In a way, this was a reaction to people using the term "HIP" to denote anything that is taking place at the working or research groups. That seems to be confusing. Hence, we should define in specific terms what are the fundamental properties of HIP and what are features that are build on the top of that. As a starting point, I would propose the following: - A+B, from above, is core - being the *lowest* location-independent layer is core - the *idea* of location-independence (such as in middle box traversal) is core - the specific mechanisms for traversing specific middle boxes are NOT core - the *idea* of location-independence (such as in mobility) is core - mobility and multi-homing, as defined in the mobility and multi-homing draft, are NOT core - even the idea of rendezvous is NOT core but just as something that is needed for location-independence The fact that HIP will eventually require us to reconsider the placement of various functions, such as congestion control, in the stack, is a feature and not a bug. Hence, it is a direct consequence of what is core to HIP. Punch line: Use "lowest location-independent" as Occam's razor! DNS semantics ============= Today, a (leaf) DNS name defines a service, not a host. In many cases, the same service is provided by many hosts. The current practise is to list the IP addresses of all of the hosts providing to that service under the given DNS name. This is the semantics that HIP must conform to. There is a separate thread on this on the WG mailing list, so no more on this here. Punch line: Don't tell me what to put in my DNS! Preferred Alternatives to Tunnelling HIP (PATH) =============================================== I have changed my mind on HIP legacy NAT traversal. Two years ago I opposed it on architectural bases. A year ago I would not have done it myself but didn't oppose it any more. Now I am doing it. To make HIP the lowest location-independent layer in today's networks, we must make HIP to go through current NATs and firewalls. While making pinholes through firewalls seems like an arms race, there is no question in the value of making HIP to go through current "convenience" NATs. Those NATs are primarily there to solve the address space problem, and there are a hoard of applications that already make it possible to open a connection to a host behind a firewall. STUN, ICE and other specifications already define how you should do that, for your application. Let's make this application independent, allowing you to use both existing and future applications without having to worry about NATs. Given that we can directly employ the mechanisms in STUN and ICE, this seems to be a relatively easy piece of work, now. That might not have been the case two years ago. In the future, we can probably lean even more to the work in produced by the BEHAVE and other working groups, without spending too much cycles on making this clean and mean. Basically, we agreed to write two drafts: 1. Packet formats for HIP over UDP and UDP as locator. 2. A document specifying a STUN-server like HIP rendezvous server, and the protocols that you use to register to the server and making HIP connections to the host behind the NAT with the help of such a server. Both documents should be relatively short, as they can mostly rely on work done elsewhere. Punch line: Make UDP based NAT traversal a trivial combination of methods developed elsewhere. What is a locator? ================== As a starting point, HIP was designed to function on the top of the two versions of IP, providing connectivity over both of them. Unfortunately, IPv4 does not provide end-to-end connectivity today. Instead, one must use various kinds of hacks, like tunnelling other protocols on the top of UDP. To keep the HIP architecture relatively clean, it looks preferable to model all the different means of providing end-to-end connectivity as locators. That is, whenever there is an "address", i.e. a piece of information that allows one to make a connection, this is modelled as a locator. The first such locator type to be defined would be for HIP-over-UDP tunnelling. Basically, this requires one to convey information about IP addresses and UDP ports, and their usage; should a given port be used for HIP traffic, for ESP traffic, or for both? If the latter, how exactly one should determine whether a received packet is a HIP or an ESP packet? Hence, to me it looks like that we want to generalise the notion of locator, making HIP an universal non-tunnelling tunnelling protocol. That is, providing HIP with the generic hooks that allow HIP to traverse all the imaginable kinds of protocols, providing the "HIP connectivity service" on the top of that. Note that while we use here tunnelling like mechanisms, this is not really tunnelling in the sense that we are providing something more than what is available below the tunnel, the A+B property from above, and we also provide the property of mobility across these various tunnelling methods. As a result, I think that we should define an extensible locator data type, to be used the REA payload. Additionally, it *might* make sense to define a new DNS resource record that allows one to store these additional locators into the DNS. OTOH, my current feeling is that it is too early to propose the new DNS resource record. We might as well try to get some operational experience with rendezvous and mobility based NAT traversal mechanisms first. Punch line: HIP over Anything and Everything (HAE) Separation of signalling and data ================================= The way HIP is currently defined provide a convenient way of separating signalling and data traffic. Basically, host-to-host signalling traffic is carried within the HIP protocol while data traffic is carried within the ESP protocol. In the future, I surmise that we will support other data protocols but ESP, too. As we now aim to support legacy NAT traversal, we probably need to provide some more flexibility on this. For example, we may want to provide one UDP port for HIP traffic while using another one for ESP traffic. More generally, we may want to express that one particular locator is only valid for HIP traffic while the other locator may be used for ESP traffic. Even more generally, we probably want to add capabilities to locators, allowing us to express explicitly what each locator is good for. The telecom people will love this, I am sure. Finally they can understand TCP/IP, at least when HIP is used :-) Punch line: Let's make HIP appealing both to Internet and Telecom folks :-) --Pekka From pekka.nikander@nomadiclab.com Mon Nov 15 07:32:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 15 07:32:00 2004 Subject: [Hipsec] Generic locator data for REA Message-ID: <62ADC1C0-370C-11D9-A88A-000D9331AFB0@nomadiclab.com> Below is my initial proposal for the new locator data type, to be carried by the REA payload. Initial design constraints: - support extensibility - support variable length data - keep 64-bit alignment - support locator roles, i.e., what a locator can be used for - optimise support for the most common locator types - IPv4 address - IPv6 address - IPv4 address + UDP port number Base locator header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator type | Flags |P| Locator roles |H|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Locator type: 0 Reserved 1 IPv4 address 2 IPv6 address 3 IPv4 address and UDP port There must exist an explicit specification and packet formats for any new locator type, such as HIP over TCP, HIP over HTTP, etc.. Flags: P Preferred locator Locator roles all zero: Reserved H These locator(s) can be used for sending HIP packets to the recipient. E These locator(s) can be used for sending ESP packets to the recipient. For IPv4, the base header is followed by 0-N IPv4 addresses, each taking 4 bytes. The number of addresses is determined by the parameter length. For IPv6, the base header is followed by 0-N IPv6 addresses, each taking 16 bytes. The number of addresses is determined by the parameter length. For IPv4 UDP encapsulation, the base header is followed by 0-N data structures of the following format. The number of structures is determined by the parameter length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Role XOR mask | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Role XOR mask is a mask that is applied to the Locator roles, allowing the bits to be flipped for this specific locator, and the Port is the UDP port. --Pekka From jari.arkko@piuha.net Mon Nov 15 09:47:00 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon Nov 15 09:47:00 2004 Subject: Locators (Was: Re: [Hipsec] Pekka Nikander's personal view on HIP related discussions at DC) In-Reply-To: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <4198D1DF.8090403@piuha.net> Pekka Nikander wrote: > What is a locator? > ================== > > As a starting point, HIP was designed to function on the top of the two > versions of IP, providing connectivity over both of them. > Unfortunately, IPv4 does not provide end-to-end connectivity today. > Instead, one must use various kinds of hacks, like tunnelling other > protocols on the top of UDP. > > To keep the HIP architecture relatively clean, it looks preferable to > model all the different means of providing end-to-end connectivity as > locators. That is, whenever there is an "address", i.e. a piece of > information that allows one to make a connection, this is modelled as a > locator. > > The first such locator type to be defined would be for HIP-over-UDP > tunnelling. Basically, this requires one to convey information about IP > addresses and UDP ports, and their usage; should a given port be used > for HIP traffic, for ESP traffic, or for both? If the latter, how > exactly one should determine whether a received packet is a HIP or an > ESP packet? > > Hence, to me it looks like that we want to generalise the notion of > locator, making HIP an universal non-tunnelling tunnelling protocol. > That is, providing HIP with the generic hooks that allow HIP to traverse > all the imaginable kinds of protocols, providing the "HIP connectivity > service" on the top of that. Note that while we use here tunnelling > like mechanisms, this is not really tunnelling in the sense that we are > providing something more than what is available below the tunnel, the > A+B property from above, and we also provide the property of mobility > across these various tunnelling methods. One aspect of the new locator concept is that location may not be just data; it may also be state somewhere in the network that has to be refreshed or it will expire. For instance, in IKEv2 NAT traversal you have to do keepalive to avoid the NAT forgetting that you have a connection through it. Note that if we are doing multihoming, this keepalive has to be kept not just for the current locator but also for the backup(s)! I wonder if we could generalize this somehow. Seems like a dynamically allocated HIP rendevouz server might also have soft state in the sense that it too needs to be reminded now and then that it should serve you. --Jari From pekka.nikander@nomadiclab.com Mon Nov 15 11:19:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 15 11:19:00 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec Message-ID: <2712DD07-372C-11D9-A88A-000D9331AFB0@nomadiclab.com> I know this is quite radical, but while pondering the generalised locator proposal I sent some minutes ago, my thoughts followed the following patter: - Most probably we want to include SPI in REA, since we may want to introduce multiple new SPIs in a single packet. - SPI and REA could be made a single packet type; the length field would tell which it is. But this would be ugly. - What if we made SPI optional, and defined that the base exchange should have either SPI or REA? And as a logical consequence of this, What if we split out all concerning ESP from the base specification, and make it a (mandatory) extension? That seems to take care of a lot of problems. Firstly, the SPI payload would really become an optional payload. Semantically, it would just be a shorthand for a REA when - the locator the one from the enclosing IP or UDP header - the locator lifetime is infinite - the roles include both HIP and ESP Secondly, that would allow us to better handle the problems with mixing re-keying and locator changes in a single UPDATE. Basically, the ESP extension specification would define a simple re-keying method, to be used when only that is used, and the mobility and multi-homing extension would define a more complicated re-keying method, to be used when multi-homing is applied. If we take this path, we should probably also rename the REA payload as LOC, for locators. Any opinions? --Pekka From pekka.nikander@nomadiclab.com Mon Nov 15 13:25:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 15 13:25:01 2004 Subject: [Hipsec] Re: Locators In-Reply-To: <4198D1DF.8090403@piuha.net> References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> <4198D1DF.8090403@piuha.net> Message-ID: >> To keep the HIP architecture relatively clean, it looks preferable to >> model all the different means of providing end-to-end connectivity as >> locators. That is, whenever there is an "address", i.e. a piece of >> information that allows one to make a connection, this is modelled as >> a locator. > > One aspect of the new locator concept is that location may > not be just data; it may also be state somewhere in the > network that has to be refreshed or it will expire. Right. > I wonder if we could generalize this somehow. Maybe we should add a field for expressing how often one needs to refresh the state. For a comparison, see Section 5.3.7 of ICE: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-03.txt > Seems like a dynamically allocated HIP rendevouz server > might also have soft state in the sense that it too needs > to be reminded now and then that it should serve you. Right, but my assumption has been that the HIP registration protocol (which will be split apart from the RVS draft) will take care of that. I have further assumed that the same mechanism will be applied to architected middle boxes. Hence, what remains to be solved is those Locators that create implicit state, such as NAT traversal. --Pekka From pekkas@netcore.fi Mon Nov 15 15:08:00 2004 From: pekkas@netcore.fi (Pekka Savola) Date: Mon Nov 15 15:08:00 2004 Subject: [Hipsec] Re: Locators In-Reply-To: References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> <4198D1DF.8090403@piuha.net> Message-ID: On Mon, 15 Nov 2004, Pekka Nikander wrote: >> Seems like a dynamically allocated HIP rendevouz server >> might also have soft state in the sense that it too needs >> to be reminded now and then that it should serve you. > > Right, but my assumption has been that the HIP registration > protocol (which will be split apart from the RVS draft) will take > care of that. I have further assumed that the same mechanism > will be applied to architected middle boxes. Hence, what remains > to be solved is those Locators that create implicit state, such > as NAT traversal. It is also worth noting that NAT traversal functions change such rendezvous servers, to, basically, servers having to relay initial packets of a session. Some who would be willing to deploy a DNS-like service may be unwilling to deploy network connectivity service. The tricky part about NAT traversal is that you'll need to channel the incoming connectivity requests through a "rendezvous server", which has keep-alive state with every client it is servicing -- and the state must be refreshed with the interval of O("60 seconds") so that the data channel between HIP node behind the NAT box and the rendezvous server (and the HIP peers) remains open. And when the incoming connection occurs, what remains is a rather complex and long set of signalling exchanges to set up a "shortcut path" which doesn't go through the rendezvous server, provided that that's what you want. (And if you don't want that, it's even more question of, "who would be willing to deploy such a service?") All in all, that's a reasonably large amount of stuff to be done. Luckily enough, there is no necessity to reinvent the wheel, as e.g. Teredo should fit the bill if you just assume it's OK to use IPv6 if you're behind a NAT. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jeffrey.m.ahrenholz@boeing.com Mon Nov 15 16:33:00 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Mon Nov 15 16:33:00 2004 Subject: [Hipsec] IETF61 interoperability tests Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F15@xch-nw-09.nw.nos.boeing.com> Hi folks, During the 61st IETF meeting in WA D.C., Boeing (http://hipserver.mct.phantomworks.org/) and HIPL (http://hipl.hiit.fi/hipl/) did some interoperability testing. Here is a summary of testing: draft-ietf-hip-base-00 was tested OK. - NULL and 3DES HMAC-SHA1 transforms were tested - random IVs were tested - base exchanges were IPv6-only (Boeing supports IPv4, HIPL IPv4 support is coming soon) - base exchange was successful between HIPL and Boeing's HIP for Windows XP (without ESP support) draft-ietf-hip-mm-00 testing was mostly successful, but incomplete. - UPDATE packet exchange correct - rekeying without new DH works - some draft ambiguities were raised - While readdressing works for both implementations with themselves, Boeing doesn't create the new SAs when HIPL readdresses, and further testing is needed From jeffrey.m.ahrenholz@boeing.com Mon Nov 15 16:35:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Mon Nov 15 16:35:01 2004 Subject: [Hipsec] FW: I-D ACTION:draft-yan-hip-ike-h-00.txt Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA270427A8A6@xch-nw-09.nw.nos.boeing.com> FYI, for those not already subscribed to i-d-announce. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, November 15, 2004 12:37 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-yan-hip-ike-h-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A proposal to replace HIP base exchange with=20 IKE-H method Author(s) : R. Yan, et al. Filename : draft-yan-hip-ike-h-00.txt Pages : 10 Date : 2004-11-15 =09 This document describes using version 2 of the Internet Key Exchange=20 (IKE) to replace current HIP protocol's base exchage. IKE-H is an=20 extension of IKE used for performing mutual authentication and=20 establishing and maintaining security associations. It can be used=20 to provide continuity of communications between not only those hosts independent of the networking layer but also security gateway.=20 IKE-H is an extension to the IKEv2. It supports HIP identity=20 authentication method and the establishment of keying material,=20 which is then used by IPsec Encapsulated Security payload (ESP) to=20 establish a two-way secure communication channel between the hosts=20 or security gateway. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yan-hip-ike-h-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 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-yan-hip-ike-h-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-yan-hip-ike-h-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From pekka.nikander@nomadiclab.com Tue Nov 16 02:55:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Nov 16 02:55:00 2004 Subject: [Hipsec] Re: Locators In-Reply-To: References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> <4198D1DF.8090403@piuha.net> Message-ID: > It is also worth noting that NAT traversal functions change such > rendezvous servers, to, basically, servers having to relay initial > packets of a session. Well, now I am confused. According to the HIP architecture document, a HIP rendezvous server is used to forward (relay) the initial control packets, i.e., at least I1. Hence, I don't understand how adding NAT support would change the rendezvous other than requiring the rendezvous server to support HIP over UDP. > Some who would be willing to deploy a DNS-like service may be > unwilling to deploy network connectivity service. Would you please elaborate. I don't understand your comment. > The tricky part about NAT traversal is that you'll need to channel the > incoming connectivity requests through a "rendezvous server", which > has keep-alive state with every client it is servicing -- and the > state must be refreshed with the interval of O("60 seconds") so that > the data channel between HIP node behind the NAT box and the > rendezvous server (and the HIP peers) remains open. Right. Again, as far as I understand the situation, there are two differences here between a non-NAT and NAT-supporting rendezvous servers: - support of HIP-over-UDP (PATH) packet format - shorter registration lifetime for the NAT-supporting RVS The latter is a mere configuration issue; rendezvous is designed to be lease-based anyway. In the case of NAT, you just get a very short time lease. > And when the incoming connection occurs, what remains is a rather > complex and long set of signalling exchanges to set up a "shortcut > path" which doesn't go through the rendezvous server, provided that > that's what you want. I don't see how this is so complex, but maybe I'm just naive here. See slide 16 of http://hip.piuha.net/meetings/ietf61/slides/pres-ietf61-ad-hoc-nats- nikander.pdf I think those on the PATH ad hoc meeting on Thursday morning pretty much agreed that it is the way to go. Again, I may not understand the issue properly, but to me it looks like that the overall complexity of the base exchange does not change at all. The only difference is that the first three packets (I1, R1, I2) are relayed by the RVS, which should not be *that* hard given that it already relays I1 and R1, and the last packet (R2) is used to drill the pinhole for forthcoming ESP traffic. Yes, we probably need to add keep-alives for ESP, but that is part of ESP NAT-T already, isn't it? > (And if you don't want that, it's even more question of, "who would be > willing to deploy such a service?") I really fail to see where the complexity creeps in. I just fail to understand how NAT-supporting RVS is that much more complex than one that doesn't support. If you doubt people willing to adopt RVS servers in the first place, then I don't have much to argue. That is indeed a good question. > All in all, that's a reasonably large amount of stuff to be done. > Luckily enough, there is no necessity to reinvent the wheel, as e.g. > Teredo should fit the bill if you just assume it's OK to use IPv6 if > you're behind a NAT. Right. Some people in fact would favour Teredo, and I think it is a good solution. OTOH, it doesn't require any new specs or anything new, at least in principle. Just do it, if your OS supports Teredo and if you are willing to use the currently sponsored servers. --Pekka Nikander From pekkas@netcore.fi Tue Nov 16 07:25:01 2004 From: pekkas@netcore.fi (Pekka Savola) Date: Tue Nov 16 07:25:01 2004 Subject: [Hipsec] Re: Locators In-Reply-To: References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> <4198D1DF.8090403@piuha.net> Message-ID: Hi, On Tue, 16 Nov 2004, Pekka Nikander wrote: >> It is also worth noting that NAT traversal functions change such rendezvous >> servers, to, basically, servers having to relay initial packets of a >> session. > > Well, now I am confused. According to the HIP architecture document, a HIP > rendezvous server is used to forward (relay) the initial control packets, > i.e., at least I1. Hence, I don't understand how adding NAT support would > change the rendezvous other than requiring the rendezvous server to support > HIP over UDP. Hmm, sorry, I seem to have had a terminology mismatch. I recalled that a rendezvous server would be needed for establishing communications (instead of using, say, DNS), but maybe it isn't -- and you can deploy HIP without such a box. >> And when the incoming connection occurs, what remains is a rather complex >> and long set of signalling exchanges to set up a "shortcut path" which >> doesn't go through the rendezvous server, provided that that's what you >> want. > > I don't see how this is so complex, but maybe I'm just naive here. See slide > 16 of http://hip.piuha.net/meetings/ietf61/slides/pres-ietf61-ad-hoc-nats- > nikander.pdf I think those on the PATH ad hoc meeting on Thursday morning > pretty much agreed that it is the way to go. Again, I may not understand the > issue properly, but to me it looks like that the overall complexity of the > base exchange does not change at all. The only difference is that the first > three packets (I1, R1, I2) are relayed by the RVS, which should not be *that* > hard given that it already relays I1 and R1, and the last packet (R2) is used > to drill the pinhole for forthcoming ESP traffic. Are you making the assumption that only one end of the communication is behind a NAT, and not both of them? It's certainly relatively simple if you can assume that you're initiating towards a non-NATted network, because there's MUCH less state to worry about, but if you need to care about NATs at the both ends (which is likely), and the case where the hosts behind those NATs use different rendezvous servers, it'll get quite tricky. It wasn't 100% clear from the slides whether you had considered this case or not. Are you also assuming that the hosts behind a NAT obtain dedicated "rendezvous service" from someone, and it can't (practically) be just an open service in the Internet? (Like Teredo servers and 6to4 relays are, nowadays.) Just trying to ensure you don't fall to the same pitfalls STUN/ICE people did, and v6ops also did.. > If you doubt people willing to adopt RVS servers in the first place, then I > don't have much to argue. That is indeed a good question. Ok, this was my initial concern about adding too much weight to the RVS for relaying messages; that's OK, though the point about NAT traversal still stands. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekka.nikander@nomadiclab.com Tue Nov 16 08:09:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Nov 16 08:09:01 2004 Subject: [Hipsec] NAT details (was Locators) In-Reply-To: References: <415EB47C-36FB-11D9-A88A-000D9331AFB0@nomadiclab.com> <4198D1DF.8090403@piuha.net> Message-ID: [Updating subject line and removing Jari from CC, assuming that he can get this from list.] >>> It is also worth noting that NAT traversal functions change such >>> rendezvous servers, to, basically, servers having to relay initial >>> packets of a session. >> >> Well, now I am confused. According to the HIP architecture document, >> a HIP rendezvous server is used to forward (relay) the initial >> control packets, i.e., at least I1. Hence, I don't understand how >> adding NAT support would change the rendezvous other than requiring >> the rendezvous server to support HIP over UDP. > > Hmm, sorry, I seem to have had a terminology mismatch. I recalled > that a rendezvous server would be needed for establishing > communications (instead of using, say, DNS), but maybe it isn't -- and > you can deploy HIP without such a box. Right, you can deploy HIP without rendezvous server. Without NAT, rendezvous servers are needed to support fast mobility (so that you can't update your DNS entries) and simultaneous movement (the case when readdressing packets cross each other). However, you may want to use then as an alternative for DNS, if you are willing to. With NAT, of course, the situation changes as they make it possible to contact hosts that are behind NATs. In a way, the base (or core) HIP architecture does not say exactly how to convey the very first packets end-to-end. You may use DNS, you may use simple rendezvous, or you may use something more complex, like Hi3. At its core, HIP is very much end-to-end. It is just the complications with the current infrastructure that require us to deploy some sort of rendezvous. Hence, it looks appropriate to match the rendezvous to the network reality. > Are you making the assumption that only one end of the communication > is behind a NAT, and not both of them? Well, yes and no. That may be where you get most benefit. Or maybe not. Anyway, if one of the NATs is not symmetric but even a port restricted cone, you can still establish an end-to-end connection fairly simply. For the two symmetric NATs in a row case, there may not be any other possibility than to use a relay. That case was, more or less, covered by the previous slide (1 of 3). > It's certainly relatively simple if you can assume that you're > initiating towards a non-NATted network, because there's MUCH less > state to worry about, but if you need to care about NATs at the both > ends (which is likely), and the case where the hosts behind those NATs > use different rendezvous servers, it'll get quite tricky. I admit that it gets tricky with two symmetric NATs. And I admit that, based on what I've heard, it is sometimes very hard to tell whether your NAT is symmetric or not. > Are you also assuming that the hosts behind a NAT obtain dedicated > "rendezvous service" from someone, and it can't (practically) be just > an open service in the Internet? (Like Teredo servers and 6to4 relays > are, nowadays.) Of course it can just open a connection to Internet. That should be, by all means, trivial. That's why it is not in the slides. Or maybe there are some pitfalls there, too? The tricky case is when you open a connection from the Internet to the NATted host, or, as you point out, when there are two NATs involved. > Just trying to ensure you don't fall to the same pitfalls STUN/ICE > people did, and v6ops also did.. Thanks, I appreciate that. I am still learning the corner cases. I think this discussion is important. And, BTW, yes, I agree that a rendezvous server that is willing to pass the initial packets back and forth may not be willing to pass regular data traffic. --Pekka Nikander From thomas.r.henderson@boeing.com Wed Nov 17 11:44:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Nov 17 11:44:01 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C061405AB@xch-nw-27.nw.nos.boeing.com> =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, November 15, 2004 12:31 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Resolving the SPI question, or splitting=20 > ESP out of base spec >=20 > And as a logical consequence of this, >=20 > What if we split out all concerning ESP from the base > specification, and make it a (mandatory) extension? >=20 As I just posted on the thread on the RG list, I agree that this does seem consistent if one adopts the viewpoint that ESP is not "core" HIP. There have been various suggestions and proposals to consider HIP without ESP, for lightweight reasons (lightweight HIP) or because it conflicts/duplicates a more efficient encryption scheme (secure RTP). Also, regarding ESP, in section 11.5 of base spec the use of ESP NULL is a "SHOULD NOT", but there may be valid reasons to use just ESP authentication. I discussed this with Bob at the meeting and he said that he did not intend for ESP NULL to only be a debugging mode. Tom From thomas.r.henderson@boeing.com Wed Nov 17 20:33:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Nov 17 20:33:01 2004 Subject: [Hipsec] PATH (was HIP over STUN) meeting minutes Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06140682@xch-nw-27.nw.nos.boeing.com> Attached are some unofficial minutes of the ad hoc HIP over STUN meeting that was announced by Pekka on the list last week: http://honor.trusecure.com/pipermail/hipsec/2004-November/001115.html Preferred Alternatives for Tunneling HIP (PATH) meeting Unofficial minutes (compiled by Tom Henderson)=20 November 11, 2004 Announcement from Pekka: This is an ad hoc meeting for people interested in running HIP over NAT. It was not approved by any WG or AD as an official BOF, but the AD did give us a room. IETF NOTE WELL (RFC 3667) applies. Attendees: =20 ---------- Pekka Nikander Lars Eggert Tom Henderson Andrei Gurtov Jukka Ylitalo Petri Jokela Tero Kauppinen Nick Papadoglou Juergen Quittek Martin Stiemerling Robert Moskowitz Andrew McGregor Michael Richardson Julien Laganier Jeff Ahrenholz Miika Komu Mika Kousa Hannes Tschofenig Tim Shepard Jari Arkko James Kempf Pekka presented slides (to be posted at HIP WG supplemental page)=20 Goals: =20 - traverse legacy NATs - some firewalls but not all=20 - reachable behind NATs Discussion on whether we want a modified variant of STUN that is integrated with HIP, or just allow HIP to use whatever is available. Hannes Tschofenig: Interested in i) UDP HIP format, and ii) way for IPsec traffic to traverse. We should consider other ways besides STUN, for example, things being done for IKE. Michael Richardson: How much should we try to work on covering every case? Wondering if the set of networks that it doesn't work through should be considered off-limits (because there might be a reason that the administrator doesn't want it to work) Martin Stiemerling: Right, maybe NATs don't work for a purpose. Tom Henderson: I think we should just focus on the use cases that other WGs are worrying about. =20 Pekka: I would like to solve 80% of the cases, not 100%. Juergen Quittek: We run into problems when we try to integrate technology and merge things. STUN took a long time to define and get right. Maybe run STUN without integrating HIP with it. Julien Laganier: Noticed that VPN software often works over TCP, over port 80, so maybe consider that. Tom: Would like to not force STUN or RVS/STUN integration on people, but instead work on an approach that allows use of all possible=20 mechanisms (TURN, ICE) etc. Also SOCKS firewall traversal. Juergen: Yes, don't reinvent wheel, ADs will not like it if our draft doesn't reuse previous work here. Andrew McGregor: We should split the effort into two drafts: i) UDP packet formats and extensions to HIP parameters ii) Procedures for using Rendezvous Server, etc. =20 Tim Shepard: I think we should standardize escalation techniques for=20 finding NAT traversals, like how VPN software operates. Michael: Don't agree. Nothing stops client from doing different things. Does not work if both behind NAT. =20 Michael: (situation 2 in Pekka's slides)-- only ever use if you=20 have a symmetric NAT, but you should do this one because it is=20 more portable. Pekka: (responding to a question on packet formats, I think it was on the use of port numbers as a version number). Want to save 8 bytes, but also make it a bit ugly to discourage people from using this. Tim (and others): That will just discourage people from implementing it,=20 not using it. Pekka: Yes, but we have contradicting forces-- deployment, and keeping the architecture clean. =20 Jari Arkko: We are forgetting about multihoming, mobility in this=20 discussion. Need to refresh state in network if I have all these addresses. Andrew: (comment about locator format IPv4 format and pair of port numbers in the REA?) Lars: What about Teredo? Tom: OK except it doesn't support IPv4 only. Pekka: Most of implementors are in this room. Do you want to implement Teredo (no or few hands) or STUN (more hands). Michael: Although I am implementor, from a non-implementors point of view,=20 I was hoping that we did not focus on v4, because I see HIP as an avenue to encourage v6 adoption. Tom: I don't want to deprecate v4 because we are also focused on getting implementation experience on ID/locator split, from application perspective. Michael: I don't understand why you want to write all this code if=20 you have Teredo available. Also, STUN will get deployed. In favor of reusing existing techniques. Pekka: Maybe we form two design teams. =20 i) draft of packet formats over UDP, UDP-REA ii) draft of how to run a rendezvous server (meeting adjourned) From Julien.Laganier@Sun.COM Mon Nov 22 11:20:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Nov 22 11:20:01 2004 Subject: [Hipsec] Generic locator data for REA In-Reply-To: <62ADC1C0-370C-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <62ADC1C0-370C-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <200411221721.01917.julien.laganier@sun.com> Hi Pekka, On Monday 15 November 2004 14:43, Pekka Nikander wrote: > Below is my initial proposal for the new locator data type, > to be carried by the REA payload. I find this proposal very good. I have some questions, though: Is the sender of such header supposed to determine the the Locator=20 Lifetime of a specific (Address,Port) tuple when a NAT is present? If=20 so, is this determination supposed to occurs while registering with a=20 Rendezvous Server, or while communicating with the remote node? Thanks, =2D-julien =2D----------------------------------------------------------------- Base locator header: 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =A0 =A0 =A0 =A0 =A0 =A0 Type =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0Length =A0 =A0 =A0 =A0 =A0 =A0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SPI =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Locator Lifetime =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator type =A0| =A0 =A0Flags =A0 =A0|P| =A0 =A0 =A0 =A0 Locator roles = =A0 =A0 |H|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Locator type: =A0 =A00 =A0Reserved =A0 =A01 =A0IPv4 address =A0 =A02 =A0IPv6 address =A0 =A03 =A0IPv4 address and UDP port There must exist an explicit specification and packet formats for any new locator type, such as HIP over TCP, HIP over HTTP, etc.. =46lags: =A0 =A0P =A0Preferred locator Locator roles all zero: Reserved =A0 =A0H =A0These locator(s) can be used for sending HIP packets to the=20 recipient. =A0 =A0E =A0These locator(s) can be used for sending ESP packets to the=20 recipient. From pekka.nikander@nomadiclab.com Mon Nov 22 23:50:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Nov 22 23:50:00 2004 Subject: [Hipsec] Generic locator data for REA In-Reply-To: <200411221721.01917.julien.laganier@sun.com> References: <62ADC1C0-370C-11D9-A88A-000D9331AFB0@nomadiclab.com> <200411221721.01917.julien.laganier@sun.com> Message-ID: <099F32ED-3D0B-11D9-A799-000D9331AFB0@nomadiclab.com> >> Below is my initial proposal for the new locator data type, to be >> carried by the REA payload. > > I find this proposal very good. I have thought about this a little bit more, and I feel that my locator format proposal for premature. I'll try to send another message on that later today. > I have some questions, though: > > Is the sender of such header supposed to determine the the Locator > Lifetime of a specific (Address,Port) tuple when a NAT is present? If > so, is this determination supposed to occurs while registering with a > Rendezvous Server, or while communicating with the remote node? Well, this is a tricky question. In general, the question of how to to express a locator lifetime is not that easy. From an architectural point of view, we most probably do want to have explicit locator lifetime; most locators do have a to-the-peer local lifetime today anyway. It makes sense to deprecate locators when this lifetime expires, unless the peer renews the locator binding before that. The harder question is how to handle the state in the network. This seems to be trickiest with NATs, which tend to have pretty short memory, but it applies to other middle boxes, too. At this point of time, at least I don't have any good answer. Basically, my feeling is that I don't understand the situation well enough. Maybe we should have two lifetimes in a locator, one for the actual locator, i.e., how long the sending party is likely to "hold" that locator, and another for the network state, i.e., how often one must send keep-alives to keep the locator functioning. My guess is that the exact semantics and interpretation of the keep-alive field would be locator-type specific. --Pekka From Julien.Laganier@Sun.COM Thu Nov 25 03:43:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Nov 25 03:43:00 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <048CEC87-34A8-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <200411102038.15863.julien.laganier@sun.com> <4193EA0F.5090105@netlab.nec.de> <048CEC87-34A8-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <200411250944.09985.julien.laganier@sun.com> Hi Pekka, More below, On Friday 12 November 2004 13:40, Pekka Nikander wrote: > Lars, > > > I understood this differently. In my understanding, they were > > arguing that we cannot not force that the DNS contain only a > > single HIT entry per record, i.e., we cannot put constraints on > > the DNS, it has no mechanism to enforce this constraint, and > > should not. This is obviously true. > > Here we seem to agree. > > > However, within HIP, we can at this point declare that records > > with more than one HIT per record are *at this time* illegal *for > > HIP* and we will disregard them *for now*. This is *not* a change > > to the DNS. This is a HIP-local decision to interpret the results > > of DNS records in a specific way. Since they're "our" entries, we > > are free to make this decision. > > Well, maybe so, but I certainly did not understand it so. Hence, > it is certainly good to discuss this at the mailing list, if for > nothing else to reconfirm. FWIW, I am in favor of storing several HITs and IPs at the same FQDN in a flat manner. This allows for easier load balancing, and a couple of others features. > Considering implementation, I get the feeling that maybe we should > go for somewhat loose language here, i.e., a number of SHOULD > instead of MUSTs. I would suggest the following. It remains to be > determined what of this belongs to the DNS draft, what to an > appendix in the base spec. > > If a host receives multiple HITs in a response to > a DNS query, those HITs MUST be considered to denote > a single service, and be semantically equivalent > from that point of view. When initiating a base > exchange with the denoted service, the host SHOULD > be prepared to accept any of HITs as the peer's > identity. A host MAY implement this by using the > opportunistic mode (destination HIT null in I1), or by > sending multiple I1s, if needed. > > In particular, if a host receives multiple HITs and > multiple IP addresses in response to a DNS query, the > host cannot know how the HITs are reachable at the > listed IP addresses. The mapping may be any, i.e., > all HITs may be reachable at all of the listed IP > addresses, some of the HITs may be reachable at some > of the IP addresses, or there may even be one-to-one > mapping between the HITs and IP addresses. In general, > the host cannot know the mapping and MUST NOT expect > any particular mapping. > > It is RECOMMENDED that if a host receives multiple HITs, > the host SHOULD first try to initiate the base exchange > by using the opportunistic mode. If the returned HIT > does not match with any of the expected HITs, the host > SHOULD retry by sending further I1s, one at time, trying > out all of the listed HITs. If the host receives an > R1 for any of the I1s, the host SHOULD continue to use > the successful IP address until an R1 with a listed HIT > is received, or the host has tried all HITs, and try > the other IP addresses only after that. A host MAY > also send multiple I1s in parallel, but sending such > I1s MUST be rate limited to avoid flooding. > > How does that sound? Any comments? This text sounds fine to me. As to the question to what document it belongs, it appears to me that these issues are either: - specific to DNS, in which case the text belongs to the DNS draft. - impacting any combination of HIP with a 'flat lookup' service (i.e. returning a bunch of flats HITs and IPs), in which case the text belongs to the base protocol draft, and should be generalized to refer to "a flat lookup service (e.g. DNS)" instead of just "DNS". Comments? Thanks, --julien From lars.eggert@netlab.nec.de Thu Nov 25 10:04:00 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Nov 25 10:04:00 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <200411250944.09985.julien.laganier@sun.com> References: <200411102038.15863.julien.laganier@sun.com> <4193EA0F.5090105@netlab.nec.de> <048CEC87-34A8-11D9-A88A-000D9331AFB0@nomadiclab.com> <200411250944.09985.julien.laganier@sun.com> Message-ID: <41A5F439.9090909@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms090207030000030608010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Julien Laganier wrote: >> >>>I understood this differently. In my understanding, they were >>>arguing that we cannot not force that the DNS contain only a >>>single HIT entry per record, i.e., we cannot put constraints on >>>the DNS, it has no mechanism to enforce this constraint, and >>>should not. This is obviously true. >> >>Here we seem to agree. >> >>>However, within HIP, we can at this point declare that records >>>with more than one HIT per record are *at this time* illegal *for >>>HIP* and we will disregard them *for now*. This is *not* a change >>>to the DNS. This is a HIP-local decision to interpret the results >>>of DNS records in a specific way. Since they're "our" entries, we >>>are free to make this decision. >> >>Well, maybe so, but I certainly did not understand it so. Hence, >>it is certainly good to discuss this at the mailing list, if for >>nothing else to reconfirm. > > FWIW, I am in favor of storing several HITs and IPs at the same FQDN > in a flat manner. This allows for easier load balancing, and a couple > of others features. I've had some time to think on this approach since IETF and am starting to like it more than before. I'd still like to see if we give up any capabilities by going to this looser mapping between IPs and HITs, but this is no showstopper. Your proposal for the draft (cut to save some trees) is fine, too, both the text and the general mechanism. Lars -- Lars Eggert NEC Network Laboratories --------------ms090207030000030608010901 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 NDExMjUxNTAzMjFaMCMGCSqGSIb3DQEJBDEWBBR1yacA8zuofEc9WRkboa/hEw/wnDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQBVJhbLldbg1U15Zr+ZZx9mieZ0Se29WkXwiZ567Ao5HfeW Sr3Qa4NCBVy233OePeGxMD07QDRL332mPxOK9RpzCqk+0VpT5L1LqgVbsc8LPyU5WgM/Ziae g0y5roGkM3LVdfz4TJSiT/yJG/zoIy2Leq7urLos8rSMUFDAqzZfXAYFeZ4iZ+X7Mvp9aPSo JkhAJ1DccDArFZpZEHig1peo/LNclhFpc+2NKw5DgqKS5V3Ao/SB+HNCvYekFPVJT5e2Hl9e hDru72REShGfIo63X0+U+BW3S23KveQqALPozZP5cOvq/ktXsIxm0ncm5J9BH7wimrypcRHn 2hmAoMZyAAAAAAAA --------------ms090207030000030608010901-- From miika@iki.fi Thu Nov 25 16:48:01 2004 From: miika@iki.fi (Miika Komu) Date: Thu Nov 25 16:48:01 2004 Subject: [Hipsec] DNS issue #1: Using multiple HIs and IPs In-Reply-To: <200411250944.09985.julien.laganier@sun.com> References: <200411102038.15863.julien.laganier@sun.com> <4193EA0F.5090105@netlab.nec.de> <048CEC87-34A8-11D9-A88A-000D9331AFB0@nomadiclab.com> <200411250944.09985.julien.laganier@sun.com> Message-ID: On Thu, 25 Nov 2004, Julien Laganier wrote: > This text sounds fine to me. As to the question to what document it > belongs, it appears to me that these issues are either: > > - specific to DNS, in which case the text belongs to the DNS draft. > > - impacting any combination of HIP with a 'flat lookup' service (i.e. > returning a bunch of flats HITs and IPs), in which case the text > belongs to the base protocol draft, and should be generalized to > refer to "a flat lookup service (e.g. DNS)" instead of just "DNS". > > Comments? The text is good. I'd put in the DNS draft because the properties of DNS are the reason to include this text anyway. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From fanzhao@ucdavis.edu Sun Nov 28 17:23:00 2004 From: fanzhao@ucdavis.edu (Fan Zhao) Date: Sun Nov 28 17:23:00 2004 Subject: [Hipsec] Call for Papers: IEEE JSAC MRNM Message-ID: <200411282222.iASMMVNR009820@phaenicia.ucdavis.edu> PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications and models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From joseph-so@gmx.net Sun Nov 28 19:21:00 2004 From: joseph-so@gmx.net (Joseph) Date: Sun Nov 28 19:21:00 2004 Subject: [Hipsec] Question about Mobile Router support in HIP Message-ID: <20041129002048.B7C857313@honor.icsalabs.com> This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C4D605.6DC8C030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I have read some papers mentioned that Mobile Router is not supported in HIP at this moment. In my understanding, the packet is routered by IP but not HI/HIT. Why can't we use current mobile router for HIP at this moment? What makes HIP not able to support current mobile router? Thanks a lot. Yours faithfully, Joseph ------=_NextPart_000_000F_01C4D605.6DC8C030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
    I have=20 read some papers mentioned that Mobile Router is not supported in HIP at = this=20 moment. In my understanding, the packet is routered by IP but not = HI/HIT. Why=20 can't we use current mobile router for HIP at this moment? What makes = HIP not=20 able to support current mobile router? Thanks a lot.
Yours=20 faithfully,
Joseph
------=_NextPart_000_000F_01C4D605.6DC8C030--