From miika@iki.fi Thu Dec 2 10:58:01 2004 From: miika@iki.fi (Miika Komu) Date: Thu Dec 2 10:58:01 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec In-Reply-To: <2712DD07-372C-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <2712DD07-372C-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: On Mon, 15 Nov 2004, Pekka Nikander wrote: > 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? > ... > > If we take this path, we should probably also rename the REA > payload as LOC, for locators. > > Any opinions? There has been no responses to this this email, so here's one. I guess this depends on whether we want to finish the base exchange and get an RFC faster. If we split the IPsec stuff, it is going to delay the standardization, IMHO. On the other hand, perhaps the split would make HIP also a more "generic" protocol. For example, this would make it easier to implement HIP enabled multicast. However, the multicast requires other changes, and perhaps should be further discussed in the research group... -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Gonzalo.Camarillo@ericsson.com Tue Dec 7 07:02:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Dec 7 07:02:00 2004 Subject: [Hipsec] Minutes from DC Message-ID: <41B59B86.7040503@ericsson.com> Folks, David has put together the minutes of our last meeting in DC. You can fetch them from: http://standards.ericsson.net/gonzalo/61st_IETF_HIP_Minutes.htm We intend to submit them to the secretariat by Friday. Thanks, Gonzalo From jeffrey.m.ahrenholz@boeing.com Thu Dec 9 19:51:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Thu Dec 9 19:51:01 2004 Subject: [Hipsec] Question about Mobile Router support in HIP Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F2B@xch-nw-09.nw.nos.boeing.com> Joseph, It looks like nobody has yet answered your question. Maybe you could mention which papers you are referring to, and what you mean by "Mobile Router" (i.e., MIP?). However, this working group is chartered to define the "minimal infrastructure elements" (http://www.ietf.org/html.charters/hip-charter.html) for end-to-end HIP, and perhaps your question is more suitable for the HIP-RG (http://www.irtf.org/charters/hip.html). HIP routing using HI/HITs sounds like an architectural topic of study. -Jeff -----Original Message----- From: Joseph [mailto:joseph-so@gmx.net]=20 Sent: Sunday, November 28, 2004 4:20 PM To: hipsec@honor.trusecure.com Subject: [Hipsec] Question about Mobile Router support in HIP 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 From mkousa@cc.hut.fi Fri Dec 10 10:46:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Fri Dec 10 10:46:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing Message-ID: Section 8.11 "Processing UPDATE packets" of the base draft does not explicitly tell whether the destination address of the reply UPDATE packet must be the same as the source address of the received initial UPDATE packet. When I was doing some mobility draft tests, sometimes the UPDATE packet was lost because it went to a non-existing address (the case when I removed one network card and inserted an other card). This was due to the assumption I made based on the base draft, that the reply UPDATE is to be always sent to the source address of the initial UPDATE address. Should the draft explicitly mention that destination address of the reply UPDATE packet must be the source address of the received initial UPDATE packet ? This requirement should not break the base draft case functionality for static hosts and it seems to work well with mobile hosts. From marcelo@it.uc3m.es Sun Dec 12 05:41:01 2004 From: marcelo@it.uc3m.es (marcelo bagnulo braun) Date: Sun Dec 12 05:41:01 2004 Subject: [Hipsec] Question about Mobile Router support in HIP In-Reply-To: <20041129002048.B7C857313@honor.icsalabs.com> References: <20041129002048.B7C857313@honor.icsalabs.com> Message-ID: <1B4140E7-4C2A-11D9-A7EC-000D93ACD0FE@it> Hi Joseph, sorry for late reply (i don't know if you are still interested in this=20= issue by now :-) But in case you are, a very good paper about the issues of supporting=20 mobile routers (and other scenarios) when crypt based identities (being=20= HIP just one instance of such approach) is "Delegation of signaling=20 rights" by P. Nikander and J. Arkko In this paper you can get a good idea about the problems in this=20 scenario and possible approaches to deal with them. Hope you find it useful (i did) Regards, marcelo El 29/11/2004, a las 1:20, Joseph escribi=F3: > Dear All, > =A0=A0=A0=A0I have read some papers mentioned that Mobile Router is = not=20 > supported in HIP at this moment. In my understanding, the packet is=20 > routered by IP but not HI/HIT. Why can't we use current mobile router=20= > for HIP at this moment? What makes HIP not able to support current=20 > mobile router? Thanks a lot. > Yours faithfully, > Joseph From joseph-so@gmx.net Sun Dec 12 08:38:01 2004 From: joseph-so@gmx.net (Joseph) Date: Sun Dec 12 08:38:01 2004 Subject: [Hipsec] Question about Mobile Router support in HIP In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F2B@xch-nw-09.nw.nos.boeing.com> Message-ID: <20041212133728.CBEA77322@honor.icsalabs.com> Thanks a lot. In T. R. Henderson, et al., "Experience with the host identity protocol for secure host mobility and multihoming," presented at Wireless Communications and Networking, 2003. WCNC 2003. 2003 IEEE, 2003, It mentions that "However, Mobile IP offers potential advantages when entire subnets (routers) are mobile, where HIP is not deployed, or where infrastructure to support pervasive IPsec has not been deployed. " I think that the entire subnets (routers) are mobile, is talking about the "Mobile Router". So I want to know more about how the scenario it is of current HIP when the subnet is mobile. In my mind, all the packet are router by IP addresses, HI / HIT is only for host identity only, so that subnet is mobile or not should not be affected. But the paper seems to say HIP cannot work property when the subnet is mobile Thanks a lot. Joseph -----Original Message----- From: Ahrenholz, Jeffrey M [mailto:jeffrey.m.ahrenholz@boeing.com] Sent: Friday, December 10, 2004 11:51 AM To: Joseph; hipsec@honor.trusecure.com Subject: RE: [Hipsec] Question about Mobile Router support in HIP Joseph, It looks like nobody has yet answered your question. Maybe you could mention which papers you are referring to, and what you mean by "Mobile Router" (i.e., MIP?). However, this working group is chartered to define the "minimal infrastructure elements" (http://www.ietf.org/html.charters/hip-charter.html) for end-to-end HIP, and perhaps your question is more suitable for the HIP-RG (http://www.irtf.org/charters/hip.html). HIP routing using HI/HITs sounds like an architectural topic of study. -Jeff -----Original Message----- From: Joseph [mailto:joseph-so@gmx.net] Sent: Sunday, November 28, 2004 4:20 PM To: hipsec@honor.trusecure.com Subject: [Hipsec] Question about Mobile Router support in HIP 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 From thomas.r.henderson@boeing.com Sun Dec 12 17:55:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Dec 12 17:55:01 2004 Subject: [Hipsec] Question about Mobile Router support in HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406096D@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Joseph [mailto:joseph-so@gmx.net] > Sent: Sunday, December 12, 2004 5:37 AM > To: Ahrenholz, Jeffrey M; hipsec@honor.trusecure.com > Subject: RE: [Hipsec] Question about Mobile Router support in HIP >=20 > But the paper seems to say HIP=20 > cannot work > property when the subnet is mobile It doesn't say that HIP can't work properly when subnet is mobile-- only that the original HIP proposal didn't have any explicit mechanism for subnet mobility. Anyway, I would suggest to direct any more discussion of this to hipsec-rg list, since this is out of scope for HIP WG. Thanks, Tom From thomas.r.henderson@boeing.com Sun Dec 12 18:07:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Dec 12 18:07:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi] > Sent: Friday, December 10, 2004 7:45 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Destination address usage in UPDATE packet=20 > processing >=20 >=20 > Section 8.11 "Processing UPDATE packets" of the base draft does not=20 > explicitly tell whether the destination address of the reply=20 > UPDATE packet=20 > must be the same as the source address of the received initial UPDATE=20 > packet. >=20 > When I was doing some mobility draft tests, sometimes the=20 > UPDATE packet=20 > was lost because it went to a non-existing address (the case when I=20 > removed one network card and inserted an other card). This=20 > was due to the=20 > assumption I made based on the base draft, that the reply=20 > UPDATE is to be=20 > always sent to the source address of the initial UPDATE address. Were you sending the UPDATE before you removed the network card? I would assume that if you removed one network card and inserted another, the UPDATE would originate from the new address. >=20 > Should the draft explicitly mention that destination address=20 > of the reply=20 > UPDATE packet must be the source address of the received=20 > initial UPDATE=20 > packet ? This requirement should not break the base draft case=20 > functionality for static hosts and it seems to work well with mobile=20 > hosts. In general, that would seem to work well for transparent middleboxes. However, I wonder whether it should be a MUST, since that might constrain implementation (depending on how HIP is implemented and the socket model, it is not always easy to tell what the IP address was of the incoming packet). Tom From mkousa@cc.hut.fi Wed Dec 15 06:56:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Dec 15 06:56:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> Message-ID: On Sun, 12 Dec 2004, Henderson, Thomas R wrote: -> > -----Original Message----- -> > From: Mika Kousa [mailto:mkousa@cc.hut.fi] -> > Sent: Friday, December 10, 2004 7:45 AM -> > To: hipsec@honor.trusecure.com -> > Subject: [Hipsec] Destination address usage in UPDATE packet -> > processing -> > -> > -> > Section 8.11 "Processing UPDATE packets" of the base draft does not -> > explicitly tell whether the destination address of the reply -> > UPDATE packet -> > must be the same as the source address of the received initial UPDATE -> > packet. -> > -> > When I was doing some mobility draft tests, sometimes the -> > UPDATE packet -> > was lost because it went to a non-existing address (the case when I -> > removed one network card and inserted an other card). This -> > was due to the -> > assumption I made based on the base draft, that the reply -> > UPDATE is to be -> > always sent to the source address of the initial UPDATE address. -> -> Were you sending the UPDATE before you removed the network card? I -> would assume that if you removed one network card and inserted another, -> the UPDATE would originate from the new address. The scenario was: An internal network interface was running. HIP association was set up using that interface. The network interface was disabled. UPDATE could not be sent, because there was no available network connectivity. A moment later another external network interface card was inserted, and when this card got addresses, UPDATE was sent. The host which received the UPDATE packet followed the design principle "when sending HIP control packets to the peer, use verified addresses only". At this time this host knew only the address used during the base exchange. However, that address belongs to the interface which is down, so the packet was sent to non-existent address, and the readdressing failed. If the draft would have said that reply is sent to the source address of the initial address and not to a verified address, there would not have been any problems. -> > Should the draft explicitly mention that destination address -> > of the reply -> > UPDATE packet must be the source address of the received -> > initial UPDATE -> > packet ? This requirement should not break the base draft case -> > functionality for static hosts and it seems to work well with mobile -> > hosts. -> -> In general, that would seem to work well for transparent middleboxes. -> However, I wonder whether it should be a MUST, since that might -> constrain implementation (depending on how HIP is implemented and the -> socket model, it is not always easy to tell what the IP address was -> of the incoming packet). Then how about some level of recommendation ? Would sending of same UPDATEs to multiple addresses (both to a verified address and to the source of the initial packet) be a better approach ? If the UPDATE IDs are the same, the later packet is just dropped if both packets are received. From pekka.nikander@nomadiclab.com Wed Dec 15 11:14:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 15 11:14:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> Message-ID: <34E679CA-4EB4-11D9-BEDF-000D9331AFB0@nomadiclab.com> > The scenario was: > > An internal network interface was running. HIP association was set up > using that interface. The network interface was disabled. UPDATE could > not > be sent, because there was no available network connectivity. A moment > later another external network interface card was inserted, and when > this > card got addresses, UPDATE was sent. > > The host which received the UPDATE packet followed the design principle > "when sending HIP control packets to the peer, use verified addresses > only". At this time this host knew only the address used during the > base > exchange. However, that address belongs to the interface which is > down, so > the packet was sent to non-existent address, and the readdressing > failed. > > If the draft would have said that reply is sent to the source address > of > the initial address and not to a verified address, there would not have > been any problems. > > ... > > Then how about some level of recommendation ? draft-ietf-hip-mm-00.txt, Section 5.1, bullet 2, last sentence: > The UPDATE messages sent from the peer back to the > mobile are sent to the newly advertised address. Then there is some text about reachability test in Section 4.2. But maybe those are not enough? If so, what would be your suggestion? Concrete text/diff, please. --Pekka From pekka.nikander@nomadiclab.com Wed Dec 15 11:20:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 15 11:20:01 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec In-Reply-To: <2712DD07-372C-11D9-A88A-000D9331AFB0@nomadiclab.com> References: <2712DD07-372C-11D9-A88A-000D9331AFB0@nomadiclab.com> Message-ID: <1FC54DBE-4EB5-11D9-BEDF-000D9331AFB0@nomadiclab.com> > I know this is quite radical, but ... > > 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. So far I haven't seen any discussion on this other than Miika's response where he is concerned about how fast we could do such a split in practice, and some face-to-face discussions with Petri where we have been trying to ponder this without coming into any concrete conclusions, at least not yet. I'd like to proceed by making a concrete proposal. However, before that, I'd like to get some feedback from the WG on whether this is considered to be a viable way at all or not. While the short run benefit seems to be that it makes the mm spec easier to get done, it opens potential complexities (but also increased flexibility) in the longer run. --Pekka From mkousa@cc.hut.fi Wed Dec 15 11:52:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Dec 15 11:52:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing In-Reply-To: <34E679CA-4EB4-11D9-BEDF-000D9331AFB0@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> <34E679CA-4EB4-11D9-BEDF-000D9331AFB0@nomadiclab.com> Message-ID: On Wed, 15 Dec 2004, Pekka Nikander wrote: -> > If the draft would have said that reply is sent to the source address of -> > the initial address and not to a verified address, there would not have -> > been any problems. -> > -> > ... -> > -> > Then how about some level of recommendation ? -> -> draft-ietf-hip-mm-00.txt, Section 5.1, bullet 2, last sentence: -> -> > The UPDATE messages sent from the peer back to the -> > mobile are sent to the newly advertised address. -> -> Then there is some text about reachability test in Section 4.2. Ah, I was just reading the base draft, not the mm draft. I guess that adding the same sentence as above would not hurt the base draft either. -> But maybe those are not enough? If so, what would be your suggestion? -> Concrete text/diff, please. Based on my current knowledge on this issue, I think it is sufficient most of the time. However, I haven't thought about the destination address selection in the situations when there are more than one address in the REA parameter (and possibly no address flagged as the preferred address), or there are multiple REA parameters. From pekka.nikander@nomadiclab.com Wed Dec 15 12:37:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 15 12:37:01 2004 Subject: [Hipsec] Destination address usage in UPDATE packet processing In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406096E@xch-nw-27.nw.nos.boeing.com> <34E679CA-4EB4-11D9-BEDF-000D9331AFB0@nomadiclab.com> Message-ID: > -> > Then how about some level of recommendation ? > -> > -> draft-ietf-hip-mm-00.txt, Section 5.1, bullet 2, last sentence: > -> > -> > The UPDATE messages sent from the peer back to the > -> > mobile are sent to the newly advertised address. > -> > -> Then there is some text about reachability test in Section 4.2. > > Ah, I was just reading the base draft, not the mm draft. I guess that > adding the same sentence as above would not hurt the base draft either. Well, the base spec does not cover mobility or multi-homing situations. The assumption is, more or less, that you just don't change your addresses while the HIP association is active. Should there be an explicit caveat emptor about that somewhere? However, the situation is likely to get even more complicated when we really start to consider the cases where the signalling packets (UPDATE) and data packets (ESP) may take different paths, as in the case of Hi3. But I would not like to complicate the current specs with that, but wait for some experimentation and research results before jumping into that rat hole. > However, I haven't thought about the destination address selection in > the > situations when there are more than one address in the REA parameter > (and > possibly no address flagged as the preferred address), or there are > multiple REA parameters. Ok. It you come up with something, it would be nice to include some text, if needed. --Pekka From thomas.r.henderson@boeing.com Wed Dec 15 14:11:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Dec 15 14:11:02 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406097B@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Wednesday, December 15, 2004 8:20 AM > To: Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Resolving the SPI question, or splitting ESP out > of base spec >=20 >=20 > > I know this is quite radical, but ... > > > > 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. >=20 > So far I haven't seen any discussion on this other than Miika's > response where he is concerned about how fast we could do such > a split in practice, and some face-to-face discussions with Petri > where we have been trying to ponder this without coming into any > concrete conclusions, at least not yet. >=20 > I'd like to proceed by making a concrete proposal. However, > before that, I'd like to get some feedback from the WG on whether > this is considered to be a viable way at all or not. While the > short run benefit seems to be that it makes the mm spec easier to > get done, it opens potential complexities (but also increased > flexibility) in the longer run. >=20 I will voice support for splitting up the current base and mm drafts = into possibly the following: i) core HIP signaling (I1 through R2, CLOSE, CLOSE_ACK, NOTIFY, UPDATE), = without IPSec-related fields or processing ii) IPsec (ESP) extension (ESP_TRANSFORM, SPI, rules for KEYMAT, BEET semantics, NES and rekeying) iii) mobility (locator change) iv) host multi-homing v) upper layer considerations (transport checksums, MTU, congestion control, user-space API) I think that the above will allow us to more easily consider and experiment with variants that have been proposed (such as use of HIP without ESP, and use of HIP using IKEv2 exchange for signaling, and even possibly use of HIP in multi6 context). Is this too much decomposition? My rationale for splitting mobility and multihoming is that our initial experience is that multihoming is going to take a while longer to sort out completely (and we are lacking initial implementation experience in that area). My rationale for suggesting a "upper layer" document (v) is thinking ahead to the possibility that IKE or some multi6 protocol is used instead of base exchange, in which case it might be nice if all of the upper layer considerations are not embedded in the base document. Tom=20 From pekka.nikander@nomadiclab.com Wed Dec 15 15:21:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Dec 15 15:21:00 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406097B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406097B@xch-nw-27.nw.nos.boeing.com> Message-ID: > I will voice support for splitting up the current base and mm drafts > into > possibly the following: > i) core HIP signaling (I1 through R2, CLOSE, CLOSE_ACK, NOTIFY, > UPDATE), > without IPSec-related fields or processing > ii) IPsec (ESP) extension (ESP_TRANSFORM, SPI, rules for KEYMAT, BEET > semantics, NES and rekeying) > iii) mobility (locator change) > iv) host multi-homing > v) upper layer considerations (transport checksums, MTU, congestion > control, user-space API) I think this is a reasonable proposal, and as a first reaction seems good other than that I'm not sure about transport checksums. In my opinion, separating the IP routing and the upper layers from each other is an important feature of HIP. Hence, at minimum, I think that we want the base spec to say that the upper layer checksums, if there are ones, SHOULD be computed based on location-independent identifiers. To leave space for something like multi6 protocols, we may still leave it open what those identifiers are, and just suggest HITs as the default case. But I'm afraid I need to think about this a little bit longer, and consider the details, e.g., where the KEYMAT derivation really belongs. > I think that the above will allow us to more easily consider and > experiment with variants that have been proposed (such as use of HIP > without ESP, and use of HIP using IKEv2 exchange for signaling, and > even possibly use of HIP in multi6 context). IMHO, this is a good goal. > Is this too much decomposition? My rationale for splitting mobility > and multihoming is that our initial experience is that multihoming is > going to take a while longer to sort out completely (and we are lacking > initial implementation experience in that area). Agreed. > My rationale for suggesting a "upper layer" document (v) is > thinking ahead to the possibility that IKE or some multi6 > protocol is used instead of base exchange, in which case > it might be nice if all of the upper layer considerations > are not embedded in the base document. I think this is a reasonable goal as well, but OTOH I have a hard time to figure out how exactly to say things. Maybe we want to say some things a few times, i.e., to repeat them in different documents. IIRC, right now we say very little about MTU, congestion control, or APIs. AFAIK, we can't say much about them other than MTU, which seems to mostly fit into the ESP document at this point of time. Hence, I may be inclined to retain the transport checksum considerations in the protocol spec, to say something about MTU in the ESP spec, and leave the other upper layer considerations for RG work at this point of time. In any case, the purpose of this WG is to get the defined minimal set of documents out so that we have a stable reference point for our experiments and further protocol and architecture design. --Pekka From pekka.nikander@nomadiclab.com Thu Dec 16 07:01:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Dec 16 07:01:01 2004 Subject: [Hipsec] Addressing WG LC comments on draft-ietf-hip-arch Message-ID: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> Lars, I have now tried to address your WG LC comments (the only ones!) on draft-ietf-hip-arch-00.txt. http://honor.trusecure.com/pipermail/hipsec/2004-October/001069.html http://honor.trusecure.com/pipermail/hipsec/2004-October/001074.html The result is now available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.html http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16.xml Diffs to the previous version are available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16- chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec16- diff.html Would you please check that I have addressed your comments to your satisfaction. Once we have your comments addressed, I think that the draft is ready to be shipped to the IESG for consideration to be published as Informational. --Pekka From petri.jokela@nomadiclab.com Thu Dec 16 08:58:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Dec 16 08:58:01 2004 Subject: [Hipsec] Resolving the SPI question, or splitting ESP out of base spec In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406097B@xch-nw-27.nw.nos.boeing.com> Message-ID: <41C192E0.2090305@nomadiclab.com> Pekka Nikander wrote: >> I will voice support for splitting up the current base and mm drafts into >> possibly the following: >> i) core HIP signaling (I1 through R2, CLOSE, CLOSE_ACK, NOTIFY, UPDATE), >> without IPSec-related fields or processing > > I think this is a reasonable proposal, and as a first reaction seems good I'll start working with the base specification part with this proposal in mind. So, I hope I get the first version out soon. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From lars.eggert@netlab.nec.de Mon Dec 20 12:55:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Mon Dec 20 12:55:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> References: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> Message-ID: <41C711D5.5010900@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms060900040906050707030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > Would you please check that I have addressed your comments to > your satisfaction. Generally looks good, some other very minor issues below. > Abstract ... > protocols are defined. The memo describes the thinking of the > authors as of Fall 2003. Fall 2004? (Here and at several other places later.) > 2. Introduction ... > The proposed Host Identity namespace fills an important gap between > the IP and DNS namespaces. The Host Identity namespace consists of > Host Identifiers (HI). A Host Identifier is cryptographic in its > nature; it is the public key of an asymmetric key-pair. Each host > will have at least one Host Identity, but it will typically have more > than one. Each host identity uniquely identifies a single host, > i.e., no two hosts have the same host identity. The Host Identity, > and the corresponding Host Identifier, can either be public (e.g. > published in the DNS), or unpublished. Client systems will tend to > have both public and unpublished Identities. "Host Identity" is not capitalized twice - oversight? > When HIP is used, the actual payload traffic between two HIP hosts is > typically, but not necessarily, protected with IPsec. The Host > Identities are used to create the needed IPsec Security Associations > (SA) and to authenticate the hosts. When IPsec is used, the actual s/(SA) and to authenticate/(SAs) to authenticate/ > payload IP packets do not differ in any way from standard IPsec > protected IP packets. What do you mean by "payload IP packets?" Maybe rephrase as: "IPsec-protected HIP payload packets do not differ in any way from IPsec-protected IP packets." > | Public key | The public key from an asymmetric cryptographic | ... > | Private key | The private or secret key from an asymmetric | s/from an/of an/ > | | | > | Public key | An asymmetric cryptographic key pair consisting of | > | pair | a public and private keys. For example, | s/of a public/of public/ > | Unpublished | A Host Identifier that is not placed in any public | > | Host | directory, and the corresponding Host Identity. | > | Identifier | Unpublished Host Identities are typically short | > | and Identity | living in nature, being often replaced and | > | | possibly used just once. | s/short living/short lived/ > 4. Background ... > infrastructure, and services (applications). The Internet exists to > service two principal components: people and robotic services s/service/serve/ I would also not capitalize "Domain Names" in the remainder of section 4. > IP numbers name networking interfaces, and typically only when the > interface is connected to the network. Originally IP numbers had s/Originally /Originally, / > long-term significance. Today, the vast number of interfaces use > ephemeral and/or non-unique IP numbers. That is, every time an s/every time/everytime/ > 4.1 A desire for a namespace for computing platforms ... > o The namespace should fully decouple the internetworking layer from > the higher layers. The names should replace all occurrences of IP > addresses within applications (like in the TCB). This may require TCB? TCP Control Block? (Again later in the section.) > changes to the current APIs. In the long run, it is probable that > some new APIs are needed. s/probable/possible/ > In this document, a new namespace approaching these ideas is called > the Host Identity namespace. Using Host Identities requires its own > protocol layer, the Host Identity Protocol, between the > internetworking and transport layers. The names are based on > public-key cryptography to supply authentication services. Properly > designed, it can deliver all of the above stated requirements. First sentence is clunky, maybe: "This document introduces a new namespace to support these ideas. It is called the Host Identity namespace." s/above stated requirements/above requirements/ > 5. Host Identity namespace ... > 'well known', some unpublished or 'anonymous'. A system may self > assert its own identity, or may use a third-party authenticator like > DNSSEC, PGP, or X.509 to 'notarize' the identity assertion. It is > expected that the Host Identifiers will initially be authenticated > with DNSSEC and that all implementations will support DNSSEC as a > minimal baseline. s/self assert/self-assert/ Do we really want the last sentence about DNSSEC in there? (And if we do, we shoud cite it.) > 5.1 Host Identifiers > > Host Identity adds two main features to Internet protocols. The s/Host Identity/The Host Identity Protocol/ > authentication. Because the Host Identifier is a public key, this > key can be used to authenticate security protocols like IPsec. s/can be used to authenticate/can be used for authentication in/ > 5.2 Storing Host Identifiers in DNS > > The public Host Identifiers should be stored in DNS; the unpublished > Host Identifiers should not be stored anywhere (besides the > communicating hosts themselves). The (public) HI is stored in a new > RR type, to be defined. This RR type is likely to be quite similar > to the IPSECKEY RR [5]. I guess we can't cite Julien's DNS ID in an RFC to-be? > 5.3 Host Identity Tag (HIT) > > A Host Identity Tag is an 128-bit representation for a Host Identity. s/an 128-bit/a 128-bit/ s/for a/of a/ > the Host Identifier in protocols. Firstly, its fixed length makes > for easier protocol coding and also better manages the packet size > cost of this technology. Secondly, it presents the identity in a Clunky. Maybe: "First, a fixed-length hash simplifies protocol implementation and reduces per-packet overhead." > universe as long as it is being used. In the extremely rare case > that a single HIT happens to map to more than one Host Identity, the s/that a single HIT happens to map/of a single HIT mapping/ > Host Identifiers (public keys) will make the final difference. If s/will make the final difference/differentiate between the two/ > 5.4 Local Scope Identifier (LSI) ... > Examples of how LSIs can be used include: as the address in a FTP s/a FTP/an FTP/ > 6. New stack architecture > > One way to characterize Host Identity is to compare the proposed new s/Host Identity/the Host Identity Protocol/ > 6.1 Transport associations and end-points > > Architecturally, HIP provides for a different binding of s/for a/a/ > 7. End-host mobility and multi-homing ... > reassignments, or a NAT device remapping its translation. Likewise, > a system is considered multi-homed if it has more than one globally > routable IP address at the same time. HIP links IP addresses Why "globally routable?" Can't I be multi-homed through two NATs? Maybe say "connects to the Internet via multiple different interfaces?" > changes are rather straightforward. The peer of the mobile node can > just accept a HIP or an integrity protected IPsec packet from any > address and totally ignore the source address. However, as discussed s/totally// > 7.1 Rendezvous mechanism > > Making a contact to a mobile node is slightly more involved. In > order to start the HIP exchange, the initiator node has to know how > to reach the mobile node. Although infrequently moving HIP nodes > could use Dynamic DNS to update their reachability information in the cite Dynamic DNS > 7.2 Protection against flooding attacks > > distributed flooding attack an attacker opens high volume HIP s/high volume/high-bandwidth/ > 8. HIP and IPsec ... > active transport is also maintained. Thus, real world conditions s/real world/real-world/ > 10. Multicast > > Back in the fall of 2003, there was little if any concrete thoughts > about how HIP might affect IP-layer or application-layer multi-cast. s/multi-cast/multicast/ > 12. Benefits of HIP ... > This is why many systems on the internet are not registered in the > DNS; they do not have services of interest to other Internet hosts. s/internet/Internet/ > IP and DNS namespaces. An interesting thing about the HI is that it > actually allows one to give-up all but the 3rd network-layer s/give-up/give up/ -- Lars Eggert NEC Network Laboratories --------------ms060900040906050707030204 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 NDEyMjAxNzU0MjlaMCMGCSqGSIb3DQEJBDEWBBQS2bV/un1/tkqNO8gvrUXECKt3BDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQC4wnsDEOIB8PrbHrQ/AHqFe3uAsbiMFSE9pFrk7STM6Wa7 jymVD6JBR8cxLBVmogWwDfvKuax3FXxZEq9D6ytP0/vAxivzzT1itYU0kPcm2KBryMeMApLR k6vPeroQ8qKxvBZulVmO1GMZWeJe2cTcsxP0HkpJnq54beSUtVgBhcwsHBBw7+eyWmzfieIW QTl1Vb63W2/4IsYu6rTqBQVY3B/sbIdSJOaVnernc6/JukTRjAau3mDFI2hcEm71MkEThyzh fjYkcy0sM3apf0ZFHVT63bj3WyU1wsWMOSKKwtyjN0+UkOLt0ipdy8psttXc9aZjoM446rZq W+W1K4mfAAAAAAAA --------------ms060900040906050707030204-- From thomas.r.henderson@boeing.com Mon Dec 20 14:08:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Dec 20 14:08:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: Monday, December 20, 2004 9:54 AM > To: Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch >=20 > > Abstract > ... > > protocols are defined. The memo describes the thinking of the > > authors as of Fall 2003. >=20 > Fall 2004? (Here and at several other places later.) Pekka, maybe you or Gonzalo can clarify this point. My understanding is that we are trying to publish a historical document here that = documents the thinking of no later than 2003. That is, refinements to the = architecture document or architectural thinking since fall of last year are out of = scope. >=20 > > changes to the current APIs. In the long run, it is=20 > probable that > > some new APIs are needed. >=20 > s/probable/possible/ I think "probable" is more accurate. > > 5. Host Identity namespace > ... > > 'well known', some unpublished or 'anonymous'. A system may self > > assert its own identity, or may use a third-party=20 > authenticator like > > DNSSEC, PGP, or X.509 to 'notarize' the identity=20 > assertion. It is > > expected that the Host Identifiers will initially be=20 > authenticated > > with DNSSEC and that all implementations will support DNSSEC as a > > minimal baseline. >=20 > s/self assert/self-assert/ >=20 > Do we really want the last sentence about DNSSEC in there? (And if we=20 > do, we shoud cite it.) This was probably true as of last year, but recently there has been a chorus against requiring a DNS dependency. Tom From pekka.nikander@nomadiclab.com Mon Dec 20 15:03:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Dec 20 15:03:00 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> Message-ID: <136B6C16-52C2-11D9-977D-000D9331AFB0@nomadiclab.com> >>> Abstract >> ... >>> protocols are defined. The memo describes the thinking of the >>> authors as of Fall 2003. >> >> Fall 2004? (Here and at several other places later.) > > Pekka, maybe you or Gonzalo can clarify this point. My understanding > is that we are trying to publish a historical document here that > documents > the thinking of no later than 2003. That is, refinements to the > architecture > document or architectural thinking since fall of last year are out of > scope. Yes, Tom, you are right. The intention is to publish a document that reflects back our understanding as of a year ago from now. We may want to codify our understanding as of now (or in the future) too, but that would be a different effort. For example, I'm starting to disagree with the tight integration with ESP, but I certainly did not a year ago. I'll return to the rest of the messages tomorrow, now it is too late here. --Pekka From lars.eggert@netlab.nec.de Tue Dec 21 03:42:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Dec 21 03:42:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <136B6C16-52C2-11D9-977D-000D9331AFB0@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> <136B6C16-52C2-11D9-977D-000D9331AFB0@nomadiclab.com> Message-ID: <41C7E1A2.8080401@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms000602070300000207000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom, Pekka, Pekka Nikander wrote: >>> >>> Fall 2004? (Here and at several other places later.) >> >> Pekka, maybe you or Gonzalo can clarify this point. My understanding >> is that we are trying to publish a historical document here that >> documents >> the thinking of no later than 2003. That is, refinements to the >> architecture >> document or architectural thinking since fall of last year are out of >> scope. > > Yes, Tom, you are right. The intention is to publish a document that > reflects back our understanding as of a year ago from now. I'd put short paragraph on this into the abstract, introduction and conclusion; along the lines of "This document describes the HIP architecture at its state in the fall of 2003. Although the architecture has evolved since then, this document is an important fix point in understanding." Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms000602070300000207000104 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 NDEyMjEwODQxMDZaMCMGCSqGSIb3DQEJBDEWBBRBgtxYOQuyhzbLteYzB9aAFDFAfDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQB/h3HQd719WPWh/J71nYVZmBCEHmktahZQTnwriHTX96i6 YyLcvBuMNcLO97YxIWqwXV8RVKkxYP1XEXQhJ0WX/Ja3nAOZ/0MXTMha7CmpAsH5gGmY5GWZ bcCwbF+ILeoPRynDLOdTgJjXBYHQIppnTSQoc7Ygxjeo6W6DpEFSmcR/2hvOWhLCUrxSeWlv 8puRPCF8tTdUq9Cwtfp6jO1ebkDPSwcryl9hJNDlG/cOCoRMHiTAD80InqnbGCExulF+cLD4 TAZmiKAoEjPsA6FdSplny9GrH1LBfNW7O9vFTddOBopTTYpanqdklXgEqCM2umPV/Ywu0TGq 3R4h+3kcAAAAAAAA --------------ms000602070300000207000104-- From pekka.nikander@nomadiclab.com Tue Dec 21 06:23:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 21 06:23:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <41C7E1A2.8080401@netlab.nec.de> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> <136B6C16-52C2-11D9-977D-000D9331AFB0@nomadiclab.com> <41C7E1A2.8080401@netlab.nec.de> Message-ID: <9A5B4926-5342-11D9-B221-000D9331AFB0@nomadiclab.com> > I'd put short paragraph on this into the abstract, introduction and > conclusion; along the lines of > > "This document describes the HIP architecture at its state in the fall > of 2003. Although the architecture has evolved since then, this > document is an important fix point in understanding." Note that the beginning of Abstract already mentions the snapshot nature. I changed the abstract to read as follows: This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. I think that is enough, as the introduction already mentions this. What do you think? --Pekka From lars.eggert@netlab.nec.de Tue Dec 21 06:28:02 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Dec 21 06:28:02 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <9A5B4926-5342-11D9-B221-000D9331AFB0@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406098B@xch-nw-27.nw.nos.boeing.com> <136B6C16-52C2-11D9-977D-000D9331AFB0@nomadiclab.com> <41C7E1A2.8080401@netlab.nec.de> <9A5B4926-5342-11D9-B221-000D9331AFB0@nomadiclab.com> Message-ID: <41C808B4.3040609@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms070903030806030808080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > Note that the beginning of Abstract already mentions the snapshot nature. > I changed the abstract to read as follows: > > This memo describes a snapshot of the reasoning behind a > proposed new namespace, the Host Identity namespace, and a new > protocol layer, the Host Identity Protocol, between the > internetworking and transport layers. Herein are presented the > basics of the current namespaces, their strengths and > weaknesses, and how a new namespace will add completeness to > them. The roles of this new namespace in the protocols are > defined. The memo describes the thinking of the authors as of > Fall 2003. The architecture may have evolved since. This document > represents one stable point in that evolution of > understanding. > > I think that is enough, as the introduction already mentions this. > What do you think? Very happy with this. -- Lars Eggert NEC Network Laboratories --------------ms070903030806030808080005 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 NDEyMjExMTI3NDhaMCMGCSqGSIb3DQEJBDEWBBRRLNAwMxrIS+kLF7HBH3RnrO9sPjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQA6m3qE4Kbj582TF9GZvsZznm5M5FwvuAT9yT6t6cRnFm0O r2BMRI0lGR4Jv6rFd2152bpQz1T/S2SPOMmDlf7hICy9N/60RKIVSd5WWvoJHc4x7H7n1leM LKOrP5wkqanPLvlqgZ/aGT4NQho2WPqVX4wGfZSH4/M95aUhBqN/ev5U6Xv/iWnYMBX+R9MD 7bkquhi/OM8G4oey2Gls3qSs7zzlM8HS2Ud8KSNAyaw9v3GOivH6LDG/q0O7B0IzHgs/H4va kjm86xo2AzJ55WslBpmx9SZLNmuZ7m0MpVxAdM/2mzLj73XbYvPUjaVwAOijYURp67j0uqmH egqCauMRAAAAAAAA --------------ms070903030806030808080005-- From pekka.nikander@nomadiclab.com Tue Dec 21 07:06:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 21 07:06:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <41C711D5.5010900@netlab.nec.de> References: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> <41C711D5.5010900@netlab.nec.de> Message-ID: <8D40C6E0-5348-11D9-B221-000D9331AFB0@nomadiclab.com> > "Host Identity" is not capitalized twice - oversight? Bug, fixed. Thanks. > s/(SA) and to authenticate/(SAs) to authenticate/ Fixed. >> payload IP packets do not differ in any way from standard IPsec >> protected IP packets. > > What do you mean by "payload IP packets?" Packets that carry traffic, i.e., not signalling. Pretty much using the standard meaning of the word, e.g., according to Merriam-Webster online, meaning 1: http://www.m-w.com/cgi-bin/dictionary?payload%20 > Maybe rephrase as: "IPsec-protected HIP payload packets do not differ > in any way from IPsec-protected IP packets." That would be definitely wrong, as "HIP payload" is confusing. Do you mean packets that carry HIP signalling, i.e. payload from HIP point of view, or application payload? I have to admit that I am puzzled here of why do you find the expression confusing. The paragraph already before refers to "actual payload traffic", and you don't seem to have any problems with that. > s/from an/of an/ Changed. However, I can't tell which is better. > s/of a public/of public/ Fixed. > s/short living/short lived/ Fixed. >> infrastructure, and services (applications). The Internet exists >> to >> service two principal components: people and robotic services > > s/service/serve/ "service" is a transitive verb, in addition to a noun. As this text originates from Bob, I'd rather not change. > I would also not capitalize "Domain Names" in the remainder of section > 4. As this text originates from Bob, I'd rather not change. > s/Originally /Originally, / Fixed. > s/every time/everytime/ M-W does not recognise "everytime", nor does my spell checker. > TCB? TCP Control Block? (Again later in the section.) Actually Transport Control Block, as it may also apply to UDP. Now spelled out on first occurrence. >> changes to the current APIs. In the long run, it is probable >> that >> some new APIs are needed. > > s/probable/possible/ I agree with Tom here. It looked probable back then, and almost certain now. >> In this document, a new namespace approaching these ideas is called >> the Host Identity namespace. Using Host Identities requires its >> own >> protocol layer, the Host Identity Protocol, between the >> internetworking and transport layers. The names are based on >> public-key cryptography to supply authentication services. >> Properly >> designed, it can deliver all of the above stated requirements. > > First sentence is clunky, maybe: "This document introduces a new > namespace to support these ideas. It is called the Host Identity > namespace." I agree, but as it is part of Bob's writing style, I'd rather not touch. > s/above stated requirements/above requirements/ I don't agree with that. "requirements above" would be OK, but I don't know if it is any better. Google finds some 4500 occurrences of "the above stated requirements", if that is of any indication. > s/self assert/self-assert/ Fixed. > Do we really want the last sentence about DNSSEC in there? (And if we > do, we shoud cite it.) I agree with Tom that we thought so back then. Reference added. >> 5.1 Host Identifiers >> Host Identity adds two main features to Internet protocols. The > > s/Host Identity/The Host Identity Protocol/ As this text originates from Bob, I'd rather not change. > s/can be used to authenticate/can be used for authentication in/ Changed. >> to the IPSECKEY RR [5]. > > I guess we can't cite Julien's DNS ID in an RFC to-be? No, and that didn't exist back then. > s/an 128-bit/a 128-bit/ Fixed. > s/for a/of a/ Both seem to be proper English. Didn't change. >> the Host Identifier in protocols. Firstly, its fixed length makes >> for easier protocol coding and also better manages the packet size >> cost of this technology. Secondly, it presents the identity in a > > Clunky. Maybe: "First, a fixed-length hash simplifies protocol > implementation and reduces per-packet overhead." Part of Bob's style. I'd rather not change. > s/that a single HIT happens to map/of a single HIT mapping/ Fixed. > s/will make the final difference/differentiate between the two/ I find the existing easier to understand, though admittedly less formal. Not changed. > s/a FTP/an FTP/ Fixed. > s/Host Identity/the Host Identity Protocol/ See above. NOt changed. >> 6.1 Transport associations and end-points >> Architecturally, HIP provides for a different binding of > > s/for a/a/ In my opinion, it is "provides for". HIP does not do it by itself, small changes are also required elsewhere. >> 7. End-host mobility and multi-homing > ... >> reassignments, or a NAT device remapping its translation. >> Likewise, >> a system is considered multi-homed if it has more than one globally >> routable IP address at the same time. HIP links IP addresses > > Why "globally routable?" Can't I be multi-homed through two NATs? > Maybe say "connects to the Internet via multiple different > interfaces?" If you connect through two NATs, you do have two globally routable addresses, one at each NAT. I'd rather not change. Besides, the case of multi-homing through NATs is still not clear in detail, and certainly wasn't a year ago. >> address and totally ignore the source address. However, as >> discussed > > s/totally// Fixed, though I don't understand exactly why. > cite Dynamic DNS Added reference to RFC 2136. > s/high volume/high-bandwidth/ IMHO volume is more accurate here. > s/real world/real-world/ Fixed. > s/multi-cast/multicast/ Fixed. > s/internet/Internet/ Fixed. > s/give-up/give up/ Fixed. Overall, thanks for your very thorough proof reading. I hope we can converge on the remaining few points soon. The new version is available at: http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.html http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21.xml Diffs to -01: http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21- chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01-pre-Dec21- diff.html --Pekka From lars.eggert@netlab.nec.de Tue Dec 21 07:23:02 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Dec 21 07:23:02 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <8D40C6E0-5348-11D9-B221-000D9331AFB0@nomadiclab.com> References: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> <41C711D5.5010900@netlab.nec.de> <8D40C6E0-5348-11D9-B221-000D9331AFB0@nomadiclab.com> Message-ID: <41C8158F.7000300@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms010608030302000505090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Overall, thanks for your very thorough proof reading. > I hope we can converge on the remaining few points soon. I think we are converged, it's up to you as editor to decide on editorial comments :-) Some further comments below, but I don't feel strongly about any of them. >>> payload IP packets do not differ in any way from standard IPsec >>> protected IP packets. > >> Maybe rephrase as: "IPsec-protected HIP payload packets do not differ >> in any way from IPsec-protected IP packets." > > That would be definitely wrong, as "HIP payload" is confusing. Do you > mean packets that carry HIP signalling, i.e. payload from HIP point of > view, or application payload? No, I mean that it's a HIP-generated IPsec packet that carries application payload. (Same as you I think.) Anyway, minor point. >>> 7. End-host mobility and multi-homing >>> reassignments, or a NAT device remapping its translation. Likewise, >>> a system is considered multi-homed if it has more than one globally >>> routable IP address at the same time. HIP links IP addresses >> >> Why "globally routable?" Can't I be multi-homed through two NATs? >> Maybe say "connects to the Internet via multiple different interfaces?" > > If you connect through two NATs, you do have two globally routable > addresses, one at each NAT. I'd rather not change. Besides, the case > of multi-homing through NATs is still not clear in detail, and > certainly wasn't a year ago. The NATs do, but the heading says this is about end host multi-homing, and the end hosts don't have global addresses. But since the memo describes a past understanding, that may be fine. >>> address and totally ignore the source address. However, as >>> discussed >> >> s/totally// > > Fixed, though I don't understand exactly why. Slang. Everytime I read "totally" I hear it with an LA valley girl accent... Lars -- Lars Eggert NEC Network Laboratories --------------ms010608030302000505090602 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 NDEyMjExMjIyMzlaMCMGCSqGSIb3DQEJBDEWBBTQBDFxq4hs6vjfl3nuxdfiyHg/rDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQCIlu/2c7ucdesD1oK+NjHzH4wjlLPpLzrItvri5nISWwVu AQVBXQ9HQbqiGUX9KIeoSK4H7QvBYSVYt2XQyQ8v5yGQ4vLByJA0eJ+zwRcG1oOr8OPGAAT2 FQV9Up0XImgSKZlrCYXTinX6b6vgyX4EjrmPyyxbQ5hCkr1fSo6WVGxESoTUqQb85UIJGvcy avdyxUYZF2cui33dgPTyQN1oRH9DMxPLp7452fJnSdVkXXLNYlvNJ8cEgCW9kx3KlZcPeUq/ U4vH/E+W6T+yUp9yixOfgPay4v//6oX/+oFvGCYKrfWxzuQEBaMWTUSEihxN2vruY7q2ELXa caJ2gUE+AAAAAAAA --------------ms010608030302000505090602-- From pekka.nikander@nomadiclab.com Tue Dec 21 07:31:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 21 07:31:01 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch In-Reply-To: <41C8158F.7000300@netlab.nec.de> References: <068242A4-4F5A-11D9-8389-000D9331AFB0@nomadiclab.com> <41C711D5.5010900@netlab.nec.de> <8D40C6E0-5348-11D9-B221-000D9331AFB0@nomadiclab.com> <41C8158F.7000300@netlab.nec.de> Message-ID: <12E4FF0C-534C-11D9-B221-000D9331AFB0@nomadiclab.com> > I think we are converged, it's up to you as editor to decide on > editorial comments :-) Ok, fine. I'll submit the draft and let the chairs to decide if it is ready for the IESG or if further clean ups are needed. --Pekka From pekka.nikander@nomadiclab.com Tue Dec 21 07:37:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Dec 21 07:37:00 2004 Subject: [Hipsec] HIP architecture document ready for the IESG Message-ID: Dear HIP WG chairs, I submitted minutes ago the HIP architecture document, draft-ietf-hip-arch-01.txt, to the repostitory. In the meanwhile, it is also available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01.html http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-01.xml The draft has passed the WG LC, and I believe that we have been able to address the comments. Hence, I believe that the draft is ready to be submitted to the IESG for consideration to be published as an Informational RFC. --Pekka Nikander From thomas.r.henderson@boeing.com Tue Dec 21 12:03:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Dec 21 12:03:02 2004 Subject: [Hipsec] Re: Addressing WG LC comments on draft-ietf-hip-arch Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060994@xch-nw-27.nw.nos.boeing.com> > >>> address and totally ignore the source address. However, as =20 > >>> discussed > >> > >> s/totally// > >=20 > > Fixed, though I don't understand exactly why. >=20 > Slang. Everytime I read "totally" I hear it with an LA valley=20 > girl accent... >=20 This is good fodder for an April 1 draft: The Internet has, like, two totally cool global namespaces: Internet = Protocol (IP) addresses and Domain Name Service (DNS) names. These two = namespaces have a set of super-nice features and abstractions that have totally = powered the Internet to what it is today. They also have a number of = weaknesses that are grody to the max. Like, basically, since they are all we = have, we try and do too much with them. Semantic overloading and = functionality=20 extensions have greatly complicated these namespaces, so much that I = am like freaking out totally. Oh my God! From Internet-Drafts@ietf.org Thu Dec 23 15:27:01 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu Dec 23 15:27:01 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-arch-01.txt Message-ID: <200412232026.PAA17540@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Architecture Author(s) : R. Moskowitz, P. Nikander Filename : draft-ietf-hip-arch-01.txt Pages : 24 Date : 2004-12-23 This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-23124614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-23124614.I-D@ietf.org> --OtherAccess-- --NextPart--