From thomas.r.henderson@boeing.com Wed Feb 2 00:27:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Feb 2 00:27:01 2005 Subject: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> > Since I haven't seen any objections to this proposed=20 > restriction, I hereby suggest that we add the following text=20 > to the HIT section in the base specification. Comments? >=20 > --Pekka Generally OK with me-- a few minor comments below. >=20 > To facilitate experimentation and make certain kind of=20 > implementations easier, the following restrictions are=20 > temporarily placed on HITs. =20 > These restriction are to be lifted at the end of 2008. That=20 > is, after January 1st 2009, any implementation claiming=20 > conformance to this specification MUST accept any HITs from=20 > peers and be able to process them normally. >=20 > The restrictions: Before the end of 2008, all implementations=20 > SHOULD restrict the HITs they generate to ones whose=20 > upper-most (left-most) two bits are either binary 01 or 10. =20 > That is, when generating new HIs, if the resulting HIT has as=20 > its first two bits as 00 or 11, the implementation SHOULD=20 > generate new HIs until it generates one that fulfils this=20 s/fulfils/fulfills/ > restriction. Additionally, a conforming implementation MAY=20 > refuse to communicate with a peer that has a HIT with the=20 > upper-most bits either 00 or 11. When refusing a HIP=20 > connection on this bases, the implementation MUST send an R2=20 > with a NOTIFY payload, with the NOTIFY code being=20 > UNSUPPORTED_HIT_VALUE_RANGE. MAY instead of MUST (since NOTIFY is optional), and add "Any such NOTIFYs may be rate-limited" >=20 > A rationale: One way to implement HIP is to use unmodified=20 > IPv6, TCP and UDP implementations in the stack, using HITs in=20 > the place of IPv6 addresses. In such an implementation,=20 > modifications are only needed at the API level, where it may=20 > be necessary to convert HITs into LSIs and vice versa, and at=20 > or below ESP, where it is necessary to convert HITs into=20 > locators (IP addresses) and vice versa. However, if the IPv6=20 > address space and the HIT value space overlap, it becomes=20 > quite hard to define secure IPsec policies. Furthermore,=20 > there is also the possibility of having a conflict between a=20 > HIT value and an IPv6 address, leading to potential confusion=20 > within the stack. >=20 > This restriction temporarily allows such simple minded=20 > implementations.=20 > It is expected that such implementations will eventually=20 > migrate to a different implementation details, e.g., by=20 > tagging the values either as HITs or IPv6 addresses. =20 > However, tagging the values may be hard in existing IPv6=20 > implementations; the purpose of this restriction is to allow=20 > such HIP implementations that rely on and patch on existing=20 > IPv6 implementations. >=20 I suggest replacing the above two paragraphs with: A rationale: One way to experimentally implement HIP is to use=20 unmodified IPv6, TCP and UDP implementations in the stack, using HITs=20 in the place of IPv6 addresses. This modification makes it easier to=20 use existing IPv6 data structures to hold HITs and to distinguish=20 between the two data types. If the IPv6 address space and the HIT value space overlap, it becomes hard to define secure IPsec policies without explicitly tagging the values either as HITs or IPv6 addresses. Tom From pekka.nikander@nomadiclab.com Wed Feb 2 05:57:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Feb 2 05:57:01 2005 Subject: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> Message-ID: >> ... Additionally, a conforming implementation MAY >> refuse to communicate with a peer that has a HIT with the >> upper-most bits either 00 or 11. When refusing a HIP >> connection on this bases, the implementation MUST send an R2 >> with a NOTIFY payload, with the NOTIFY code being >> UNSUPPORTED_HIT_VALUE_RANGE. > > MAY instead of MUST (since NOTIFY is optional), and add > "Any such NOTIFYs may be rate-limited" Ok. > I suggest replacing the above two paragraphs with: > > A rationale: One way to experimentally implement HIP is to use > unmodified IPv6, TCP and UDP implementations in the stack, using HITs > in the place of IPv6 addresses. This modification makes it easier to > use existing IPv6 data structures to hold HITs and to distinguish > between the two data types. If the IPv6 address space and the HIT > value > space overlap, it becomes hard to define secure IPsec policies without > explicitly tagging the values either as HITs or IPv6 addresses. Looks good to me. If nobody has any objections or comments, I suggest that Petri would add the resulting text to the next version. Opinions, others? --Pekka From andrew@indranet.co.nz Wed Feb 2 06:03:01 2005 From: andrew@indranet.co.nz (Andrew McGregor) Date: Wed Feb 2 06:03:01 2005 Subject: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> Message-ID: <392a4561db826a26fbf7a796548f7c46@indranet.co.nz> On 2/02/2005, at 11:56 PM, Pekka Nikander wrote: >> >> A rationale: One way to experimentally implement HIP is to use >> unmodified IPv6, TCP and UDP implementations in the stack, using HITs >> in the place of IPv6 addresses. This modification makes it easier to >> use existing IPv6 data structures to hold HITs and to distinguish >> between the two data types. If the IPv6 address space and the HIT >> value >> space overlap, it becomes hard to define secure IPsec policies without >> explicitly tagging the values either as HITs or IPv6 addresses. > > Looks good to me. > > If nobody has any objections or comments, I suggest that Petri > would add the resulting text to the next version. > > Opinions, others? > > --Pekka (unlurks) Looks good to me. I had no other comments, and Tom has just answered the last one. Andrew From petri.jokela@nomadiclab.com Thu Feb 3 05:55:01 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Feb 3 05:55:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP Message-ID: <42020300.5040302@nomadiclab.com> Folks, The ESP text is moved now from the Base specification into a new draft. The preliminary version 1 of this draft is available at: http://www.hip4inter.net/drafts.php Some notes: The ESP setup and rekeying processes are defined as conceptual protocols HIP ESP Setup (HES) and HIP ESP Rekeying (HER). In a usual implementation, the contents of these packets is put in base exchange packets and UPDATEs, respectively. The NES and SPI are proposed to be replaced with a single parameter: ESP_INFO. Comments are appreciated. The intention is to make fixes during next week and submit the draft before the IETF deadline for -00 drafts (Feb 14) BR, 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 fanzhao@ucdavis.edu Thu Feb 3 10:01:01 2005 From: fanzhao@ucdavis.edu (Fan Zhao) Date: Thu Feb 3 10:01:01 2005 Subject: [Hipsec] Call for Paper: JSAC-MRNM Message-ID: <200502031130.j13BUgUv021962@tremex.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 nad 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 kgrace@mitre.org Thu Feb 3 13:51:01 2005 From: kgrace@mitre.org (Kevin Grace) Date: Thu Feb 3 13:51:01 2005 Subject: [Hipsec] Rendezvous Server Concerns Message-ID: <42027267.5090503@mitre.org> After cogitating on the topic of Rendezvous Servers for HIP, some concerns have emerged that should probably be discussed within the WG. It seems that these concerns are pretty fundamental and may ultimately limit the desire to pursue Rendezvous Servers. From reading draft-ietf-hip-rvs-00.txt, two reasons are given to motivate the use of Rendezvous Servers. The first has to do with the cost of resigning DNS zones after an update, the second has to do with stale entries in caches being used to respond to queries...the relevant pararaphs are: One drawback of using dynamic DNS updates in this way is the cost of updating secure zones. Re-signing an entire zone whenever the IP addresses of one entry change places a high cost on the DNS server. Using dynamic DNS to update HI->IP mappings may thus not be appropriate when changes of IP addresses are frequent. .... Another concern with using the DNS to support HIP node mobility is the propagation time of updated DNS entries. DNS servers frequently cache DNS responses to reduce the load on the primary servers. During the time-to-live associated with a DNS response, DNS servers may answer additional requests for the same DNS entry from their local caches instead of contacting the primary servers. Thus, even after a HIP node updates its DNS entry, the DNS can still serve the old entry until the cached responses expire. This can lead to communication problems, because peers may try to contact a HIP node at an IP address it is no longer reachable at. The Rendezvous Server approach seeks to avoid sending dynamic updates to DNS for mobile nodes and instead creates a new resource record type in DNS that will allow HIP aware nodes to learn of the IP address(es) or hostname(s) of a mobile node's relatively static Rendezvous Server. It seems that this approach will prevent a mobile HIP node from being reachable by *all* non-HIP nodes, whenever it moves and its current IP address is not the IP address stored in DNS. This seems like an unacceptable outcome. Does it not make more sense for the mobile node to perform a dynamic DNS update so that it can be reached by non-HIP nodes? And if that's the case, then doesn't the RVS become unnecessary since its raison d'etre was to avoid dynamic DNS updates? The second reason given to motivate the use of Rendezvous Servers was to avoid cache staleness problems. It seems that this can be directly solved simply by setting time-to-live values on mobile node resource records to very small values...again, Rendezvous Servers seem unnecessary. Are there any compelling reasons to pursue Rendezvous Servers that outweigh the loss of reachability that non-HIP nodes will experience? Regards, Kevin From pekka.nikander@nomadiclab.com Thu Feb 3 14:50:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Feb 3 14:50:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <42027267.5090503@mitre.org> References: <42027267.5090503@mitre.org> Message-ID: <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> > It seems that this approach will prevent a mobile HIP node from being > reachable by *all* non-HIP nodes, whenever it moves and its current IP > address is not the IP address stored in DNS. This seems like an > unacceptable outcome. Nothing prevents you from using some non-HIP mechanism to remain reachable by non-HIP nodes. For example, if you can arrange one of your rendezvous servers (or some other node) to forward packets to you and packets sent by you, i.e. what is sometimes called a HIP proxy, you can certainly make your A / AAAA record to point to that node. But that is beyond the scope of core HIP, and beyond the scope of the current WG charter. Two questions: - Have you read what the architecture draft says about rendezvous? Does that make sense to you? http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt - Are you familiar with more advanced rendezvous concepts, like Hi3 or rendezvous-based NAT traversal? http://www.watersprings.org/pub/id/draft-nikander-hiprg-hi3-00.txt Note that the advanced rendezvous issues are being discussed at the *Research* Group side, as they go beyond the current WG charter. --Pekka Nikander From kgrace@mitre.org Thu Feb 3 15:58:01 2005 From: kgrace@mitre.org (Kevin Grace) Date: Thu Feb 3 15:58:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> Message-ID: <4202904C.8070909@mitre.org> Hi Pekka, Thanks for the response. My comments are interspersed below... >> It seems that this approach will prevent a mobile HIP node from being >> reachable by *all* non-HIP nodes, whenever it moves and its current IP >> address is not the IP address stored in DNS. This seems like an >> unacceptable outcome. > > > Nothing prevents you from using some non-HIP mechanism to remain > reachable by non-HIP nodes. For example, if you can arrange one > of your rendezvous servers (or some other node) to forward packets > to you and packets sent by you, i.e. what is sometimes called a > HIP proxy, you can certainly make your A / AAAA record to point > to that node. But that is beyond the scope of core HIP, and > beyond the scope of the current WG charter. > So rather than just letting mobile nodes do dynamic DNS updates, you are suggesting a better alternative is to: 1) Implement and deploy rendezvous servers 2) Modify existing DNS implementations to support a new resource record type for the rendezvous server (doubtful that proprietary implementations would ever evolve to support it) 3) Specify, implement, and deploy HIP proxies (all of which are challenging) and then possibly suffer the resultant triangle based routing Doesn't that seem like alot of effort just to avoid dynamic DNS updates from mobile nodes? > Two questions: > > - Have you read what the architecture draft says about rendezvous? Yep. > Does that make sense to you? No...not given that dynamic DNS updates appear to obviate the need for Rendezvous Servers. As for the problem of both nodes changing their addresses at the same time, HIP implementations could detect the loss of connectivity and query DNS for the peer's new IP address... > - Are you familiar with more advanced rendezvous concepts, like > Hi3 or rendezvous-based NAT traversal? > Not really, though I did quickly skim the doc and honestly I don't see how it makes a compelling argument in support of Rendezvous Servers when someone wants to use HIP simply for the purpose of maintaining connectivity with mobile nodes. Are there reasons beside not wanting to perform dynamic DNS updates that justify all the implementation and deployment costs that Rendezvous Servers seem to require? Thanks, Kevin From andrew@indranet.co.nz Thu Feb 3 16:13:00 2005 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Feb 3 16:13:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <4202904C.8070909@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> Message-ID: On 4/02/2005, at 9:57 AM, Kevin Grace wrote: > Hi Pekka, > > Thanks for the response. My comments are interspersed below... >> > So rather than just letting mobile nodes do dynamic DNS updates, you > are suggesting a better alternative is to: > 1) Implement and deploy rendezvous servers > 2) Modify existing DNS implementations to support a new resource > record type for the rendezvous server (doubtful that proprietary > implementations would ever evolve to support it) > 3) Specify, implement, and deploy HIP proxies (all of which are > challenging) and then possibly suffer the resultant triangle based > routing > > Doesn't that seem like alot of effort just to avoid dynamic DNS > updates from mobile nodes? Not if you want to support really low-latency mobility. Personally, I've always thought of the RVS as being supplementary to dynamic DNS; use it when either you can't do a DNS update (for example if you're not routable, and the RVS is going to send you to a proxy) or you want it done too fast (in the middle of a VoIP call, for example). > >> Two questions: >> >> - Have you read what the architecture draft says about rendezvous? > > Yep. > >> Does that make sense to you? > > No...not given that dynamic DNS updates appear to obviate the need for > Rendezvous Servers. As for the problem of both nodes changing their > addresses at the same time, HIP implementations could detect the loss > of connectivity and query DNS for the peer's new IP address... And lose connectivity for several seconds, at the very least. RVS does take a few round trips, but in most of the cases of interest that's much better than seconds. > > Are there reasons beside not wanting to perform dynamic DNS updates > that justify all the implementation and deployment costs that > Rendezvous Servers seem to require? Latency and providing some basics for the research group results to build on. Andrew From pekka.nikander@nomadiclab.com Fri Feb 4 05:10:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Feb 4 05:10:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> Message-ID: Trying to summarise, the WG motivation for rendezvous servers is latency. You just can't get sub-second (or even sub-10-second) latencies from the DNS. Going to anywhere below 30 minutes will have DNS performance consequences that will make the DNS WG to object, and possibly IESG to reject. At the RG side, the situation is richer. We have the new possibilities, such as Hi3. We have the need to act without DNS names, i.e., using HITs as primary identity handles. Thirdly, there is some tendency in seeking for alternatives for the DNS. What comes to your comment: >> So rather than just letting mobile nodes do dynamic DNS updates, you >> are suggesting a better alternative is to: >> 1) Implement and deploy rendezvous servers >> 2) Modify existing DNS implementations to support a new resource >> record type for the rendezvous server (doubtful that proprietary >> implementations would ever evolve to support it) >> 3) Specify, implement, and deploy HIP proxies (all of which are >> challenging) and then possibly suffer the resultant triangle based >> routing >> >> Doesn't that seem like alot of effort just to avoid dynamic DNS >> updates from mobile nodes? If you are saying that the requirements for added infrastructure may make HIP deployment harder, you are certainly right. To mitigate or counter that argument, we have to consider the following: - You can achieve small scale HIP deployment without DNS. That is what is happening now. People are using /etc/hosts to configure their peers' HITs. - For wider scale early deployment, you need proxies anyway. - There are concrete plans to deploy Hi3 in PlanetLab during this year. --Pekka From kgrace@mitre.org Fri Feb 4 09:16:00 2005 From: kgrace@mitre.org (Kevin Grace) Date: Fri Feb 4 09:16:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> Message-ID: <42038367.5030507@mitre.org> > Trying to summarise, the WG motivation for rendezvous servers is > latency. You just can't get sub-second (or even sub-10-second) > latencies from the DNS. Going to anywhere below 30 minutes will > have DNS performance consequences that will make the DNS WG to > object, and possibly IESG to reject. > Today, using readily available DNS implementations and without Rendezvous Servers, one can create an A record in an authoritative name server for a mobile host and assign it a time-to-live of 1 second. The longest the record could possibly be cached by non-authoritative name servers then is 1 second.When the node moves and changes IP addresses, it can successfully update its A record within the authoritative name server in less than a second. The total latency between when a node's address changes and when DNS is properly updated need not exceed a couple seconds and could well be closer to one second. This appears to be a perfectly legitimate usage of DNS. Why would the DNS WG or IESG have any authority or control over what an individual mobile node chooses for its time-to-live? On the other hand, using Rendezvous Servers will require modifications to DNS to support a new resource record type...this would definitely require acceptance by the DNS WG and unless demand for HIP is high, proprietary implementations of DNS may never be modified regardless of acceptance for the modifications within the DNS WG. The prospects here seem much less certain than simply adjusting time-to-live fields. >>> So rather than just letting mobile nodes do dynamic DNS updates, you >>> are suggesting a better alternative is to: >>> 1) Implement and deploy rendezvous servers >>> 2) Modify existing DNS implementations to support a new resource >>> record type for the rendezvous server (doubtful that proprietary >>> implementations would ever evolve to support it) >>> 3) Specify, implement, and deploy HIP proxies (all of which are >>> challenging) and then possibly suffer the resultant triangle based >>> routing >>> >>> Doesn't that seem like alot of effort just to avoid dynamic DNS >>> updates from mobile nodes? >> > > If you are saying that the requirements for added infrastructure > may make HIP deployment harder, you are certainly right. To > mitigate or counter that argument, we have to consider the > following: > > - You can achieve small scale HIP deployment without DNS. > That is what is happening now. People are using /etc/hosts > to configure their peers' HITs. One can achieve large scale HIP deployment without modifying DNS and without Rendezvous Servers. The HIP protocol appears to support optional certificates within the base exchange messages. By combining these certificates with HIP's opportunistic mode, there is a very simple and elegant way of obtaining a peer's host identity that is not vulnerable to man-in-the-middle attacks...and it doesn't require HIT's to be stored in DNS. > > - For wider scale early deployment, you need proxies anyway. Not if you avoid using Rendezvous Servers... HIP appears to be a wonderful mobility enabler and hopefully will be deployed widely. In order for that to happen though, it seems to make alot of sense to minimize the amount of complexity, effort, and acceptance which is required. Rendezvous Servers, modifying DNS, and HIP proxies seem to add lots of new challenges that are not really necessary in order for HIP to be widely deployable. The arguments in support of Rendezvous Servers (possibly reduced update latency, and "providing some basics for the research group results to build on") seem pretty thin; the arguments against them seem much more compelling...IMHO. Regards, Kevin From pekka.nikander@nomadiclab.com Fri Feb 4 10:46:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Feb 4 10:46:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <42038367.5030507@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> Message-ID: <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> Kevin, > Today, using readily available DNS implementations and without > Rendezvous Servers, one can create an A record in an authoritative > name server for a mobile host and assign it a time-to-live of 1 > second. The longest the record could possibly be cached by > non-authoritative name servers then is 1 second.When the node moves > and changes IP addresses, it can successfully update its A record > within the authoritative name server in less than a second. The total > latency between when a node's address changes and when DNS is properly > updated need not exceed a couple seconds and could well be closer to > one second. This is very good news indeed. Would you care to share us with a reference? > This appears to be a perfectly legitimate usage of DNS. Why would the > DNS WG or IESG have any authority or control over what an individual > mobile node chooses for its time-to-live? Well, I am certainly not a DNS expert. However, I have been told that you SHOULD not use TTL less than 30 minutes, or you will cause bad performance. But maybe all those people have been wrong. Googling revealed the following paper, which seems to indicate reverse: Performance and the Effectiveness of Caching, Jaeyeon Jung, Emil Sit, Hari Balakrishnan, Robert Morris Proc. ACM SIGCOMM Internet Measurement Workshop, 2001 http://nms.lcs.mit.edu/papers/dns-imw2001.html But they "fast" TTL seems still to be a few hundred seconds? >> - You can achieve small scale HIP deployment without DNS. >> That is what is happening now. People are using /etc/hosts >> to configure their peers' HITs. > > One can achieve large scale HIP deployment without modifying DNS and > without Rendezvous Servers. > The HIP protocol appears to support optional certificates within the > base exchange messages. By combining these certificates with HIP's > opportunistic mode, there is a very simple and elegant way of > obtaining a peer's host identity that is not vulnerable to > man-in-the-middle attacks...and it doesn't require HIT's to be stored > in DNS. If what you indicate about DNS is true, I would certain agree. OTOH, you still need a CA for that, but so do you need for many uses anyway. >> - For wider scale early deployment, you need proxies anyway. > > Not if you avoid using Rendezvous Servers... Yes, you do, as you have to support legacy hosts. They just don't work if you change your IP address dynamically. > HIP appears to be a wonderful mobility enabler and hopefully will be > deployed widely. In order for that to happen though, it seems to make > alot of sense to minimize the amount of complexity, effort, and > acceptance which is required. I fully agree. > Rendezvous Servers, modifying DNS, and HIP proxies seem to add lots of > new challenges that are not really necessary in order for HIP to be > widely deployable. I'm afraid we can't avoid proxies, but it would be great if we could do without DNS modifications, and initially without rendezvous servers. > The arguments in support of Rendezvous Servers (possibly reduced > update latency, and "providing some basics for the research group > results to build on") seem pretty thin; the arguments against them > seem much more compelling...IMHO. If you manage to convince the DNS WG that zero or near-zero TTL A/AAAA records are fine, my guess is that there are very few if any members of this WG that insist on rendezvous servers. --Pekka From kgrace@mitre.org Mon Feb 7 08:41:00 2005 From: kgrace@mitre.org (Kevin Grace) Date: Mon Feb 7 08:41:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> Message-ID: <42076FE3.3070304@mitre.org> Pekka Nikander wrote: > Kevin, > >> Today, using readily available DNS implementations and without >> Rendezvous Servers, one can create an A record in an authoritative >> name server for a mobile host and assign it a time-to-live of 1 >> second. The longest the record could possibly be cached by >> non-authoritative name servers then is 1 second.When the node moves >> and changes IP addresses, it can successfully update its A record >> within the authoritative name server in less than a second. The total >> latency between when a node's address changes and when DNS is >> properly updated need not exceed a couple seconds and could well be >> closer to one second. > > > This is very good news indeed. Would you care to share us with a > reference? Sure. From the London Communications Symposium in 2002: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf The authors in the referenced paper demonstrate empirically how fast DNS can perform zone transfers and the maximum update rate it can support for a given configuration. Note, they are using what today would be considered slow platforms (650 MHz PIII) and even better performance results can be obtained today. My own organization has conducted similar tests using faster hardware and have been able to support over 300 individual dynamic updates/sec where each mobile node has a unique TSIG key; each individual update completes in well under a second. >>> - For wider scale early deployment, you need proxies anyway. >> >> >> Not if you avoid using Rendezvous Servers... > > > Yes, you do, as you have to support legacy hosts. They just don't > work if you change your IP address dynamically. No, legacy hosts can be directly supported without proxies and without Rendezvous Servers. If a mobile node moves and updates DNS with its new IP address, it can be reached by HIP aware and HIP unaware (legacy) nodes. Why do you think proxies are required? Regards, Kevin From pekka.nikander@nomadiclab.com Tue Feb 8 11:48:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Feb 8 11:48:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <42076FE3.3070304@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> Message-ID: > Sure. From the London Communications Symposium in 2002... Sounds interesting. I'll return to this once I've read the paper. > Why do you think proxies are required? To me, mobility does not only mean reachability or initial rendezvous, but also session continuity. In other words, IP mobility means that you can keep your active TCP connections running when you change your address. That's why. --Pekka From kgrace@mitre.org Tue Feb 8 12:43:03 2005 From: kgrace@mitre.org (Kevin Grace) Date: Tue Feb 8 12:43:03 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> Message-ID: <4208FA03.6050503@mitre.org> Pekka Nikander wrote: >> Why do you think proxies are required? > > > To me, mobility does not only mean reachability or initial rendezvous, > but also session continuity. In other words, IP mobility means that > you can keep your active TCP connections running when you change your > address. That's why. Session continuity is achievable without proxies. In the case where only one of the HIP peers moves at a time and changes its address, the mobile node can readily send a HIP UPDATE to its peer (whose address has not changed) to indicate its new IP address, thus maintaining all existing transport layer sessions between them. In the more challenging case where both nodes move simultaneously and change addresses, upon detecting that HIP UPDATE messages are not getting ACK'd, a node can query DNS for the peer's new IP address and then proceed to send HIP UPDATE messages to the peer at the new address. This seems like a pretty straightforward modification to a HIP implementation...and it doesn't require proxies. The only requirement is for mobile nodes to dynamically update DNS. There are some additional pertinent details to this approach. One is: how does a HIP implementation learn a peer's hostname? This can be done in a variety of ways. One promising way is for a hostnames to be included in the optional CERT's during the base exchange. The nice thing about using CERT's during the base exchange is not only does it allow hostnames to be exchanged (which enables the above solution to the problem of both peers simultaneously moving) but it also allows HI's to be exchanged in "opportunistic mode" without exposing either to a man-in-the-middle attack. And since HI's can be securely exchanged, there is no longer a need to modify DNS to store HIPHI (as well as HIPRVS) records. Regards, Kevin From pekka.nikander@nomadiclab.com Tue Feb 8 23:13:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Feb 8 23:13:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <4208FA03.6050503@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> Message-ID: <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> >> To me, mobility does not only mean reachability or initial rendezvous, >> but also session continuity. In other words, IP mobility means that >> you can keep your active TCP connections running when you change your >> address. That's why. > > Session continuity is achievable without proxies. Towards legacy nodes? Remember, it was communication between HIP and legacy nodes that we were discussing about in the context of proxies. For HIP double jump you may still want to have HIP *rendezvous* servers, not proxies, or perhaps you can come along without, as you suggest. But I am getting a feeling that you are personally stuck to the idea of using the DNS. I agree that the DNS would be one nice alternative, provided that it works, which remains to be seen. OTOH, I don't think either rendezvous or DNS are a panacea; more probably both are needed. --Pekka From miika@iki.fi Wed Feb 9 03:19:01 2005 From: miika@iki.fi (Miika Komu) Date: Wed Feb 9 03:19:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <4208FA03.6050503@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> Message-ID: On Tue, 8 Feb 2005, Kevin Grace wrote: > Session continuity is achievable without proxies. In the case where only > one of the HIP peers moves at a time and changes its address, the mobile > node can readily send a HIP UPDATE to its peer (whose address has not > changed) to indicate its new IP address, thus maintaining all existing > transport layer sessions between them. In the more challenging case > where both nodes move simultaneously and change addresses, upon > detecting that HIP UPDATE messages are not getting ACK'd, a node can > query DNS for the peer's new IP address and then proceed to send HIP > UPDATE messages to the peer at the new address. This seems like a pretty > straightforward modification to a HIP implementation...and it doesn't > require proxies. The only requirement is for mobile nodes to dynamically > update DNS. If we talk about implementation stuff, I think you don't want to *require* the dependency on DNS. For example, the HIPL implementation is completely kernel based and you generally don't want to do DNS look-ups from the HIP module in such an implementation. According to the layering principle, it is better to keep the HIP layer independent from the "DNS layer" (i.e. application layer) after the initial contact. I haven't considered NA(P)Ts yet. Is there an advantage of using DNS vs. rendezvous with NATs? > There are some additional pertinent details to this approach. One is: > how does a HIP implementation learn a peer's hostname? This can be done > in a variety of ways. One promising way is for a hostnames to be > included in the optional CERT's during the base exchange. The HI can already include the hostname. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Julien.Laganier@Sun.COM Wed Feb 9 04:31:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Feb 9 04:31:01 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <42038367.5030507@mitre.org> References: <42027267.5090503@mitre.org> <42038367.5030507@mitre.org> Message-ID: <200502091033.39400.julien.laganier@sun.com> Hi Kevin, Please find my answer inlined below, On Friday 04 February 2005 15:15, Kevin Grace wrote: > On the other hand, using Rendezvous Servers will require > modifications to DNS to support a new resource record type...this > would definitely require acceptance by the DNS WG and unless demand > for HIP is high, proprietary implementations of DNS may never be > modified regardless of acceptance for the modifications within the > DNS WG. The prospects here seem much less certain than simply > adjusting time-to-live fields. Using Rendezvous Servers does not require to modify DNS per se. You can use a Rendezvous Servers (1) without DNS, (2) with non-HIP-aware DNS, and (3) with HIP-aware DNS. In (1), you are not using DNS so you supposedly gain knowledge of the IP address of your peer by out-of-band means. Hence, you're likely to be in position to also obtain the peers's HI/HIT, and possibly its RVS IP address. In (2), you are using non-HIP-aware DNS, hence you can resolve a FQDN into an A/AAAA RR. The A/AAAA record can also be used to store the RVS IP address, provided it is returned as the last RR in the RR set. The AAAA record can also be used to store the HIT (or IPv6 LSI), still if it is returned as the last RR in the RR set. In (3), you use A, AAAA, HIPHI and HIPRVS to store the appropriate informations. In both (2) and (3) you can still use DynDNS. RVS may is usefol when the scenario includes highly mobile or NATed nodes, or a more elaborated rendezvous architecture (ala Hi3). > > If you are saying that the requirements for added infrastructure > > may make HIP deployment harder, you are certainly right. To > > mitigate or counter that argument, we have to consider the > > following: > > > > - You can achieve small scale HIP deployment without DNS. > > That is what is happening now. People are using /etc/hosts > > to configure their peers' HITs. > > One can achieve large scale HIP deployment without modifying DNS > and without Rendezvous Servers. That's why the rendezvous server protocol and DNS extensions are in separate documents and not in the base protocol. > > - For wider scale early deployment, you need proxies anyway. > > Not if you avoid using Rendezvous Servers... > > HIP appears to be a wonderful mobility enabler and hopefully will > be deployed widely. In order for that to happen though, it seems to > make alot of sense to minimize the amount of complexity, effort, > and acceptance which is required. Rendezvous Servers, modifying > DNS, and HIP proxies seem to add lots of new challenges that are > not really necessary in order for HIP to be widely deployable. I am quite sure nobody in the WG would object if you choose to use HIP without rendezvous servers and without using the DNS extensions. These are optional components of HIP and are not required per se to use HIP. Even if you don't support RVS you should still be able to contacts nodes staying behind a RVS if you know their IP address or those of the RVS. The RVS protocol has been designed to be mostly transparent to Initiators. If you don't support DNS extensions you can store your IP addresses in A/AAAA RRs, and the HITs in the last AAAA RR returned in a set (yes, this is a hack). Thanks, --julien From kgrace@mitre.org Wed Feb 9 09:23:00 2005 From: kgrace@mitre.org (Kevin Grace) Date: Wed Feb 9 09:23:00 2005 Subject: [Hipsec] Rendezvous Server Concerns In-Reply-To: <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> Message-ID: <420A1C8B.2080108@mitre.org> Pekka Nikander wrote: >>> To me, mobility does not only mean reachability or initial rendezvous, >>> but also session continuity. In other words, IP mobility means that >>> you can keep your active TCP connections running when you change your >>> address. That's why. >> >> >> Session continuity is achievable without proxies. > > > Towards legacy nodes? Remember, it was communication between HIP and > legacy nodes that we were discussing about in the context of proxies. Perhaps if there was a draft on the HIP proxy, some of the discussion here about its purpose and functionality would be simpler. An earlier part of this thread seemed to indicate that HIP proxies were intended to make HIP nodes behind an RVS be reachable by legacy nodes. Now it seems that proxies are intended to allow mobile HIP nodes to maintain sessions with stationary legacy nodes regardless of whether RVS's are present. The former purpose, by itself, did not seem compelling enough to warrant the creation of HIP proxies if simply by avoiding RVS's the problem went away. On the other hand, the latter purpose seems to have alot of merit as one can envision numerous cases where it would be useful to maintain sessions between legacy nodes and mobile HIP nodes. Is a draft description of HIP proxies on the horizon? Is it envisioned that HIP proxies will be able to maintain sessions between legacy nodes and mobile HIP nodes without the existence of an RVS? > > For HIP double jump you may still want to have HIP *rendezvous* > servers, not proxies, or perhaps you can come along without, as you > suggest. But I am getting a feeling that you are personally stuck > to the idea of using the DNS. I agree that the DNS would be one > nice alternative, provided that it works, which remains to be seen. > OTOH, I don't think either rendezvous or DNS are a panacea; more > probably both are needed. > You may be right. If one really needs sub-second mobile update latencies, then RVS's may be warranted. If, on the other hand, one can get by with one second update latencies, then the additional RVS requirements of a HIP proxy server (for legacy node connectivity) and modifications to DNS for the HIPRVS records seem pretty steep. Thanks for the discussion. Kevin From thomas.r.henderson@boeing.com Wed Feb 9 16:12:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Feb 9 16:12:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Petri, thanks for producing this draft. I have several comments: More substantial: - I have previously suggested not making ESP a MUST implement. For now, I think it can stay that way but I would like to have some further discussion, perhaps after I submit a more lengthy draft on this topic. - I did not find the new conceptual protocols helpful-- to me, it seems unnecessary to add this terminology, unless you have some downstream plan to do something different with these packet exchanges. Wording such as "In a typical implementation, the parameters are included in R1, I2, and R2" seems to suggest that atypical implementations also may exist that include these parameters in other messages, and that we therefore have to be prepared for all possible situations, which I don't think is what is intended. I would suggest using the explicit R1, I2, R2, and UPDATE names for the packets instead of HES and HER.=20 - There are probably some additional things that need to be specified to cover some cases of multihoming, but I think we will need to collaborate a bit in the future on this point, since I don't have a concrete proposal for you now. For example, there are statements like (in 7.1) "Ensure that the outgoing ESP protected packet has proper IP addresses in its IP header" but it doesn't say explicitly how such bindings are maintained-- maybe need a reference to the mobility draft. =20 - I agree with the new ESP_INFO parameter - Section 4.1 (Implementation options) seems misplaced, perhaps. Maybe as an appendix? In any case, I don't think that the spec should RECOMMEND how to implement (last sentence). I would rather just see an explanation of what has to happen to the packets. For example, Section 3 of RFC 2406 describes ESP packet processing (both inbound and outbound). We should just have a similar section that points to RFC 2406 and mentions any differences in the processing. For example, Sections 3 and 4 (and maybe need to consider also Sections 7.1 and 7.2) could be reoutlined as follows: 3. Using ESP with HIP 3.1 ESP packet format (pointer to Sec 2 of RFC 2406) 3.2 ESP packet processing (pointer to Sec 3 of RFC 2406, explaining any diffs resulting from BEET mode, and perhaps add the existing Sec 3.2 on SPI semantics) 3.3 Security Association establishment and maintenance (existing Sec. 4.2-4.7) - Section 4.6, I disagree with disallowing ESP NULL-- it may have some operational use (maybe allow null encryption-- if both enc and auth are null, all ESP is providing is the SPI and sequence number, and there may be a better way to compress the HITs in such a case). Minor: - page 4: s/a symmetric pair of ESP/a pair of ESP/=20 - page 6: s/require some minor modifications in/require some minor additions to/ s/One new parameter is introduced for this purpose; the ESP_INFO parameter./The ESP_INFO parameter introduced above is also used for this purpose./ - page 6, 2nd paragraph. I found this confusing to read at first, then it was clearer after I read section 4.1. Perhaps the text needs to point forward to that. The next-to-last sentence doesn't make sense (the word "problems" seems misplaced). =20 - page 7, s/that are conceptually included in every packet// s/at every given/at any given/ - page 10, s/both HITs since a/both local and remote HITs since a/ - page 10, it is not clear from reading this document whether AES and HMAC-SHA-1-96 should be offered in the R1, or whether they are implicit and do not ever need to be offered as possible transforms. - page 11, s/that have been authenticated// s/conseptual/conceptual - page 18, s/ones carrying a HER1 information/ones carrying HER1 information/ - page 19, s/MAY responder, rate limited,/MAY respond (subject to rate limiting the responses)/ - page 20, sections 7.1 and 7.2 might need some similar reference to 2401bis for how to do security association lookup? - page 21, s/piggypacked/piggybacked/=20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Thursday, February 03, 2005 2:55 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Draft: ESP usage in HIP >=20 > Folks, >=20 > The ESP text is moved now from the Base specification into a=20 > new draft.=20 > The preliminary version 1 of this draft is available at: >=20 > http://www.hip4inter.net/drafts.php >=20 > Some notes: >=20 > The ESP setup and rekeying processes are defined as=20 > conceptual protocols HIP ESP Setup (HES) and HIP ESP Rekeying=20 > (HER). In a usual implementation, the contents of these=20 > packets is put in base exchange packets and UPDATEs, respectively. >=20 > The NES and SPI are proposed to be replaced with a single parameter:=20 > ESP_INFO. >=20 > Comments are appreciated. The intention is to make fixes=20 > during next week and submit the draft before the IETF=20 > deadline for -00 drafts (Feb 14) >=20 > BR, Petri >=20 > --=20 > 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 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 >=20 From petri.jokela@nomadiclab.com Thu Feb 10 11:44:01 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Feb 10 11:44:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Message-ID: On Wed, 9 Feb 2005, Henderson, Thomas R wrote: > More substantial: > - I have previously suggested not making ESP a MUST implement. For now, > I think it can stay that way but I would like to have some further > discussion, perhaps after I submit a more lengthy draft on this topic. Ok. We leave it as it is (for the time being). > - I did not find the new conceptual protocols helpful-- to me, it seems > unnecessary to add this terminology, unless you have some downstream > plan to do something different with these packet exchanges. Wording > such as "In a typical implementation, the parameters are included in R1, > I2, and R2" seems to suggest that atypical implementations also may > exist that include these parameters in other messages, and that we > therefore have to be prepared for all possible situations, which I don't > think is what is intended. I would suggest using the explicit R1, I2, > R2, and UPDATE names for the packets instead of HES and HER. The idea was that we do not bind the required information exchange to these particular HIP packets. Perhaps we could set up the ESP Security Association afterwards using UPDATE messages. I must admit that I have a similar feeling that the current text is not very reader friendly. I am not going to change this before the initial submission (Friday), but I would like to hear more comments on this. Based on the discussion, changes can be made to the next version of the draft. > - There are probably some additional things that need to be specified to > cover some cases of multihoming, but I think we will need to collaborate > a bit in the future on this point, since I don't have a concrete > proposal for you now. For example, there are statements like (in 7.1) > "Ensure that the outgoing ESP protected packet has proper IP addresses > in its IP header" but it doesn't say explicitly how such bindings are > maintained-- maybe need a reference to the mobility draft. Ok. I'll see the text tomorrow, but I suppose all changes go to the next version and we can discuss them later. > - I agree with the new ESP_INFO parameter Ok. > - Section 4.1 (Implementation options) seems misplaced, perhaps. Maybe > as an appendix? In any case, I don't think that the spec should > RECOMMEND how to implement (last sentence). > I would rather just see an > explanation of what has to happen to the packets. For example, Section > 3 of RFC 2406 describes ESP packet processing (both inbound and > outbound). We should just have a similar section that points to RFC > 2406 and mentions any differences in the processing. For example, > Sections 3 and 4 (and maybe need to consider also Sections 7.1 and 7.2) > could be reoutlined as follows: > 3. Using ESP with HIP > 3.1 ESP packet format > (pointer to Sec 2 of RFC 2406) > 3.2 ESP packet processing > (pointer to Sec 3 of RFC 2406, explaining any diffs resulting from BEET > mode, and perhaps add the existing Sec 3.2 on SPI semantics) > 3.3 Security Association establishment and maintenance > (existing Sec. 4.2-4.7) I'll come up with a proposal before next draft. I have only one day to fix the draft before my submission deadline. > - Section 4.6, I disagree with disallowing ESP NULL-- it may have some > operational use (maybe allow null encryption-- if both enc and auth are > null, all ESP is providing is the SPI and sequence number, and there may > be a better way to compress the HITs in such a case). I read 4.6 so that it is not illegal to use ESP NULL, but you have to configure it separately. In this case, data would "never" be in the network unprotected, unless you explicitly allow the host to do so. I would stick with the current text. Any opinions? Clarifications / changes needed to the text? BR, 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 petri.jokela@nomadiclab.com Fri Feb 11 08:01:00 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Feb 11 08:01:00 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Message-ID: <420CAC67.7090301@nomadiclab.com> Hi! I submitted the ESP draft to IETF. The document can also be found from: http://www.hip4inter.net/drafts.php I didn't have time to make any big changes base on Tom's comments. I made only one change in the text in addition to the typo fixes. > - page 10, it is not clear from reading this document whether AES and > HMAC-SHA-1-96 should be offered in the R1, or whether they are implicit > and do not ever need to be offered as possible transforms. I changed this a bit to make it mandatory to include the transport in the packet. Otherwise the negotiation is cancelled. Any opinions? "All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. If the Initiator does not support any of the transforms offered by the Responder in the R1 HIP packet, it should abandon the negotiation and inform peer with a NOTIFY message about a non-supported transform." BR, 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 pekka.nikander@nomadiclab.com Fri Feb 11 11:49:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Feb 11 11:49:00 2005 Subject: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <420CAC67.7090301@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> <420CAC67.7090301@nomadiclab.com> Message-ID: <7bf421bcd16d663547a3c6cc4fca0cb3@nomadiclab.com> > I changed this a bit to make it mandatory to include the transport in > the packet. Otherwise the negotiation is cancelled. Any opinions? > > "All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. > If the Initiator does not support any of the transforms offered by > the Responder in the R1 HIP packet, it should abandon the negotiation > and inform peer with a NOTIFY message about a non-supported > transform." Looks good other than that the NOTIFY packet is unnecessary. The responder doesn't have any state; it will simply ignore the NOTIFY. Having it to process an unprotected NOTIFY and change its policy would pose a security risk. In general, if the responder and initiator policies are incompatible, there is nothing one can do. The responder won't even know, unless the initiator completes the base exchange (without ESP) and THEN sends a NOTIFY. --Pekka From chvogt@tm.uka.de Tue Feb 15 06:13:00 2005 From: chvogt@tm.uka.de (Christian Vogt) Date: Tue Feb 15 06:13:00 2005 Subject: [Hipsec] New I-D: draft-vogt-hip-credit-based-authorization-00.txt Message-ID: <4211D90C.7080400@tm.uka.de> Hi HIP folks. End-Host Mobility with HIP as well as Mobile IPv6 require a reachability test of a mobile node's new IP address. This test must be performed before packets are sent to this new IP address to prevent malicious redirection attacks and third-party flooding. In the MIP6 and Mobopts groups, we have thought about a secure way to check a mobile node's reachability at a new IP address, subsequent to handover, *in parallel* with already having communications go through this new IP address. We particularly discussed a credit-based solution, Credit-Based Authorization (CBA). It turns out that CBA can be applied to End-Host Mobility with HIP as well. Pekka and I talked about this at the IETF 61 meeting in Washington D.C. The draft cited below gives an overview on CBA and explains its integration with HIP mobility. Your folks' opinions on this topic are greatly appreciated. Best regards, - Christian PS: I posted this email on the HIP RG's mailing list as well. Title...: Credit-Based Authorization for HIP Mobility with Concurrent IP-Address Tests Author..: Christian Vogt http://www.tm.uka.de/~chvogt/ro2/pub/2005/draft-vogt-hip-credit-based-authorization-00.txt Abstract End-host mobility with the Host Identity Protocol uses IP-address tests to protect against malicious packet redirection and third-party flooding. The tests cause handover signaling delays to increase by one round-trip time. This document proposes a credit-based strategy that allows peers to securely resume active communications after handover as soon as possible, and to pursue a concurrent IP-address test subsequently. The optimization thus eliminates the additional handover delay that IP-address tests entail. -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) From tkoponen@iki.fi Tue Feb 15 12:52:00 2005 From: tkoponen@iki.fi (Teemu Koponen) Date: Tue Feb 15 12:52:00 2005 Subject: [Hipsec] A new I-D: HIP Registration Extension Message-ID: Folks, A new draft that is a spin-off from the rendezvous draft: Title : Host Identity Protocol (HIP) Registration Extension Author(s) : T. Koponen, et al. Filename : draft-koponen-hip-registration-00.txt Pages : 13 Date : 2005-2-14 This document specifies a registration mechanism for the Host Identity Protocol that allows hosts to register with services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koponen-hip-registration -00.txt Teemu -- From thomas.r.henderson@boeing.com Tue Feb 15 22:16:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Feb 15 22:16:01 2005 Subject: [Hipsec] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, January 31, 2005 2:35 AM > To: Henderson, Thomas R > Cc: Petri Jokela; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Base HIP: 02 PRE1 >=20 > >>>> 3.2 Local Scope Identifier (LSI) > >> > >> While I think that we are doing good progress with LSIs=20 > currently at=20 > >> the RG discussion, it might still be a good option to move=20 > LSIs into=20 > >> a separate draft. Such a document could discuss LSIs, how=20 > they are=20 > >> used at the APIs and by applications, and _also_ define a HIP=20 > >> protocol extension for informing about used/assigned LSIs. > >> Opinions? > > > > I would favor such a document, scoped as "Using HIP with=20 > legacy APIs"=20 > > and it could contain more discussion about the LSIs and incorporate=20 > > the material in current Appendix A. > > > > I'd be willing to take a first cut at it. >=20 > Great! A draft should be hitting the IETF-announce list soon that is intended to replace Appendix A. I would suggest that Appendix A be removed from the base draft at some point. However, the new draft does not cover LSIs in detail, so I will back off (for now) the request to remove LSIs from the base draft. Some other comments on the pre2 draft: I reviewed only looking at the UPDATE portions, since they are coupled to the mobility draft (which will soon be updated as well). In Section 8.9, someone (Petri?) raised the issue of whether=20 UPDATE retransmissions should be exponentially backed off, like in TCP and many other protocols. I agree.. perhaps change 8.9 item 4 to say also "The UPDATE timer MAY be exponentially backed=20 off for subsequent retransmissions." Section 8.10, item 3 should start: "Additionally (or alternatively),..." since item 2 may not hold. For now, that is all I have on the UPDATE-- I think that it was a good first cut at extracting out the NES/ESP material. =20 Tom From andrew@indranet.co.nz Tue Feb 15 22:26:00 2005 From: andrew@indranet.co.nz (Andrew McGregor) Date: Tue Feb 15 22:26:00 2005 Subject: [Hipsec] Base HIP: 02 PRE1 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> Message-ID: <065d719af7ac51466e18d8bd94b4d19d@indranet.co.nz> On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: > > In Section 8.9, someone (Petri?) raised the issue of whether > UPDATE retransmissions should be exponentially backed off, like in > TCP and many other protocols. I agree.. perhaps change 8.9 item > 4 to say also "The UPDATE timer MAY be exponentially backed > off for subsequent retransmissions." > May I recommend SHOULD? Andrew From thomas.r.henderson@boeing.com Tue Feb 15 22:31:00 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Feb 15 22:31:00 2005 Subject: [Hipsec] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> =20 > -----Original Message----- > From: Andrew McGregor [mailto:andrew@indranet.co.nz]=20 > Sent: Tuesday, February 15, 2005 7:24 PM > To: Henderson, Thomas R > Cc: Petri Jokela; hipsec@honor.trusecure.com; Pekka Nikander > Subject: Re: [Hipsec] Base HIP: 02 PRE1 >=20 >=20 > On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: >=20 > > > > In Section 8.9, someone (Petri?) raised the issue of whether UPDATE=20 > > retransmissions should be exponentially backed off, like in TCP and=20 > > many other protocols. I agree.. perhaps change 8.9 item > > 4 to say also "The UPDATE timer MAY be exponentially backed off for=20 > > subsequent retransmissions." > > >=20 > May I recommend SHOULD? >=20 Yes, I guess that these are generally SHOULDs instead of MAYs. Tom From miika@iki.fi Wed Feb 16 04:34:01 2005 From: miika@iki.fi (Miika Komu) Date: Wed Feb 16 04:34:01 2005 Subject: [Hipsec] SHA1 broken? Message-ID: http://www.schneier.com/blog/archives/2005/02/sha1_broken.html -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From shep@alum.mit.edu Wed Feb 16 07:00:01 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Feb 16 07:00:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: Your message of Wed, 16 Feb 2005 11:33:10 +0200. Message-ID: > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html Does this mean that HITs will need to be 256 bits long now (for there are no crypto hash functions left standing with output shorter than 256 bits)? I think so. I wonder how long SHA256 will remain standing. -Tim Shepard shep@alum.mit.edu From jari.arkko@piuha.net Wed Feb 16 07:05:01 2005 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Feb 16 07:05:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: References: Message-ID: <42133673.5040907@piuha.net> Tim Shepard wrote: > Does this mean that HITs will need to be 256 bits long now (for there > are no crypto hash functions left standing with output shorter than > 256 bits)? I think so. Well, if those other functions are secure, do you have to use all the output bits? Seems like an output cut to 128 would suffice too, unless there's some weakness in the hash function. Presumably the SHA-1 weaknesses, if real, relate to some problem in the definition of the function rather than the mere insufficiency of the bits... --Jari From kgrace@mitre.org Wed Feb 16 07:27:00 2005 From: kgrace@mitre.org (Kevin Grace) Date: Wed Feb 16 07:27:00 2005 Subject: [Hipsec] Base HIP: 02 PRE1 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> Message-ID: <42133BFF.2050309@mitre.org> Considering that retransmissions could be due to lossy wireless links, recommending exponential backoff (a congestion avoidance mechanism) may not be always appropriate. "MAY" seems to recognize this possibility more than "SHOULD". Kevin Henderson, Thomas R wrote: > > > > >>-----Original Message----- >>From: Andrew McGregor [mailto:andrew@indranet.co.nz] >>Sent: Tuesday, February 15, 2005 7:24 PM >>To: Henderson, Thomas R >>Cc: Petri Jokela; hipsec@honor.trusecure.com; Pekka Nikander >>Subject: Re: [Hipsec] Base HIP: 02 PRE1 >> >> >>On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: >> >> >> >>>In Section 8.9, someone (Petri?) raised the issue of whether UPDATE >>>retransmissions should be exponentially backed off, like in TCP and >>>many other protocols. I agree.. perhaps change 8.9 item >>>4 to say also "The UPDATE timer MAY be exponentially backed off for >>>subsequent retransmissions." >>> >>> >>> >>May I recommend SHOULD? >> >> >> > >Yes, I guess that these are generally SHOULDs instead of MAYs. > >Tom >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec > > From thomas.r.henderson@boeing.com Wed Feb 16 17:09:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Feb 16 17:09:01 2005 Subject: [Hipsec] FW: I-D ACTION:draft-henderson-hip-generalize-00.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 16, 2005 7:11 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-henderson-hip-generalize-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalizing the HIP base protocol Author(s) : T. Henderson Filename : draft-henderson-hip-generalize-00.txt Pages : 19 Date : 2005-2-15 =09 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. This draft observes that HIP can be viewed as an instance of a more general migration towards decoupling identity from location in the Internet architecture, and shows how other proposals (mobile IP, multi6, mobike, and i3) fit into this framework. We argue that if the HIP base protocol were to be slightly generalized, it might be useful to other related efforts and might allow more experimental flexibility. Specifically, an extensible identifier TLV, the ability to define usage profiles for the HIP handshake, and a relaxation of the requirements that specific HIP messages carry specific parameters are the three changes suggested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henderson-hip-generalize-00.tx t From thomas.r.henderson@boeing.com Wed Feb 16 17:12:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Feb 16 17:12:01 2005 Subject: [Hipsec] FW: I-D ACTION:draft-henderson-hip-applications-00.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE7@xch-nw-27.nw.nos.boeing.com> -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 16, 2005 7:23 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-henderson-hip-applications-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using HIP with Legacy Applications Author(s) : T. Henderson Filename : draft-henderson-hip-applications-00.txt Pages : 9 Date : 2005-2-15 =09 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-00. txt From Gonzalo.Camarillo@ericsson.com Sun Feb 20 03:30:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sun Feb 20 03:30:01 2005 Subject: [Hipsec] Agenda requests, IETF 62 Message-ID: <42184A21.8040008@ericsson.com> Folks, we are officially starting to gather agenda requests for the HIP WG meeting in Minneapolis. The agenda needs to be ready by March 28th. So, please, send your requests by the end of this week (Friday, March 25th). You should send your agenda request to the chairs indicating: 1) the topic you want to present 2) related Internet-Drafts 3) length of the requested agenda-slot Thanks, Gonzalo HIP co-chair From Julien.Laganier@Sun.COM Tue Feb 22 06:48:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Feb 22 06:48:01 2005 Subject: [Hipsec] Agenda requests, IETF 62 In-Reply-To: <42184A21.8040008@ericsson.com> References: <42184A21.8040008@ericsson.com> Message-ID: <200502221248.00080.julien.laganier@sun.com> On Sunday 20 February 2005 09:28, Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for the HIP WG > meeting in Minneapolis. The agenda needs to be ready by March 28th. > So, please, send your requests by the end of this week (Friday, > March 25th). Dear HIP WG chairs, I'd like to request three presentation slots for the next HIP WG meeting in Minneapolis, with the following specifics: --------------------------------------------- > 1) the topic you want to present o HIP Registration Extensions > 2) related Internet-Drafts o draft-koponen-hip-registration-00.txt > 3) length of the requested agenda-slot o 10 min. --------------------------------------------- > 1) the topic you want to present o HIP Rendezvous Servers Extensions > 2) related Internet-Drafts o draft-ietf-hip-rvs-01.txt > 3) length of the requested agenda-slot o 10 min. --------------------------------------------- > 1) the topic you want to present o HIP Domain Name System Extensions > 2) related Internet-Drafts o draft-ietf-hip-dns-01.txt > 3) length of the requested agenda-slot o 5 min. Thanks, -- Julien Laganier Sun Microsystems, Inc. From Internet-Drafts@ietf.org Tue Feb 22 15:42:40 2005 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue Feb 22 15:42:40 2005 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-02.txt Message-ID: <200502222039.PAA17171@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 Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-02.txt Pages : 95 Date : 2005-2-22 This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-02.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-base-02.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-base-02.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: <2005-2-22155716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155716.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Tue Feb 22 15:42:42 2005 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue Feb 22 15:42:42 2005 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-01.txt Message-ID: <200502222039.PAA17136@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 : End-Host Mobility and Multi-Homing with Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-mm-01.txt Pages : 34 Date : 2005-2-22 This document defines a "locator" parameter for the Host Identity Protocol and specifies an end-host mobility mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-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-mm-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-mm-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: <2005-2-22155710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155710.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Tue Feb 22 15:42:45 2005 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue Feb 22 15:42:45 2005 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-01.txt Message-ID: <200502222039.PAA17188@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 (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-01.txt Pages : 27 Date : 2005-2-22 This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-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-dns-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-dns-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: <2005-2-22155722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155722.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Tue Feb 22 15:42:50 2005 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue Feb 22 15:42:50 2005 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-01.txt Message-ID: <200502222039.PAA17195@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 (HIP) Rendezvous Extensions Author(s) : J. Laganier, L. Eggert Filename : draft-ietf-hip-rvs-01.txt Pages : 21 Date : 2005-2-22 This document discusses a Rendezvous extension for the Host Identity Protocol (HIP). The Rendezvous extension extend HIP and the HIP registration extension for initiating communication between HIP nodes via HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-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-rvs-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-rvs-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: <2005-2-22155727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-rvs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-rvs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155727.I-D@ietf.org> --OtherAccess-- --NextPart-- From gmp@research.panasonic.com Tue Feb 22 16:33:02 2005 From: gmp@research.panasonic.com (Greg Perkins) Date: Tue Feb 22 16:33:02 2005 Subject: [Hipsec] SHA1 broken? References: <42133673.5040907@piuha.net> Message-ID: <073b01c51928$36411bb0$ef01a996@gmp> The HIT needs two properties: 1) probably unique 2) a identifier for the HI SHA1 will still supply property 1). As for property 2), I thought HIP was using a non-keyed SHA1 hash for HI=>HIT computation? Basically, HIP is using SHA1's "randomness" property to meet property 1), yes? In this case, there is nothing to break and property 2) holds as well. As for using keyed SHA1 for say, signing a packet or whatnot, then yes, looks like SHA256 will have to be used soon. Greg Perkins ----- Original Message ----- From: "Jari Arkko" To: "Tim Shepard" Cc: "Miika Komu" ; Sent: Wednesday, February 16, 2005 7:02 AM Subject: Re: [Hipsec] SHA1 broken? > Tim Shepard wrote: > > > Does this mean that HITs will need to be 256 bits long now (for there > > are no crypto hash functions left standing with output shorter than > > 256 bits)? I think so. > > Well, if those other functions are secure, do you have to use > all the output bits? Seems like an output cut to 128 would > suffice too, unless there's some weakness in the hash > function. Presumably the SHA-1 weaknesses, if real, > relate to some problem in the definition of the function > rather than the mere insufficiency of the bits... > > --Jari > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > From gurtov@cs.helsinki.fi Sun Feb 27 11:53:03 2005 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Sun Feb 27 11:53:03 2005 Subject: [Hipsec] InfraHIP update Message-ID: <4221FACD.3020401@cs.helsinki.fi> Hi, The project "Infrastructure for HIP" got a new webpage at http://infrahip.hiit.fi. We plan a next release of HIPL compatible with current drafts on March 14th. Andrei From Gonzalo.Camarillo@ericsson.com Mon Feb 28 09:18:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Feb 28 09:18:01 2005 Subject: [Hipsec] Agenda IETF 62 Message-ID: <42232818.1080805@ericsson.com> Folks, this is the preliminary agenda for the Minneapolis meeting: http://hip.piuha.net/meetings/ietf62/agenda.html Note that every speaker has gotten more time than he requested. Regards, Gonzalo From Julien.Laganier@Sun.COM Mon Feb 28 09:33:00 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Feb 28 09:33:00 2005 Subject: [Hipsec] Agenda IETF 62 In-Reply-To: <42232818.1080805@ericsson.com> References: <42232818.1080805@ericsson.com> Message-ID: <200502281535.41127.julien.laganier@sun.com> Hi Gonzalo, On Monday 28 February 2005 15:18, Gonzalo Camarillo wrote: > Folks, > > this is the preliminary agenda for the Minneapolis meeting: > > http://hip.piuha.net/meetings/ietf62/agenda.html Thanks. I wonder if it would make sense to move the HIP registration slot before the HIP rendezvous slot (or vice versa), because a node use registration protocol to register with its rendezvous server. --julien From Gonzalo.Camarillo@ericsson.com Mon Feb 28 11:48:00 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Feb 28 11:48:00 2005 Subject: [Hipsec] Agenda IETF 62 In-Reply-To: <200502281535.41127.julien.laganier@sun.com> References: <42232818.1080805@ericsson.com> <200502281535.41127.julien.laganier@sun.com> Message-ID: <42234B51.4030208@ericsson.com> Done. Gonzalo Julien Laganier wrote: > Hi Gonzalo, > > On Monday 28 February 2005 15:18, Gonzalo Camarillo wrote: > >>Folks, >> >>this is the preliminary agenda for the Minneapolis meeting: >> >>http://hip.piuha.net/meetings/ietf62/agenda.html > > > Thanks. > > I wonder if it would make sense to move the HIP registration slot > before the HIP rendezvous slot (or vice versa), because a node use > registration protocol to register with its rendezvous server. > > --julien From thomas.r.henderson@boeing.com Mon Feb 28 12:04:02 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Feb 28 12:04:02 2005 Subject: [Hipsec] Agenda IETF 62 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> Gonzalo, i) it would seem to make sense to keep the discussion on HIP-MM draft together-- suggest moving my presentation on hip-mm to just before Christian's slot ii) likewise, the draft on generalizing HIP pertains to the base spec and could be moved up to the third slot. Tom=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Monday, February 28, 2005 6:18 AM > To: HIP > Cc: David Ward > Subject: [Hipsec] Agenda IETF 62 >=20 > Folks, >=20 > this is the preliminary agenda for the Minneapolis meeting: >=20 > http://hip.piuha.net/meetings/ietf62/agenda.html >=20 > Note that every speaker has gotten more time than he requested. >=20 > Regards, >=20 > Gonzalo > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 >=20