From pekka.nikander@nomadiclab.com Sun Feb 1 08:24:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 1 08:24:00 2004 Subject: [Hipsec] Moving resynch into a separate draft? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC266@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC266@xch-nw-27.nw.nos.boeing.com> Message-ID: <3AB0D69A-54AF-11D8-B339-000393CE1E8C@nomadiclab.com> Given that getting the resynch design seems to be hard, and that it seems that we need some extensions (Unknown SPI) for the resynch packets anyway, I would suggest moving resynch into a separate draft in -10. (Let it stay for -09, since it is already there, and it might be good to get some implementation experience.) IMHO, that would allow easier discussion in the WG, and would allow the base draft to proceed faster. Opinions? --Pekka PS. I still have some backlog of earlier messages that I need to clear out at some point of time. From Jan.Melen@nomadiclab.com Mon Feb 2 01:53:00 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Mon Feb 2 01:53:00 2004 Subject: [Hipsec] Moving resynch into a separate draft? In-Reply-To: <3AB0D69A-54AF-11D8-B339-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC266@xch-nw-27.nw.nos.boeing.com> <3AB0D69A-54AF-11D8-B339-000393CE1E8C@nomadiclab.com> Message-ID: <200402020933.57296.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Sunday 01 February 2004 14:07, Pekka Nikander wrote: > Given that getting the resynch design seems to be hard, > and that it seems that we need some extensions (Unknown SPI) > for the resynch packets anyway, I would suggest moving > resynch into a separate draft in -10. (Let it stay for -09, > since it is already there, and it might be good to get some > implementation experience.) > > IMHO, that would allow easier discussion in the WG, and > would allow the base draft to proceed faster. > > Opinions? I would also like to see the resynch in separate draft due to that it seems= to=20 more complex than what one would expect. Here is one example what kind of=20 problem scenario I have played around: If host-A receives a ESP packet containing unknown SPI. Host-A will send a = I1=20 with resynch bit true. Now if the host-C wants to be nasty it can send ESP= =20 packets containing random SPIs from random src addresses and the host-A wil= l=20 respond with I1 to these packets.=20 Now if the host-C wants to spend the CPU cycles of host-A instead of just=20 sending ESP packets it can also send afaik R1 packets (those of course have= =20 to match with the faik ESP packets). Now host-A thinks that it has received= a=20 ESP from unknown SPI, host-A has sent a I1 and gotten a R1 back as response= =20 to the I1. Host-A starts to process R1 and spends some cycles on solving th= e=20 puzzle and in creation of I2 packet. Now there is a possibility to solve CPU exhausting problem by limiting the= =20 amount of ongoing HIP negotiations but still the host-C can make sure that= =20 host-A has the maximium number of HIP negotiations going on all the time. BR. Jan =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAHf1jp4iklvjQtTgRArCiAJ9yBM4sivjcz7g6Pg4CjxqS54yeeQCcDm7v zoNPWVuUWd1s/Z/hQOckqCE=3D =3DWubC =2D----END PGP SIGNATURE----- From thomas.r.henderson@boeing.com Mon Feb 2 09:48:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Feb 2 09:48:01 2004 Subject: [Hipsec] Moving resynch into a separate draft? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC273@xch-nw-27.nw.nos.boeing.com> I agree also that resync could be moved outside until it is more mature. I think that we will have a hard time defining a mechanism responding to unknown SPIs that doesn't result in some DoS vulnerability. However, many of these can be reasonably limited when processing unknown SPIs by either configuring policy rules on them (or blocking the response to them altogether), or if a host takes care to check "uptime" and=20 throws away these packets if the daemon has been running=20 for some time. > -----Original Message----- > From: Jan Mikael Melen [mailto:Jan.Melen@nomadiclab.com]=20 > Sent: Sunday, February 01, 2004 11:34 PM > To: Pekka Nikander; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Moving resynch into a separate draft? >=20 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi! >=20 > On Sunday 01 February 2004 14:07, Pekka Nikander wrote: > > Given that getting the resynch design seems to be hard, > > and that it seems that we need some extensions (Unknown SPI) > > for the resynch packets anyway, I would suggest moving > > resynch into a separate draft in -10. (Let it stay for -09, > > since it is already there, and it might be good to get some > > implementation experience.) > > > > IMHO, that would allow easier discussion in the WG, and > > would allow the base draft to proceed faster. > > > > Opinions? >=20 > I would also like to see the resynch in separate draft due to=20 > that it seems to=20 > more complex than what one would expect. Here is one example=20 > what kind of=20 > problem scenario I have played around: >=20 > If host-A receives a ESP packet containing unknown SPI.=20 > Host-A will send a I1=20 > with resynch bit true. Now if the host-C wants to be nasty=20 > it can send ESP=20 > packets containing random SPIs from random src addresses and=20 > the host-A will=20 > respond with I1 to these packets.=20 >=20 > Now if the host-C wants to spend the CPU cycles of host-A=20 > instead of just=20 > sending ESP packets it can also send afaik R1 packets (those=20 > of course have=20 > to match with the faik ESP packets). Now host-A thinks that=20 > it has received a=20 > ESP from unknown SPI, host-A has sent a I1 and gotten a R1=20 > back as response=20 > to the I1. Host-A starts to process R1 and spends some cycles=20 > on solving the=20 > puzzle and in creation of I2 packet. >=20 > Now there is a possibility to solve CPU exhausting problem by=20 > limiting the=20 > amount of ongoing HIP negotiations but still the host-C can=20 > make sure that=20 > host-A has the maximium number of HIP negotiations going on=20 > all the time. >=20 > BR. Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (FreeBSD) >=20 > iD8DBQFAHf1jp4iklvjQtTgRArCiAJ9yBM4sivjcz7g6Pg4CjxqS54yeeQCcDm7v > zoNPWVuUWd1s/Z/hQOckqCE=3D > =3DWubC > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From Julien.Laganier@Sun.COM Mon Feb 2 09:55:02 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Feb 2 09:55:02 2004 Subject: [Hipsec] Moving resynch into a separate draft? In-Reply-To: <3AB0D69A-54AF-11D8-B339-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC266@xch-nw-27.nw.nos.boeing.com> <3AB0D69A-54AF-11D8-B339-000393CE1E8C@nomadiclab.com> Message-ID: <200402021636.07229.julien.laganier@sun.com> On Sunday 01 February 2004 13:07, Pekka Nikander wrote: > Given that getting the resynch design seems to be hard, > and that it seems that we need some extensions (Unknown SPI) > for the resynch packets anyway, I would suggest moving > resynch into a separate draft in -10. (Let it stay for -09, > since it is already there, and it might be good to get some > implementation experience.) > > IMHO, that would allow easier discussion in the WG, and > would allow the base draft to proceed faster. > > Opinions? That's fine with me. Tnx, --julien From Julien.Laganier@Sun.COM Mon Feb 2 10:08:02 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Feb 2 10:08:02 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> Message-ID: <200402021648.51514.julien.laganier@sun.com> On Sunday 01 February 2004 00:43, Henderson, Thomas R wrote: > Petri, here are some comments: Tom, Petri (and others), please find below some thoughts, fwiw: > General: > i) In reading through the draft, it struck me that there are > lots of instances where HIP silently drops packets (if something > goes wrong, etc.). For example, if a certain parameter type > is not supported, HIP drops the packet. While it is necessary > to prevent exploitation of a "REJECT" mechanism, I think that > there probably will be some use to having a HIP REJECT (with > type code to denote the error) to tell the peer what went > wrong. Something to think about... I remember that while I was implementing and debugging RSIP (RFC3103), I found very useful the RSIP_ERROR TLV, which was embedding error code ala HTTP (i.e., x0y, where x denotes the error type and y the subtype). Perhaps we can specify similar error codes as well as rate limitation of these, while keeping their processing informal (i.e., no action taken upon receipt of HIP_ERROR, just log the error if the daemon is in debug mode) > ii) I'd like to ask that, when the issue tracker is restarted, > that "possible removal of Birthday count" be added to the list. > (see previous email message: > http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.ht >ml) If we move the RESYNC mechanism in another draft, IMHO the birthday count should be 1) optionnal and 2) defined in the new draft. > Specific: > - top of page 5, "identies" -> "identities" > > - The state machine doesn't seem to allow for retransmitted I2s. > If in ESTABLISHED, and I2 is received, it should not necessarily > cause drop of SAs or drop of I2 (due to birthday check fail)-- > it may just mean that R2 needs retransmitted. This means that > even though distinction between Initiator and Responder can mostly > be dropped when entering ESTABLISHED, there is still the > possibility that the Responder will need to retransmit the R2. > > - how about "UPD" -> "UPDATE" (global change)? I agree. > - I must have missed this in previous drafts, but why do we need > to have different parameter type codes for BIRTHDAY_COOKIE? My understanding is that R1s carry a cookie request, while I2s carry a cookie response, hence the different parameter type. Thanks, --julien From thomas.r.henderson@boeing.com Mon Feb 2 10:26:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Feb 2 10:26:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM]=20 > Sent: Monday, February 02, 2004 7:49 AM > To: Henderson, Thomas R; Petri Jokela; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Preliminary version of draft-moskowitz-hip-09 >=20 >=20 > If we move the RESYNC mechanism in another draft, IMHO the birthday=20 > count should be 1) optionnal and 2) defined in the new draft. I agree that these parameters (birthday, cookie) do not need to=20 be coupled. I support such a change. =20 > > - I must have missed this in previous drafts, but why do we need > > to have different parameter type codes for BIRTHDAY_COOKIE? >=20 > My understanding is that R1s carry a cookie request, while=20 > I2s carry a=20 > cookie response, hence the different parameter type. >=20 I was assuming that request/response is inferred by R1 or I2. I don't really care either way that much, but if we keep separate parameter types, I suggest naming them differently (e.g.,=20 "COOKIE_REQUEST" and "COOKIE_RESPONSE"), or "COOKIE" if one=20 parameter type is used. Tom From jeffrey.m.ahrenholz@boeing.com Mon Feb 2 18:25:02 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Mon Feb 2 18:25:02 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361DFB@xch-nw-09.nw.nos.boeing.com> Below are some spelling-only suggestions for this -09pre2 draft: page section suggestion 9 3.1.1 accomodate > accommodate 11 3.3 signalled > signaled 15 4.1.1 similarily > similarly 16 4.1.2 sents > sends 19 5.1 birthdate > birthday (?) 20 5.3 negotiaton > negotiation 31 6.2.2 registed > registered 32 6.2.3 talkin > talking must to represent > must use to represent 33 6.2.6 Suide > Suite-IDs 38 6.2.10 consequtive > consecutive 41 6.2.13 the the (repeated word) 43 6.2.15 nonexisting > nonexistent 49 7.5 Recipients's > Recipient's 49 7.6 NetBios > NetBIOS 50 7.7 Recipients's > Recipient's 51 7.8 Senders's > Sender's Recipients's > Recipient's 52 8.1 destinated > destined 53 8.2 succesful > successful 60 8.6 Ithe > the Icheck > check 66 9 Reponder's > Responder's 69 11.1 Initator > Initiator 70 11.2 Similarily > Similarly 70 11.5 algoritms > aglorithms 71 11.6 cryptoanalysis > cryptanalysis 82 Ap A applcations > applications 84 Ap C probablity > probability (x2) 85 Ap D implmentators > implementors 85 Ap D depracated > deprecated 86 Ap D legitimite > legitimate 89 Ap E Destionation > Destination -Jeff > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, January 30, 2004 6:03 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 >=20 >=20 > I uploaded pre2 version of the draft-moskowitz-hip-09 to >=20 > http://hip4inter.net/drafts.php >=20 > There are both text and html versions as well as diffs between 08 ->=20 > 09pre2 and 09pre1 -> 09pre2. >=20 > Please, feel free to comment. Shortly (before leaving home): >=20 > I have fixed the state machine (a bit) and changed the=20 > section 8 to meet=20 > the current idea of sending I1 as a response to an unknown=20 > ESP. This may=20 > still require fixes... >=20 > NES is changed to UPD, NES_INFO parameter to NES, state names=20 > changed in=20 > the state machine, RESYNC state added and R-bit added to the=20 > HIP header=20 > for RESYNC purposes (this requires still some thinking). >=20 > HIP_SIGNATURE (1&2) have new type numbers, we propose to leave some=20 > empty space behind them for possible future use (at the same=20 > time, HMAC=20 > type was changed to keep it below SIGs). >=20 > Appendix F contains now help for checksum verification. >=20 > Have a nice weekend! >=20 > Petri >=20 >=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 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com=20 > http://honor.trusecure.com/mailman/listinfo/hi> psec >=20 From petri.jokela@nomadiclab.com Tue Feb 3 00:16:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 3 00:16:02 2004 Subject: [Hipsec] Moving resynch into a separate draft? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC273@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC273@xch-nw-27.nw.nos.boeing.com> Message-ID: <401F3823.5080108@nomadiclab.com> Henderson, Thomas R wrote: > I agree also that resync could be moved outside until it is > more mature. Ok, it seems that people do not oppose this proposal. In that case, I will remove it from the base draft (after -09 and Seoul) and we can put it into a new one. /petri > I think that we will have a hard time defining a mechanism > responding to unknown SPIs that doesn't result in some DoS > vulnerability. However, many of these can be reasonably > limited when processing unknown SPIs by either configuring > policy rules on them (or blocking the response to them > altogether), or if a host takes care to check "uptime" and > throws away these packets if the daemon has been running > for some time. > -- 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 Tue Feb 3 01:24:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 3 01:24:00 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> Message-ID: <401F4818.2030703@nomadiclab.com> Henderson, Thomas R wrote: > Petri, here are some comments: > > General: > i) In reading through the draft, it struck me that there are > lots of instances where HIP silently drops packets (if something > goes wrong, etc.). For example, if a certain parameter type > is not supported, HIP drops the packet. While it is necessary > to prevent exploitation of a "REJECT" mechanism, I think that > there probably will be some use to having a HIP REJECT (with > type code to denote the error) to tell the peer what went > wrong. Something to think about... Ok, this might be a good idea. I'll add it to the issue list. > ii) I'd like to ask that, when the issue tracker is restarted, > that "possible removal of Birthday count" be added to the list. > (see previous email message: > http://honor.trusecure.com/pipermail/hipsec/2003-December/000365.html) I installed a new tracker (roundup) and it can be found from: http://hip4inter.net/cgi-bin/roundup.cgi/ The hip-base is ment for base draft issues and hip-mm for mobility and multihoming draft. There have been some problems while adding issues but it seems to work now. I noticed also that some of the issues may overlap. > - The state machine doesn't seem to allow for retransmitted I2s. > If in ESTABLISHED, and I2 is received, it should not necessarily > cause drop of SAs or drop of I2 (due to birthday check fail)-- > it may just mean that R2 needs retransmitted. This means that > even though distinction between Initiator and Responder can mostly > be dropped when entering ESTABLISHED, there is still the > possibility that the Responder will need to retransmit the R2. This is true and it must be fixed. > - how about "UPD" -> "UPDATE" (global change)? Can be done, no problem. > - I must have missed this in previous drafts, but why do we need > to have different parameter type codes for BIRTHDAY_COOKIE? As far as I can remember, the reason was to separate these semantically different packets from each other. > - regarding the critical parameter, what is the situation for > which a critical parameter is not recognized by the recipient > (Sec 6.2.1, page 29)? Shouldn't this cause an increment > of HIP version number? Do you mean that introducing new critical parameters should increase the HIP version? > - there are a couple of instances where packet processing > text is placed in the parameter definition section. e.g., > HMAC calculation and processing 6.2.11 and signature processing > (6.2.12)-- I think these sections should be in the packet > processing section 8, and keep section 6 limited to specifying > the syntax and semantics of the parameter fields. Ok, that's true. I'll try to fix this. > - Section 8.2-- processing incoming application data. > - first comment is that in sentence 1, it implies that IPsec > SAs are selected based on IP addresses, which is not > necessarily the case for BEET mode. The 2401bis defines, if I understand correctly, that the identification is based on SPIs. Shall we change the text: "1. Detect the proper IPsec SA using the SPI. If the resulting ..." > - in sentence 4, should note that demultiplexing is based > on HITs *and port numbers* Ok. /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 Tue Feb 3 02:22:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 3 02:22:01 2004 Subject: [Hipsec] Moving NES_INFO before Diffie-Hellman In-Reply-To: References: Message-ID: <401F557D.4020604@nomadiclab.com> Are there any thoughts about the following issue raised earlier by Pekka? /petri Pekka Nikander wrote: > I'd like to move the NES_INFO parameter so that it always > preceeds the Diffie-Hellman parameter. That would make > middlebox implementation slightly easier, since middle-boxes > need to track NES_INFO but they do not need to care about > Diffie-Hellman. > > The change would also make it easier to include several > REA parameters in a single NES packet. > > Hence, the new type values would be something like > > NES_INFO 9 Old SPI, New SPI and other > info needed for NES > > DIFFIE_HELLMAN 13 variable public key > > The new format for the NES packet would be > > IP ( HIP ( NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) > > Then, when REA is included, it would be > > IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) > > This may require some changes to the NES processing logic > on some implementations, but that shouldn't be too hard, > since the end-hosts need to scan for the HMAC before > processing the NES_INFO anyway. > > Any thoughts? -- 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 Tue Feb 3 03:01:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 3 03:01:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> Message-ID: <401F5EA3.1050007@nomadiclab.com> This mail includes now two separate issues: 1) Remove the Birthday from the BIRTHDAY_COOKIE and divide COOKIE into two different parameters. The Birthday will be completely moved into the new draft discussing about the resync. These changes are realistic in draft version -10 where the resync handling is removed. 2) HOST_ID_FQDN: Remove the current HOST_ID and rename the HOST_ID_FQDN as HOST_ID. The FQDN Length field tells if there is a FQDN or not ( length = 0 if not). This change could be done already in the draft version -09. I suppose that the reason for separating these two was originally the parameter structure that caused packet handling problems in the end-hosts. With the current HOST_ID_FQDN structure there should not be that kind of problems. New parameters follow. Opinions? /petri 1) BIRTHDAY_COOKIE ================== 6.2.4 COOKIE_REQUEST 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 28 Reserved Zero when sent, ignored when received Random # I random number K K is the number of verified bits Random #I and K are represented as 64-bit integers, in network byte order. 6.2.5 COOKIE_RESPONSE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length 28 Reserved Zero when sent, ignored when received Random # I random number Random # J random number Random #I and Random #J are represented as 64-bit integers, in network byte order. 2) HOST_ID ========== 6.2.9 HOST_ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HI Length | FQDN Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | FQDN / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 35 Length length in octets, excluding Type, Length, and padding HI length length of the Host Identity FQDN length length of the FQDN Host Identity actual host identity FQDN Fully Qualified Domain Name, in the binary format. The Host Identity is represented in RFC2535 [9] format. The algorithms used in RDATA format are the following: Algorithms Values RESERVED 0 DSA 3 [RFC2536] (REQUIRED) RSA 5 [RFC3110] (OPTIONAL) The format for the FQDN is defined in RFC1035 [2] Section 3.1. If there is no FQDN, the FQDN Length field is set to zero. -- 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 Julien.Laganier@Sun.COM Tue Feb 3 04:46:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Feb 3 04:46:00 2004 Subject: [Hipsec] Moving NES_INFO before Diffie-Hellman In-Reply-To: <401F557D.4020604@nomadiclab.com> References: <401F557D.4020604@nomadiclab.com> Message-ID: <200402031121.32182.julien.laganier@sun.com> On Tuesday 03 February 2004 09:02, Petri Jokela wrote: > Are there any thoughts about the following issue raised earlier by > Pekka? I support this change. Tnx, --julien > Pekka Nikander wrote: > > I'd like to move the NES_INFO parameter so that it always > > preceeds the Diffie-Hellman parameter. That would make > > middlebox implementation slightly easier, since middle-boxes > > need to track NES_INFO but they do not need to care about > > Diffie-Hellman. > > > > The change would also make it easier to include several > > REA parameters in a single NES packet. > > > > Hence, the new type values would be something like > > > > NES_INFO 9 Old SPI, New SPI and other > > info needed for NES > > > > DIFFIE_HELLMAN 13 variable public key > > > > The new format for the NES packet would be > > > > IP ( HIP ( NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) > > ) > > > > Then, when REA is included, it would be > > > > IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, > > HIP_SIGNATURE ) ) > > > > This may require some changes to the NES processing logic > > on some implementations, but that shouldn't be too hard, > > since the end-hosts need to scan for the HMAC before > > processing the NES_INFO anyway. > > > > Any thoughts? -- Julien Laganier SUN Microsystems Laboratories From pekka.nikander@nomadiclab.com Tue Feb 3 05:02:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Feb 3 05:02:00 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <401F5EA3.1050007@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> <401F5EA3.1050007@nomadiclab.com> Message-ID: Petri, On Feb 3, 2004, at 10:41, Petri Jokela wrote: > This mail includes now two separate issues: > > 1) Remove the Birthday from the BIRTHDAY_COOKIE and divide COOKIE > into two different parameters. The Birthday will be completely > moved into the new draft discussing about the resync. > > These changes are realistic in draft version -10 where the resync > handling is removed. This sounds good. > 2) HOST_ID_FQDN: Remove the current HOST_ID and rename the HOST_ID_FQDN > as HOST_ID. The FQDN Length field tells if there is a FQDN or not ( > length = 0 if not). Ok for me. > 6.2.4 COOKIE_REQUEST > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Random # I, 8 bytes | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | K, 8 bytes | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ How about removing reserved and making K only 4 bytes and before #I? Would save a few bytes. R1 and I2 are so different from each other anyway that having the same structure doesn't really matter any more. --Pekka From mkousa@cc.hut.fi Tue Feb 3 05:57:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Feb 3 05:57:00 2004 Subject: [Hipsec] Moving NES_INFO before Diffie-Hellman In-Reply-To: <401F557D.4020604@nomadiclab.com> References: <401F557D.4020604@nomadiclab.com> Message-ID: On Tue, 3 Feb 2004, Petri Jokela wrote: -> Are there any thoughts about the following issue raised earlier by Pekka? This change is ok. -- Windows NT - Version of Windows for optimized for crashing high-end servers. From jeffrey.m.ahrenholz@boeing.com Tue Feb 3 11:04:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Tue Feb 3 11:04:01 2004 Subject: [Hipsec] Moving NES_INFO before Diffie-Hellman Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361DFC@xch-nw-09.nw.nos.boeing.com> This change seems ok. It looks like the middlebox will also be scanning through and picking out the signature to validate the packet (sec 7.5) otherwise attackers could spoof UPDATE packets. This change would align with sec 7.3 of the -mm-02 draft. -Jeff > > I'd like to move the NES_INFO parameter so that it always preceeds the=20 > > Diffie-Hellman parameter. That would make middlebox implementation=20 > > slightly easier, since middle-boxes need to track NES_INFO but they=20 > > do not need to care about Diffie-Hellman. > >=20 > > The change would also make it easier to include several > > REA parameters in a single NES packet. > >=20 From petri.jokela@nomadiclab.com Fri Feb 6 07:26:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Feb 6 07:26:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <401F4818.2030703@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> Message-ID: <40239196.3010606@nomadiclab.com> Here is some new text for -09 version. Please comment before monday evening (finnish time), I will send the -09 on tuesday morning. BR, Petri === Removed old HOST_ID TLV, renamed old HOST_ID_FQDN as HOST_ID: 6.2.8 HOST_ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HI Length | FQDN Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | FQDN / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 35 Length length in octets, excluding Type, Length, and padding HI length length of the Host Identity FQDN length length of the FQDN Host Identity actual host identity FQDN Fully Qualified Domain Name, in the binary format. The Host Identity is represented in RFC2535 [9] format. The algorithms used in RDATA format are the following: Algorithms Values RESERVED 0 DSA 3 [RFC2536] (REQUIRED) RSA 5 [RFC3110] (OPTIONAL) The format for the FQDN is defined in RFC1035 [2] Section 3.1. If there is no FQDN, the FQDN Length field is set to zero. === Issue 25: change the order of NES and DIFFIE_HELLMAN parameters In 6.2 HIP parameters: NES 9 Old SPI, New SPI and other info needed for UPDATE DIFFIE_HELLMAN 13 variable public key In 7.5 UPDATE - the HIP New SPI Packet IP ( HIP ( NES, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) ===== Issue 24: move packet handling text from 6.x to 8.x Text removed from HMAC, HIP_SIGNATURE and HIP_SIGNATURE2, text added to a new subsection 8.3: 6.2.10 HMAC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65245 Length 20 HMAC 160 low order bits of the HMAC computed over the HIP packet, excluding the HMAC parameter and any following HIP_SIGNATURE or HIP_SIGNATURE2 parameters. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. The HMAC calculation and verification process is presented in Section 8.3.1 6.2.11 HIP_SIGNATURE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIG alg | Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65279 (2^16-2^8-1) Length length in octets, excluding Type, Length, and padding SIG alg Signature algorithm Signature the signature is calculated over the HIP packet, excluding the HIP_SIGNATURE TLV field, but including the HMAC field, if present. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated to the beginning of the HIP_SIGNATURE TLV when the signature is calculated. The signature algorithms are defined in Section 6.2.8. The signature in the Signature field is encoded using the proper method depending on the signature algorithm (e.g. in case of DSA, according to [10]). The HIP_SIGNATURE calculation and verification process is presented in Section 8.3.2 6.2.12 HIP_SIGNATURE_2 The TLV structure is the same as in Section 6.2.11. The fields are: Type 65277 (2^16-2^8-3) Length length in octets, excluding Type, Length, and padding SIG alg Signature algorithm Signature the signature is calculated over the R1 packet, excluding the HIP_SIGNATURE_2 TLV field, but including the HMAC field, if present. Initiator's HIT and Checksum field MUST be set to zero and the HIP packet length in the HIP header MUST be calculated to the beginning of the HIP_SIGNATURE_2 TLV when the signature is calculated. Zeroing the Initiator's HIT makes it possible to create R1 packets beforehand to minimize the effects of possible DoS attacks. Signature calculation and verification follows the process in Section 8.3.2. --8<--- 8.3 HMAC and SIGNATURE calculation and verification The following subsections define the actions for processing HMAC, HIP_SIGNATURE and HIP_SIGNATURE2 TLVs. 8.3.1 HMAC calculation The HMAC TLV is defined in Section 6.2.10. HMAC calculation and verification process: Packet sender: 1. Create the HIP packet, without the HMAC and possibly following HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. 2. Calculate the length field in the HIP header. 3. Compute the HMAC. 4. Add the HMAC TLV to the packet following possible HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. 5. Recalculate the length field in the HIP header. Packet receiver: 1. Verify the HIP header length field. 2. Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE or HIP_SIGNATURE2 fields, remove them too, saving the contents if they will be needed later. 3. Recalculate the HIP packet length in the HIP header and clear the checksum field (set it to all zeros). 4. Compute the HMAC and verify it against the received HMAC. 8.3.2 Signature calculation The following process applies both to the HIP_SIGNATURE and HIP_SIGNATURE2 TLVs. When processing HIP_SIGNATURE2, the only difference is that instead of HIP_SIGNATURE TLV the HIP_SIGNATURE2 TLV is used, and the Initiator's HIT is cleared (set to all zeros) before computing the signature. The HIP_SIGNATURE TLV is defined in Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section 6.2.12. Signature calculation and verification process: Packet sender: 1. Create the HIP packet without the HIP_SIGNATURE TLV. 2. Calculate the length field in the HIP header. 3. Compute the signature. 4. Add the HIP_SIGNATURE TLV to the packet. 5. Recalculate the length field in the HIP header. Packet receiver: 1. Verify the HIP header length field. 2. Save the contents of the HIP_SIGNATURE TLV and remove it from the packet. 3. Recalculate the HIP packet length in the HIP header and clear the checksum field (set it to all zeros). 4. Compute the signature and verify it against the received signature. The verification can use either the HI received from a HIP packet, the HI from a DNS query, if the FQDN has been received either in the HOST_ID or in the CER packet, or one received by some other means. -- 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 jeffrey.m.ahrenholz@boeing.com Fri Feb 6 11:35:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Fri Feb 6 11:35:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361E00@xch-nw-09.nw.nos.boeing.com> I think the new text looks good. The only part that seems a little unclear to me is (from 8.3.1 HMAC calculation): > 1. Create the HIP packet, without the HMAC and possibly following > HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. ... > 4. Add the HMAC TLV to the packet following possible HIP_SIGNATURE > or HIP_SIGNATURE2 TLVs. I would write something like: "1. Create the HIP packet, without the HMAC or any possible HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. ... 4. Add the HMAC TLV to the packet and any HIP_SIGNATURE or=20 HIP_SIGNATURE2 TLVs that may follow." The main idea being that the HMAC follows the packet, which is followed by a signature if needed, and the signature is computed over the packet+HMAC. -Jeff From mkousa@cc.hut.fi Fri Feb 6 15:34:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Fri Feb 6 15:34:01 2004 Subject: [Hipsec] Preliminary version of draft-moskowitz-hip-09 In-Reply-To: <40239196.3010606@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> <40239196.3010606@nomadiclab.com> Message-ID: On Fri, 6 Feb 2004, Petri Jokela wrote: -> Here is some new text for -09 version. Please comment before monday -> evening (finnish time), I will send the -09 on tuesday morning. I found nothing to complain except some really minor (I'm feeling pedantic today..) cosmetic comments on the field names and their respective description texts. Usually when I read some drafts or RFCs I interpret capitalized names as something which refer to some specific and defined parameters/values/etc. Then when I encounter names which are not written in capital letter, I have to think about whether the name means some specific and defined parameter/value/etc or some more or less large issue. Explicitly writing the names in capital letters decreases the possibility of misinterpretation of the given name. Especially when I'm new to some topic and I'm not familiar with the topic's vocabulary I almost every time have to use some time to think which interpretation is meant if it is not absolutely clear from the context. -> 6.2.8 HOST_ID -> -> 0 1 2 3 -> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | Type | Length | -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | HI Length | FQDN Length | -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | Host Identity / -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> / | FQDN / -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> / | Padding | -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> -> Type 35 -> Length length in octets, excluding Type, Length, and -> padding Padding is capitalized in the picture but not in the description text of Length. -> HI length length of the Host Identity HI Length. -> FQDN length length of the FQDN FQDN Length. Also add "in octects" to HI Length and FQDN Length. -> 6.2.11 HIP_SIGNATURE -> -> 0 1 2 3 -> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | Type | Length | -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> | SIG alg | Signature / -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> / | padding | -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -> -> Type 65279 (2^16-2^8-1) -> Length length in octets, excluding Type, Length, and padding The text in the picture and in the description text should be Padding. -> 6.2.12 HIP_SIGNATURE_2 -> -> The TLV structure is the same as in Section 6.2.11. The fields are: -> -> Type 65277 (2^16-2^8-3) -> Length length in octets, excluding Type, Length, and padding Padding. -> Signature the signature is calculated over the R1 packet, -> excluding the HIP_SIGNATURE_2 TLV field, but -> including the HMAC field, if present. Initiator's -> HIT and Checksum field MUST be set to zero and the -> HIP packet length in the HIP header MUST be -> calculated to the beginning of the HIP_SIGNATURE_2 -> TLV when the signature is calculated. Hmm..6.2.1's "Checksum field" is written in small letter c. -> 8.3.1 HMAC calculation -> Packet sender: -> 2. Calculate the length field in the HIP header. -> 5. Recalculate the length field in the HIP header. -> Packet receiver: -> 1. Verify the HIP header length field. Length field. -> 3. Recalculate the HIP packet length in the HIP header and clear the -> checksum field (set it to all zeros). Checksum field. -> 8.3.2 Signature calculation -> -> Packet sender: -> -> 2. Calculate the length field in the HIP header. -> 5. Recalculate the length field in the HIP header. -> Packet receiver: -> -> 1. Verify the HIP header length field. -> 3. Recalculate the HIP packet length in the HIP header and clear the -> checksum field (set it to all zeros). Length field, Checksum field. -- Excessive login or logout messages are a sure sign of senility. From Gonzalo.Camarillo@ericsson.com Fri Feb 6 16:06:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Feb 6 16:06:01 2004 Subject: [Hipsec] Supplemental Page Message-ID: <40240B54.2080704@ericsson.com> Folks, we have just set up our supplemental web page: http://hip.piuha.net/ The page is still under construction, but if you have a HIP related draft, let us know and we will list it under: http://hip.piuha.net/drafts/ Comments and suggestions to improve this web page (e.g., information that you think it should be there but it isn't) are welcome. Regards, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From Gonzalo.Camarillo@ericsson.com Fri Feb 6 16:10:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Feb 6 16:10:01 2004 Subject: [Hipsec] Agenda requests Message-ID: <40240C54.9020604@ericsson.com> Folks, we will be elaborating the agenda for Seoul shortly. So, you can start sending us your agenda requests. All the agenda requests will be listed under: http://hip.piuha.net/meetings/ietf59/requests.html Make sure that your request is listed there. If it is not, it is because we lost it ;o) If you use the html template below to send me your agenda requests, you will make my life easier. Pekka Nikander Mobility and Multihoming
10
draft-nikander-hip-mm-01.txt Thanks, Gonzalo HIP co-chair This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From pekka.nikander@ericsson.com Sat Feb 7 03:36:03 2004 From: pekka.nikander@ericsson.com (Pekka Nikander) Date: Sat Feb 7 03:36:03 2004 Subject: [Hipsec] Supplemental Page In-Reply-To: <40240B54.2080704@ericsson.com> References: <40240B54.2080704@ericsson.com> Message-ID: Gonzalo, Good job. If you have time, you may want to grab some old draft versions etc. from http://www.tml.hut.fi/~pnr/HIP/ --Pekka On Feb 6, 2004, at 23:47, Gonzalo Camarillo wrote: > Folks, > > we have just set up our supplemental web page: > > http://hip.piuha.net/ > > The page is still under construction, but if you have a HIP related > draft, let us know and we will list it under: > > http://hip.piuha.net/drafts/ > > Comments and suggestions to improve this web page (e.g., information > that you think it should be there but it isn't) are welcome. > > Regards, > > Gonzalo > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we > only send and receive e-mails on the basis that we are not liable for > any such corruption, interception, amendment, tampering or viruses or > any consequences thereof. > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec From Gonzalo.Camarillo@ericsson.com Sat Feb 7 09:30:02 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sat Feb 7 09:30:02 2004 Subject: [Hipsec] Supplemental Page In-Reply-To: References: <40240B54.2080704@ericsson.com> Message-ID: <40250031.7040506@ericsson.com> Pekka, thanks for the pointer. I have stored old versions of the drafts at: http://hip.piuha.net/morgue/ I have also added the minutes from MN. They can be fetched from: http://hip.piuha.net/meetings/ietf58/ Gonzalo Pekka Nikander wrote: > Gonzalo, > > Good job. If you have time, you may want to grab > some old draft versions etc. from > http://www.tml.hut.fi/~pnr/HIP/ > > --Pekka > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From thomas.r.henderson@boeing.com Sat Feb 7 14:39:14 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Feb 7 14:39:14 2004 Subject: [Hipsec] Preliminary -09 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC28E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] > Sent: Monday, February 02, 2004 11:05 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: new tracker url >=20 >=20 > > - regarding the critical parameter, what is the situation for > > which a critical parameter is not recognized by the recipient > > (Sec 6.2.1, page 29)? Shouldn't this cause an increment > > of HIP version number? >=20 > Do you mean that introducing new critical parameters should=20 > increase the=20 > HIP version? It seems to me that if a parameter is specified as critical, but that the receiver doesn't recognize it and terminates processing of the packet, then there is effectively a version mismatch. That is, the critical parameter bit seems redundant=20 with the version field. =20 >=20 > > - Section 8.2-- processing incoming application data.=20 > > - first comment is that in sentence 1, it implies that IPsec > > SAs are selected based on IP addresses, which is not=20 > > necessarily the case for BEET mode. >=20 > The 2401bis defines, if I understand correctly, that the=20 > identification=20 > is based on SPIs. Shall we change the text: >=20 > "1. Detect the proper IPsec SA using the SPI. If the resulting ..." >=20 Fine. Tom=20 From Gonzalo.Camarillo@ericsson.com Mon Feb 9 11:05:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Feb 9 11:05:01 2004 Subject: [Hipsec] Issue tracker Message-ID: <4027B962.2000805@ericsson.com> Folks, I have added a link to the issue tracker in the supplemental web page: http://hip.piuha.net/ So, we already have a draft tracker and an issue tracker. I believe that we already have enough tools for this WG, but if somebody is missing some type of extra information in the web page, please let me know. Regarding the tracker, my preferred tracker is bugzilla, but we did not want to have the authors migrate all the existing issues to a new system again (they already did it once!). So, we will keep on working with the current tracker (which does provide all we need so far). Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From petri.jokela@nomadiclab.com Tue Feb 10 01:34:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 10 01:34:01 2004 Subject: [Hipsec] Preliminary -09 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC28E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC28E@xch-nw-27.nw.nos.boeing.com> Message-ID: <40288511.5050301@nomadiclab.com> Henderson, Thomas R wrote: >>From: Petri Jokela [mailto:petri.jokela@nomadiclab.com] >>>- regarding the critical parameter, what is the situation for >>>which a critical parameter is not recognized by the recipient >>>(Sec 6.2.1, page 29)? Shouldn't this cause an increment >>>of HIP version number? >> >>Do you mean that introducing new critical parameters should >>increase the >>HIP version? > > > It seems to me that if a parameter is specified as critical, > but that the receiver doesn't recognize it and terminates > processing of the packet, then there is effectively a version > mismatch. That is, the critical parameter bit seems redundant > with the version field. Ok, but should we reserve the possibility to define new critical parameters without changing the HIP version number? E.g. a case when some hosts can use this parameter when they know that the peer understands it (employee traveling with his laptop and contacting the corporate HIP gateway). This could be some kind of policy decision on the end-host; do not use the critical parameter unless you talk to the corporate gateway. I have interpreted 6.2.2 in this way. Another possibility is of course to explicitly say that it is not allowed to introduce new critical parameters unless the HIP version number is increased. /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 Tue Feb 10 04:15:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Feb 10 04:15:02 2004 Subject: [Hipsec] draft-moskowitz-hip-09 submitted Message-ID: <4028AADF.7070507@nomadiclab.com> I submitted draft-moskowitz-hip-09 few minutes ago. The draft can be fetched from: http://hip4inter.net/drafts.php /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 Tue Feb 10 12:32:04 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Feb 10 12:32:04 2004 Subject: [Hipsec] [Fwd: I-D ACTION:draft-eggert-hip-rendezvous-00.txt] Message-ID: <4028DCF4.5040400@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms000800080601010504030205 Content-Type: multipart/mixed; boundary="------------000702020403060205060002" This is a multi-part message in MIME format. --------------000702020403060205060002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I've put together an ID that discusses different alternatives for HIP rendezvous mechanisms, and would appreciate WG feedback. Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------000702020403060205060002 Content-Type: message/rfc822; name="I-D ACTION:draft-eggert-hip-rendezvous-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-eggert-hip-rendezvous-00.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from yamato.ccrle.nec.de (neptune.office [10.1.1.83]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2E6FE7A6A8; Mon, 9 Feb 2004 23:15:38 +0100 (CET) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by yamato.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i19MFbDR014154; Mon, 9 Feb 2004 23:15:37 +0100 (CET) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AqJ78-0004rU-Jc for ietf-announce-list@asgard.ietf.org; Mon, 09 Feb 2004 16:38:46 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AqIgV-0005AM-66 for all-ietf@asgard.ietf.org; Mon, 09 Feb 2004 16:11:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12277 for ; Mon, 9 Feb 2004 16:11:12 -0500 (EST) Message-Id: <200402092111.QAA12277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eggert-hip-rendezvous-00.txt Date: Mon, 09 Feb 2004 16:11:12 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Scanned-By: MIMEDefang 2.35 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identity Protocol (HIP) Rendezvous Mechanisms Author(s) : L. Eggert Filename : draft-eggert-hip-rendezvous-00.txt Pages : 27 Date : 2004-2-9 This document discusses rendezvous mechanisms for the Host Identity Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous Servers, improve operation when HIP nodes are multi-homed or mobile. They can also facilitate communication between HIP and non-HIP nodes. Possible rendezvous mechanisms differ in performance, compatibility, and impact on the HIP and Internet architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-hip-rendezvous-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eggert-hip-rendezvous-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-eggert-hip-rendezvous-00.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-2-9161124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eggert-hip-rendezvous-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-eggert-hip-rendezvous-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9161124.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000702020403060205060002-- --------------ms000800080601010504030205 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjEwMTMzMDI4WjAjBgkqhkiG 9w0BCQQxFgQUVmwTNiC71kBBJTs9dfDAMTjCAnIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA vBgRnutsqyBRwQIveDIrHt+DwjXP7tvYq6RxECxvIdjrLJcsCjkGCRvC/y2TwM5G43QB1iHK hSC87mbVdvuAUibSthvMJl7rlt5zz13TSfli1fyeOrI3n7Xc37E7lwesMbQK+0lzMgEZtxOb LlLvuTH+mnKCK6Cxo1t41GoeHz3N0Y/zpJ20MPmoT+6sx3ZNza/3AR4ZLCHyOVn88PtgrYXA 7RMFG8BC6nJfvp3cHtbr5SjPnQ+1CQSk0lK+J13Rij17wJ/jIkH8dd/r7ha7tu8dTg2ATjud PRasWQ8d6pEZT3bHAgG5CBCgRb5jZN1ks+Zew6h1FpgfCzVnZ88HhgAAAAAAAA== --------------ms000800080601010504030205-- From kslavov@hiit.fi Wed Feb 11 07:44:01 2004 From: kslavov@hiit.fi (Kristian Slavov) Date: Wed Feb 11 07:44:01 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 Message-ID: <402A2D6D.4090900@hiit.fi> Hi, First of all, I think the draft presented the rendezvous server to be more like a non-HIP-to-HIP gateway/proxy. This part is ok. Even though not directly suggested by the draft, I don't the idea that the "main" HIP architecture/infrastructure should handle non-HIP <-> HIP communication. The "default" rendezvous server, in my view, should be used solely for HIP purposes (i.e. not providing "legacy" support). I'd like to keep the base as simple as possible. We do not yet know, what are all the tasks the rendezvous servers will have to do. That is why we shouldn't overload them with functionality that is not essential for HIP. We could, for example, have the rendezvous servers helping in reverse mapping the HITs etc. The extensions are free to do more things (like providing non-HIP <-> HIP communication). BR, -- Kristian Slavov Research Assistant Helsinki Institute for Information Technology Gsm: +358-40-7220960 From lars.eggert@netlab.nec.de Wed Feb 11 12:05:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Wed Feb 11 12:05:01 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: <402A2D6D.4090900@hiit.fi> References: <402A2D6D.4090900@hiit.fi> Message-ID: <402A3540.30107@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms040402030704020107030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kristian, thanks for the feedback! Kristian Slavov wrote: > > First of all, I think the draft presented the rendezvous server to be > more like a non-HIP-to-HIP gateway/proxy. This part is ok. Even though > not directly suggested by the draft, I don't the idea that the "main" > HIP architecture/infrastructure should handle non-HIP <-> HIP > communication. The HIP architecture currently states that HIP nodes that use rendezvous servers will register the IP addresses of their rendezvous servers in the DNS, instead of their own. If they register these IP addresses in A records, non-HIP nodes will use the rendezvous servers' addresses to reach a HIP node. Thus, HIP-to-non-HIP communication will involve the rendezvous server due to this aspect of the current HIP architecure, not the proposed ID. Tom Henderson suggested off-list that this can be avoided by using a different record type for rendezvous servers. The -00 ID does not currently discuss this alternative. Another option would be to use a separate lookup mechanism from the DNS (see below.) > The "default" rendezvous server, in my view, should be used solely for > HIP purposes (i.e. not providing "legacy" support). I'd like to keep the > base as simple as possible. We do not yet know, what are all the tasks > the rendezvous servers will have to do. That is why we shouldn't > overload them with functionality that is not essential for HIP. I agree that the basic (HIP-HIP) rendezvous mechanism should be kept simple. But for the HIP-HIP case there is little reason to even use the DNS to store the HI->IP mapping, other than immediate deployability and a somewhat reduced base exchange latency. A separate mechanism may offer better lookup/update characteristics and may not only keep HIP simple, but also the DNS. I had assumed that one reason for using the DNS to hold the HI->IP information was compatibility with non-HIP nodes. If that is not the case, it may be useful to investigate non-DNS lookup mechanisms? Lars -- Lars Eggert NEC Network Laboratories --------------ms040402030704020107030703 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjExMTM1OTI4WjAjBgkqhkiG 9w0BCQQxFgQUqdm7Hc72cF4RRetOJe/axi9QZtAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA vEIu4Ua5UiIafGFog2zNlTFcnCZz80cpGHoyy7gS50lUiHPHhevdBcBjJ8gTgZCkKj9MlEOS R02ZdbyT+xuCQGWQH3b5maKta3Weng+6xYny10Y0Mo9YAhGHjVw3K5w9GbAXwqmm+RxVg2eW EvqEFESMooN8yKbJ4R+2+R+yU7aBMt7cMYiPP3DZzb3Ct1ttir8ErjcUBgUc4jZOzI3Dyo2j gMbDUYZSDgCV3l4PSAXPOBPNwNOcvT0Qnn4Ik8lVGvkNzv2EtQCdOgaAUHsA6QiDYiBS74Yj ajE6hgwGGyn2t3UFFE4JGWkgnQ0qa7qE+pSKbngKeqJLk81I7UefBgAAAAAAAA== --------------ms040402030704020107030703-- From mkousa@cc.hut.fi Wed Feb 11 13:33:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Feb 11 13:33:00 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: <402A2D6D.4090900@hiit.fi> References: <402A2D6D.4090900@hiit.fi> Message-ID: "4.1 Non-HIP Initiator to HIP Responder When non-HIP node I starts communication with R, it performs a DNS lookup on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I does not support HIP, it disregards the Host Identity HI(R) returned by the DNS lookup. Instead, it sets up transport-layer connections using the IP addresses IP(RVS) obtained from the DNS. The Rendezvous Server RVS must then transparently relay the communication to one of R's current IP addresses IP(R) in step #5." Let's assume that I want to make a connection to R: for FQDN(R) I get an IP address, say IP_RVS. Then I connect using this address IP_RVS, and RVS relays these packets somehow to R. I understood this, but let's assume that I want to connect directly to RVP (if I understood right the RVS is just a host in a network as any other host): for FQDN(RVS) I get the same IP address IP_RVS and then initiate a new connection to this address IP_RVS. What happens now ? How can RVP distinguish these two situations, whether the second connection should for relayed to R or is this connection really meant for RVP and therefor must not be relayed ? 4.2 HIP Initiator to Non-HIP Responder In figure 5 "#4 IP(I)" should be "#4 IP(R)". 5. Rendezvous Broker "When the non-HIP initiator I performs a DNS lookup in step #6" Should this be "step #5" ? On my opinion the draft was interesting and easy to read and understand. It's a good point to start this discussion on rendezvous mechanisms. -- printk(KERN_ERR "happy meal: Transceiver BigMac ATTACK!"); -- linux/drivers/net/sunhme.c From Spencer Dawkins" Message-ID: <009001c3f169$9d013cf0$0400a8c0@DFNJGL21> From: "Mika Kousa" To: Sent: Wednesday, February 11, 2004 1:14 PM Subject: Re: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 > > Let's assume that I want to make a connection to R: for FQDN(R) I get an > IP address, say IP_RVS. Then I connect using this address IP_RVS, and RVS > relays these packets somehow to R. I understood this, but let's assume > that I want to connect directly to RVP (if I understood right the RVS is > just a host in a network as any other host): for FQDN(RVS) I get the same > IP address IP_RVS and then initiate a new connection to this address > IP_RVS. > > What happens now ? How can RVP distinguish these two situations, whether > the second connection should for relayed to R or is this connection really > meant for RVP and therefor must not be relayed ? Don't we usually solve this problem using tunneling/double encapsulation? Is there another way? Spencer From lars.eggert@netlab.nec.de Thu Feb 12 07:52:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Feb 12 07:52:01 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: References: <402A2D6D.4090900@hiit.fi> Message-ID: <402B80AB.7030502@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms020608080301070509070800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mika Kousa wrote: > "4.1 Non-HIP Initiator to HIP Responder > > When non-HIP node I starts communication with R, it performs a DNS lookup > on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I does not > support HIP, it disregards the Host Identity HI(R) returned by the DNS > lookup. Instead, it sets up transport-layer connections using the IP > addresses IP(RVS) obtained from the DNS. The Rendezvous Server RVS must > then transparently relay the communication to one of R's current IP > addresses IP(R) in step #5." > > Let's assume that I want to make a connection to R: for FQDN(R) I get an > IP address, say IP_RVS. Then I connect using this address IP_RVS, and RVS > relays these packets somehow to R. I understood this, but let's assume > that I want to connect directly to RVP (if I understood right the RVS is > just a host in a network as any other host): for FQDN(RVS) I get the same > IP address IP_RVS and then initiate a new connection to this address > IP_RVS. > > What happens now ? How can RVP distinguish these two situations, whether > the second connection should for relayed to R or is this connection really > meant for RVP and therefor must not be relayed ? That is similar to identifying which HIP node an inbound packet is destined to. Section 4.3.3 discusses this. I will add this as an additional concern for the next revision. > 4.2 HIP Initiator to Non-HIP Responder > > In figure 5 "#4 IP(I)" should be "#4 IP(R)". > > > 5. Rendezvous Broker > > "When the non-HIP initiator I performs a DNS lookup in step #6" > > Should this be "step #5" ? Will fix these as well. Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms020608080301070509070800 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjEyMTMzMzMxWjAjBgkqhkiG 9w0BCQQxFgQUqzulE+ckJ8rhD7B1vXl3yGBoWlEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA C0na6ZJx8fhoRIWpcaLUib31FR5UrXxqeIZaNhQN4dtDTtpvW2CPt4iyFzJsccezw4nGo7uW i1uRNaVRgXGGlWdpYcyVrRF2f/dL6YOtKy9F5AzkIolX4yzwr5aH/YM0jKHNwF9ktek6jORR +bDhfHbY1MMiF5NeW8Y4Fl88jqE08eQ8Ewbg7Fyg1HR0j0FhlkD+BkeaSsSZ5xeDFxu3ASPd n79L/gWTUe0dcZZvbZkPKRC2fFBxbV5loo4swKZSTBPN1XhkBiKgrIm6ZEIRcoRwHF3kg/Mt My9rncvvG95vlHJXN19BgcMcgfqLrc9rHe8JyfekF5Xj5jbLo23e+AAAAAAAAA== --------------ms020608080301070509070800-- From lars.eggert@netlab.nec.de Thu Feb 12 07:54:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Feb 12 07:54:01 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: <009001c3f169$9d013cf0$0400a8c0@DFNJGL21> References: <402A2D6D.4090900@hiit.fi> <009001c3f169$9d013cf0$0400a8c0@DFNJGL21> Message-ID: <402B8121.7030703@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms020407070500000006080703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > From: "Mika Kousa" > To: > Sent: Wednesday, February 11, 2004 1:14 PM > Subject: Re: [Hipsec] General thoughts on ideas in > draft-eggert-hip-rendezvous-00 > >>What happens now ? How can RVP distinguish these two situations, whether >>the second connection should for relayed to R or is this connection really >>meant for RVP and therefor must not be relayed ? > > Don't we usually solve this problem using tunneling/double > encapsulation? Is there another way? Right. Section 5 discusses a solution based on tunneling. Lars -- Lars Eggert NEC Network Laboratories --------------ms020407070500000006080703 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjEyMTMzNTI5WjAjBgkqhkiG 9w0BCQQxFgQUfEITdEE0uel+u1vI4i7m8Q1DCYwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA XsdLWnuSrTCjdK1gcoq6aOfyt/VGvWEC+phSNWE591kBElrdjln2+BejiRhD9JZuxjlnW6V/ h2wPnqaBhSt6NPyTd5LlbeI3qa8Z+MfJl01yMyyzgK+Ww62If6oTdWWvveZnIXvtLgBwplO7 5a3R7Zr4oMQiJKSd0OvPwb3B/lhUJfR2CRiTYYnGY9S0wGUt0pgE0EvbDe1IKJ2gfrUQ/1jc fk9GgRJvRBumGwsP8dTjk3Vrk6sTEI2fWkV2KG5G86LhEXesZ1oHdb7SoKISa5SfSYTC8axP aXwVLaw1BCbE/+mu/7/i+nWT+rVJMtKlye8CbK6a1CZeHOxK+WRuuQAAAAAAAA== --------------ms020407070500000006080703-- From pekka.nikander@nomadiclab.com Thu Feb 12 09:15:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Feb 12 09:15:01 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: <402A3540.30107@netlab.nec.de> References: <402A2D6D.4090900@hiit.fi> <402A3540.30107@netlab.nec.de> Message-ID: Lars, >> First of all, I think the draft presented the rendezvous server to be >> more like a non-HIP-to-HIP gateway/proxy. This part is ok. Even >> though not directly suggested by the draft, I don't the idea that the >> "main" HIP architecture/infrastructure should handle non-HIP <-> HIP >> communication. > > The HIP architecture currently states that HIP nodes that use > rendezvous servers will register the IP addresses of their rendezvous > servers in the DNS, instead of their own. If they register these IP > addresses in A records, non-HIP nodes will use the rendezvous servers' > addresses to reach a HIP node. Thus, HIP-to-non-HIP communication will > involve the rendezvous server due to this aspect of the current HIP > architecure, not the proposed ID. My understanding from the discussions that Dave and I had with the ADs prior to the WG formation was that the WG work should really focus on a minimal rendezvous server, i.e. the baseline minimum needed to solve the double-jump and fast movement problems. That would probably be a HIP-only I1-only forwarding rendezvous server, possibly with some very small extensions. The rest should be worked on at the RG side. In HIP terminology (HIPnology?), the kind of HIP-to-non-HIP server is often referred to as a "proxy". > Tom Henderson suggested off-list that this can be avoided by using a > different record type for rendezvous servers. The -00 ID does not > currently discuss this alternative. Another option would be to use a > separate lookup mechanism from the DNS (see below.) I like the idea of different RR. Indeed, it makes the potential HIP RR to resemble even more IPSECKEY, as the RR could contain both the public key (HI) and the address(es) of rendesvouz server(s). Or maybe two RR types, one for the HI and the other one for rendezvous server address. > I agree that the basic (HIP-HIP) rendezvous mechanism should be kept > simple. But for the HIP-HIP case there is little reason to even use > the DNS to store the HI->IP mapping, other than immediate > deployability and a somewhat reduced base exchange latency. A > separate mechanism may offer better lookup/update characteristics and > may not only keep HIP simple, but also the DNS. I don't quite understand what you are trying to say. Could you elaborate? > > I had assumed that one reason for using the DNS to hold the HI->IP > information was compatibility with non-HIP nodes. If that is not the > case, it may be useful to investigate non-DNS lookup mechanisms? Yes, it has been a goal that both HIP and non-HIP hosts could contact HIP hosts using information from DNS. On the other hand, it would certainly be useful to look at non-DNS lookup mechanisms at the RG side. I would really encourage people to look at various DHT approaches (e.g. i3), and think about deployment incentives and scalability. What comes to the present problem, a bootleg solution is that HIP hosts list their HIP-only rendezvous server as the lowest priority address in DNS (in DNS servers that support that), making non-HIP hosts to try to contact the other addresses first. Alternatively, a HIP-only rendezvous server could be configured in such a way that it does not respond to non-HIP communications at all. In that case a non-HIP host would get a timeout and try another address. But I think that a separate RR type would probably be better. --Pekka From pekka.nikander@nomadiclab.com Thu Feb 12 09:17:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Feb 12 09:17:00 2004 Subject: Critical parameters vs. HIP version number (was Re: [Hipsec] Preliminary -09) In-Reply-To: <40288511.5050301@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC28E@xch-nw-27.nw.nos.boeing.com> <40288511.5050301@nomadiclab.com> Message-ID: <036E2489-5D6C-11D8-BD23-000393CE1E8C@nomadiclab.com> >>>> - regarding the critical parameter, what is the situation for >>>> which a critical parameter is not recognized by the recipient >>>> (Sec 6.2.1, page 29)? Shouldn't this cause an increment >>>> of HIP version number? >>> >>> Do you mean that introducing new critical parameters should increase >>> the HIP version? >> It seems to me that if a parameter is specified as critical, >> but that the receiver doesn't recognize it and terminates >> processing of the packet, then there is effectively a version >> mismatch. That is, the critical parameter bit seems redundant with >> the version field. > > Ok, but should we reserve the possibility to define new critical > parameters without changing the HIP version number? E.g. a case when > some hosts can use this parameter when they know that the peer > understands it (employee traveling with his laptop and contacting the > corporate HIP gateway). This could be some kind of policy decision on > the end-host; do not use the critical parameter unless you talk to the > corporate gateway. I have interpreted 6.2.2 in this way. > > Another possibility is of course to explicitly say that it is not > allowed to introduce new critical parameters unless the HIP version > number is increased. IMHO HIP version number should only be increased when introducing a protocol change that makes all old implementations to break. Introducing a critical parameter may or may not be such a change, depending on where and how it is introduced. For example, using critical parameters could be configurable depending on the peer HI, to be used only if the peer is known to support it. Hence, the "critical" bit would in this situation be more like a safeguard, make sure that nothing bad happens in the case of misconfiguration. It might be a good idea to clarify the draft. --Pekka From pekka.nikander@nomadiclab.com Thu Feb 12 09:19:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Feb 12 09:19:01 2004 Subject: COOKIE naming (was Re: [Hipsec] Preliminary version of draft-moskowitz-hip-09) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC274@xch-nw-27.nw.nos.boeing.com> Message-ID: <38EEE33E-5D6C-11D8-BD23-000393CE1E8C@nomadiclab.com> On Feb 2, 2004, at 18:04, Henderson, Thomas R wrote: >>> - I must have missed this in previous drafts, but why do we need >>> to have different parameter type codes for BIRTHDAY_COOKIE? >> >> My understanding is that R1s carry a cookie request, while >> I2s carry a >> cookie response, hence the different parameter type. >> > > I was assuming that request/response is inferred by R1 or I2. > I don't really care either way that much, but if we keep separate > parameter types, I suggest naming them differently (e.g., > "COOKIE_REQUEST" and "COOKIE_RESPONSE"), or "COOKIE" if one > parameter type is used. I agree with Tom, especially now that the cookies will be separated from the birthday value. --Pekka From pekka.nikander@nomadiclab.com Thu Feb 12 09:26:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Feb 12 09:26:01 2004 Subject: [Hipsec] HIP WG slot request: resynch and birthday Message-ID: <2F3516E5-5D6D-11D8-BD23-000393CE1E8C@nomadiclab.com> Gonzalo and Dave, One of the remaining tough issues in the base protocol draft is resynching in the case of one end-point loosing state. This is also related to the birthday value, which is used to protect the resynch process from replay attacks. I think that we should use some face time to discuss this issue at the meeting, and perhaps create a design team to produce a decent resynch/birthday mechanism. In the good case, the design team might be able to resolve the problem even while at Seoul :-) (Such things have happened before with HIP.) Anyway, a 10 minute slot for either presenting the problem and forming design team, or presenting a solution if one magically emerges before the meeting. --Pekka From lars.eggert@netlab.nec.de Fri Feb 13 08:30:03 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Fri Feb 13 08:30:03 2004 Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00 In-Reply-To: References: <402A2D6D.4090900@hiit.fi> <402A3540.30107@netlab.nec.de> Message-ID: <402CDB3B.80603@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms000102060504070304090300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, Pekka Nikander wrote: > > My understanding from the discussions that Dave and I had > with the ADs prior to the WG formation was that the WG > work should really focus on a minimal rendezvous server, > i.e. the baseline minimum needed to solve the double-jump > and fast movement problems. That would probably be a HIP-only > I1-only forwarding rendezvous server, possibly with some very > small extensions. > > The rest should be worked on at the RG side. thank you for this information. As mentioned in the submission email, I wasn't quite sure which group (WG or RG) this ID should be addressed to. Splitting the work into rendezvous mechanisms in the manner you describe seems useful. >> Tom Henderson suggested off-list that this can be avoided by using a >> different record type for rendezvous servers. The -00 ID does not >> currently discuss this alternative. Another option would be to use a >> separate lookup mechanism from the DNS (see below.) > > I like the idea of different RR. Indeed, it makes > the potential HIP RR to resemble even more IPSECKEY, > as the RR could contain both the public key (HI) and > the address(es) of rendesvouz server(s). Or maybe > two RR types, one for the HI and the other one for > rendezvous server address. I agree that a using something other than an A record for the IP address of the (simple, initial) rendezvous service makes sense. At the very least, it doesn't paint us in a corner with respect to a design for HIP proxies, as overloading the A record can. >> I agree that the basic (HIP-HIP) rendezvous mechanism should be kept >> simple. But for the HIP-HIP case there is little reason to even use >> the DNS to store the HI->IP mapping, other than immediate >> deployability and a somewhat reduced base exchange latency. A >> separate mechanism may offer better lookup/update characteristics and >> may not only keep HIP simple, but also the DNS. > > I don't quite understand what you are trying to say. Could you > elaborate? I was trying to point out that different ways for finding the set of IP addresses associated with a HIP node may exist, other than the DNS. The DNS should continue to map names into Host Identities (otherwise IP stacks need to change too much), but resolving a Host Identity into a set of IP addresses may involve some new lookup service instead of the DNS. I think you make exactly the same point in this later paragraph: > Yes, it has been a goal that both HIP and non-HIP hosts > could contact HIP hosts using information from DNS. > On the other hand, it would certainly be useful to look > at non-DNS lookup mechanisms at the RG side. I would > really encourage people to look at various DHT approaches > (e.g. i3), and think about deployment incentives and > scalability. Lars -- Lars Eggert NEC Network Laboratories --------------ms000102060504070304090300 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjEzMTQxMjExWjAjBgkqhkiG 9w0BCQQxFgQUcsD7txkMWgjLL6EE0qCaE/vjmLMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA yr4iLAjXEbJ6KViw4qYRQ3U6Bu3X6h6Owtugf2tt779pm4KDrk2X/IIfInmP2Mq5pGbjjlmk qQyiYR6maXDp+f3o/kqbkMF/eKJ/N880W1IRq/fyWXije1rl2jhst0lWT7Vw6sDoN9ACs3R3 o5KmrxyUJde9vLQON5rfZDqW33XkjcfVx3oaQKvTnSEijJ9mzwVPdIKlS+Hr7jF0zlWcp9Ls xMqqgSZN2TzDv4EzYQ50FIOY1igKBa8Lk7xtpaeGe1BMx1QWUl/YA6wZODVQM4j8khPdZCz3 cJnkmsOaPce/gKiqihy2Ybr26s0/O2zrIohP2Xsmy9EMefMqIK/0ugAAAAAAAA== --------------ms000102060504070304090300-- From pekka.nikander@nomadiclab.com Mon Feb 16 02:37:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Feb 16 02:37:00 2004 Subject: [Hipsec] About the HIP security model (was Re: New multi6 draft: WIMP) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> Message-ID: Senthil, > while HIP depends on a trusted model like DNSSEC, why it does extra > work (crypto puzzles) to avoid third party infrastructure? The Security Considerations section in the HIP architecture document (currently draft-moskowitz-hip-arch-05.txt) tries to explain this. If it fails, I'd like to get feedback; there is still time to fix that before the draft goes to RFC. Hence, I please read and comment that section. In particular, HIP does not include the crypto puzzle in order to *avoid* third party infrastructure. It does that in order to block a DoS attack where an attacker makes the Responder to make expensive crypto operations (D-H shared key generation and DSA verification) just by sending garbage keys to the Responder. > the incentive to use such schemes? Although, crypto puzzles work > against intruders, are we not penalizing a legitimate user by asking > him to waste his CPU cycle? Unfortunately you cannot avoid such "pay-first-something" schemes in an open network. You don't know whether the Initiator is a legitimate user or a DoS attacker before you check the signature. Unfortunately, checking the signature costs CPU, and therefore it makes sense to ask the user to "pay", or show that it is sincere, by burning some CPU *first*. In other words, you raise the bar for DoS attackers, by slightly penalizing legitimate users. Furthermore, in HIP you can adjust how hard the puzzle is. Hence, as long as you work under normal conditions, you can make the puzzle very easy to solve. As soon as you start to see load, you can change over to a scheme where solving the puzzle requires more CPU. See, e.g., the following paper, for more information. Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo, "DOS-resistant Authentication with Client Puzzles," in Christianson, Malcolm, Crispo, and Roe (Eds.) Security Protocols, 8th International Workshop, Cambridge, UK, April 3-5, 2000; revised papers, LNCS 2133, pp. 170-177, Springer 2001. > btw, is their any standardized RFC supporting weak authentication > methods? My understanding of "weak" authentication is that the whole area is pretty new. In fact, it looks like that we launched the term in our paper a couple of years ago: Jari Arkko and Pekka Nikander, "How to Authenticate Unknown Principals without Trusted Parties," to appear in Proceedings of Security Protocols Workshop 2002, Cambridge, UK, April 16-19, 2002. Mobile IPv6 RO depends on a "weak authentication" method, RR. Other than that, I don't know, but I may be just ignorant. > anyway, I wish that authors of HIP/WIMP explicitly state the > environment in which weak authentication is ok. draft-moskowitz-hip-arch-05.txt tries to discuss this form the HIP point of view. Again, if you find that discussion lacking or confusing, please let me know in which ways. If you could suggest improvements, that would be even better. --Pekka N. From saq66@umkc.edu Mon Feb 16 04:26:00 2004 From: saq66@umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Mon Feb 16 04:26:00 2004 Subject: [Hipsec] RE: About the HIP security model (was Re: New multi6 draft: WIMP) Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> >> the incentive to use such schemes? Although, crypto puzzles work >> against intruders, are we not penalizing a legitimate user by asking >> him to waste his CPU cycle? > > In other words, you raise the bar for DoS attackers, by slightly=20 > penalizing legitimate users. =20 =20 IMO, HIP is a great choice for mobility/wireless scenarios( otoh, it has to depend on something else for providing reliability.) But, one cannot=20 expect a PDA/mobile device to burn cycles for solving the puzzle. In a=20 wired-cum-wireless case, wired nodes are better placed than wireless=20 nodes ( wrt CPU cycles.) Also, imagine a scenario where an attacker has high CPU power and a legitimate user on a low end system. So, I would expect the puzzle to vary depending on the CPU power (i.e. if high CPU=20 power...it should solve fast.) I did see a work by MSR Penny Black folks = addressing this aspect. =20 >> btw, is their any standardized RFC supporting weak authentication >> methods? >=20 > My understanding of "weak" authentication is that the whole > area is pretty new. In fact, it looks like that we launched > the term in our paper a couple of years ago: =20 The term is introduced by your paper. But, it is pretty common to see research works in ad-hoc networks using weak authentication scheme.=20 e.g., Ross Anderson's Resurrecting Duckling model. But, i agree, the=20 security protocol 2002 survey paper is the widely cited one. I was=20 just curious to know about IETF related works using weak authentication. = thanks to both you and jari for the detailed replies.=20 =20 I would respond for the remaining parts of the mail after reading the=20 HIP arch draft. =20 =20 From pekka.nikander@nomadiclab.com Mon Feb 16 04:45:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Feb 16 04:45:01 2004 Subject: [Hipsec] Re: About the HIP security model (was Re: New multi6 draft: WIMP) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> Message-ID: > ... So, I would > expect the puzzle to vary depending on the CPU power (i.e. if high CPU > power...it should solve fast.) I did see a work by MSR Penny Black > folks > addressing this aspect. We did consider Mike Burrow's memory bound functions about a year ago, after their publication at NDSS. However, the general feeling was that they were too new (too little analysis) and too unclear from IPR point of view. Hence, the decision back then was to use SHA-1 for now. Of course, the decision can be reversed if it becomes clear that the memory bound functions (or some other form of puzzles) works better, and is sufficiently IPR free. --Pekka N. From pekka.nikander@nomadiclab.com Mon Feb 16 05:46:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Feb 16 05:46:00 2004 Subject: [Hipsec] HIP firewalling In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> Message-ID: <341E9474-6073-11D8-A37D-000393CE1E8C@nomadiclab.com> Senthil, > As a side note, how is HIP going to allow port blocking? Will it avoid > worm attacks by its puzzle mechanism. I don't think it is possible (but > it can reduce its spawning speed.) You can build a HIP firewall that uses HIs as the level of granularity. Beyond that, on the port level, you have to do locally at the host. But that's the right way to do it anyway, IMHO. The current worms and other internet fauna are a problem that SHOULD NOT be handled at the network level but by the operating system. Do you expect to run HIP in your Win98 box? --Pekka N. From saq66@umkc.edu Mon Feb 16 06:05:01 2004 From: saq66@umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Mon Feb 16 06:05:01 2004 Subject: [Hipsec] RE: HIP firewalling Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BD@KC-MAIL4.kc.umkc.edu> >> As a side note, how is HIP going to allow port blocking? Will it = avoid >> worm attacks by its puzzle mechanism. I don't think it is possible = (but >> it can reduce its spawning speed.) > > You can build a HIP firewall that uses HIs as the level of > granularity. Beyond that, on the port level, you have to > do locally at the host. But that's the right way to do it > anyway, IMHO. The current worms and other internet fauna > are a problem that SHOULD NOT be handled at the network level > but by the operating system. =20 The patch solution has its limitations. If i am a network admin, i have to track the infected hosts, wake up the user, convince them that it is really a problem, then ask him to patch his OS, and then allow the user to play with his machine. It is not a day's work but sometimes goes in the order of months. port blocking will fix the problem quickly, OTOH. So, IAB's recent port blocking concerns did not consider the total=20 picture. > Do you expect to run HIP in your Win98 box? of course. my school just provides windoze machine(and run linux through = emulation,VMware etc.) Is IETF just support non-windoze platforms? ;-) From saq66@umkc.edu Tue Feb 17 09:58:02 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Tue Feb 17 09:58:02 2004 Subject: [Hipsec] HIP security model In-Reply-To: <40308471.5030307@piuha.net> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> <40308471.5030307@piuha.net> Message-ID: <6.0.3.0.0.20040217085332.01dd9000@imap4.roos.umkc.edu> At 02:50 AM 2/16/2004, you wrote: >In HIP, its about the ability to bind all communications to the host >identity. This is different, but not at all weaker than authenticating >all nodes to some security infrastructure. For instance, I might be >able to prove that I am jari.arkko@ericsson.com, but does that entitle >me to grab all communications destined to at IP >layer? I am not able to follow your example. But, from a routing perspective, origin and path validation is the basic security requirement. I should be able to prove that a particular AS is allowed to announce a block of prefix (delegated according to the address allocation policy.) In this case, how HIP identity will be able to self-certify? It doesn't have enough information to prove address space ownership(a PKI/CA-web of trust model is necessary.) This is the only way to avoid address space thefts. From Julien.Laganier@Sun.COM Wed Feb 18 01:37:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Feb 18 01:37:00 2004 Subject: [Hipsec] HIP security model In-Reply-To: <6.0.3.0.0.20040217085332.01dd9000@imap4.roos.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> <40308471.5030307@piuha.net> <6.0.3.0.0.20040217085332.01dd9000@imap4.roos.umkc.edu> Message-ID: <200402180819.03365.Julien.Laganier@Sun.COM> Hi Senthil, Please find some thoughts included below, On Tuesday 17 February 2004 16:35, senthil ayyasamy wrote: > At 02:50 AM 2/16/2004, you wrote: > >In HIP, its about the ability to bind all communications to the host > >identity. This is different, but not at all weaker than authenticating > >all nodes to some security infrastructure. For instance, I might be > >able to prove that I am jari.arkko@ericsson.com, but does that entitle > >me to grab all communications destined to at IP > >layer? > > I am not able to follow your example. But, from a routing perspective, > origin and path validation is the basic security requirement. I should > be able to prove that a particular AS is allowed to announce a block > of prefix (delegated according to the address allocation policy.) In > this case, how HIP identity will be able to self-certify? HIP identity self-certify as a regular public-private key pair. If someon= e=20 claims to have a given public key, nobody can pretend to have the same pu= blic=20 key unless he knows the corresponding private key; so by keeping your pri= vate=20 key, you make your public key self-certifying (same things for self-signe= d=20 certificates). The same applies to the HI which is a mere public key > It doesn't > have enough information to prove address space ownership(a PKI/CA-web > of trust model is necessary.) This is the only way to avoid address > space thefts. If you generate your HI, nobody can steal it. Then you hash the HI into y= our=20 128bit HIT. An attacker wanting to steal your HIT would need to generate = a=20 public-private key pair that hash to the same HIT, and it doesn't appear = to=20 me as an easy task because it's somewhat equivalent to reversing the=20 _one-way_ hash function. Thanks, --julien From jari.arkko@piuha.net Wed Feb 18 02:57:00 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Feb 18 02:57:00 2004 Subject: [Hipsec] HIP security model In-Reply-To: <200402180819.03365.Julien.Laganier@Sun.COM> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> <40308471.5030307@piuha.net> <6.0.3.0.0.20040217085332.01dd9000@imap4.roos.umkc.edu> <200402180819.03365.Julien.Laganier@Sun.COM> Message-ID: <4033243C.5080508@piuha.net> Julien Laganier wrote in response to Senthil Ayyasamy: >>It doesn't >>have enough information to prove address space ownership(a PKI/CA-web >>of trust model is necessary.) This is the only way to avoid address >>space thefts. > > > If you generate your HI, nobody can steal it. Then you hash the HI into your > 128bit HIT. An attacker wanting to steal your HIT would need to generate a > public-private key pair that hash to the same HIT, and it doesn't appear to > me as an easy task because it's somewhat equivalent to reversing the > _one-way_ hash function. I agree with Julien on the above. Also, I'd like to ask you Senthil more about what you mean by address space ownership. If you mean host address ownership, I think it has been demonstrated many times in the past that PKI or web of trust is not at all suitable for that. Or does your personal / host certificate say something about the IPv6 addresses you can use? (If you have a cert; most people don't.) I thought so... And in HIP, we don't really need to show address ownership because all communications are tied to the HI/HIT. It is only necessary to show ownership of that. On the other hand, perhaps you are referring to some other property than host address ownership. Perhaps ownership of an address block by an access router or a border router? For that, PKIs may be useful, SEND, for instance, provides an optional capability for this using certs and I think there was also some BGP feature that made use of the same style of certs. But I'm not sure what address block ownership would have to do with HIP or MULTI6 problems. Perhaps you or someone else can clarify that to me. --Jari From saq66@umkc.edu Wed Feb 18 06:20:01 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Wed Feb 18 06:20:01 2004 Subject: [Hipsec] HIP security model In-Reply-To: <4033243C.5080508@piuha.net> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> <40308471.5030307@piuha.net> <6.0.3.0.0.20040217085332.01dd9000@imap4.roos.umkc.edu> <200402180819.03365.Julien.Laganier@Sun.COM> <4033243C.5080508@piuha.net> Message-ID: <6.0.3.0.0.20040218054527.01e1cef0@imap4.roos.umkc.edu> At 10:37 AM 2/18/2004 +0200, jari arkko wrote: >>>It doesn't >>>have enough information to prove address space ownership(a PKI/CA-web >>>of trust model is necessary.) This is the only way to avoid address >>>space thefts. >> >>If you generate your HI, nobody can steal it. Then you hash the HI into >>your 128bit HIT. An attacker wanting to steal your HIT would need to >>generate a public-private key pair that hash to the same HIT, and it >>doesn't appear to me as an easy task because it's somewhat equivalent to >>reversing the _one-way_ hash function. > >I agree with Julien on the above. > >Also, I'd like to ask you Senthil more about what you mean by >address space ownership. If you mean host address ownership, I think >it has been demonstrated many times in the past that PKI or web >of trust is not at all suitable for that. Or does your personal / >host certificate say something about the IPv6 addresses you can >use? (If you have a cert; most people don't.) I thought so... > >And in HIP, we don't really need to show address ownership because >all communications are tied to the HI/HIT. It is only necessary to >show ownership of that. I clearly see the benefit in coupling self-certifying identification with its on-going communications. Also, I understand the limitations of web of trust model for host identity. other than the documented problems, PKI or CA doesn't satisfy usable security (cost/complexity) requirements. For example, as a student, i should be able to deploy a secure application system without wasting my money and also, not depend on my university admins. Here, i can opt for HIP, instead of cert+SSL. But, by address space ownership, i actually meant address _block_ ownership; which is more than host identity. As you mention below, i was thinking about BGP security (and what HIP has to offer, as it provides authorization feature which IPsec lacks.) But, as the name suggests, HIP can only help in validating the "identifier" rather than "locator" claim. From a multi-homing perspective, locator validation is very important (more on this below.) btw, in my previous mail, i just meant to say, HIP is not a replacement to PKI. as a side note, weak authentication using hash chains can be useful in detecting invalid routes. An Autonomous system will hear more than single advertisement for the same destination. So, WIMP like feature (reverse hash chains) can be used for route consistency tests between those multiple advertisements. but, i am digressing ;-) >On the other hand, perhaps you are referring to some other property >than host address ownership. Perhaps ownership of an address block >by an access router or a border router? For that, PKIs may be useful, >SEND, for instance, provides an optional capability for this using >certs and I think there was also some BGP feature that made use of >the same style of certs. But I'm not sure what address block ownership >would have to do with HIP or MULTI6 problems. Perhaps you or someone >else can clarify that to me. I agree, address block ownership has nothing to do with HIP or its mobility extensions. But, it has more to do with site multi-homing. Site multi homing is a legitimate case of multiple locator origin. OTOH, MOAS (multi origin prefix) announcements due to intentional attacks are very common. So, how we are going to differentiate between a legitimate MOAS case (site multi-homing) and the intentional MOAS case? Here, locator verification is important than identifier verification. How HIP helps here? It needs S-BGP/ soBGP which depends on PKI/CA. also, locator re-writing solutions not just introduce redirection attacks but also, makes BGP AS path verification difficult. The threat attack draft seems to be silent on network based attack possibilities(it just extends MIP6 based attack scenarios.) In short, locator authorization has routing related security considerations which HIP cannot support. At 08:19 AM 2/18/2004 +0100, Julien Laganier wrote: > > >In HIP, its about the ability to bind all communications to the host > > >identity. This is different, but not at all weaker than authenticating > > >all nodes to some security infrastructure. For instance, I might be > > >able to prove that I am jari.arkko@ericsson.com, but does that entitle > > >me to grab all communications destined to at IP > > >layer? > > > > I am not able to follow your example. But, from a routing perspective, > > origin and path validation is the basic security requirement. I should > > be able to prove that a particular AS is allowed to announce a block > > of prefix (delegated according to the address allocation policy.) In > > this case, how HIP identity will be able to self-certify? > >HIP identity self-certify as a regular public-private key pair. If someone >claims to have a given public key, nobody can pretend to have the same public >key unless he knows the corresponding private key; so by keeping your private >key, you make your public key self-certifying (same things for self-signed >certificates). The same applies to the HI which is a mere public key taking your statement at its face value, a MITM attacker can easily subvert the initial exchange. but, yes, it can be avoided by a challenge-response mechanism and HIP supports such a feature. From mkousa@cc.hut.fi Wed Feb 18 08:15:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Feb 18 08:15:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: It seems that mm-01 has the same issue which I was thinking about when I was implementing mm-00: how does a host tell its peer that "remove all my addresses belonging to the Interface ID x immediately ?". This might be needed e.g. when you plug out a PCMCIA network card and the kernel notices this event, so it needs to inform the peer not to use anymore the card's addresses (assuming that the HIP implementation uses direct ifindex->Interface ID mapping). Simply by relying on (potentially very long) address timeouts might cause problems on the given example case when the peer tries to send data to old addresses. Is this a relevant issue or a non-issue ? In mm-00 I was experimenting with my own idea of "REA_INFO with no addresses". When the peer received this kind of REA_INFO, it just deleted every peer address which were associated with the Interface ID in given REA_INFO parameter and did not send any AC packets. From pekka.nikander@nomadiclab.com Wed Feb 18 13:17:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Feb 18 13:17:01 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing.com> Message-ID: <9B84D200-6244-11D8-9BF0-000393CE1E8C@nomadiclab.com> > It seems that mm-01 has the same issue which I was thinking about when > I > was implementing mm-00: how does a host tell its peer that "remove all > my > addresses belonging to the Interface ID x immediately ?". This might be > needed e.g. when you plug out a PCMCIA network card and the kernel > notices > this event, so it needs to inform the peer not to use anymore the > card's > addresses (assuming that the HIP implementation uses direct > ifindex->Interface ID mapping). Simply by relying on (potentially very > long) address timeouts might cause problems on the given example case > when > the peer tries to send data to old addresses. > > Is this a relevant issue or a non-issue ? I don't know, I have to check. But I don't have time before Seoul, sorry. Other than that, it has been brought to my attention via private communications that certain aspects of mm-01 either cannot be implemented or are very cumbersome to implement. I haven't had time to consider this, either, but I'll try to find time for these kinds of issues while in Seoul. In any case, my current assumption is that the RR mechanism, which is currently based on NES, may need big changes for -02. I'd like to get more feedback, especially from those who either have or have tried to implement it. --Pekka From mcr@sandelman.ottawa.on.ca Wed Feb 18 13:38:02 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed Feb 18 13:38:02 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: Your message of "Wed, 18 Feb 2004 15:57:47 +0200." Message-ID: <5839.1077132031@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mika" == Mika Kousa writes: Mika> "remove all my addresses belonging to the Interface ID x Mika> immediately ?". This might be needed e.g. when you plug out a Mika> PCMCIA network card and the kernel notices this event, so it needs Mika> to inform the peer not to use anymore the card's addresses Mika> (assuming that the HIP implementation uses direct Mika> ifindex-> Interface ID mapping). Simply by relying on (potentially Mika> very long) address timeouts might cause problems on the given Mika> example case when the peer tries to send data to old addresses. I'm not really up-to-speed on HIP-MM (yet). But, since I think it supports multiple Interface IDs, isn't the problem of an address going away like this equivalent to one path becoming very slow? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQDO6/oqHRg3pndX9AQHq2QQA2wtheEzyTmPzEnFDSl0Y/mFUsf0KHoae coQojQelBSQpS9KnulCS0Rtg0r74GPhgr3x0Y1jb2zz9MqSp+3GlJQjrDCTFM9yP 7zOokDoKC1zl1XzHZ6h7DlEcYXD8WpRw3DMcqNgpJwxw1qClauqi1PUxu73Ko7ro Ghpx/DRXZTY= =Hy+A -----END PGP SIGNATURE----- From Erik Nordmark Thu Feb 19 01:34:01 2004 From: Erik Nordmark (Erik Nordmark) Date: Thu Feb 19 01:34:01 2004 Subject: [Hipsec] HIP security model In-Reply-To: "Your message with ID" <6.0.3.0.0.20040218054527.01e1cef0@imap4.roos.umkc.edu> Message-ID: > also, locator re-writing solutions not just introduce redirection > attacks but also, makes BGP AS path verification difficult. The > threat attack draft seems to be silent on network based attack > possibilities(it just extends MIP6 based attack scenarios.) Can you flesh out more about the types of attacks you think are missing from the draft/discussion? Erik From andrew@indranet.co.nz Thu Feb 19 21:28:51 2004 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Feb 19 21:28:51 2004 Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B610B@xch-nw-27.nw.nos.boeing .com> Message-ID: <14300000.1077292243@ijir> --On Wednesday, February 18, 2004 03:57:47 PM +0200 Mika Kousa wrote: > It seems that mm-01 has the same issue which I was thinking about when I > was implementing mm-00: how does a host tell its peer that "remove all my > addresses belonging to the Interface ID x immediately ?". This might be > needed e.g. when you plug out a PCMCIA network card and the kernel notices > this event, so it needs to inform the peer not to use anymore the card's > addresses (assuming that the HIP implementation uses direct > ifindex->Interface ID mapping). Simply by relying on (potentially very > long) address timeouts might cause problems on the given example case when > the peer tries to send data to old addresses. > > Is this a relevant issue or a non-issue ? It's relevant, but shouldn't the peer notice ICMP messages (Host Unreachable or whatever) and correct fairly quickly anyway? > > In mm-00 I was experimenting with my own idea of "REA_INFO with no > addresses". When the peer received this kind of REA_INFO, it just deleted > every peer address which were associated with the Interface ID in given > REA_INFO parameter and did not send any AC packets. This sounds like a pretty good solution, and is how I was planning on doing it. Andrew -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 From pekka.nikander@nomadiclab.com Fri Feb 20 05:20:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Feb 20 05:20:01 2004 Subject: [Hipsec] Slot, agenda and scribes for the IRTF HIPRR BOF Message-ID: <5A116330-6394-11D8-8F32-000393CE1E8C@nomadiclab.com> As you probably have already figured out, we will have an IRTF HIPRR (HIP Related Research -- a working name) BOF on Monday night at 1930-2200. The tentative agenda is available at http://www.ietf.org/ietf/04mar/hiprr.txt The WG meeting is currently scheduled for Wednesday afternoon. (It *is* a WG, not a BOF, as per yesterday IESG decision!) In addition to what is already in the agenda, I guess that we also want to talk about NAT traversal and generalised rendezvous servers/proxies, as we do have drafts about those. If there are anything else that you would like to talk about, please let Tom and me know. As this is a RG (BOF) instead of an WG, we have more freedom to allocate time. IMHO, we are *supposed* to "waste" time in discussing what is useful and what is not, and in pursuing difficult research problems. Secondly, we will need two (or more) scribes so that we get the minutes correctly recorded. As before, I will process the notes from the scribes immediately after the meeting while I still will have fresh memories. Hence, I am looking for two or more people that are willing to type during the session and send in the raw notes, with all glory errors and spelling mistakes, as soon as the session ends. --Pekka From Gonzalo.Camarillo@ericsson.com Fri Feb 20 07:00:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Feb 20 07:00:01 2004 Subject: [Hipsec] Slot, agenda and scribes for the IRTF HIPRR BOF In-Reply-To: <5A116330-6394-11D8-8F32-000393CE1E8C@nomadiclab.com> References: <5A116330-6394-11D8-8F32-000393CE1E8C@nomadiclab.com> Message-ID: <40360071.1080307@ericsson.com> Pekka, > In addition to what is already in the agenda, I guess > that we also want to talk about NAT traversal and > generalised rendezvous servers/proxies, as we do have > drafts about those. Regarding the rendezvous work, I would like to have the basic mechanism (initial I1 routing; HIP-to-HIP) presented in the WG. More advanced features (also present in the same draft) can be discussed in the RG. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From pekka.nikander@nomadiclab.com Fri Feb 20 07:14:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Feb 20 07:14:03 2004 Subject: [Hipsec] Basic rendezvous for the WG (was Slot... for the IRTF HIPRR) In-Reply-To: <40360071.1080307@ericsson.com> References: <5A116330-6394-11D8-8F32-000393CE1E8C@nomadiclab.com> <40360071.1080307@ericsson.com> Message-ID: <4326F06F-63A4-11D8-8F32-000393CE1E8C@nomadiclab.com> Gonzalo, > Regarding the rendezvous work, I would like to have the basic > mechanism (initial I1 routing; HIP-to-HIP) presented in the WG. More > advanced features (also present in the same draft) can be discussed in > the RG. If nobody else volunteers, I can give a 5 min talk about the problem and the potential approach. Unfortunately I won't have time to write even a drafty draft before Seoul. (But maybe there on Monday or Tuesday.) --Pekka From Gonzalo.Camarillo@ericsson.com Sat Feb 21 02:53:02 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sat Feb 21 02:53:02 2004 Subject: [Hipsec] Preliminary agenda Message-ID: <40371869.2070008@ericsson.com> Folks, here you have the preliminary agenda of the WG. Comments are welcome. http://hip.piuha.net/meetings/ietf59/agenda.html Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From saq66@umkc.edu Mon Feb 23 19:40:01 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Mon Feb 23 19:40:01 2004 Subject: [Hipsec] SIGCOMM FDNA 04 In-Reply-To: <40371869.2070008@ericsson.com> References: <40371869.2070008@ericsson.com> Message-ID: <6.0.3.0.0.20040223192010.01e39b88@imap4.roos.umkc.edu> CFP of interest to HIPsec http://www.acm.org/sigcomm/sigcomm2004/fdna.html From Gonzalo.Camarillo@ericsson.com Tue Feb 24 02:58:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Feb 24 02:58:01 2004 Subject: [Hipsec] Identifying SIP user agents Message-ID: <403B0E23.1020704@ericsson.com> Folks, one of the goals of the HIP WG is to help other communities understand the implications of introducing this technology in the net. Here we have a situation where the multimedia community could benefict from the HIP work, or at least, from some of our ideas. The SIPPING WG is working on defining global identifiers for SIP (Session Initiation Protocol) user agents. That is, my SIP phone will have a global identifier, so that I can distinguish it from my other SIP devides (like my software based SIP user agent running in my laptop). the relevant drafts are: http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt The multimedia community was wondering whether they could use HIs or HITs for this purpose. They will welcome your comments. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From saq66@umkc.edu Tue Feb 24 03:38:01 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Tue Feb 24 03:38:01 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <403B0E23.1020704@ericsson.com> References: <403B0E23.1020704@ericsson.com> Message-ID: <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> At 10:41 AM 2/24/2004 +0200, Gonzalo Camarillo wrote: >The SIPPING WG is working on defining global identifiers for SIP (Session >Initiation Protocol) user agents. That is, my SIP phone will have a global >identifier, so that I can distinguish it from my other SIP devides (like >my software based SIP user agent running in my laptop). the relevant >drafts are: > >http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt >http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt without looking into the drafts, how it is different from globally routable UA URI? >The multimedia community was wondering whether they could use HIs or HITs >for this purpose. It can use if we solve the referral/rendezvous issue(i.e. SIP can use HI instead of IP address.) I have two questions about rendezvous/referral: 1. If HIPRR come up with a better-than-DNS naming resolution system, can applications bypass DNS and directly access the new system? It will be useful for many future applications like ad-hoc, sensor, P2P etc. 2. I was looking into draft-ietf-dnsext-mdns today. what are your views about LLMNR _like_ model + distributed object look-up for name resolution? From Gonzalo.Camarillo@ericsson.com Tue Feb 24 03:43:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Feb 24 03:43:01 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> References: <403B0E23.1020704@ericsson.com> <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> Message-ID: <403B18CF.7030404@ericsson.com> Hi, > without looking into the drafts, how it is different from globally > routable UA URI? A globally routable URI is a URI that routes to a particular user agent in the context of a *dialog*. That is, while I am in a session with you, you can use that URI to reach me. These type of URIs are generated by the server. > It can use if we solve the referral/rendezvous issue(i.e. SIP can use HI > instead of IP > address.) The global identifiers we are looking for do not even need to be routable. That is, it can be a sequence of bits that identify a UA. SIP provides other mechanisms to be able to contact such a UA. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From Julien.Laganier@Sun.COM Tue Feb 24 04:01:03 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Feb 24 04:01:03 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <40239196.3010606@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> <40239196.3010606@nomadiclab.com> Message-ID: <200402240943.58693.julien.laganier@sun.com> Folks, Sorry to get back to this issue so late, but after having implemented and tested interop with the new HOST_ID, I have to mention that I would have preffered to split the HOST_ID_FQDN TLV into two TLVs (HOST_ID and FQDN) rather than using only one, with its three length fields, which is IMHO (and when I'm coding ;-) very prone to error. So perhaps we could have two separate parameters, as for COOKIE and BIRTHDAY. Note that this doesn't preclude encryption of both HI and FQDN, because we could either put both into a single ENCRYPTED TLV, or put each of them into its own ENCRYPTED TLV. Any thoughts? Thanks, --julien > > Removed old HOST_ID TLV, renamed old HOST_ID_FQDN as HOST_ID: > > > 6.2.8 HOST_ID > > 0 1 2 > 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HI Length | FQDN Length > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Host Identity > | / > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / > | FQDN / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / > | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type 35 > Length length in octets, excluding Type, Length, and > padding > HI length length of the Host Identity > FQDN length length of the FQDN > Host Identity actual host identity > FQDN Fully Qualified Domain Name, in the binary > format. > > > The Host Identity is represented in RFC2535 [9] format. The > algorithms used in RDATA format are the following: > > Algorithms Values > > RESERVED 0 > DSA 3 [RFC2536] (REQUIRED) > RSA 5 [RFC3110] (OPTIONAL) > > The format for the FQDN is defined in RFC1035 [2] Section 3.1. > If there is no FQDN, the FQDN Length field is set to zero. > > > > > > === > > Issue 25: change the order of NES and DIFFIE_HELLMAN parameters > > In 6.2 HIP parameters: > > NES 9 Old SPI, New SPI and > other info needed for UPDATE DIFFIE_HELLMAN 13 variable > public key > > In 7.5 UPDATE - the HIP New SPI Packet > > IP ( HIP ( NES, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) > > > ===== > > Issue 24: move packet handling text from 6.x to 8.x > > Text removed from HMAC, HIP_SIGNATURE and HIP_SIGNATURE2, text > added to a new subsection 8.3: > > 6.2.10 HMAC > > 0 1 2 > 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HMAC > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type 65245 > Length 20 > HMAC 160 low order bits of the HMAC computed over the > HIP > > packet, excluding the HMAC parameter and any > following HIP_SIGNATURE or HIP_SIGNATURE2 > parameters. The checksum field MUST be set to > zero and the HIP header length in the HIP common header MUST be > calculated not to cover any excluded parameters when the HMAC is > calculated. > > > The HMAC calculation and verification process is presented in > Section 8.3.1 > > > 6.2.11 HIP_SIGNATURE > > 0 1 2 > 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SIG alg | Signature > | / > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / > | padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type 65279 (2^16-2^8-1) > Length length in octets, excluding Type, Length, and > padding SIG alg Signature algorithm > Signature the signature is calculated over the HIP packet, > excluding the HIP_SIGNATURE TLV field, but > including the HMAC field, if present. The checksum field MUST be > set to zero and the HIP header length in the HIP common header MUST > be calculated to the beginning of the HIP_SIGNATURE TLV when the > signature is calculated. > > The signature algorithms are defined in Section 6.2.8. The > signature in the Signature field is encoded using the proper method > depending on the signature algorithm (e.g. in case of DSA, > according to [10]). > > The HIP_SIGNATURE calculation and verification process is > presented in Section 8.3.2 > > 6.2.12 HIP_SIGNATURE_2 > > The TLV structure is the same as in Section 6.2.11. The fields > are: > > Type 65277 (2^16-2^8-3) > Length length in octets, excluding Type, Length, and > padding SIG alg Signature algorithm > Signature the signature is calculated over the R1 packet, > excluding the HIP_SIGNATURE_2 TLV field, but > including the HMAC field, if present. > Initiator's HIT and Checksum field MUST be set to zero and the HIP > packet length in the HIP header MUST be calculated to the beginning > of the HIP_SIGNATURE_2 TLV when the signature is calculated. > > Zeroing the Initiator's HIT makes it possible to create R1 > packets beforehand to minimize the effects of possible DoS attacks. > > Signature calculation and verification follows the process in > Section 8.3.2. > > --8<--- > > 8.3 HMAC and SIGNATURE calculation and verification > > The following subsections define the actions for processing > HMAC, HIP_SIGNATURE and HIP_SIGNATURE2 TLVs. > > 8.3.1 HMAC calculation > > The HMAC TLV is defined in Section 6.2.10. HMAC calculation and > verification process: > > Packet sender: > > 1. Create the HIP packet, without the HMAC and possibly > following HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. > > 2. Calculate the length field in the HIP header. > > 3. Compute the HMAC. > > 4. Add the HMAC TLV to the packet following possible > HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. > > 5. Recalculate the length field in the HIP header. > > Packet receiver: > > 1. Verify the HIP header length field. > > 2. Remove the HMAC TLV, and if the packet contains any > HIP_SIGNATURE or HIP_SIGNATURE2 fields, remove them too, saving the > contents if they will be needed later. > > 3. Recalculate the HIP packet length in the HIP header and > clear the checksum field (set it to all zeros). > > 4. Compute the HMAC and verify it against the received HMAC. > > > 8.3.2 Signature calculation > > The following process applies both to the HIP_SIGNATURE and > HIP_SIGNATURE2 TLVs. When processing HIP_SIGNATURE2, the only > difference is that instead of HIP_SIGNATURE TLV the > HIP_SIGNATURE2 TLV is used, and the Initiator's HIT is cleared (set > to all zeros) before computing the signature. The HIP_SIGNATURE TLV > is defined in Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section > 6.2.12. > > Signature calculation and verification process: > > Packet sender: > > 1. Create the HIP packet without the HIP_SIGNATURE TLV. > > 2. Calculate the length field in the HIP header. > > 3. Compute the signature. > > 4. Add the HIP_SIGNATURE TLV to the packet. > > 5. Recalculate the length field in the HIP header. > > Packet receiver: > > 1. Verify the HIP header length field. > > 2. Save the contents of the HIP_SIGNATURE TLV and remove it > from the packet. > > 3. Recalculate the HIP packet length in the HIP header and > clear the checksum field (set it to all zeros). > > 4. Compute the signature and verify it against the received > signature. > > The verification can use either the HI received from a HIP > packet, the HI from a DNS query, if the FQDN has been received > either in the HOST_ID or in the CER packet, or one received by some > other means. From saq66@umkc.edu Tue Feb 24 04:06:00 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Tue Feb 24 04:06:00 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <403B18CF.7030404@ericsson.com> References: <403B0E23.1020704@ericsson.com> <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> <403B18CF.7030404@ericsson.com> Message-ID: <6.0.3.0.0.20040224032937.01e5ee88@imap4.roos.umkc.edu> At 11:26 AM 2/24/2004 +0200, Gonzalo Camarillo wrote: >>It can use if we solve the referral/rendezvous issue(i.e. SIP can use HI >>instead of IP >>address.) > >The global identifiers we are looking for do not even need to be routable. >That is, it can be a sequence of bits that identify a UA. SIP provides >other mechanisms to be able to contact such a UA. then, it requires something like LSI (local scope.) But, I was talking about use of IP address in SIP header. In multi6 list, christian mentioned that SIP doesn't use FQDN because of performance/privacy problems (although, it allows change of IP address.) So, how about using HI instead of IP address in SIP headers? This also avoids _all_ transport traversal problem by making the NAT to be HIP aware (STUN does the opposite; also works for UDP only.) From Gonzalo.Camarillo@ericsson.com Tue Feb 24 04:27:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Feb 24 04:27:01 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <6.0.3.0.0.20040224032937.01e5ee88@imap4.roos.umkc.edu> References: <403B0E23.1020704@ericsson.com> <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> <403B18CF.7030404@ericsson.com> <6.0.3.0.0.20040224032937.01e5ee88@imap4.roos.umkc.edu> Message-ID: <403B230D.2030701@ericsson.com> Hi, > In multi6 list, christian mentioned that SIP doesn't use FQDN because of > performance/privacy problems SIP uses FQDNs, so I do not understand why somebody would say that it does not. > So, how about using HI instead of IP address in SIP headers? This would be a bigger step, which may be taken when HIP is more mature. Right now, the only problem they need to resolve is having a globally unique identifier for user agents. Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From saq66@umkc.edu Tue Feb 24 04:37:00 2004 From: saq66@umkc.edu (senthil ayyasamy) Date: Tue Feb 24 04:37:00 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <403B230D.2030701@ericsson.com> References: <403B0E23.1020704@ericsson.com> <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> <403B18CF.7030404@ericsson.com> <6.0.3.0.0.20040224032937.01e5ee88@imap4.roos.umkc.edu> <403B230D.2030701@ericsson.com> Message-ID: <6.0.3.0.0.20040224041339.01e5e338@imap4.roos.umkc.edu> At 12:10 PM 2/24/2004 +0200, Gonzalo Camarillo wrote: >>In multi6 list, christian mentioned that SIP doesn't use FQDN because of >>performance/privacy problems > >SIP uses FQDNs, so I do not understand why somebody would say that it does >not. ok. I should have been clear. _I_ was wrong in stating that FQDN is not all used. I was just talking about SIP's use of IP address. sorry for the confusion and thanks for your clarification ! anyway, since i misquoted christian, here is the original post: http://psg.com/lists/multi6/multi6.2004/msg00207.html From miika@iki.fi Tue Feb 24 08:34:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Feb 24 08:34:01 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> References: <403B0E23.1020704@ericsson.com> <6.0.3.0.0.20040224025011.01e724c0@imap4.roos.umkc.edu> Message-ID: On Tue, 24 Feb 2004, senthil ayyasamy wrote: > I have two questions about rendezvous/referral: > > 1. If HIPRR come up with a better-than-DNS naming resolution system, can > applications bypass > DNS and directly access the new system? It will be useful for many > future applications > like ad-hoc, sensor, P2P etc. This depends on the userspace resolver library that makes the queries. I am currently experimenting with a "native" HIP resolver which could handle multiple types of directories. But I really haven't thought about other other than DNS resolvers yet. > 2. I was looking into draft-ietf-dnsext-mdns today. what are your views > about LLMNR _like_ > model + distributed object look-up for name resolution? HIP does not currently support multicast. It would be nice research topic though. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From miika@iki.fi Wed Feb 25 04:11:02 2004 From: miika@iki.fi (Miika Komu) Date: Wed Feb 25 04:11:02 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <200402240943.58693.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> <40239196.3010606@nomadiclab.com> <200402240943.58693.julien.laganier@sun.com> Message-ID: On Tue, 24 Feb 2004, Julien Laganier wrote: > Sorry to get back to this issue so late, but after having implemented > and tested interop with the new HOST_ID, I have to mention that I > would have preffered to split the HOST_ID_FQDN TLV into two TLVs > (HOST_ID and FQDN) rather than using only one, with its three length > fields, which is IMHO (and when I'm coding ;-) very prone to error. > > So perhaps we could have two separate parameters, as for COOKIE and > BIRTHDAY. Note that this doesn't preclude encryption of both HI and > FQDN, because we could either put both into a single ENCRYPTED TLV, > or put each of them into its own ENCRYPTED TLV. I agree that the new TLV is more error prone to implement the first time, but I kind of like the new one more than the old one. It would be nice if the new TLV would not change anymore because it causes lots of implementation bugs. Btw, what would the fqdn name contain if the host id was introduced by a user (not a host)? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From kslavov@hiit.fi Wed Feb 25 04:36:01 2004 From: kslavov@hiit.fi (Kristian Slavov) Date: Wed Feb 25 04:36:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> <40239196.3010606@nomadiclab.com> <200402240943.58693.julien.laganier@sun.com> Message-ID: <403C76BB.6010306@hiit.fi> Miika Komu wrote: > > Btw, what would the fqdn name contain if the host id was introduced by a > user (not a host)? > How about email address? Naturally you could not trust that the user is really the user, who he/she claims to be. At least you would get a hint how to possibly contact the peer user. Perhaps in future we could have global directories that would contain email addresses and associated encryption keys. Then an implementation could check from such directories whether the user is, who he/she claims to be. Well... just a thought :) -- Kristian Slavov Research Assistant Helsinki Institute for Information Technology Gsm: +358-40-7220960 From miika@iki.fi Wed Feb 25 05:09:01 2004 From: miika@iki.fi (Miika Komu) Date: Wed Feb 25 05:09:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <403C76BB.6010306@hiit.fi> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <401F4818.2030703@nomadiclab.com> <40239196.3010606@nomadiclab.com> <200402240943.58693.julien.laganier@sun.com> <403C76BB.6010306@hiit.fi> Message-ID: On Wed, 25 Feb 2004, Kristian Slavov wrote: > Miika Komu wrote: > > > > Btw, what would the fqdn name contain if the host id was introduced by a > > user (not a host)? > > > > How about email address? Naturally you could not trust that the user is > really the user, who he/she claims to be. At least you would get a hint > how to possibly contact the peer user. Sounds reasonable. Non-host specific identifiers would then also require a new flag in the HIP header... -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Julien.Laganier@Sun.COM Wed Feb 25 05:13:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Feb 25 05:13:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200402240943.58693.julien.laganier@sun.com> Message-ID: <200402251156.13213.Julien.Laganier@Sun.COM> On Wednesday 25 February 2004 10:53, Miika Komu wrote: > On Tue, 24 Feb 2004, Julien Laganier wrote: > > Sorry to get back to this issue so late, but after having implemented > > and tested interop with the new HOST_ID, I have to mention that I > > would have preffered to split the HOST_ID_FQDN TLV into two TLVs > > (HOST_ID and FQDN) rather than using only one, with its three length > > fields, which is IMHO (and when I'm coding ;-) very prone to error. > > > > So perhaps we could have two separate parameters, as for COOKIE and > > BIRTHDAY. Note that this doesn't preclude encryption of both HI and > > FQDN, because we could either put both into a single ENCRYPTED TLV, > > or put each of them into its own ENCRYPTED TLV. > > I agree that the new TLV is more error prone to implement the first tim= e, > but I kind of like the new one more than the old one. It would be nice = if > the new TLV would not change anymore because it causes lots of > implementation bugs. Now that I've eventually get it right, I agree it's better not to modify = it=20 ;-) > Btw, what would the fqdn name contain if the host id was introduced by = a > user (not a host)? login@fqdn --julien From petri.jokela@nomadiclab.com Wed Feb 25 07:36:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Wed Feb 25 07:36:00 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <200402251156.13213.Julien.Laganier@Sun.COM> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200402240943.58693.julien.laganier@sun.com> <200402251156.13213.Julien.Laganier@Sun.COM> Message-ID: <403CA0D6.8030507@nomadiclab.com> >>Btw, what would the fqdn name contain if the host id was introduced by a >>user (not a host)? > > > login@fqdn Ok, here is one proposal how the HOST_ID would look like. I give some additional proposals - length of the FQDN/other field from 16 bits to 12 bits (should be still enough) - 4 bits reserved for the type of the Domain Identifier - Change the name of the field to Domain Identifier (DI) - define DI: 0 = nothing; 1=FQDN; 2=NAI, leaving space for possible other later definitions Is there a need for such an additional reservation, I don't know. We can, of course, take only one bit from the DI Length field for the N-bit that would tell if the field contains either FQDN or NAI. In that case the field could be named FQDN/NAI instead of DI. Any opinions? Petri ---8<---------------------------------- 6.2.8 HOST_ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HI Length |DI-type| DI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Domain Identifier / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... DI-type type of the following Domain Identifier field DI Length length of the FQDN or NAI in octets N if set, the following FQDN/NAI field contains a NAI Host Identity actual host identity Domain Identifier the identifier of the sender ... The following DI-types have been defined: Type Value none included 0 FQDN 1 NAI 2 FQDN Fully Qualified Domain Name, in binary format. NAI Network Access Identifier, in binary format. The format of the NAI is login@FQDN. -- 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 Gonzalo.Camarillo@ericsson.com Fri Feb 27 01:39:02 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Feb 27 01:39:02 2004 Subject: [Hipsec] Note taker Message-ID: <403EF03C.5050907@ericsson.com> Folks, we will be needing (at least) one note taker for the HIP WG session. He or she will not need to edit his or her notes. I will use them as input to elaborate the minutes of the meeting afterwards. Volunteers, please drop me a private note. If somebody wants to act as a Jabber coordinator during the meeting, that would be great. Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From Gonzalo.Camarillo@ericsson.com Fri Feb 27 01:43:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Feb 27 01:43:00 2004 Subject: [Hipsec] Slides Message-ID: <403EF0BD.7040201@ericsson.com> Folks, those of you who will be presenting in the HIP WG session, please, send me your slides so that I can make them available for everyone at the supplemental page: http://hip.piuha.net/meetings/ietf59/ Thanks, Gonzalo This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From pekka.nikander@nomadiclab.com Sat Feb 28 06:41:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Feb 28 06:41:02 2004 Subject: [Hipsec] Note taker In-Reply-To: <403EF03C.5050907@ericsson.com> References: <403EF03C.5050907@ericsson.com> Message-ID: <05088DC3-69E9-11D8-8A26-000393CE1E8C@nomadiclab.com> We are also still seeking for note takers for HIPRR BOF on Monday at 1930-2200. Please send me a private note if you can take notes. As I already wrote, no editing is needed, I will do the editing. --Pekka From pekka.nikander@nomadiclab.com Sat Feb 28 23:21:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Feb 28 23:21:02 2004 Subject: [Hipsec] Updated HIP RR BOF agenda Message-ID: Here is the updated agenda for tomorrow's HIP RR BOF. I'll try to put up my slides (and any other slides that I receive) later today or tomorrow morning. 1930 Agenda bashing Chairs 1935 RG background & Status Chairs & TBD 1945 HIP related research elsewhere Pekka Nikander 2000 HIP proxy service Lars Eggert 2015 NAT problem statement Martin Simmerling 2030 LHIP or delayed state setup Pekka Nikander 2045 SLAP / CELP Dave Crocker 2115 Referrals problem statement Pekka Nikander 2130 Open discussion All 2145 Summary & steps forward Chairs --Tom & Pekka From miika@iki.fi Sat Feb 28 23:51:00 2004 From: miika@iki.fi (Miika Komu) Date: Sat Feb 28 23:51:00 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <403CA0D6.8030507@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200402240943.58693.julien.laganier@sun.com> <200402251156.13213.Julien.Laganier@Sun.COM> <403CA0D6.8030507@nomadiclab.com> Message-ID: On Wed, 25 Feb 2004, Petri Jokela wrote: > >>Btw, what would the fqdn name contain if the host id was introduced by a > >>user (not a host)? > > > > > > login@fqdn > > Ok, here is one proposal how the HOST_ID would look like. I give > some additional proposals > > - length of the FQDN/other field from 16 bits to 12 bits (should be > still enough) > - 4 bits reserved for the type of the Domain Identifier > - Change the name of the field to Domain Identifier (DI) > - define DI: 0 = nothing; 1=FQDN; 2=NAI, leaving space for possible > other later definitions > > Is there a need for such an additional reservation, I don't know. We > can, of course, take only one bit from the DI Length field for the N-bit > that would tell if the field contains either FQDN or NAI. In that case > the field could be named FQDN/NAI instead of DI. Any opinions? RFC 2535 section 3.1 (KEY RDATA format) defines the format for "host identity" field in the HOST_ID parameter. The field constains "flags" which is explained in section 3.1.2. One of the bits in the flags is an extension bit: Bits 3 is reserved as a flag extension bit. If it is a one, a second 16 bit flag field is added after the algorithm octet and before the key data. This bit MUST NOT be set unless one or more such additional bits have been defined and are non-zero. This could be also used for storing host id related information. I don't know which one is better: the host id parameter header or the extension bit in the host identity field. Btw, would it make sense to store anonymous bit redundantly in the host id parameter also? > 6.2.8 HOST_ID > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HI Length |DI-type| DI Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Host Identity / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Domain Identifier / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I don't like shortening the length. I would prefer a new a 8-bit field. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Sun Feb 29 01:14:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 29 01:14:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200402240943.58693.julien.laganier@sun.com> <200402251156.13213.Julien.Laganier@Sun.COM> <403CA0D6.8030507@nomadiclab.com> Message-ID: <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> >> - length of the FQDN/other field from 16 bits to 12 bits (should be >> still enough) > > I don't like shortening the length. I would prefer a new a 8-bit field. You can't fit 2^12 = 4096 bytes in current packets anyway. I don't see the point. For me, 8 bits would be enough for the Domain Identifier length; anyway, DNS names are limited to 255 bytes. --Pekka From pekka.nikander@nomadiclab.com Sun Feb 29 01:23:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 29 01:23:02 2004 Subject: [Hipsec] Identifying SIP user agents In-Reply-To: <403B0E23.1020704@ericsson.com> References: <403B0E23.1020704@ericsson.com> Message-ID: Gonzalo, (Sorry for the delay in answering,) > The SIPPING WG is working on defining global identifiers for SIP > (Session Initiation Protocol) user agents. That is, my SIP phone will > have a global identifier, so that I can distinguish it from my other > SIP devides (like my software based SIP user agent running in my > laptop). the relevant drafts are: > > http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt Looking at Section 3 of this draft: > 3.1 Characteristics of a GUID > > The idea of a globally unique ID is hardly a new concept. ... > > A common characteristic of these identification numbers is that > they > have two basic properties: > > - They are unique to the entity they are associated with. > > - A central authority coordinates the assignment of IDs to > ensure > that no two entities are given the same identifier. Well, in the case of HIP we do not (necessarily have this). Central assigning authority is not currently available, and the HITs are unique only because the probability of collision is so low. And even in the case of two HITs colliding, the actual public keys are very very likely to be unique. (If they aren't, the private keys are also the same, and it is impossible to distinguish between the hosts. But that is likely to happen only if we assign multiple public keys to each atom in the universe.) > Note, that there is no requirement that there be any sort of > registry > that knows which entity has what identifier.... Ok. > Sometimes entities need to be able to be identified uniquely, > but to > have a central authority assign an identifier would be difficult > or > impossible. In these situations, it is still possible for the > entity > to assign itself a unique identifier. This can be achieved by > using a > mechanism that ensures that the odds of any two entities having > the > same identifier are statistically insignificant. Just like currently in HIP. > An example of this mechanism would be human fingerprints.... The section then gives a fairly simple mechanism of generating GUIDs using time, space and other attributes as source of randomness. Hence, just looking at the draft, I think that using HITs instead would make great sense. It would give the additional property of self-authentication. --Pekka From miika@iki.fi Sun Feb 29 03:55:01 2004 From: miika@iki.fi (Miika Komu) Date: Sun Feb 29 03:55:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200402240943.58693.julien.laganier@sun.com> <200402251156.13213.Julien.Laganier@Sun.COM> <403CA0D6.8030507@nomadiclab.com> <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: On Sun, 29 Feb 2004, Pekka Nikander wrote: > >> - length of the FQDN/other field from 16 bits to 12 bits (should be > >> still enough) > > > > I don't like shortening the length. I would prefer a new a 8-bit field. > > You can't fit 2^12 = 4096 bytes in current packets anyway. > I don't see the point. For me, 8 bits would be enough for > the Domain Identifier length; anyway, DNS names are limited > to 255 bytes. Ok. There may some other strings (e.g. NAI) which may be longer than FQDNs but I guess 4096 bytes is still enough. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Sun Feb 29 18:52:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 29 18:52:01 2004 Subject: [Hipsec] Note takers still needed!!! Message-ID: <669DC82E-6B18-11D8-8A26-000393CE1E8C@nomadiclab.com> Folks, We have now one note taker for the RG BOF and the WG, but we desperately need another one. Please consider. Even if you know that you will be able to take only partial notes, even them help. --Pekka From pekka.nikander@nomadiclab.com Sun Feb 29 19:59:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 29 19:59:01 2004 Subject: [Hipsec] Note takers still needed!!! In-Reply-To: <669DC82E-6B18-11D8-8A26-000393CE1E8C@nomadiclab.com> References: <669DC82E-6B18-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: We have now enough note takers for the RG. Thanks Andrew, Julien and Petri. One more would not hurt for the WG, though; Petri is not able to do it for the WG as he has to leave early. --Pekka From miika@iki.fi Sun Feb 29 20:53:01 2004 From: miika@iki.fi (Miika Komu) Date: Sun Feb 29 20:53:01 2004 Subject: [Hipsec] Note takers still needed!!! In-Reply-To: References: <669DC82E-6B18-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: On Mon, 1 Mar 2004, Pekka Nikander wrote: > We have now enough note takers for the RG. Thanks > Andrew, Julien and Petri. One more would not hurt > for the WG, though; Petri is not able to do it for > the WG as he has to leave early. Mika promised to make notes in the WG. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Sun Feb 29 22:58:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Feb 29 22:58:01 2004 Subject: [Hipsec] Early versions of today's HIPRR slides Message-ID: Some early versions of the slides for today's HIPRR meeting are now available at http://www.tml.hut.fi/~pnr/hiprr/ The final slides will most probably be different, but I just wanted to give people a chance to have a look at the slides and ideas beforehand. --Pekka