From Julien.Laganier@Sun.COM Mon Mar 1 07:24:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Mar 1 07:24:00 2004 Subject: [Hipsec] A possible LSI collision resolution Message-ID: <200403012208.06767.julien.laganier@sun.com> Folks, Here are some thoughts about SPI collision: HIT's are admittedly _statistically_ unique identifiers, and LSI's aren't. The reason behind that is that the probability of having a collision between two random LSI is 1/2^24, which is quite great compared to 1/2^128. But if one consider the probability of having a collision between any permutation of two sets of N randomly chosen LSI's: It is equal (if my maths are still good ;-) to (1/2^24)^N = 1/2^24xN. So to have about the same probability of collision, you needs N=5.333... So if you have two sets of 6 randomly chosen LSI's, the probability that the two sets are equal is approximately the same than having a collison on two 128 bits HITs. Here's come the solution: When a legacy IPv4 apps is resolving a DNS name into an A resource record, the resolver query HIT and IP addresses into a DNS, and then returns the set of 6 randoms LSI to the apps. It will be up to the appplication to try to connect cycling within this sets of 6 LSI, the connect possibly failing when LSI collision happened. What do you think? Thank, --julien From lars.eggert@netlab.nec.de Mon Mar 1 19:44:00 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Mon Mar 1 19:44:00 2004 Subject: [Hipsec] rendezvous section of hip-arch Message-ID: <4043E30C.6080401@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms030809050404090200070101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, as explained during my RG slot yesterday, I'd like the group to consider changing the hip-arch ID to remove discussion of the specifics of rendezvous mechanisms. I'll go over this in the WG slot as well, but the basic reason is that the current text in the hip-arch ID states some specifics about the behavior of rendezvous mechanisms that may paint us into a corner. Having this text in the hip-arch ID when it goes to RFC may complicate the RG's and WG's work into the details of rendezvous mechanisms. Here's some proposed changes to the only three parts of draft-moskowitz-hip-arch-05.txt that talk about rendezvous. They essentially remove these specifics: (1) Change section 5.1 to: 5.1 Rendezvous mechanism Making a contact to a mobile node is slightly more involved. In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. Although Dynamic DNS could be used for this function for infrequently moving nodes, an alternative to using DNS in this fashion is to use a piece of new static infrastructure to facilitate a rendezvous between HIP nodes. A rendezvous mechanism is also needed if both of the nodes are mobile and happen to move at the same time. In that case, the HIP readdress packets will cross each other in the network and never reach the peer node. A separate document will specify the details of the HIP rendezvous mechanism. (2) Remove the last paragraph of section 9 (just before 9.1). I'm not too worried about what it says about rendezvous servers, but it doesn't seem to follow out of the preceding paragraph, and it doesn't lead into the following section. Don't know the edit history of the ID in detail; maybe it is left over from a previous round of edits? It currently reads: Since all systems can have a Host Identity, every system can have an entry in the DNS. The mobility features in HIP make it attractive to trusted 3rd parties to offer rendezvous servers. (3) Change item 6 of section 9.1 to: 6. What administrative infrastructure is needed to support it? It is possible to use HIP opportunistically, without any infrastructure. However, to gain full benefit from HIP, the HIs must be stored in the DNS or a PKI, and a new rendezvous mechanism is needed. Comments? Lars -- Lars Eggert NEC Network Laboratories --------------ms030809050404090200070101 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMzAyMDEyNzQwWjAjBgkqhkiG 9w0BCQQxFgQUJwP6cAT54/zXTAUehoDs+5CdqQgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA nOSg01FhXk0NOGj5JbquFnhwUGfCZ0ly8RnAPCCrWkRMy2u73LavUlQx2Mu6xGUOd8Gox7EW F1Lm+zlVxwfS84qc0R6hTgrQfoJjycURkUidoMK3wTxMub9qws6+fwvjbO4Om6E6skmbyiTj Gb3bOLJaFihjYZELwSXSwKXwT3sdXTyBzJ3kquEMnpU9CJh5huak4myecFcgyr7/0cXBuF1/ 0heKsd2aolARyxMSvyHUy+HHUHsi6kOBs4SIbXR+++B6RfDfG6D7Owm8bxtX0T13L0I6nVnz DZ987bjJ+Yci0/VKVvqOMKVJTxkZgOb6QVxExqttSIlDU/dDNmeiygAAAAAAAA== --------------ms030809050404090200070101-- From thomas.r.henderson@boeing.com Mon Mar 1 19:59:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Mar 1 19:59:01 2004 Subject: [Hipsec] A possible LSI collision resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604B0@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > Sent: Monday, March 01, 2004 5:08 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] A possible LSI collision resolution >=20 >=20 > Here's come the solution: When a legacy IPv4 apps is resolving a DNS=20 > name into an A resource record, the resolver query HIT and IP=20 > addresses into a DNS, and then returns the set of 6 randoms LSI to=20 > the apps. >=20 > It will be up to the appplication to try to connect cycling within=20 > this sets of 6 LSI, the connect possibly failing when LSI collision=20 > happened. >=20 It is not the matter of picking the peer's LSI (destination) that is=20 the problem. It is the application's own LSI (sending address) that=20 causes the collision at the peer. Tom From Julien.Laganier@Sun.COM Tue Mar 2 19:43:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Mar 2 19:43:01 2004 Subject: [Hipsec] A possible LSI collision resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604B0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604B0@xch-nw-27.nw.nos.boeing.com> Message-ID: <200403030353.00695.julien.laganier@sun.com> On Tuesday 02 March 2004 10:41, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > > Sent: Monday, March 01, 2004 5:08 AM > > To: hipsec@honor.trusecure.com > > Subject: [Hipsec] A possible LSI collision resolution > > > > > > Here's come the solution: When a legacy IPv4 apps is resolving a > > DNS name into an A resource record, the resolver query HIT and IP > > addresses into a DNS, and then returns the set of 6 randoms LSI > > to the apps. > > > > It will be up to the appplication to try to connect cycling > > within this sets of 6 LSI, the connect possibly failing when LSI > > collision happened. > > It is not the matter of picking the peer's LSI (destination) that > is the problem. It is the application's own LSI (sending address) > that causes the collision at the peer. You're right Tom. So perhaps those sets of 6 LSIs can be 'negociated' just after DNS name resolution: i.e., a cryptography-free I0/R0 roundtrip, where each peer just select its own LSI within the set it received, trying to avoid collision. If collision cannot be avoided (which isn't likely to happen more oftenly than HIT collision, given the entropy you have with 6 randomly chosen 32 bits LSIs ~ 192 bits), the peers can just retry with an additionnal I0/R0 round trip. Question is: Does it works? Thanks, --julien From Gonzalo.Camarillo@ericsson.com Tue Mar 2 19:54:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Mar 2 19:54:00 2004 Subject: [Hipsec] Few slides uploaded Message-ID: <404536FA.60907@ericsson.com> Folks, the slides the different presenters will be using today are available at: http://hip.piuha.net/meetings/ietf59/slides/ 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 Thu Mar 4 00:10:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Mar 4 00:10: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> <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: On Sun, 29 Feb 2004, Miika Komu wrote: > Ok. There may some other strings (e.g. NAI) which may be longer than FQDNs > but I guess 4096 bytes is still enough. Actually it is too much. The HIP header has 8-bit payload length, setting the limit to the HIP parameters field. The maximum size of the HIP parameters section is thus 2008 bytes (in section 6.1 Payload format). In HOST_ID, 11 bits for the length would be enough to fill a HIP packet. Due to the 2008 bytes limit, Will we run into problems with other TLVs in the packet (e.g. D-H). /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 Jan.Melen@nomadiclab.com Thu Mar 4 02:05:03 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Thu Mar 4 02:05:03 2004 Subject: [Hipsec] Update race condition Message-ID: <200403040948.53919.Jan.Melen@nomadiclab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! The draft-moskowitz-hip-09 in section 8.10 step 10 the draft state that "If the system is in state REKEYING, and the UPDATE doesn't have the R-bit set in the NES TLV, there are apparently two UPDATE packets crossing each other in the network. Consequently, the R-bit-less packet is handled as specified in Section 8.10.1." The update packets that are crossing each other in the network can not be handled as specified today in section 8.10.1 because if they are handled as specified in 8.10.1 then both ends will fetch wrong incoming SA keys and wrong outgoing SA keys. Host-A expects to receive with the same key as HOST-B expects to receive not good. Have I understood the draft correctly? Solution to this problem would be that the keys would be fetched in predefined order. When a update packet is received the keys are always fetched in following way. Compare the HITs and first fetch the key of the host that has in network byte order smaller HIT and then fetch the key of the host that has in network byte order greater HIT (this is also used in section 9 generating HIP Keymat). Comments? There is one corner case which has to be also stated in the draft and that is. If host A has sent a update containing keymat index 172 to host B. At the same host B has sent a update packet containing keymat index 220 to host A (B has for some reason decided not to use the keying material between 172-220 this is allowed already today). These two packets are crossing each other on the network. So A has to accept the greater keymat index gotten in update packet although it does not match with the index sent. Also B has to accept that the keymat index in update packet is older than what it would like to use (this is new and should be allowed only if B is in state rekeying). Both A and B when creating the update reply packet must put the greater keymat index in to the reply packet. The bigger keymat index always wins. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFARt9hp4iklvjQtTgRAscMAJ4yEG2RgaTOHP4JF/1HcMkCO2MgeACeLMkY 95sUm6iDQiJnG9W5W+K7PTo= =oOEq -----END PGP SIGNATURE----- From petri.jokela@nomadiclab.com Thu Mar 4 04:32:04 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Mar 4 04:32:04 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> <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: On Thu, 4 Mar 2004, Petri Jokela wrote: > Due to the 2008 bytes limit, Will we run into problems with other TLVs in > the packet (e.g. D-H). Still few words about this... The current I2 packet size with the Oakley group 1 is around 760 bytes. This means that with 8192-bit group the size is around 1700 bytes. And this is without the FQDN, for which we leave some 300 bytes with this packet content (usually it should be enough). This, however, does not leave any space for future DH-group modifications (or even for large NAI/FQDNs). /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Thu Mar 4 05:43:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Mar 4 05:43:00 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> <91030F0C-6A84-11D8-8A26-000393CE1E8C@nomadiclab.com> Message-ID: > The current I2 packet size with the Oakley group 1 is around 760 bytes. > This means that with 8192-bit group the size is around 1700 bytes. And > this is without the FQDN, for which we leave some 300 bytes with this > packet content (usually it should be enough). This, however, does not > leave any space for future DH-group modifications (or even for large > NAI/FQDNs). I think that it would be good enough just to document this, and leave it (mostly) as it is. --Pekka From miika@iki.fi Thu Mar 4 10:58:02 2004 From: miika@iki.fi (Miika Komu) Date: Thu Mar 4 10:58:02 2004 Subject: [Hipsec] interoperability summary from IETF59 Message-ID: Interoperability tests during IETF59 were based on the 09 draft. Only base exchange was subject to testing. Boeing-Ericsson: Interoped fully with Ericsson v4. v6 did not quite work-- problems with ssh returning prompt (perhaps due to reverse lookups) and TCP resets crashing the Boeing machine when we tried Telnet. Boeing-HIPL: Interoped fully with HIPL for v6 (worked smoothly the first time we tried!). Boeing-Sun: Interoped the handshake with Julien for v6, except he has a problem with his cookie puzzle solution and did not implement IPsec support. Ericsson-HIPL: Successful already just before IETF. Ericsson-Sun: Partial success. Julian's cookies are broken and IPsec support is not implemented. There may have been some other problems too. Sun-HIPL: Successful except HIPL had to turn off cookie validation because Julien's cookies were invalid. Julien has not IPsec support yet. Andrew: Andrew's python based HIP implementation was not up-to-date with the 09 draft, so it was not tested. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Fri Mar 5 00:50:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 5 00:50:01 2004 Subject: [Hipsec] rendezvous section of hip-arch In-Reply-To: <4043E30C.6080401@netlab.nec.de> References: <4043E30C.6080401@netlab.nec.de> Message-ID: <292E0DE2-6E6F-11D8-9EC7-000393CE1E8C@nomadiclab.com> Lars, > (1) Change section 5.1 to: I worded this slightly differently, resulting in the following: > 6.1 Rendezvous mechanism > > Making a contact to a mobile node is slightly more involved. In > order to start the HIP exchange, the initiator node has to know how > to reach the mobile node. Although Dynamic DNS could be used for > this function for infrequently moving nodes, an alternative to using > DNS in this fashion is to use a piece of new static infrastructure > to > facilitate rendezvous between HIP nodes. > > The mobile node keeps the rendezvous infrastructure continuously > updated with its current IP address(es). The mobile nodes must > trust > the rendezvous server to properly maintain their HIT and IP address > mappings. > > The rendezvous mechanism is also needed if both of the nodes happen > to change their address at the same time, either because they are > mobile and happen to move at the same time, because one of them is > off-line for a while, or because of some other reason. In such a > case, the HIP readdress packets will cross each other in the network > and never reach the peer node. > > A separate document will specify the details of the HIP rendezvous > mechanism. Ok? > (2) Remove the last paragraph of section 9. Tentatively removed, subject to further discussion / objection by Bob M. > (3) Change item 6 of section 9.1 to: Again, I worded it slightly differently, resulting in the following: > 6. What administrative infrastructure is needed to support it? > > It is possible to use HIP opportunistically, without any > infrastructure. However, to gain full benefit from HIP, the > HIs must be stored in the DNS or a PKI, and a new rendezvous > mechanism is needed. Such a new rendezvous mechanism may > need > new infrastructure to be deployed. Ok? --Pekka From pekka.nikander@nomadiclab.com Fri Mar 5 00:54:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 5 00:54:01 2004 Subject: [Hipsec] Update race condition In-Reply-To: <200403040948.53919.Jan.Melen@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> Message-ID: > Solution to this problem would be that the keys would be fetched in > predefined > order. When a update packet is received the keys are always fetched in > following way. Compare the HITs and first fetch the key of the host > that has > in network byte order smaller HIT and then fetch the key of the host > that has > in network byte order greater HIT (this is also used in section 9 > generating > HIP Keymat). Comments? Sounds good to me. > There is one corner case which has to be also stated in the draft and > that is. > If host A has sent a update containing keymat index 172 to host B. At > the > same host B has sent a update packet containing keymat index 220 to > host A (B > has for some reason decided not to use the keying material between > 172-220 > this is allowed already today). These two packets are crossing each > other on > the network. So A has to accept the greater keymat index gotten in > update > packet although it does not match with the index sent. Also B has to > accept > that the keymat index in update packet is older than what it would > like to > use (this is new and should be allowed only if B is in state > rekeying). Both > A and B when creating the update reply packet must put the greater > keymat > index in to the reply packet. The bigger keymat index always wins. Sounds good. --Pekka From lars.eggert@netlab.nec.de Fri Mar 5 19:16:00 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Fri Mar 5 19:16:00 2004 Subject: [Hipsec] rendezvous section of hip-arch In-Reply-To: <292E0DE2-6E6F-11D8-9EC7-000393CE1E8C@nomadiclab.com> References: <4043E30C.6080401@netlab.nec.de> <292E0DE2-6E6F-11D8-9EC7-000393CE1E8C@nomadiclab.com> Message-ID: <40492283.20101@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms080405010808020407020202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka, Pekka Nikander wrote: > Lars, > >> (1) Change section 5.1 to: > > I worded this slightly differently, resulting in the following: > >> 6.1 Rendezvous mechanism >> >> Making a contact to a mobile node is slightly more involved. In >> order to start the HIP exchange, the initiator node has to know how >> to reach the mobile node. Although Dynamic DNS could be used for >> this function for infrequently moving nodes, an alternative to using >> DNS in this fashion is to use a piece of new static infrastructure to >> facilitate rendezvous between HIP nodes. editorial nit: This reads like dynDNS could provide the rendezvous function, which it can't - it can be used to update the locality information. Slightly reworded: "Although infrequently moving HIP nodes could use Dynamic DNS to update their reachability information in the DNS, an alternative is..." But I can live with your text as well, if you'd rather keep it. >> >> The mobile node keeps the rendezvous infrastructure continuously >> updated with its current IP address(es). The mobile nodes must trust >> the rendezvous server to properly maintain their HIT and IP address >> mappings. >> >> The rendezvous mechanism is also needed if both of the nodes happen >> to change their address at the same time, either because they are >> mobile and happen to move at the same time, because one of them is >> off-line for a while, or because of some other reason. In such a >> case, the HIP readdress packets will cross each other in the network >> and never reach the peer node. >> >> A separate document will specify the details of the HIP rendezvous >> mechanism. > > Ok? Looks good, modulo the change suggested above. >> (2) Remove the last paragraph of section 9. > > Tentatively removed, subject to further discussion / objection by Bob M. Looks fine - this change is not something critical, was a more editorial comment. >> (3) Change item 6 of section 9.1 to: > > Again, I worded it slightly differently, resulting in the following: > >> 6. What administrative infrastructure is needed to support it? >> >> It is possible to use HIP opportunistically, without any >> infrastructure. However, to gain full benefit from HIP, the >> HIs must be stored in the DNS or a PKI, and a new rendezvous >> mechanism is needed. Such a new rendezvous mechanism may need >> new infrastructure to be deployed. > > Ok? Yup. Thanks for taking care of this so quickly! Lars -- Lars Eggert NEC Network Laboratories --------------ms080405010808020407020202 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMzA2MDA1OTQ3WjAjBgkqhkiG 9w0BCQQxFgQUzTnvaX+WdXV33zK1vY6uh4Ox3rMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA O+dqm7ZQkCxUt2zNEFSAL5x4XPbcbAbKbJGyy++QVR/RkfSScjfVHsHLZBanSL5YfFyJun5V LkzQhvwOiqVdc8s2GOglwIQ574izHYtHCTzZL3LmTQdqDF6i7e3JXleZJTWXpacifksby9X4 3+UwfthsrVzY/V30LWSsTPwOltZoMzxYq5WYTmFVNGpH44/HZUx37cCXl4beuVzYJgV/uqNK QPqFChfuE7On2pZvyZZ8csNTe0RV1bqYBmm391dlxVM7B+PbZstoEBEDDKS2FpFUZP5wwOAg wpiAcXLnOJWgiZQZxmBUAsc31My512Q/wsEh5qCycOZ1voGjK9+xkgAAAAAAAA== --------------ms080405010808020407020202-- From pekka.nikander@nomadiclab.com Fri Mar 5 19:24:03 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 5 19:24:03 2004 Subject: [Hipsec] rendezvous section of hip-arch In-Reply-To: <40492283.20101@netlab.nec.de> References: <4043E30C.6080401@netlab.nec.de> <292E0DE2-6E6F-11D8-9EC7-000393CE1E8C@nomadiclab.com> <40492283.20101@netlab.nec.de> Message-ID: >>> Making a contact to a mobile node is slightly more involved. In >>> order to start the HIP exchange, the initiator node has to know >>> how >>> to reach the mobile node. Although Dynamic DNS could be used for >>> this function for infrequently moving nodes, an alternative to >>> using >>> DNS in this fashion is to use a piece of new static >>> infrastructure to >>> facilitate rendezvous between HIP nodes. > > editorial nit: This reads like dynDNS could provide the rendezvous > function, which it can't - it can be used to update the locality > information. Slightly reworded: > > "Although infrequently moving HIP nodes could use Dynamic DNS to > update their reachability information in the DNS, an alternative > is..." Ok, adopted. >>> The mobile node keeps the rendezvous infrastructure continuously >>> updated with its current IP address(es). The mobile nodes must >>> trust >>> the rendezvous server to properly maintain their HIT and IP >>> address >>> mappings. I also fixed the above mention of a "server" to mention a "mechanism". --Pekka From pekka.nikander@iki.fi Fri Mar 5 19:25:02 2004 From: pekka.nikander@iki.fi (Pekka Nikander) Date: Fri Mar 5 19:25:02 2004 Subject: [Hipsec] Preliminary minutes from the Monday HIP RR BOF Message-ID: --Apple-Mail-18--766375674 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Please find enclosed preliminary minutes from the HIP RR BOF. Basically, this contains the discussion transcripts, the rest of the material to be added later. Please send any corrections ASAP to me. I haven't had time to process all of the note taker notes yet, so I may also make changes (mostly additions/names) by my own. I just wanted to get this out now so that people may make corrections while they still may remember what happened. :-) --Pekka --Apple-Mail-18--766375674 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name="ietf59_hiprr_minutes.html" Content-Disposition: attachment; filename=ietf59_hiprr_minutes.html IETF-59 HIP Releated Research BOF Summary and Minutes

Host Identity Protocol Related Research BOF (hiprr)

These are the minutes for the Host Identity Protocol Related Research BOF (hiprr) meeting, held at IETF-59 on Monday, March 1, 2004, at Seoul Lotte. Thanks to Marcelo Bagnulo, Petri Jokela, Miika Komu, Julien Lagnier, and Andrew McGregor, for the notes, on which these minutes are based on.

Decisions

  1. Should we continue to work on full blown non-HIP supporting proxies?

    Yes. Transition mechanisms are an important issue.

  2. Should we continue to work on NAT traversal?

    Yes, but unclear how. Pressure to work both on solutions that are friendly to current NAT boxes and on solutions that make NAT boxes friendly to HIP.

  3. Should we continue to work on the Lightweight HIP idea?

    Yes (large interest).

  4. Should we continue to work on CELP?

    Yes (some interest).

  5. Should we continue to work on DHT / HIP overlay / ... ideas?

    Yes, but unclear where to focus

  6. Any additional important areas that we missed?

    Applications point of view.

Summary of discussions

This summary has been compiled by Pekka Nikander, based on the discussion minutes, included below.

Points to pay attention to

Presentations and Discussion

Research Group background and Status

Slides

As a continuation of the successful HIP BOF in Minneapolis and the WG chartering discussions that followed, there is a clear need for a research group that will study the consiquences of HIP or the ID/LOC split in general. However, ID / locator split major architectural issue and the IAB wants to investigate it before making a decision. There is hope that the discussion will be finished shortly, i.e., during the week In any case, there will be space for HIP research group.

Dave Crocker:
What is going on this week about the id/loc split? The plenary is often not good for resolving issues.
Vern Paxon:
The IAB discussion will take place before the plenary, and results will then be presented there. The plenary is then a place to see what the community things.

HIP related research elsewhere

Slides

Pekka briefly discribed related research elswhere, including the NewArch, Ambient Networks and Daidalos projects.

Vern Paxon and others:
The NewArch project is done.
Pekka Nikander:
Ok, but I see the work continuing. We have to follow what's going on.
Kevin Fall:
There has been lots of work on interoperability over networks that are not Internet networks. Separation is related to routing, there is SIGCOMM 2003 paper discussing the area. The delay tolerant networking folks have been thinking about ID/Loc and have been doing IRTF stuff. See www.dtnrg.org. [The SIGCOMM paper that Kevin mentioned is available through the DTN RG web pages.]

HIP proxy / rendezvous broker

Slides

Lars Eggert gave a presentation related to draft-eggert-hip-rendezvous-00.txt.

[The comments in the following discussion transcription have been slightly reordered so that related comments are collected together.]

Erik Nordmark (clarifying question):
Why does a rendezvous server need to NAT, why not tunnel?
Lars Eggert:
NAT is what the current architectura draft states. Actually I will propose tunneling a couple of slides later.
Greg Daley:
To me this looks like Mobile IP or like a VPN tunnel server endpoint. You have a static address, like in MIP, which acts as the identifier. Would it be worth comparing?
Lars Eggert:
The difference really is that this kind of a relay is needed only if the other party does not understand HIP.
Greg Daley:
It's the same thing with MIP. What is an advantage for HIP?
Elliot Lear:
Could you comment differences with mipv6?
Lars Eggert:
For the HIP-HIP case, a rendezvous can be anywhere, you don't need to have a fixed home network.
James Kempf:
If you renumber the home network, your identity changes in Mobile, IP but not in HIP.
Pekka Nikander:
The proposal it is very similar to MIP for non-HIP nodes. On the other hand, if we consider only HIP hosts, there are no restrictions on where you put your rendezvous server, and you can have multiple rendezvous servers, even dynamically.
Joe Touch:
Are you changing the DNS or modifying the entries? So the reverse lookups will be ambiguous anyway and lot of protocols will start failing?
Lars Eggert:
There will be additional changes.
Rob Austein (clarification):
You do not actually need to resign the entire zone if a single record is updated via DynDNS. You can do incremental signing.
Miika Komu:
We should concentrate more on the HIP-to-HIP rendezvous server case. If the peer does not understand HIP, we fall back to IP.
Lars Eggert:
If the IP address in the DNS is the IP address of a randezvous server, such fallback would not work.
Pekka Nikander:
We can't put the rendezvous server address in the DNS. The WG must rethink this. The WG is supposed to do the I1/UPDATE only rendezvous server, plus the rendezvous server DNS record.
Kevin Fall:
The terminlogy used here seems to relate to I3 work. Any comments?
Pekka Nikander:
Distributed Hash Tables will come up in later presentations.
Pekka Nikander (chairing):
Is this a topic that should be studied in the RG? Or should we leave this for the WG?
Juergen Quitteck:
This should be a work issue, because it is important to communicate hip and non hip nodes.
Pekka Nikander (chairing):
There seems to be some interest. I don't see any reason why we can't work on this.

NAT problem statement

Slides

Juergen Quitteck gave a presentation related to draft-XXX-00.txt.

Joe Touch:
Most of the reasons why you say NAT is bad is that NAT makes everything behind the network look like one host and this is what you don't want. Most justifications for NAT are reasons for its brokenness. Stop supporting them.
JQ:
NAT is what the users do, you cannot stop them.
PN:
If you do a loc/id split, NAT may become less evil, since you obtain stable id end-to-end. Even if the locators are changed on the fly, the id is still stable.
JQ:
This is not advertising nat, but to address the problems that NAT pose to HIP. The point is to make HIP and NAT coexist.
PN (clarification):
There are no problems with HIP and checksums in NAT traversal, since in HIP the pseudo header contains HITs, not IP addresses.
PN (comment):
I'd like to mention a couple of problems with mobility and multihoming. If a mobile host goes to a network behind a NAT, it already has an association. The NAT has to find out from the UPDATE packet the new address. The SPI values is also problem: there may be collisions. Should the SPIs be within or outside of the signature calculation? DoS does not seem to be a problem.
JQ:
The conflict with using same SPI can be solved with NATs that have more than one IP address available.
Greg Daley:
99% of NATs are unmanaged, so what if they don't support the hip? Stay in TCP or UDP so you don't rely on NAT upgrades?
Tim Shepard:
I agree. We won't get NATs upgraded. HIP could be use to get IPv6 for home node behind a NAT. Maybe even in such a way that v6 is never seen in core network, i.e., use 6to4. We can't upgrade NAts, but we can ask vendors to support 6to4. This seems like the right thing.
Greg Labovitz:
We are a NAT implementer and we don't have problem changing NATs.
Dave Crocker:
It is easy to get one person to do one thing, the problem is to get everybody to do it?

Why did I stand up? Well, NATs are not a problem in the net, they are a problem in the IETF. There are HIP things and then there are other things that HIP must cope with. NAT is not core business for HIP.

There are couple of ways to deal with things. If we wait for NAT boxes to change, we have to wait for a long long time. If we don't wait, we have to manage difficult things. Thus, there are multiple ways to solve problems. Short term hacks will probably be long term (wrong way). Hence, make the ugly thing and the right thing coexist.
Pekka:
I'm not worried about NATs. If HIP happens there will be an incentive for NAT vendors to support HIP and for users to upgrade. The boxes are cheap and get cheaper.

We have to make a distinction between two different things:
  1. compatibility with current NATs,
  2. HIP allows cross IP realm traversal, which we probably should not even call NAT
You could have multiple IP address realms and let traffic flow between them, while retaining the 3.5 layer end-to-end connectivity. We have tried to design the system to make things to work with 3.5 routing. The state in the layer 3.5 routers must be a soft state.
Elliot Lear:
HIP solutions should be long term and problems solve in the long term ones.
Gonzalo Camarillo:
You will never deploy HIP if you need to update NATs. It is the same problem in SIP. Don't require modifying NAT.
Erik Nordmark:
Should we match HIP and NAT or decouple them the more possible?
LQ:
The question is whether we want to make HIP more NAT friendly or NATs more HIP friendly.

Lightweight HIP

Slides

Pekka presented an idea. No questions or comments, but considerable interest on working on the idea.

CELP

Slides

Dave Croker gave a presentation related to draft-crocker-celp-00.txt.

Pekka (comment):
If we do id/locator split, we get into situation where we have two sets of different congestion control variables. Some are related to the path and some to the flow.
Dave:
I agree with you. The id-locator combination is both on the layer 3 and 4. This was not point of this discussion; a different discussion. If we solve this cleanly, it is good.

Presentation continues with security issues.

Pekka:
Security issues were touched already today. If you do RR test using IKEv2 or MIPv6, there results are different from the security point of view. A solution to this may be to add a a security related granularity parameter.
Dave:
We need to figure out the minimum level of security. I propose naming the IP address pools with domain names, but this is handwaving that requires work. One of the problems is that the DNS name -> IP address -> DNS name chain may not work. There seems to be problems with operation and administration.
Erik Nordmark:
I'm wondering about issues with a shared pool and multiple users. What is the key for looking up from the pool? What if we have two users, (two connections), and they give a different key to retrieve the address from the pool? Or if the users are attaching different informations to the same key?
Dave:
I don't have an answer, needs more investigation. Multi-address parallel usage would be great.
Pekka:
I have an example. Consider using HIP and SCTP. HIP gets more addresses to the pool (rendezvous servers) than SCTP.
Elliot Lear:
On the use of the domain names. Firstly, there must be no circular dependencies. Secondly, I was asked to write a draft for the multi6 WG, things to think about. There are couple of points that are interesting.

Presentation continues.

Dave (question):
Is this interesting? [A few few hands.]
Pekka:
I have a gut feeling: DNS names are not going to work. You dont put DNS names into the kernel. Looks complicated. My personal feeling that it is a bad idea.
Dave:
Your comments were mild compared to others. Interesting discussion.
Andrew McGregor:
How to you manage the address pool in the DNS server?? DNS names are pronote to a dispute.
Tim Shepard:
Needs cooperation from DNS admins. This is a showstopper. It is hard to work on a protocol and deploy it if I can't use it on a network until I get cooperation form the administrator of the DNS.
Dave Crocker:
From the CELP point of view, DNS provides two different services: lookup service and naming service. We are not necessarily doing lookups.
Erik Nordmark:
Locator pools apply, even if you introduce new name space.
Dave Crocker:
We need an identifier space for pools. We need some commonality between the users of the pool, in order for this to be useful.
Kevin Fall:
Why not use URI space instead of FQDN?
X:
you said: there should be a DB and a key. Key seems to be DNS names.
Dave Crocker:
We need to add a few details before it is practical.
xx:
The CELP acronym is already taken.

Referrals problem statement

Slides

Pekka Nikander gave a presentation where he tried to clearly state the referral problem but actually talked more about Distributed Hash Tables (DHTs). He really should not give that many presentations during a single RG meeting. [A note to those whose sense of irony is limited: remember who has compiled these minutes.]

Joe Touch:
I have a little confusion here, why don't we want to use the DNS?
PN:
The HI / HIT name space is flat. You can't use DNS, as DNS requires hierarchy.
JT:
Well, then, make the name space hiearchical.
PN:
Earlier version of the HIP drafts contained an hierarchical name space as an alternative. It was removed for the sake of simplicity and some other problems. The HIP WG can certainly add it back if they want to. In the Research Group side, though, I think that we want to explore the other possibilities.
XX (from Deutche Telecom?):
The carriers may not want to use DHTs because of the amount of traffic generated.
PN:
There may be a misunderstanding here. The way I envision that we might use DHTs is not really P2P like, or at least not Napster like P2P. It does not generate any more traffic than DNS.
Rob Austein:
A problme with a DHT is the trust model. In the DNS you have somone in control of which servers you trust, and that is not possible in the DHT case.
Pekka Nikander:
In DHT you can use several hash keys and several independent servers.
Rob Austein:
So you must trust several strangers insteas of just one.
PN:
The assumption is that you have a strong id check, so you just need enough replicas to find at least one set of valid data, i.e., one where the signature is valid. Remember, if we use DHT with HIP, we have a public key and the strong relation with HIT. The real problem is whether you get data back or not. To solve this, you can make ten replicas or so. This is not a perfect solution, there may be better ones, but is a solution.

But yes, we have two problems: collusion (as I mention in the slide) and replay of old data. The latter can be solved by always making more than one lookups, but that is bad from a performance point of view.
PN:
So, basically, what I am saying is that we know how to make DHTs work in theory but not how in practice.
Erik Nordmark:
Practical issues of how well it scales? In a large network we have many hosts joining and leaving? We would have a million or more servers. This is different if all internet uses this than the current DNS use or current DHT research use.
Kevin Fall:
All this discussion relates to the new layer. Maybe i disagree on the issues on the agenda?
Pekka Nikander:
We need a mechanism to get IP addresses from identifiers. We try to get attention from academic research.
Kevin Fall:
This is distraction to the reseach group. There are other communities that are solving these problems. We should focus on the problems that others are not solving.
Pekka Nikander:
how about Erik's comments?
Kevin Fall:
Research is going on but you have a different problem, yes.
Thomas Henderson:
Any fresh ideas?

Using any servers as rendezvous points

Slides

Tim Shepard described his idea of using any servers as rendezvous servers.

Tim Shepard:
About HIP rendezvous issues. I'd like to have a system that doesn't use DNS at all, where end points recognize each other without using dns. You just introduce each other once and then they know each other. Server mobility is easy because the server remains fixes simultaneous movement: only one of the moving host has to maintain a association with the rvs could all hip nodes act as relays?
Elliot Lear:
That was a great bar conversation. Really good questions. May I disagree: it is ok to use DNS, its ok to fail if the resouce is not present. First question: In simultaneous movement, what is the tolerable period to have stale info? Second question: In moving from one location to another, how do you introduce the routing system, leave info in everywhere you go?
James Kempf:
Two nodes moving at the same time. You lose the update. When a node moves it tells the old router so that the traffic can flows to the new location. So we can come up with a local link fixed routing protocol (for HIP, MIP...)

For VoIP, the maximum is 40 ms dropout period. This figure also works for HIP. This work has not gone anywhere due to non-interest.
Tim Shepard:
This is this same as Eliot mentioned.
James Kempf:
Yes, approximately. Router and node has to find out the movement. 40 ms is allowed, due to voip apps.
Tim Shepard:
May be. However, my basic observation is that if you have implemented HIP, you are only few lines [of code] away from a [I1-only] rendezvous server.
Erik Nordmark:
If every node acts as a relay wouldn't this enable new attacks, is it worse tat than ipv4 today? Consider open SMTP relays today. Here you have strong identity. You have to tell where they are coming from to get them shut up if needed. You can hide your IP address. If you have IP address, you can tell the ISP that this guy must be "closed".
Kevin Fall:
This looks awfully lot like i3. Refrasing, is is better to have an infra with storage capability, or is it better to be more active.
Pekka Nikander:
This is one very good question. This is the third independent time that I hear I3 and HIP in same sentence. I am starting to wonder why
X:
HIP identifiers like ethernet addresses from the forwarding point of view. You use the identifier only on the last part. Not so vulnerable.
Tim Shepard:
I dont really understand the question. HIP ids can be proved to be owned.
X:
Different thing. It is just equivalent to that point.
Tim Shepard:
Are you saying that we should take only part of the HIT as the id. Possiblity of collisions gets greater. I don't know how to solve that.

Open mike

Pekka:
People are working on the DHT problems elsewhere so we don't have to take so much effort on those things. Concentrate on understanding HIP effect to the Internet.
Steve Kempf:
What's impact on applications?
Erik Nordmark:
Another thing, how IDs show up at the application layer. Does this change applications? Does this change the way to use applications?
Pekka Nikander:
One of the questions is that we have an aulli mailing list, basically dead at the moment. Which is the right forum to look at application area?

Maybe we should have a sub research group for application issues. I don't know how to organize this kind of thing.
Erik Nordmark:
Are there people in the room that understand application level identifiers? [No hands]
XX:
This is a difficult question.
Joe Touch:
I can take applications that use ip addressses in different ways. They will suffer from using HITs. Who understands apps. use of addresses? Many bizzarre things out there. Is non-hip host talking to non-hip app on hip enabled device a problem?
Erik Nordmark:
No idea, but does existence of HIP namespace change things in interesting ways? What other kinds of IDs do applications use?
XX:
There is also a body existing work related to these things. There are surveys about these issues. Have been surveys of app protocol use of IP addresses.
Keving fall:
Are these right things? Semantics, routing system, what layer routing system it relates to, hierarchical. Lot of things to cope with.
Elliot Lear:
NSRP draft looks at some of this. Remember also the draft mentioned earlier with the open questions.
Pekka Nikander:
There are some answers in HIP architecture draft. Maybe they are not sufficient. The draft was in RFC Editor queue, but it is now back for editing. Please review the architectural draft, needs to be stable as soon as possible.
Pekka Nikander (chairing):
No more comments? Seems to be so that we have many of the correct problems. The apps level identifiers stuff needs to thought in more detail. We Need help from the apps people.

Footnote: I have no idea who Steve Kempf is, but one of the note takers marked this particular speaker as "Steve" while the other one attributed "Kempf". The other's didn't have a name recorded, or not even the comment recorded.

Valid XHTML 1.0!

Copyright  ©  2004 Internet Engineering Task Force.

--Apple-Mail-18--766375674-- From pekka.nikander@nomadiclab.com Sun Mar 7 17:39:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Mar 7 17:39:01 2004 Subject: [Hipsec] AC/ACR or NES based RR? Message-ID: Folks, At the WG meeting in Seoul there was no clear consensus on whether people prefer the explicit AC/ACR based RR mechanism that was present in the -00 version of the mobility and multi-homing draft or the current NES based mechanism used in the -01 draft. Basically, only three people showed hands, clearly indicating that more clarification is needed on the issue. The purpose of this message is to create some discussion this issue so that more people could form their opinions. Even though this note is intended to contain the essence of the difference, reading the drafts is probably needed to really understand the difference between the approaches. The -00 draft is available at http://www.watersprings.org/pub/id/draft-nikander-hip-mm-00.txt The -01 draft is available at http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-01.txt, and an early version of the to-be -02 is available at http://www.tml.hut.fi/~pnr/HIP/ 1. The AC/ACR approach In the -00 draft, a REA was performed by an explicit three way handshake, consisting of REA, AC, and ACR packets: A B REA: My new IP is 1.2.3.4 ---------------------------> AC: Are you at 1.2.3.4? <--------------------------- ACR: Yes, I am ---------------------------> A major problem with the -00 draft was that it didn't really address multi-homing requirements. In particular, the possibility of using multiple parallel SAs to overcome difficulties with different path characteristics and replay protection was missing. However, other than that the AC/ACR mechanism might still be useful. Basically, to make the AC/ACR mechanism useful even in the case where the sender of REA is multi-homed and needs multiple parallel SAs, the AC needs to be made more REA (or NES) like. That is, if the REA introduces a new B->A SA, the AC must introduce a corresponding A->B SA. The difference with the REA is that while the REA introduces a new SA that has a new destination IP address, the AC introduces a new SA that shares the same destination IP address as the old one. These parallel SAs are needed in both directions, since the QoS mostly seems to depend on the path taken, not the destination address. Hence, when A sends packets to B, it needs to decide on SA use based on the source interface used, not the destination IP address. The two SAs are needed to make sure that no packets are dropped at B due to different replay protection windows on the different paths. 2. The REA/NES approach In the -01 draft, the REA packet was replaced with a REA parameter, and both REA and NES parameters were carried in UPDATE packets. A B REA: My new IP is 1.2.3.4, NES: with SPI 1234 ----------------------------------------------> NES: my new SPI corresponding is 4321 <---------------------------------------------- ESP traffic to B on SPI 4321 ----------------------------------------------> There were a number of motivating factors for this change. The ultimate factors were the desire to reuse existing mechanism and architectural simplicity. - reuse of the NES mechanism, with the hope of generating less code - getting rid of ACR, as it is basically a binary message indicating that A received AC - desire not to carry SPIs in REA as they need to be carried in the NES anyway - better support for middle boxes by requiring them to track NES only, learning the SPIs from NES payloads, not elsewhere. With regard to multi-homing, the -01 draft still does not work quite right. Basically, it does not tell how to create SPIs in both direction. Hence, some changes/additions are needed in order to support bi-directional parallel SAs. 3. Remarks / thoughts Considering a case like using GPRS (900 ms delay, real throughput of maybe 10 kilobits/second) and WLAN (20 ms delay, 5 Mb/s), it is clear that different SAs are needed in both directions. Otherwise any packet sent over the GPRS channel will get dropped at the receiving end as outside of the replay protection window. In the A->B direction (A being multi-homed and B not), there is no real different between the parallel SAs. A can use either of them on either path. Basically, it is A's responsibility to use them in a sensible way so that replay protection windows are never exceeded. Hence, here we seem to have the possibility where we have two address groups (since we have two SAs), and a single address shared between the address groups. Hence, the REA/NES based transaction seems to become in the multi-homing case like the following: A B REA: My new IP is 1.2.3.4, NES: with SPI 1234 ----------------------------------------------> REA: New address group NES: with SPI 4321 <---------------------------------------------- ESP traffic to B on SPI 4321 ----------------------------------------------> Note that the second REA does *not* require any RR test as it does not introduce any new addresses. A remark about data structures: - RR status is per address, not per address group or per address in an address group. I.e. it is enough to check an address for RR once, and use that RR status even if the address appears later in new address groups. Opinions/further thoughts/mistakes in my logic? --Pekka From jari.arkko@piuha.net Sun Mar 7 22:14:00 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun Mar 7 22:14:00 2004 Subject: [Hipsec] AC/ACR or NES based RR? In-Reply-To: References: Message-ID: <404BEEF4.70500@piuha.net> Hi Pekka, I'm not really responding to your specific question, just commenting a few other related items... sorry if this has been discussed before, I have recently been too busy to follow all HIP discussions. > Considering a case like using GPRS (900 ms delay, > real throughput of maybe 10 kilobits/second) and > WLAN (20 ms delay, 5 Mb/s), it is clear that > different SAs are needed in both directions. > Otherwise any packet sent over the GPRS channel > will get dropped at the receiving end as outside > of the replay protection window. True. But there's also a corresponding transport layer issue, even if you get the SAs right. If you were carrying a single TCP session, the disparity in the interface speeds would cause problems for TCP. Hence it may make more sense to constrain the use of multiple interfaces for failover rather than load balancing, or even randomly using more than one interface. Has this been discussed previously? Are we talking about this yet anywhere in the documents? > A B > REA: My new IP is 1.2.3.4, NES: with SPI 1234 > ----------------------------------------------> > REA: New address group NES: with SPI 4321 > <---------------------------------------------- > ESP traffic to B on SPI 4321 > ----------------------------------------------> I'm just wondering how the REA - NES approach fits in with possible RR optimizations that people have talked about in MIPv6 and MOBOPTS groups. Perhaps its too early to adopt any specific optimization to HIP as people are just basically brainstorming about it. But it might be good to think about it. --Jari From pekka.nikander@nomadiclab.com Mon Mar 8 01:28:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 8 01:28:01 2004 Subject: [Hipsec] AC/ACR or NES based RR? In-Reply-To: <404BEEF4.70500@piuha.net> References: <404BEEF4.70500@piuha.net> Message-ID: <014FBF43-70D0-11D8-9EC7-000393CE1E8C@nomadiclab.com> Jari, >> Considering a case like using GPRS (900 ms delay, >> real throughput of maybe 10 kilobits/second) and >> WLAN (20 ms delay, 5 Mb/s), it is clear that >> different SAs are needed in both directions. > > True. But there's also a corresponding transport > layer issue, even if you get the SAs right. Right. This has been discussed a little bit, but we certainly need more discussion on this. > If you were carrying a single TCP session, the disparity > in the interface speeds would cause problems for TCP. > Hence it may make more sense to constrain the use > of multiple interfaces for failover rather than > load balancing, or even randomly using more than > one interface. I think we have here two separate issues. One is the architectural issue wrt. transport use, which you mention. There I fully agree with you that we do not want to do anything, yet, at the working group side, but just say that for a single TCP connection you just use a single SPI at time, and you have to be pretty careful if you switch it. However, I do see there a great place for some interesting work in the research group side. The second issue is getting the HIP protocol right. There I really think that we should specify it to have multiple parallel SAs, even if the upper layer in a given implementation were use only one of them at a time. Getting this (almost) right doesn't seem to be that complicated. Basically, we need to have an SA pair for each path. We just have to make the signalling protocol so that we have a reasonable abstraction for paths, for associating paths with IP addresses, and for changing the associated IP address set. In the current drafts there is the deficit that they do not really deal with SA pairs but try to come along with unidirectional SAs. That doesn't quite work, Jan Melen noted while trying to implement this stuff. (Again, we see what value implementation has.) As a conclusion, the "interface" concept which is used in -01 is bad terminology. Just renaming it to "address group" as is done in -02-pre is not quite right, either. We must represent paths, and associate them with IP address pairs, not single addresses. Apparently we have to think a little bit more about this, independent on whether we go back to AC/ACR or continue using SPIs as RR triggers. > Are we talking about this yet anywhere in the > documents? I don't think so. > I'm just wondering how the REA - NES approach fits > in with possible RR optimizations that people have > talked about in MIPv6 and MOBOPTS groups. Perhaps > its too early to adopt any specific optimization to > HIP as people are just basically brainstorming about > it. But it might be good to think about it. This is a very good question. I really encourage people to think about this, especially while evaluating whether to use AC/ACR (-00 approach) or SPI triggers (-01 approach). --Pekka From Spencer Dawkins" <404BEEF4.70500@piuha.net> Message-ID: <030e01c4050c$d6a41340$0400a8c0@DFNJGL21> See the multi6 archives, especially the thread from October/November on "Re: Notes on draft-crocker-mast-analysis-01.txt", and anything posted by Mark Allman. Spencer From: "Jari Arkko" > > > Considering a case like using GPRS (900 ms delay, > > real throughput of maybe 10 kilobits/second) and > > WLAN (20 ms delay, 5 Mb/s), it is clear that > > different SAs are needed in both directions. > > Otherwise any packet sent over the GPRS channel > > will get dropped at the receiving end as outside > > of the replay protection window. > > True. But there's also a corresponding transport > layer issue, even if you get the SAs right. If you > were carrying a single TCP session, the disparity > in the interface speeds would cause problems for TCP. > Hence it may make more sense to constrain the use > of multiple interfaces for failover rather than > load balancing, or even randomly using more than > one interface. Has this been discussed previously? > Are we talking about this yet anywhere in the > documents? From Spencer Dawkins" <404BEEF4.70500@piuha.net> <014FBF43-70D0-11D8-9EC7-000393CE1E8C@nomadiclab.com> Message-ID: <032601c4050f$fb388490$0400a8c0@DFNJGL21> I may not be clear enough when I'm describing this... just a couple more words, to see if I can be clearer. Spencer From: "Pekka Nikander" > > If you were carrying a single TCP session, the disparity > > in the interface speeds would cause problems for TCP. > > Hence it may make more sense to constrain the use > > of multiple interfaces for failover rather than > > load balancing, or even randomly using more than > > one interface. > > I think we have here two separate issues. One is the > architectural issue wrt. transport use, which you mention. > There I fully agree with you that we do not want to do > anything, yet, at the working group side, but just say > that for a single TCP connection you just use a single > SPI at time, and you have to be pretty careful if you > switch it. However, I do see there a great place for "Switching" paths for a single TCP connection is not a problem, especially if you are switching paths for a reason (like, the old path seems to have quit working). The worst that can happen is that your new path gets some segments to the far end more than four segments "out of order" from the old path, and you generate a round of TCP fast retransmit/fast recovery, and we have to accept that sometimes we'll choose a new path that's more congested than the old path, so we would generate a round of TCP fast retransmit/fast recovery anyway as we figure out what the new path capacity is. If you choose paths for a single TCP connection more often than TCP can recovery from out of order delivery - think loadbalancing, with round-robin selection as the limiting case - this IS a problem. TCP slows down more quickly than it speeds up (additive increase, multiplicative decrease), and you don't have to cut your estimate of path bandwidth in half very often to be pretty noticeable. For better or worse, we haven't widely deployed per-destination or per-destination-subnet congestion management, so you can probably choose a different path for different TCP connections to the same destination, no problem, and can certainly choose a different path for TCP connections to different destinations in the same subnet, no problem. > some interesting work in the research group side. Spencer From miika@iki.fi Tue Mar 9 09:46:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Mar 9 09:46:01 2004 Subject: [Hipsec] java + hip Message-ID: Today Jaakko Kangasharju finished writing of java JNI wrapper library for HIPL legacy HIP resolver library. The wrapper library was tested with two test network applications written in java. The amount of changes in the application code required just adding one line of code in each application to bypass standard java socket classes to the JNI wrapper. I guess this was the first java application ever that was HIP enabled? We will celebrate that with Jaakko with some beer and sauna. Cheers! -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Gonzalo.Camarillo@ericsson.com Wed Mar 10 03:35:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Mar 10 03:35:01 2004 Subject: [Hipsec] Notes and minutes Message-ID: <404ED224.1090701@ericsson.com> Folks, the notes and the draft minutes from the meeting in Seoul are already available under: http://hip.piuha.net/meetings/ietf59/notes/ If you have any comments on the draft minutes, please send them to the chairs. 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 thomas.r.henderson@boeing.com Wed Mar 10 17:21:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Mar 10 17:21:01 2004 Subject: [Hipsec] responding to unknown SPIs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604E2@xch-nw-27.nw.nos.boeing.com> (cross-posted for now to IPsec and HIP mailing lists). This is a request from the HIP WG for some information from IPsec WG=20 participants. At last week's HIP meeting, there was some discussion on whether HIP (which functions similar to an IPsec key management protocol) should=20 respond to ESP packets received with an unknown SPI. =20 Some issues raised included: - don't IPsec key management protocols ignore these? (It was pointed out by a participant that the latest draft of IKEv2 has support for responding to them) - what if multiple keying daemons (HIP, IPsec) are running on the same box-- do both respond? - what is the appropriate response, if there is one? (inside/outside SA context, rate limited, request to reestablish the SA?) - is a response dependent on whether the localhost determines that it has rebooted recently? - in practice, if a reboot has occurred, won't applications have lost=20 their context anyway in this case? What is the scenario for which a=20 response is useful? In looking at the latest draft (below), it seems that IKEv2 MAY respond, either within the SA context or outside, to these=20 unknown SPIs, but there is not much further guidance given. In summary, at the HIP WG it was not clear if this was a useful mechanism, so we decided to defer to IPsec WG for guidance. Has it been found to be useful? Thanks, Tom >From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt INVALID_SPI 11 MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by the recipient as a "hint" that something might be wrong (because it could easily be forged). From thomas.r.henderson@boeing.com Thu Mar 11 23:17:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Mar 11 23:17:01 2004 Subject: [Hipsec] API and LSI resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> In Seoul, I presented an API/LSI proposal for the base spec=20 (see = http://hip.piuha.net/meetings/ietf59/slides/pres-ietf59-hip-henderson-api= .ppt) Due to lack of opinion expressed, we decided to discuss more on the = list. So to reiterate my proposal, I suggest the following: i) Remove LSI TLVs from the protocol; LSIs are statically derived from = the=20 HIT and are defined by 1.x.x.x where the lower 24 bits correspond to the = 24=20 lowest HIT bits. ii) Any collisions, if they are handled, are handled by host NAT at the = host=20 that discovers the local collision (that is, the stack may NAT the LSI = into=20 one that doesn't conflict, and take care if it sees the changed LSI in = the=20 application data stream to flip it back) iii) Add a subsection after 3.5 (TCP/UDP checksum) that describes ii) = above, and summarizes API issues and the issue of LSIs or HITs in the = application data stream, while deferring full API discussion to another draft iv) remove Appendix A from the base spec If there is no conceptual objection to the above, I will propose some=20 specific draft text. Tom From miika@iki.fi Fri Mar 12 01:18:00 2004 From: miika@iki.fi (Miika Komu) Date: Fri Mar 12 01:18:00 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> Message-ID: On Thu, 11 Mar 2004, Henderson, Thomas R wrote: > In Seoul, I presented an API/LSI proposal for the base spec > (see http://hip.piuha.net/meetings/ietf59/slides/pres-ietf59-hip-henderson-api.ppt) > Due to lack of opinion expressed, we decided to discuss more on the list. > > So to reiterate my proposal, I suggest the following: > > i) Remove LSI TLVs from the protocol; LSIs are statically derived from the > HIT and are defined by 1.x.x.x where the lower 24 bits correspond to the 24 > lowest HIT bits. > ii) Any collisions, if they are handled, are handled by host NAT at the host > that discovers the local collision (that is, the stack may NAT the LSI into > one that doesn't conflict, and take care if it sees the changed LSI in the > application data stream to flip it back) > iii) Add a subsection after 3.5 (TCP/UDP checksum) that describes ii) above, > and summarizes API issues and the issue of LSIs or HITs in the application > data stream, while deferring full API discussion to another draft > iv) remove Appendix A from the base spec > > If there is no conceptual objection to the above, I will propose some > specific draft text. Sounds ok to me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Fri Mar 12 01:33:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 01:33:00 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> Message-ID: <6168D09B-73F5-11D8-A780-000393CE1E8C@nomadiclab.com> > So to reiterate my proposal, I suggest the following: To reiterate my position, here are my comments: > i) Remove LSI TLVs from the protocol; LSIs are statically > derived from the HIT and are defined by 1.x.x.x where the > lower 24 bits correspond to the 24 lowest HIT bits. This is OK to me as it can be added back later as an optional parameter. > ii) Any collisions, if they are handled, are handled by > host NAT at the host that discovers the local collision > (that is, the stack may NAT the LSI into one that doesn't > conflict, and take care if it sees the changed LSI in the > application data stream to flip it back) This is OK to me as IPv4 apps must be prepared to deal with NATs anyway. However, I also see HIP as a great opportunity to hide all NATting from apps. Hence, I would like to see, perhaps later, a mechanism that allows us to resolve LSI conflicts without the host NATting of LSIs. Hence, I would like to see using host NAT as a "MAY", with text stating that there may be other alternatives in the future, and the exact method of resolving LSI conflicts in the long run is an open issue. > iii) Add a subsection after 3.5 (TCP/UDP checksum) that > describes ii) above, and summarizes API issues and the > issue of LSIs or HITs in the application data stream, > while deferring full API discussion to another draft I'm fine with explicitly deferring API discussion to another document. What comes to the TCP/UDP checksum, we use the IPv6 pseudo header with HITs anyway, at least conceptually. Consequently, I would say that any discussion of how to handle this in the case of using IPv4 stack with possibly host NATted LSIs belongs to an appendix. Remember, already at the BOF in Minneapolis Jim Bound made the comment that in his opinion the main body of the text is too specific of how to implement things. I tend to agree with him. > iv) remove Appendix A from the base spec Ok. --Pekka From pekka.nikander@nomadiclab.com Fri Mar 12 03:16:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 03:16:00 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: <404ED224.1090701@ericsson.com> References: <404ED224.1090701@ericsson.com> Message-ID: Gonzalo (and David), Thanks for compiling the minutes. They are great in getting the overall picture. However, I would also prefer to see a compilation of the notes, to see the details of the discussions that took place. There may be some important details that might otherwise get dropped. If you don't have time for such a compilation job, maybe we should try to employ a WG secretary (as e.g. Mobike has done), and get him/her to compile the details of the discussion? > If you have any comments on the draft minutes, please send them to the > chairs. Two clarifications: 1. Explicit notification: > Topic: Reject Mechanism: Issue 21 > Slides presented: pres-ietf59-hip-henderson-reset.ppt > Discussions led by: Thomas Henderson > > Issue: do we need a message that notifies the sender that the message > received was not acceptable? (instead of just dropping it silently). > Discussion: no comments. I took this as an implicit agreement with Thomas. But maybe Thomas should perform a consensus call on the mailing list? 2. DNS: > Conclusion: For the HIP DNS work, we should reuse IPSec work as much > as possible Actually, it should be reusing "IPSECKEY", not "IPsec". --Pekka From bogus@does.not.exist.com Fri Mar 12 03:17:01 2004 From: bogus@does.not.exist.com (Petri Jokela) Date: Fri Mar 12 03:17:01 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6168D09B-73F5-11D8-A780-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F0@xch-nw-27.nw.nos.boeing.com> <6168D09B-73F5-11D8-A780-000393CE1E8C@nomadiclab.com> Message-ID: <200403121056.30757.Petri Jokela <>> On Friday 12 March 2004 09:17, Pekka Nikander wrote: > > So to reiterate my proposal, I suggest the following: > > To reiterate my position, here are my comments: > > i) Remove LSI TLVs from the protocol; LSIs are statically > > derived from the HIT and are defined by 1.x.x.x where the > > lower 24 bits correspond to the 24 lowest HIT bits. > > This is OK to me as it can be added back later as an > optional parameter. Ok. > > ii) Any collisions, if they are handled, are handled by > > host NAT at the host that discovers the local collision > > (that is, the stack may NAT the LSI into one that doesn't > > conflict, and take care if it sees the changed LSI in the > > application data stream to flip it back) > > This is OK to me as IPv4 apps must be prepared to > deal with NATs anyway. However, I also see HIP as > a great opportunity to hide all NATting from apps. The plan was to handle connections like this (if I remember correctly Seoul discussions): We have a server (S) and two clients (C1, C2). Clients have both HITs that have the lower 24 bits exactly the same, thus their LSIs would then be the same (1.X.X.X = LSIc1 = LSIc2). The server LSI is thus 1.y.y.y = LSIs. When the server receives the HIT of the peer, it can determine the LSI for the peer. At this point, the S can also find out if there is a collision between two clients (e.g. if C1 has set up already an SA with the S). It can mark the possible collision, generate a new LSI to represent C2 (LSIc2n) locally and make a NAT relation between the LSIc2 and LSIc2n. LSIc2n is seen only locally by the application running on the S. The LSI value is always NATted when a packet leaves/arrives. For applications that use the IP address in the application data, the NATting functions should also modify the application data. This makes the implementation more complicated. If the LSI is generated with another procedure, than "24 lowest bits of HIT", the S cannot detect the collision until the connection attempt comes in. > Hence, I would like to see, perhaps later, a mechanism > that allows us to resolve LSI conflicts without the host > NATting of LSIs. Hence, I would like to see using > host NAT as a "MAY", with text stating that there may > be other alternatives in the future, and the exact > method of resolving LSI conflicts in the long run is > an open issue. The NAT function described above is not nice and better proposals are welcome. /petri From Gonzalo.Camarillo@ericsson.com Fri Mar 12 03:45:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Fri Mar 12 03:45:01 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: References: <404ED224.1090701@ericsson.com> Message-ID: <405182FB.8070502@ericsson.com> Pekka, thanks for your comments: > However, I would also prefer > to see a compilation of the notes, to see the details of the > discussions that took place. There may be some important > details that might otherwise get dropped. The notes from the notetakers are available on the supplementary page. So, if what you want to do is to be able to have a look at them to see what happended, you can do that already. If, on the other hand, you want them to appear in the official minutes so that they have official status, then we will need to include them there. If you still think that we should include more detailed discussions in the official minutes, let me know and I will take care of that. Regarding the WG secretary, if we reach a point where both chairs are terribly overloaded, we will think of that. For the time being, I believe we are OK. > Two clarifications: > > 1. Explicit notification: > >> Topic: Reject Mechanism: Issue 21 >> Slides presented: pres-ietf59-hip-henderson-reset.ppt >> Discussions led by: Thomas Henderson >> >> Issue: do we need a message that notifies the sender that the message >> received was not acceptable? (instead of just dropping it silently). >> Discussion: no comments. > > > I took this as an implicit agreement with Thomas. > But maybe Thomas should perform a consensus call > on the mailing list? Yes, I prefer to have *explicit* agreements. The process is much clearer this way. > > 2. DNS: > >> Conclusion: For the HIP DNS work, we should reuse IPSec work as much >> as possible > > > Actually, it should be reusing "IPSECKEY", not "IPsec". I'll fix it. 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 Mar 12 04:05:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 04:05:02 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: <405182FB.8070502@ericsson.com> References: <404ED224.1090701@ericsson.com> <405182FB.8070502@ericsson.com> Message-ID: Gonzalo, > If you still think that we should include more detailed discussions in > the official minutes, let me know and I will take care of that. I do. Sorry about requesting you to spend a couple of hours on this issue on your already busy schedule, but I do consider the details of the discussion valuable enough to be spelled out, corrected by the participants (if they care), and to be submitted to the secretariat for the proceedings. --Pekka From petri.jokela@nomadiclab.com Fri Mar 12 04:35:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Mar 12 04:35:00 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> Message-ID: <200403121220.06554.petri.jokela@nomadiclab.com> On Thursday 04 March 2004 13:26, Pekka Nikander wrote: > > The current I2 packet size with the Oakley group 1 is around 760 bytes. > > This means that with 8192-bit group the size is around 1700 bytes. And > > this is without the FQDN, for which we leave some 300 bytes with this > > packet content (usually it should be enough). This, however, does not > > leave any space for future DH-group modifications (or even for large > > NAI/FQDNs). > > I think that it would be good enough just to document this, > and leave it (mostly) as it is. > > --Pekka I added a sentence in 6.1 Payload format, beginning from "Note:" The Header Length field contains the length of the HIP Header and the length of HIP parameters in 8 bytes units, excluding the first 8 bytes. Since all HIP headers MUST contain the sender's and receiver's HIT fields, the minimum value for this field is 4, and conversely, the maximum length of the HIP Parameters field is (255*8)-32 = 2008 bytes. Note: this sets an additional limit for sizes of TLVs included in the Parameters field, independent of the individual TLV parameter maximum lengths. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Fri Mar 12 04:43:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 04:43:01 2004 Subject: [Hipsec] HOST_ID_FQDN vs HOST_ID & FQDN In-Reply-To: <200403121220.06554.petri.jokela@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC272@xch-nw-27.nw.nos.boeing.com> <200403121220.06554.petri.jokela@nomadiclab.com> Message-ID: >>> The current I2 packet size with the Oakley group 1 is around 760 >>> bytes. >>> This means that with 8192-bit group the size is around 1700 bytes. >>> And >>> this is without the FQDN, for which we leave some 300 bytes with this >>> packet content (usually it should be enough). This, however, does not >>> leave any space for future DH-group modifications (or even for large >>> NAI/FQDNs). >> >> I think that it would be good enough just to document this, >> and leave it (mostly) as it is. > > I added a sentence in 6.1 Payload format, beginning from "Note:" > > The Header Length field contains the length of the HIP Header and > the > length of HIP parameters in 8 bytes units, excluding the first 8 > bytes. Since all HIP headers MUST contain the sender's and > receiver's HIT fields, the minimum value for this field is 4, and > conversely, the maximum length of the HIP Parameters field is > (255*8)-32 = 2008 bytes. Note: this sets an additional limit for > sizes of TLVs included in the Parameters field, independent of the > individual TLV parameter maximum lengths. Ok to me. --Pekka From pekka.nikander@nomadiclab.com Fri Mar 12 06:33:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 06:33:00 2004 Subject: [Hipsec] Text for solving the R2 losses problem Message-ID: <46F83A0F-741F-11D8-A780-000393CE1E8C@nomadiclab.com> At the Seoul meeting it was decided that I would produce proposal text for the R2 loss problem, basically adding a new state "R2 sent". We now need your comments on this, in order to resolve this issue in the base spec. Here are my proposed changes; all references to RESYNC should be changed accordingly (staying at R2-SENT) if the WG decision is to remove resynch from the base spec. 1. Section 5.4.1 HIP States: - Add a new state "R2-SENT", just after "I2-SENT" state: R2-SENT Waiting to finish HIP 2. Section 5.4.2 HIP State Process: - In states UNASSOCIATED, I1-SENT and I2-SENT, change the rule for receiving an I2 as follows: Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED/I1-SENT/I2-SENT - In state ESTABLISHED, REKEYING and RESYNC, change the rule for receiving an I2 as follows: Receive I2, process with Birthday check if successful, send R2, drop old SAs, establish new SA, go to R2-SENT if fail, stay at ESTABLISHED/REKEYING/RESYNC - Add a new state "R2-SENT", just after "I2-SENT" state: +---------+ | R2-SENT | Waiting to finish HIP +---------+ Receive I1, send R1 and go to RESYNC Receive I2, process, if successful, send R2, and cycle at R2-SENT if failed, stay at R2-SENT Receive R1, drop and stay at R2-SENT Receive R2, drop and stay at R2-SENT Receive ESP for SA, process and go to ESTABLISHED Receive UPDATE, process if successful, send UPDATE and go to ESTABLISHED if failed, stay at R2-SENT Should not ever need rekey Comments/questions: - should we have a timeout? What if we do, should the Responder move to ESTABLISHED, send yet another R2 and move to ESTABLISHED, or drop the association? - In practice, an implementation may just stay in R2-SENT for a brief period of time (few seconds), poll the SA to see if any traffic has been received, and if so, move to ESTABLISHED. - I am unsure of what we should do with UPDATE. It is perfectly possible to receive an UPDATE. That is, the Initiator may send an UPDATE immediately as a response to a R2, informing the Responder about its multi-homing situation. As a consequence, receiving an UPDATE should also be an indication that the Initiator is in ESTABLISHED. However, what if processing fails? Is staying at R2-SENT the right approach? 3. Section 5.4.3 Simplified HIP State Diagram The state diagram has to be redrawn accordingly. Here is a suggestion: DGM to send +--------------+ I2 received +---------------| UNASSOCIATED |---------------+ | +--------------+ | v | +---------+ I2 received | | I1-SENT |---------------------------------------+ | +---------+ | | | +------------------------+ | | | R1 received | I2 received | | | v | v v v +---------+ | +---------+ | I2-SENT |------------+ | R2-SENT | +---------+ +---------+ | | ^ ^ | | | | | R2 received +--------------+ ESP | | | I2 w/BD +-------------->| ESTABLISHED |<---------+ | | +--------------+ | | Rekey to perform | ^ ^ | | I2 w/BD | | +------------------+ | | | +---------------+ | | | | | | v | | | | +---------+ UPDATE recvd | | | R1 w/BD +---------+ | REKEY |---------------+ | +----------->| RESYNC | +---------+ | +---------+ | ESP/UPDATE/timeout | +--------------------+ Note that the diagram above reverts back to the previous practice that it is an R1, not I1, that triggers resync. But most probably we just remove the whole resync from the state machine; the diagram above just suggests where it plugs in, if we add it in a different draft. I'll propose text to Section 8 once we have agreement on the basic approach. Comments? Questions? --Pekka From petri.jokela@nomadiclab.com Fri Mar 12 08:40:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Mar 12 08:40:02 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: <46F83A0F-741F-11D8-A780-000393CE1E8C@nomadiclab.com> References: <46F83A0F-741F-11D8-A780-000393CE1E8C@nomadiclab.com> Message-ID: <200403121624.43538.petri.jokela@nomadiclab.com> On Friday 12 March 2004 14:17, Pekka Nikander wrote: > - Add a new state "R2-SENT", just after "I2-SENT" state: > > +---------+ > > | R2-SENT | Waiting to finish HIP > > +---------+ > > Receive I1, send R1 and go to RESYNC > Receive I2, process, > if successful, send R2, and cycle at R2-SENT > if failed, stay at R2-SENT > Receive R1, drop and stay at R2-SENT > Receive R2, drop and stay at R2-SENT > > Receive ESP for SA, process and go to ESTABLISHED > Receive UPDATE, process > if successful, send UPDATE and go to ESTABLISHED > if failed, stay at R2-SENT > Should not ever need rekey > > Comments/questions: > - should we have a timeout? What if we do, should the > Responder move to ESTABLISHED, send yet another R2 and > move to ESTABLISHED, or drop the association? I would say that we should send another R2 and stay at R2-SENT. (How many times?) If there is no data after N retries, we should probably drop the association. Isn't it so that the reason why the initiator starts the negotiation is that it has some data to send? On the other hand, can there be a situation when the Initiator sets up an SA, just to make sure that there is an SA for some data that will come later? > - I am unsure of what we should do with UPDATE. It is > perfectly possible to receive an UPDATE. That is, > the Initiator may send an UPDATE immediately as a response > to a R2, informing the Responder about its multi-homing > situation. As a consequence, receiving an UPDATE should > also be an indication that the Initiator is in ESTABLISHED. > However, what if processing fails? Is staying at R2-SENT > the right approach? The information that we need in R2-SENT state (for state transition) from the UPDATE packet is that the correct node has sent it. Thus, if the signature check is ok, we know that the UPDATE has come from the correct host and that it has received our R2 packet. In this case we could move to ESTABLISHED. It doesn't matter if the packet is otherwise correct or not; if not ok, we just move to ESTABLISHED and do not respond with an UPDATE. But, if signature fails, we naturally should stay at R2-SENT as we do not know who sent the packet. However, this makes things more complicated as we should determine how the UPDATE fails and the next state would depend on that. I think that it is simpler just stay at R2-SENT if the incoming UPDATE fails. /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 thomas.r.henderson@boeing.com Fri Mar 12 09:56:02 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 12 09:56:02 2004 Subject: [Hipsec] Notes and minutes Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604F2@xch-nw-27.nw.nos.boeing.com> > >> Topic: Reject Mechanism: Issue 21 > >> Slides presented: pres-ietf59-hip-henderson-reset.ppt > >> Discussions led by: Thomas Henderson > >> > >> Issue: do we need a message that notifies the sender that=20 > the message=20 > >> received was not acceptable? (instead of just dropping it=20 > silently). > >> Discussion: no comments. > >=20 > >=20 > > I took this as an implicit agreement with Thomas. > > But maybe Thomas should perform a consensus call > > on the mailing list? >=20 > Yes, I prefer to have *explicit* agreements. The process is=20 > much clearer=20 > this way. > I haven't put this to the list yet, but I agree with Pekka's memory on this one. =20 I have been waiting to read IKEv2 more closely before posting the proposal to the list, as I think that the Notify Payload may be=20 very close to what we want for this. Tom From thomas.r.henderson@boeing.com Fri Mar 12 10:33:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 12 10:33:01 2004 Subject: [Hipsec] Text for solving the R2 losses problem Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing.com> Pekka, I am still wondering whether this deserves to be defined as a full state in the state machine. In other signaling protocols that I have helped to define in the past, there is always the possibility that the last packet in the handshake gets lost. This is usually handled with no problem by just resending the last packet of the handshake again, and cycling in the same ESTABLISHED state. =20 Your point is that it would be odd to get an I2 when the SA has been in use, and would like to suppress response to such an I2 if it seems unusual to be receiving it. Another=20 way to do this, that seems basically equivalent, is to define=20 "I2 received" in ESTABLISHED state as follows: Receive I2, process if success and I2 appears to be retransmission, resend R2 and = stay in ESTABLISHED** if fail, stay at ESTABLISHED **NOTE: An implementation MAY choose to ignore this ** I2 if the inbound SA has already been used >=20 > Comments/questions: > - should we have a timeout? What if we do, should the > Responder move to ESTABLISHED, send yet another R2 and > move to ESTABLISHED, or drop the association? It would be preferable to avoid specifying a mechanism that requires putting a timer there. Whether to require an application to use the SA in a timely manner is an interesting question. On the one hand, it=20 might be useful to not force the sender to use the SA for the state machine to function correctly, since it is possible that some application of HIP may pre-establish the SA in the absence of any user data, just so it is in place for eventual forthcoming data transfer to cut down on the initial latency. On the other hand, setting up meaningless HIP SAs with no intention of ever using them is an avenue for resource depletion attack. > - In practice, an implementation may just stay in R2-SENT > for a brief period of time (few seconds), poll the SA > to see if any traffic has been received, and if so, move > to ESTABLISHED. If we define "R2-SENT" as an implicit optional substate of=20 ESTABLISHED, then we do not require any polling to move to=20 ESTABLISHED, and only poll if you receive an I2. This optimizes for the common case.=20 We are really debating about presentation style in the spec; implementation can probably be the same, except that the spec may lead people to implement it one way or the other. Tom From thomas.r.henderson@boeing.com Fri Mar 12 10:59:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 12 10:59:00 2004 Subject: [Hipsec] API and LSI resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604F3@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From:=20 > Sent: Friday, March 12, 2004 12:57 AM > To: Pekka Nikander; Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] API and LSI resolution >=20 >=20 > > > ii) Any collisions, if they are handled, are handled by > > > host NAT at the host that discovers the local collision > > > (that is, the stack may NAT the LSI into one that doesn't > > > conflict, and take care if it sees the changed LSI in the > > > application data stream to flip it back) > > > > This is OK to me as IPv4 apps must be prepared to > > deal with NATs anyway. However, I also see HIP as > > a great opportunity to hide all NATting from apps. >=20 > The plan was to handle connections like this (if I remember=20 > correctly Seoul=20 > discussions): >=20 yes, this is the plan. >=20 > The NAT function described above is not nice and better=20 > proposals are welcome. >=20 Agreed-- door is open for these in the future, but this seems to be the cleanest way to close this issue for now. Tom From thomas.r.henderson@boeing.com Fri Mar 12 10:59:04 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 12 10:59:04 2004 Subject: [Hipsec] API and LSI resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604F6@xch-nw-27.nw.nos.boeing.com> >=20 > Hence, I would like to see using > host NAT as a "MAY", with text stating that there may > be other alternatives in the future, and the exact > method of resolving LSI conflicts in the long run is > an open issue. OK >=20 > > iii) Add a subsection after 3.5 (TCP/UDP checksum) that > > describes ii) above, and summarizes API issues and the > > issue of LSIs or HITs in the application data stream, > > while deferring full API discussion to another draft >=20 > I'm fine with explicitly deferring API discussion to another > document. What comes to the TCP/UDP checksum, we use the > IPv6 pseudo header with HITs anyway, at least conceptually. > Consequently, I would say that any discussion of how to handle > this in the case of using IPv4 stack with possibly host > NATted LSIs belongs to an appendix. >=20 OK, but I think that there needs to be some statement in the main body that describes that HITs and LSIs may be used in the application data stream and hence may be observed at the API; such a statement deals with the bits that may be seen on the wire. It might not merit a separate section, though. I will work out a specific text proposal along the lines you suggested. Tom From pekka.nikander@nomadiclab.com Fri Mar 12 12:25:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 12 12:25:00 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604F6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F6@xch-nw-27.nw.nos.boeing.com> Message-ID: <8C5E375C-7450-11D8-A780-000393CE1E8C@nomadiclab.com> >> I'm fine with explicitly deferring API discussion to another >> document. What comes to the TCP/UDP checksum, we use the >> IPv6 pseudo header with HITs anyway, at least conceptually. >> Consequently, I would say that any discussion of how to handle >> this in the case of using IPv4 stack with possibly host >> NATted LSIs belongs to an appendix. > > OK, but I think that there needs to be some statement in the > main body that describes that HITs and LSIs may be used in > the application data stream and hence may be observed at the API; > such a statement deals with the bits that may be seen on the wire. Agreed. > It might not merit a separate section, though. I will work out > a specific text proposal along the lines you suggested. Ok. --Pekka From pekka.nikander@nomadiclab.com Mon Mar 15 04:17:04 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 15 04:17:04 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing.com> Message-ID: Tom, > I am still wondering whether this deserves to be defined as > a full state in the state machine. Well, as you state later, that is a matter of taste. In general, I think that we have to state more explicitly in Section 5 that the presented state machine is *not* normative in any way, and that Section 8 contains the (more) normative text. But let's also keep in mind Jim Bound's comment about implementation details... > In other signaling protocols > that I have helped to define in the past, there is always > the possibility that the last packet in the handshake gets > lost. This is usually handled with no problem by just resending > the last packet of the handshake again, and cycling in the > same ESTABLISHED state. We seem to have multiple issues here: 1. Do we want to preserve the distinction between the initiator and responder once we are in ESTABLISHED? The original goal was NOT to have any distinction. 2. Is it secure to process I2s in ESTABLISHED? At minimum, it may lead to unnecessary DoS. An attacker can exchange I1/R1, then solve the puzzle, and send an I2 with a valid puzzle. IIRC, one of the reasons for dropping I2s in ESTABLISHED is to avoid this DoS; I remember that we came into some problems with this in attacks where an attacker bumps up birthday thereby making this attack feasible. (One of the reasons why we have been moving away from resynching and the birthday concept) 3. The whole purpose of this discussion is to make sure that we recover from a lost R2, by allowing the responder to process I2s even after it is otherwise established. I think that we need to have a "state / substate / whatever" for a transient period of time where the responder is willing to reprocess I2s and send copies of R2. I think we agree there. The problem is in the details (as usual). > Your point is that it would be odd to get an I2 when the SA > has been in use, and would like to suppress response to such > an I2 if it seems unusual to be receiving it. Its more about the DoS attack outlined above. > Another way to do this, that seems basically equivalent, is to define > "I2 received" in ESTABLISHED state as follows: > > Receive I2, process > if success and I2 appears to be retransmission, resend R2 > and stay in ESTABLISHED** > if fail, stay at ESTABLISHED > **NOTE: An implementation MAY choose to ignore this > ** I2 if the inbound SA has already been used From the functional point of view, this would be OK. However, this would be counter to the architectural goal where the distinction between the responder and initiator is lost when they enter the ESTABLISHED state. > It would be preferable to avoid specifying a mechanism that > requires putting a timer there. The question is that if we want to make the peers equal in ESTABLISHED, we have to use something to trigger the responder to move to "fully ESTABLISHED" state, not answering to I2s any more. > Whether to require an application to use the SA in a timely > manner is an interesting question. Right... It is also a question about return routability. Remember, the responder has no state before processing I2 and responding with R2. Hence, it has no assurance that the source address listed in I2 really belongs to the initiator. In the opportunistic case, I can imagine an application where the responder starts sending large amounts of data immediately once it has entered ESTABLISHED. That would be a source of flooding attacks, unless we have some RR in place. (Of course, this is not a problem if we are not using opportunistic HIP but where the initiators are required to be pre-configured and trusted.) > On the one hand, it > might be useful to not force the sender to use the SA > for the state machine to function correctly, since it is possible > that some application of HIP may pre-establish the SA in the > absence of any user data, just so it is in place for eventual > forthcoming data transfer to cut down on the initial latency. Agreed. > On the other hand, setting up meaningless HIP SAs with no > intention of ever using them is an avenue for resource > depletion attack. That too. However, I guess the responder will just timeout such state after a short period of inactivity. In any case, it is _allowed_ to do so. >> - In practice, an implementation may just stay in R2-SENT >> for a brief period of time (few seconds), poll the SA >> to see if any traffic has been received, and if so, move >> to ESTABLISHED. > > If we define "R2-SENT" as an implicit optional substate of > ESTABLISHED, then we do not require any polling to move to > ESTABLISHED, and only poll if you receive an I2. This > optimizes for the common case. Indeed. Much better to do it in that way. > We are really debating about presentation style in the spec; > implementation can probably be the same, except that the > spec may lead people to implement it one way or the other. Agreed. We seem to have a (slight) disagreement on two points: - the architectural goal of no distinction between responder and initiator in ESTABLISHED state - the question about whether we need initial RR --Pekka From andrew@indranet.co.nz Mon Mar 15 06:29:00 2004 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Mar 15 06:29:00 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing .com> Message-ID: <36208314.1079399626@[192.168.1.249]> --On Monday, 15 March 2004 12:02 p.m. +0200 Pekka Nikander wrote: > 1. Do we want to preserve the distinction between the > initiator and responder once we are in ESTABLISHED? > The original goal was NOT to have any distinction. Which is, I think, pretty much essential to retain. That way it is always safe for either end to be the initator of any further mechanisms, without having to deal with differences to do with who was the initiator of the whole session. >> It would be preferable to avoid specifying a mechanism that >> requires putting a timer there. > > The question is that if we want to make the peers equal in > ESTABLISHED, we have to use something to trigger the responder > to move to "fully ESTABLISHED" state, not answering to I2s any > more. Sequence number zero no longer in the replay window? That might be tricky to do in some implementations, but makes a certain kind of sense. > >> Whether to require an application to use the SA in a timely >> manner is an interesting question. > > Right... It is also a question about return routability. > Remember, the responder has no state before processing I2 > and responding with R2. Hence, it has no assurance that the > source address listed in I2 really belongs to the initiator. In the presence of NAT, it may well not belong to the initiator, and the initiator may not know if the reverse mapping in the NAT works, so even a polite initiator can cause this to happen without meaning to. > > In the opportunistic case, I can imagine an application where > the responder starts sending large amounts of data immediately > once it has entered ESTABLISHED. That would be a source of > flooding attacks, unless we have some RR in place. (Of course, > this is not a problem if we are not using opportunistic HIP but > where the initiators are required to be pre-configured and > trusted.) > >> On the one hand, it >> might be useful to not force the sender to use the SA >> for the state machine to function correctly, since it is possible >> that some application of HIP may pre-establish the SA in the >> absence of any user data, just so it is in place for eventual >> forthcoming data transfer to cut down on the initial latency. > > Agreed. I have some applications in mind that will do exactly that, although they may well also be doing keepalive checks. >> On the other hand, setting up meaningless HIP SAs with no >> intention of ever using them is an avenue for resource >> depletion attack. > > That too. However, I guess the responder will just timeout > such state after a short period of inactivity. In any case, > it is _allowed_ to do so. Of course, the mere presence of an SA may have some meaning, too, without having to send anything across it. It might count as some kind of authentication success, for instance. One would presume that the responder policy would involve long timeouts in this case. Andrew --------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet-technologies.com/ From thomas.r.henderson@boeing.com Mon Mar 15 17:41:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Mar 15 17:41:00 2004 Subject: [Hipsec] Text for solving the R2 losses problem Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060500@xch-nw-27.nw.nos.boeing.com> >=20 > We seem to have a (slight) disagreement on two points: > - the architectural goal of no distinction between responder > and initiator in ESTABLISHED state I agree that to preserve this goal, it may be necessary to explicitly have the substate. =20 (from your original message) > - should we have a timeout? What if we do, should the > Responder move to ESTABLISHED, send yet another R2 and > move to ESTABLISHED, or drop the association? I would not favor sending unsolicited R2s. I would favor moving to ESTABLISHED as you suggest below. > - In practice, an implementation may just stay in R2-SENT > for a brief period of time (few seconds), poll the SA > to see if any traffic has been received, and if so, move > to ESTABLISHED. Agreed. It would be easiest if the main difference between R2-SENT and ESTABLISHED were only the willingness to respond to retransmitted I2. =20 How about, "leave R2-SENT if either some time has expired (allowing for maximal retransmission of I2s), or some data=20 has been received on the SA, or an UPDATE packet has been received (or some other packet that indicates that the peer has moved to ESTABLISHED)." > - the question about whether we need initial RR >=20 I'm having a hard time imagining a responder application that blasts away on a newly created SA that it didn't even initiate or receive any application data on. =20 (from previous message) > - I am unsure of what we should do with UPDATE. It is > perfectly possible to receive an UPDATE. That is, > the Initiator may send an UPDATE immediately as a response > to a R2, informing the Responder about its multi-homing > situation. As a consequence, receiving an UPDATE should > also be an indication that the Initiator is in ESTABLISHED. > However, what if processing fails? Is staying at R2-SENT > the right approach? I would vote for treating the UPDATE as grounds for moving to ESTABLISHED, and dealing with "UPDATE processing fails" case the same as is done in ESTABLISHED. Tom From stephen@sprunk.org Wed Mar 17 01:28:00 2004 From: stephen@sprunk.org (Stephen Sprunk) Date: Wed Mar 17 01:28:00 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs Message-ID: <004001c40bef$65bc8740$6401a8c0@ssprunk> My apologies if this has already been covered, but I'm still working my way through the archives... Obviously, in the case where the host requires HIP, the TCP handshake is delayed until HIP establishes an SA. How should hosts handle the case where local policy is to attempt HIP on all connections (inbound and/or outbound) but not require it? It seems that, to avoid the R1 timeout when the remote host doesn't support HIP, the host should start (or respond to) a TCP handshake immediately while starting the HIP base exchange in parallel and begin encapsulating that session in ESP once an SA is available (if ever). Presumably this wouldn't cause problems for NATs or firewalls because the HIP session would create viable new state and the unprotected TCP session's state would time out. I'm also confused about where LSIs and HITs are visible to applications; this doesn't seem clear in the draft (to me). Would these be the local and remote addresses of a socket returned by API calls? If that's correct, presumably an LSI would be returned to IPv4-only API calls and an HIT would be returned to IPv6-aware calls. Since HITs may collide with valid IPv6 addresses, would they have a different AF_* number? Is an HIT or LSI a valid source and/or destination address when creating a new socket? This also makes me wonder how an application is expected to handle the case where the local and/or remote "address" changes (to an LSI or HIT) from what is specified before the connection is started, possibly even well after the connection is completed (presumably as late as the R1+R2 timeouts). Last, the draft specifies 1.0.0.0/8 as the prefix for LSIs; has this been allocated by IANA for the purpose or should this really be TBD? I'm wondering if a similar allocation from the IPv6 address space should also be done to use for HITs if they're not otherwise distinguishable from IPv6 addresses. Thanks. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From shep@alum.mit.edu Wed Mar 17 02:31:01 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Mar 17 02:31:01 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs In-Reply-To: Your message of Wed, 17 Mar 2004 00:52:56 -0600. <004001c40bef$65bc8740$6401a8c0@ssprunk> Message-ID: > Last, the draft specifies 1.0.0.0/8 as the prefix for LSIs; has this been > allocated by IANA for the purpose or should this really be TBD? I'm > wondering if a similar allocation from the IPv6 address space should also be > done to use for HITs if they're not otherwise distinguishable from IPv6 > addresses. No such assignment has been made by IANA. (The official status of IANA IPv4 address space allocations (of /8 prefixes) can be seen at http://www.iana.org/assignments/ipv4-address-space). In my opinion, 1.0.0.0/8 should not appear in any of the HIP internet drafts. (So where do those of us who are experimenting learn of the current unnoffical parameters that we are using? Perhaps a 'ietf-*-hip-temporary-pre-IANA-constants-for-testing-01.txt' draft should be written and maintained.) Here is my memory of how the HIP community arrived as using 1.0.0.0/8 in the interoperability tests we've been doing (unofficially-) at IETF meetings for the past few years: We originally wanted to use 127.0.0.0/8 or perhaps 127.128.0.0/9 for LSI space but there were some problems where 127.0.0.0/8 was a bit too hardwired into the linux (2.4.x) kernel, and we couldn't get away with that. (One of the furthest-along implementations was written entirely in python, and had no other reason to patch the linux kernel.) I suggested that we use 0.0.0.0/8 but there were also problems with existing code that would not allow for a zero network value (and I think there may be some APIs that would break). So I took a look at the IANA IPv4 address space assignments and suggested 1.0.0.0/8 be used. But I say again, IANA has *not* made this assignment. 1.0.0.0/8 was chosen for expediency when we were at IETF meetings and wanted to test interoperability. I believe 127.128.0.0/9 would be a much better choice, and much less likely to raise objections. But how much additional burden this would place on implementors, I am not sure. Yes, we would want a similar allocation for IPv6. I figure an IPv6 /16 might be the appropriate size to ask for (why would anybody object to that?), but perhaps we should do some analysis to make sure that the remaining 112 bits are enough. We should somehow seperate our need for "what we experiment with now" values and final TBD official IANA values. (A Protocol Number for HIP comes to mind. Are their any others that need to be assigned from existing registries? Do any new IANA registries need to be created for HIP?) -Tim Shepard shep@alum.mit.edu From miika@iki.fi Wed Mar 17 04:20:00 2004 From: miika@iki.fi (Miika Komu) Date: Wed Mar 17 04:20:00 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs In-Reply-To: <004001c40bef$65bc8740$6401a8c0@ssprunk> References: <004001c40bef$65bc8740$6401a8c0@ssprunk> Message-ID: On Wed, 17 Mar 2004, Stephen Sprunk wrote: > I'm also confused about where LSIs and HITs are visible to applications; > this doesn't seem clear in the draft (to me). It has been left out the draft to avoid bloating the drafts. The API issues are being experimented as we speak and later written on a separate draft. The API is divided into two: legacy HIP API and the native HIP API. What you described in the email was the legacy API, so let's focus the discussion on that subject for now. > Would these be the local and remote addresses of a socket returned by > API calls? Yes. > If that's correct, presumably an LSI would be returned to IPv4-only API > calls and an HIT would be returned to IPv6-aware calls. Yes. > Since HITs may collide with valid IPv6 addresses, would they have a > different AF_* number? As it is stated in the draft, the two uppermost bits in the address indicate that the address is really a HIT. The bits have not been yet assigned by IANA. I guess most of the implementations still use AF_INET or AF_INET6 in the socket addresses because otherwise one would have to implement a AF_HIP socket handler in the kernel. However, in the native API, we are experimenting with the introduction of AF_HIP (and some other things as well). > Is an HIT or LSI a valid source and/or destination address when creating > a new socket? Yes, if the system knows the mapping from the HIT/LSI to the corresponding IP address(es). > This also makes me wonder how an application is expected to handle the case > where the local and/or remote "address" changes (to an LSI or HIT) from what > is specified before the connection is started, possibly even well after the > connection is completed (presumably as late as the R1+R2 timeouts). The address changes are not reflected on the application socket address data structure. What you really have there is a HIT, LSI or IP address. If the socket address contains a HIT or an LSI, base exchange is tried with the endpoint. If the base exchange fails, it is still possible to fall back to plain TCP/IP if the localhost knows the mapping from the HIT to IP address and the local HIP policy allows this kind of fallback. If the socket address contains an IP address, it is still possible to use opportunistic HIP. This requires that there is a local policy configured to use HIP with the specified destination address. Again, there is a possibility here to fallback to plain TCP/IP, if the base exchange fails and the local policy allows such a fallback. But in any case, the address changes are not reflected to the application. This is especially true in the HIP legacy API. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Gonzalo.Camarillo@ericsson.com Wed Mar 17 05:12:00 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Mar 17 05:12:00 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: References: <404ED224.1090701@ericsson.com> <405182FB.8070502@ericsson.com> Message-ID: <40582F23.4060406@ericsson.com> Pekka, the detailed minutes have been posted for a couple of days already at: http://hip.piuha.net/meetings/ietf59/notes/ietf59-hip-minutes.html I have not received further comments, so I will be submitting them shortly. Thanks, Gonzalo Pekka Nikander wrote: > Gonzalo, > >> If you still think that we should include more detailed discussions in >> the official minutes, let me know and I will take care of that. > > > I do. Sorry about requesting you to spend a couple of hours > on this issue on your already busy schedule, but I do consider > the details of the discussion valuable enough to be spelled out, > corrected by the participants (if they care), and to be submitted > to the secretariat for the proceedings. > > --Pekka -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~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 Wed Mar 17 06:02:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Mar 17 06:02:01 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: <40582F23.4060406@ericsson.com> References: <404ED224.1090701@ericsson.com> <405182FB.8070502@ericsson.com> <40582F23.4060406@ericsson.com> Message-ID: > the detailed minutes have been posted for a couple of days already at: > http://hip.piuha.net/meetings/ietf59/notes/ietf59-hip-minutes.html > > I have not received further comments, so I will be submitting them > shortly. Some corrections: > Pekka: There are two kinds of IPR. Those mentionned in IPsec are not > relevant (Certicom). The others are on mechanisms, I don't think they > apply as > well. We are not received yet any IPR claims apllying on the base > specification. Pekka: There have been two kinds of IPR claims. HIP shares some public key mechanisms with IKE, and Certicom has made claims on them. Those have been discussed in the IPsec WG, and the general opinion seems to be that they are not a problem in usual cases. Additionally, some companies (don't remember which) have claimed IPR on the puzzle mechanism, but as far as I know, there seems to be prior art. Other than that, I am not aware of any real or potential IPR claims. Furthermore, even in the mentioned two cases, there have been no specific IPR claims on the HIP drafts. > Pekka: The spec says that the HIP association have a time. If you > don't have traffic for some time, you drop association. I don't thoink > this is a good behavior. I don't know if we need to specify... Pekka: The spec says that the HIP association have a lifetime. If you don't have traffic for some time, you just drop association. Maybe the draft is too vague here. Maybe we need to specify the behaviour in more specific terms, but that can also be done when the spec advances from Experimental to Proposed (that is, if it does). > Pekka: The other protocol we want to look at is the protocol to find > RVS... but it goes to the RR. So, 5 pages defining base protocol, > using only an additionnal thing for saying RG > "this is not a peer but a RVS". I think the biggest issue is DNS draft. --Pekka From stephen@sprunk.org Wed Mar 17 10:08:01 2004 From: stephen@sprunk.org (Stephen Sprunk) Date: Wed Mar 17 10:08:01 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs References: <004001c40bef$65bc8740$6401a8c0@ssprunk> Message-ID: <004e01c40c38$07563a90$6401a8c0@ssprunk> Thus spake "Miika Komu" > On Wed, 17 Mar 2004, Stephen Sprunk wrote: > > I'm also confused about where LSIs and HITs are visible to applications; > > this doesn't seem clear in the draft (to me). > > It has been left out the draft to avoid bloating the drafts. The API > issues are being experimented as we speak and later written on a separate > draft. Fair enough. > > Since HITs may collide with valid IPv6 addresses, would they have a > > different AF_* number? > > As it is stated in the draft, the two uppermost bits in the address > indicate that the address is really a HIT. The bits have not been yet > assigned by IANA. > > I guess most of the implementations still use AF_INET or AF_INET6 in the > socket addresses because otherwise one would have to implement a AF_HIP > socket handler in the kernel. However, in the native API, we are > experimenting with the introduction of AF_HIP (and some other things as > well). I don't think it's reasonable to co-opt fully 1/2 of the total IPv6 address space for HIP without involving IANA, and hoping they will never use any of those addresses. If HITs are going to be part of AF_INET6, then we need a specific allocation (perhaps a /16) from IANA. If they are not going to be part of AF_INET6, we need a new AF_* number from IANA. Ditto with co-opting 1/8 for LSIs. > > This also makes me wonder how an application is expected to handle > > the case where the local and/or remote "address" changes (to an LSI > > or HIT) from what is specified before the connection is started, possibly > > even well after the connection is completed (presumably as late as the > > R1+R2 timeouts). > > The address changes are not reflected on the application socket address > data structure. What you really have there is a HIT, LSI or IP address. > ... > But in any case, the address changes are not reflected to the application. > This is especially true in the HIP legacy API. Sorry, I meant that when an application uses the legacy API is used to connect from IP1 to IP2, later API calls may reveal the actual connection is between LSI1 and LSI2 or HIT1 and HIT2 instead of the specified IP addresses. I have a nagging feeling this can cause problems, but I can't put my finger on when it would happen. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen@sprunk.org Wed Mar 17 10:08:04 2004 From: stephen@sprunk.org (Stephen Sprunk) Date: Wed Mar 17 10:08:04 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs References: Message-ID: <004f01c40c38$07c17f80$6401a8c0@ssprunk> Thus spake "Tim Shepard" > In my opinion, 1.0.0.0/8 should not appear in any of the HIP internet drafts. > (So where do those of us who are experimenting learn of the current > unnoffical parameters that we are using? Perhaps a > 'ietf-*-hip-temporary-pre-IANA-constants-for-testing-01.txt' draft > should be written and maintained.) AFAIK, standard practice is to state the final value is TBD and then give the value used during development (in the main drafts). > Yes, we would want a similar allocation for IPv6. I figure an IPv6 > /16 might be the appropriate size to ask for (why would anybody object > to that?), but perhaps we should do some analysis to make sure that > the remaining 112 bits are enough. We've certainly wasted larger portions of the IPv6 address space on other things, so it's not a big reach. When we get closer to requesting an actual allocation, we'll need to check not only the size required but if there are specific ranges it should or shouldn't be allocated from. Also, since there are different forms of HITs (type 1, type 2, etc), we may need to specify if each type gets its own allocation, or if all of them will be under a single HIP allocation (and thus each getting fewer actual bits). > We should somehow seperate our need for "what we experiment with now" > values and final TBD official IANA values. > (A Protocol Number for HIP comes to mind. Are their any others that > need to be assigned from existing registries? Do any new IANA > registries need to be created for HIP?) Off the top of my head, the draft expects IANA to manage HIP packet types and TLV types, plus the assumed protocol number and IPv4/v6 allocations. There might be more I'm forgetting. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From thomas.r.henderson@boeing.com Wed Mar 17 13:34:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Mar 17 13:34:01 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406050A@xch-nw-27.nw.nos.boeing.com> Stephen, FYI, in case you haven't seen it, there was some discussion=20 on API issues at the last IETF--see=20 http://hip.piuha.net/meetings/ietf59/slides/ >=20 > Sorry, I meant that when an application uses the legacy API is used to > connect from IP1 to IP2, later API calls may reveal the=20 > actual connection is > between LSI1 and LSI2 or HIT1 and HIT2 instead of the specified IP > addresses. >=20 > I have a nagging feeling this can cause problems, but I can't=20 > put my finger > on when it would happen. >=20 In the case you describe, HIP basically changes the semantics of the socket call from "socket bound to IP address IP1" to "socket bound=20 to the host who is located at IP1 when the socket call is made." This=20 can cause potential confusion if applications are using IP addresses as=20 semi-permanent identifiers (e.g., referrals or call backs), so any use=20 of HIP with legacy API and legacy applications like that must consider=20 these implications. Tom From shep@alum.mit.edu Wed Mar 17 14:23:00 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Mar 17 14:23:00 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs In-Reply-To: Your message of Wed, 17 Mar 2004 09:42:34 -0600. <004f01c40c38$07c17f80$6401a8c0@ssprunk> Message-ID: > specific ranges it should or shouldn't be allocated from. Also, since there > are different forms of HITs (type 1, type 2, etc), we may need to specify if > each type gets its own allocation, or if all of them will be under a single > HIP allocation (and thus each getting fewer actual bits). I'm not sure any of those implementing HIP takes the type 2 HITs seriously. (Maybe someone does, but last I knew, noone was planning on implementing them.) I suggested that the type 2 HIT stuff be removed from the draft a year or so ago (in conversation). -Tim Shepard shep@alum.mit.edu From thomas.r.henderson@boeing.com Wed Mar 17 14:53:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Mar 17 14:53:00 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406050B@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Tim Shepard [mailto:shep@alum.mit.edu]=20 > Sent: Wednesday, March 17, 2004 12:08 PM > To: Stephen Sprunk > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] HIP questions regarding TCP and HITs/LSIs=20 >=20 > I'm not sure any of those implementing HIP takes the type 2 HITs > seriously. (Maybe someone does, but last I knew, noone was planning > on implementing them.) >=20 > I suggested that the type 2 HIT stuff be removed from the draft a year > or so ago (in conversation). >=20 I've been considering whether we want to define type 2 HITs such that=20 some kind of structure or hierarchy can be embedded in the high order=20 bits, for help with reverse lookups. Specifically, I have DNS in mind, and perhaps Bob or others did when they defined type 2. This I view as=20 a research issue, so if we remove the type 2 HITs from the base draft=20 for now, let's do so in a way that doesn't preclude adding them back=20 in later. Tom From stephen@sprunk.org Wed Mar 17 16:37:01 2004 From: stephen@sprunk.org (Stephen Sprunk) Date: Wed Mar 17 16:37:01 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs References: <6938661A6EDA8A4EA8D1419BCE46F24C0406050B@xch-nw-27.nw.nos.boeing.com> Message-ID: <003c01c40c6e$57a3e070$6401a8c0@ssprunk> Thus spake "Henderson, Thomas R" > > From: Tim Shepard [mailto:shep@alum.mit.edu] > > > > I'm not sure any of those implementing HIP takes the type 2 HITs > > seriously. (Maybe someone does, but last I knew, noone was planning > > on implementing them.) > > > > I suggested that the type 2 HIT stuff be removed from the draft a year > > or so ago (in conversation). > > I've been considering whether we want to define type 2 HITs such that > some kind of structure or hierarchy can be embedded in the high order > bits, for help with reverse lookups. Specifically, I have DNS in mind, > and perhaps Bob or others did when they defined type 2. This I view as > a research issue, so if we remove the type 2 HITs from the base draft > for now, let's do so in a way that doesn't preclude adding them back > in later. The exact wording for this depends on whether HITs are part of the IPv6 address space or a different (colliding) 128-bit address space. The main issue the base draft will need to cover in either case is what a host should do when encountering an HIT from part of the address space it doesn't implement. Perhaps mandate that all hosts have at least one type 1 HIT available for fallback if its preferred type is refused by the remote host? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From petri.jokela@nomadiclab.com Thu Mar 18 07:05:03 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Mar 18 07:05:03 2004 Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs In-Reply-To: <003c01c40c6e$57a3e070$6401a8c0@ssprunk> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406050B@xch-nw-27.nw.nos.boeing.com> <003c01c40c6e$57a3e070$6401a8c0@ssprunk> Message-ID: <40599B3D.7010303@nomadiclab.com> Stephen Sprunk wrote: > The exact wording for this depends on whether HITs are part of the IPv6 > address space or a different (colliding) 128-bit address space. > > The main issue the base draft will need to cover in either case is what a > host should do when encountering an HIT from part of the address space it > doesn't implement. Perhaps mandate that all hosts have at least one type 1 > HIT available for fallback if its preferred type is refused by the remote > host? The HIP base draft touches the type 2 HITs only in section 3, pointing to the dns-draft that would define the HAA and hash in type 2 case. Will the coming DNS draft include this definition? If yes, should we leave the type 2 there as it is now? If no, shall we remove all references to type 2 and just say that "Other types of HITs can be defined in separate documents.". Another thing is, as Stephen proposes, shall we make type 1 HITs mandatory? At the moment, they implicitly are mandatory as there is no other type defined. /petri From Gonzalo.Camarillo@ericsson.com Thu Mar 18 10:26:02 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Mar 18 10:26:02 2004 Subject: [Hipsec] Notes and minutes In-Reply-To: References: <404ED224.1090701@ericsson.com> <405182FB.8070502@ericsson.com> <40582F23.4060406@ericsson.com> Message-ID: <4059CA30.6030407@ericsson.com> Fixed. Thanks, Gonzalo Pekka Nikander wrote: >> the detailed minutes have been posted for a couple of days already at: >> http://hip.piuha.net/meetings/ietf59/notes/ietf59-hip-minutes.html >> >> I have not received further comments, so I will be submitting them >> shortly. > > > Some corrections: > >> Pekka: There are two kinds of IPR. Those mentionned in IPsec are not >> relevant (Certicom). The others are on mechanisms, I don't think they >> apply as >> well. We are not received yet any IPR claims apllying on the base >> specification. > > > Pekka: There have been two kinds of IPR claims. HIP shares some > public key mechanisms with IKE, and Certicom has made claims on them. > Those have been discussed in the IPsec WG, and the general opinion > seems to be that they are not a problem in usual cases. Additionally, > some companies (don't remember which) have claimed IPR on the puzzle > mechanism, but as far as I know, there seems to be prior art. Other > than that, I am not aware of any real or potential IPR claims. > Furthermore, even in the mentioned two cases, there have been no > specific IPR claims on the HIP drafts. > >> Pekka: The spec says that the HIP association have a time. If you >> don't have traffic for some time, you drop association. I don't thoink >> this is a good behavior. I don't know if we need to specify... > > > Pekka: The spec says that the HIP association have a lifetime. If you > don't have traffic for some time, you just drop association. Maybe the > draft is too vague here. Maybe we need to specify the behaviour in > more specific terms, but that can also be done when the spec advances > from Experimental to Proposed (that is, if it does). > >> Pekka: The other protocol we want to look at is the protocol to find >> RVS... but it goes to the RR. So, 5 pages defining base protocol, >> using only an additionnal thing for saying > > RG > >> "this is not a peer but a RVS". I think the biggest issue is DNS draft. > > > --Pekka > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~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 jonwood@speakeasy.net Thu Mar 18 20:26:00 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Mar 18 20:26:00 2004 Subject: [Hipsec] Cookies Message-ID: Hi. I'm getting familiar with HIP, and I was wondering about the design rational behind the way cookies are currently defined. I am curious why something like SCTP's cookie method wasn't chosen. A quick recap on the SCTP method: SCTP cookies contain a chunk ("State Cookie") filled in by the responder. This chunk is opaque to the sender, who must return the chunk unchanged. The responder can use a secret and a MAC to trivially verify that the sender is the same host that initiated the exchange (among other things). It seems like this sort of mechanism could easily be applied to HIP R1 / I2 exchanges - the responder could use it to verify that the sender is that same host that sent the I1, and that the puzzle I is the same that was propose in the R1. This approach would be simpler to implement, I think, than the current mechanism, and would allow implementors greater flexibility to do interesting things. Another issue I see with the current mechanism is that the puzzle I is precomputed, since it is protected by the signature presumably. This means that an attacker can solve the puzzle once and then try to pound the responder by forcing it to do lots of work verifying signatures and such. This window of opportunity for attack lasts for the lifetime of the precomputed cookie. The root problem here seems to be that I is protected by the signature, so responders can't hand out a new I in each R1. So just how important is it that the I is protected by the signature? If the I doesn't need to be protected, we could do something like TCP syn cookies, where we can select a special I by combining it with a secret and the IP addresses and HITs - this would achieve the same result as SCTP-style opaque chunks and also prevent attackers from replaying solved puzzles. Any insights would be appreciated! Thanks, Jon From thomas.r.henderson@boeing.com Fri Mar 19 18:56:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 19 18:56:01 2004 Subject: [Hipsec] Cookies Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060515@xch-nw-27.nw.nos.boeing.com> Jon, responses inline below. > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Thursday, March 18, 2004 6:11 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Cookies >=20 >=20 >=20 > Hi. >=20 > I'm getting familiar with HIP, and I was wondering > about the design rational behind the way cookies > are currently defined. I am curious why something > like SCTP's cookie method wasn't chosen. >=20 > A quick recap on the SCTP method: >=20 > SCTP cookies contain a chunk ("State Cookie") filled > in by the responder. This chunk is opaque to the sender, > who must return the chunk unchanged. The responder > can use a secret and a MAC to trivially verify that the > sender is the same host that initiated the exchange > (among other things). >=20 > It seems like this sort of mechanism could easily be > applied to HIP R1 / I2 exchanges - the responder > could use it to verify that the sender is that same host > that sent the I1, and that the puzzle I is the same that > was propose in the R1. >=20 > This approach would be simpler to implement, I think, > than the current mechanism, and would allow > implementors greater flexibility to do interesting things. The puzzles allow the responder to control a certain amount of DoS resilience. I believe that the design was motivated by work described in: http://research.microsoft.com/users/tuomaura/Publications/aura-nikander-l= eiwo-protocols00.pdf >=20 > Another issue I see with the current mechanism is that > the puzzle I is precomputed, since it is protected by > the signature presumably. This means that an attacker > can solve the puzzle once and then try to pound the > responder by forcing it to do lots of work verifying signatures > and such. This window of opportunity for attack lasts for > the lifetime of the precomputed cookie. >=20 The responder should limit the number of times (once?) that it responds to the same cookie solution (solutions are supposed to be generated randomly). The responder can set the cookie difficulty (perhaps based on recent history of failed signatures) to guard against an attacker trivially churning out lots of=20 solutions. > The root problem here seems to be that I is protected by > the signature, so responders can't hand out a new I in > each R1. So just how important is it that the I is protected > by the signature? >=20 > If the I doesn't need to be protected, we could do something > like TCP syn cookies, where we can select a special I by > combining it with a secret and the IP addresses and HITs - > this would achieve the same result as SCTP-style opaque > chunks and also prevent attackers from replaying solved > puzzles. >=20 Well, it could be done that way, at the cost of having to do the cookie generation upon sending the R1, and losing the ability to force (control) initiator to pay computational cycles to get its packets processed. Tom From jonwood@speakeasy.net Fri Mar 19 20:13:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Fri Mar 19 20:13:01 2004 Subject: [Hipsec] Cookies In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060515@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060515@xch-nw-27.nw.nos.boeing.com> Message-ID: <298F0A51-7A12-11D8-8F19-0003930D291E@speakeasy.net> Hi Thomas, On Mar 19, 2004, at 4:40 PM, Henderson, Thomas R wrote: > Jon, > responses inline below. > <...> > The puzzles allow the responder to control a certain amount > of DoS resilience. I believe that the design was motivated by > work described in: > http://research.microsoft.com/users/tuomaura/Publications/aura- > nikander-leiwo-protocols00.pdf Sorry if I wasn't altogether clear - I have no doubts about the value of puzzles for enhancing DOS resilience. My questions focus on how the responder can verify that an I2 is indeed a valid response to the responder's R1. >> >> Another issue I see with the current mechanism is that >> the puzzle I is precomputed, since it is protected by >> the signature presumably. This means that an attacker >> can solve the puzzle once and then try to pound the >> responder by forcing it to do lots of work verifying signatures >> and such. This window of opportunity for attack lasts for >> the lifetime of the precomputed cookie. >> > > The responder should limit the number of times (once?) that it > responds to the same cookie solution (solutions are supposed > to be generated randomly). The responder can set the cookie > difficulty (perhaps based on recent history of failed signatures) > to guard against an attacker trivially churning out lots of > solutions. > >> The root problem here seems to be that I is protected by >> the signature, so responders can't hand out a new I in >> each R1. So just how important is it that the I is protected >> by the signature? >> >> If the I doesn't need to be protected, we could do something >> like TCP syn cookies, where we can select a special I by >> combining it with a secret and the IP addresses and HITs - >> this would achieve the same result as SCTP-style opaque >> chunks and also prevent attackers from replaying solved >> puzzles. >> > > Well, it could be done that way, at the cost of having to do > the cookie generation upon sending the R1, and losing the ability > to force (control) initiator to pay computational cycles to get its > packets processed. > Cookie generation itself is pretty cheap, no? Isn't the signature generation the computationally expensive part for the responder? I am concerned about the complexity required to implement a really robust, industrial strength system to manage R1s. I think that keeping histories of failed signatures, failed puzzle solutions, and replayed puzzle solutions will be tricky to get right. Perhaps a concrete proposal would help to clarify my (perhaps confused) thinking: Add a variable or fixed- length field to the cookie TLV (let's call it the Responder Chunk). The responder can put whatever it wants in it, and the initiator must return it without modification. The signature does not cover I, K, or the Responder Chunk, allowing the hard part of R1 generation to be precomputed. One way the responder could use the Responder Chunk is as follows: Create a secret, and change it every minute or so. Remember the last secret as well. For each I1, generate I (or maybe pull it from a block of pre-computed Is), and place it in the R1 cookie. Generate K based on some measure of the responder's current load. Combine the secret, initiator's IP address, HITs, I and K, and the secret using some method that is computationally trivial, and place the result in the Responder Chunk. On receipt of an I2, combine the parameters as described above, and check the result against the value in the Responder Chunk. If it doesn't match, try using the old secret, and if that doesn't match, drop the I2. If it does match, continue by verifying the puzzle, and so on. As far as I can see, this would eliminate the need precompute multiple R1s and manage them as described in 4.1.1 and Appendix D. Regards, Jon From thomas.r.henderson@boeing.com Fri Mar 19 21:01:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Mar 19 21:01:01 2004 Subject: [Hipsec] Cookies Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060516@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Jonathan Wood [mailto:jonwood@speakeasy.net]=20 > Sent: Friday, March 19, 2004 5:59 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Cookies >=20 > >> If the I doesn't need to be protected, we could do something > >> like TCP syn cookies, where we can select a special I by > >> combining it with a secret and the IP addresses and HITs - > >> this would achieve the same result as SCTP-style opaque > >> chunks and also prevent attackers from replaying solved > >> puzzles. > >> > > > > Well, it could be done that way, at the cost of having to do > > the cookie generation upon sending the R1, and losing the ability > > to force (control) initiator to pay computational cycles to get its > > packets processed. > > >=20 > Cookie generation itself is pretty cheap, no? Isn't the signature > generation the computationally expensive part for the responder? Yes, although there seems to have been consistent goal to make R1 independent of the I1 (I seem to remember some discussion of this on the old freeswan HIP list, but I don't know where that is archived anymore. Maybe someone else can remember or chime in.) >=20 > I am concerned about the complexity required to implement a > really robust, industrial strength system to manage R1s. I think > that keeping histories of failed signatures, failed puzzle solutions, > and replayed puzzle solutions will be tricky to get right. >=20 > Perhaps a concrete proposal would help to clarify > my (perhaps confused) thinking: OK, so I think I understand better, you are proposing: i) move cookie outside of signature ii) make "I" verifiable and initiator-specific, as alternative to=20 managing R1s And whether a responder does anything with I value (making it tied to initiator, or just a random string) is implementation-specific and up to the responder. Unless there is some reason not to move it outside signature, it seems to me that your proposal is more flexible, because it would allow either approach. Tom From thomas.r.henderson@boeing.com Sat Mar 20 17:11:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sat Mar 20 17:11:01 2004 Subject: [Hipsec] FW: I-D ACTION:draft-iab-identities-00.txt Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B65C8@xch-nw-27.nw.nos.boeing.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C40ECE.9FD476F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable of possible WG/RG interest -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 18, 2004 6:49 AM Cc: iab@iab.org Subject: I-D ACTION:draft-iab-identities-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Internet Architecture Board Working = Group of the IETF. Title : A Survey of Internet Identities Author(s) : P. Faltstrom, G. Huston Filename : draft-iab-identities-00.txt Pages : 28 Date : 2004-3-17 =09 This memo provides an overview of the various realms of identification used within the Internet protocol suite, with specific observations on the role and purpose of the Domain Name System within this environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-identities-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-iab-identities-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iab-identities-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C40ECE.9FD476F0 Content-Type: application/octet-stream; name="ATT866492.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT866492.TXT Content-Disposition: attachment; filename="ATT866492.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDA0LTMtMTgxMDEzMjAuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWFiLWlkZW50aXRpZXMt MDAudHh0DQo= ------_=_NextPart_001_01C40ECE.9FD476F0 Content-Type: application/octet-stream; name="draft-iab-identities-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-iab-identities-00.URL Content-Disposition: attachment; filename="draft-iab-identities-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pYWItaWRlbnRpdGllcy0wMC50eHQNCg== ------_=_NextPart_001_01C40ECE.9FD476F0-- From thomas.r.henderson@boeing.com Sun Mar 21 15:51:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Mar 21 15:51:01 2004 Subject: [Hipsec] API and LSI resolution Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B65CE@xch-nw-27.nw.nos.boeing.com> Below is proposed text that deals with the API and LSI issues=20 that have been discussed. Note that this text does not address the IANA issue previously raised regarding 1.0.0.0/8 range for LSIs. 3.2 Local Scope Identifier (LSI) LSIs are 32-bit localized representations of a Host Identity. The purpose of an LSI is to facilitate using Host Identities in existing IPv4 based protocols and APIs. The LSI can be used anywhere in = system processes where IP addresses have traditionally been used, such as IPv4 API calls and FTP PORT commands. The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it easier to differentiate between LSIs and IPv4 addresses at the API level. The low order 24 bits of an LSI MUST be equal to the low=20 order 24 bits of the corresponding HIT. =20 A host performing a HIP handshake may discover that the LSI formed = from=20 the peer's HIT collides with another LSI in use locally (i.e., the = lower=20 24 bits of two different HITs are the same). In that case, the host = MUST=20 handle the LSI collision locally such that application calls can be=20 disambiguated. One possible means of doing so is to perform a Host = NAT=20 function to locally convert a peer's LSI into a different LSI value. = This=20 would require the host to ensure that LSI bits on the wire (i.e., in = the=20 application data stream) are converted back to match that host's LSI. = Other=20 alternatives for resolving LSI collisions may be added in the future. 6.2 HIP parameters TLV Type Length Data SPI 1 16 Remote's SPI 6.2.3 SPI The SPI parameter contains the SPI that the receiving host must use when sending data to the sending host. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4=20 SPI Security Parameter Index 8.7 Processing incoming I2 packets 15. If the system supports LSIs, it should check that the received LSI is an acceptable representation of its own identity, and create an appropriate state. If the LSI is not acceptable, the behaviour is currently undefined; see Appendix A. 8.8 Processing incoming R2 packets 7. If the system supports LSIs, it should check that the received LSI is an acceptable representation of its own identity, and create an appropriate state. If the LSI is not acceptable, the behaviour is currently undefined; see Appendix A. Appendix A. API issues The following text is informational and may be expanded upon or=20 revised in a separate Informational document. =20 HIP may be used to support application data transfers in one of three ways: 1) the application may be HIP-aware and may explicitly use a HIP-based API and/or resolver library; 2) the application may not be HIP-aware but may be provided with HITs or LSIs in place of IP addresses as part of the address resolution = process; and=20 3) the application may or may not be HIP-aware and may present IP=20 addresses to the system, but the system may decide to=20 opportunistically invoke HIP or use a pre-existing HIP-based SA=20 on its behalf. The first case is the most straightforward. The HIP-based API=20 is outside the scope of this document. =20 The second case is one way to provide HIP support to non-HIP-aware applications. HITs may be stored in the DNS or some other=20 infrastructure, and the resolver library may choose to supply a=20 querying application with a HIT or LSI in place of an IP address. =20 Note that if the application truly needs IP addresses for a domain=20 name for some reason (e.g., a diagnostic application, or for use in=20 a referral scenario to a non-HIP-based host), blindly providing HITs=20 or LSIs in place of actual IP addresses may cause some applications=20 to break. In both of the first two cases, the means whereby a system can resolve an LSI or HIT to an IP address, when such a mapping is not locally cached in the system, is outside the scope of this document. =20 In the third case, the system is explicitly invoking HIP to a particular destination IP address on the basis of a local policy=20 decision. This approach resembles the way that opportunistic IPsec works. Effectively, this approach is implicitly associating=20 IP addresses with host identities, and is prone to certain failures=20 or ambiguity in an environment where IP addresses are dynamic (e.g.,=20 an application connects to an IP address, the peer host moves at=20 some later time, then another host acquires the old IP address,=20 and the system again receives a request to connect to that IP address, in which case it is ambiguous whether the application wants to connect to the host previously at that IP address or the new host at that address). If HIP is used to support an application, the application data stream may contain either IP addresses or LSIs or HITs in place of the IP addresses. From thomas.r.henderson@boeing.com Sun Mar 21 15:55:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Sun Mar 21 15:55:01 2004 Subject: [Hipsec] HIP Notify text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Below is some candidate text to deal with the HIP Reject issue discussed at the IETF-59 meeting. It is based the Notify Payload of the IKEv2 draft. =20 I defined both a new NOTIFY parameter and a NOTIFY packet. The text below states that NOTIFY packet is optional. The text also=20 states that the NOTIFY parameter is only sent in a NOTIFY packet,=20 although it may be possible to send NOTIFY parameters in other packets in the future (e.g., perhaps an R2 in the future does not contain the normal parameters but instead a NOTIFY parameter that indicates why the I2 failed processing). However, I refrained from=20 defining that for now, to err on the side of simplicity. The NOTIFY parameter type code and NOTIFY packet type code are=20 undefined in the below text-- I do not know the convention for these assignments (Petri can fill in). The Notify Message Type codes are=20 based on similar codes in IKEv2, but there is not a 1-to-1 mapping. Note also that a mechanism for sending a packet to indicate Unknown SPI is included. 6.2 HIP parameters TLV Type Length Data NOTIFY XX variable Informational data 6.2.14 NOTIFY The NOTIFY parameter is used to transmit informational data, such as error conditions and state transitions, to a HIP peer. A NOTIFY parameter may appear in the NOTIFY packet type. The use of the=20 NOTIFY parameter in other packet types is for further study. 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 | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Notification Data / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type XX Length length in octets, excluding Type, Length, and = Padding Reserved zero when sent, ignored when received Notify Message Specifies the type of notification Type =20 Notification Informational or error data transmitted in addition = Data to the Notify Message Type. Values for this field=20 are type specific (see below). Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. The table below lists the Notification messages and their corresponding values. =20 Types in the range 0 - 16383 are intended for reporting errors. An implementation that receives a NOTIFY error parameter in response to = a=20 request packet (e.g., I1, I2, UPDATE), SHOULD assume that the corresponding request has failed entirely. Unrecognized error types MUST be ignored except that they SHOULD be logged. Notify payloads with status types MUST be ignored if not recognized.=20 NOTIFY PARAMETER - ERROR TYPES Value ----------------------------- ----- UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 Sent if the parameter type has the "critical" bit set and = the parameter type is not recognized. Notification Data contains the two octet parameter type. INVALID_MAJOR_VERSION 5 Indicates the recipient cannot handle the version of HIP specified in the header. The closest version number that the recipient can support will be in the reply header. INVALID_SYNTAX 7 Indicates that the HIP message received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a denial of service attack using forged messages, this status may only be returned for and in an encrypted packet if the message ID and cryptographic checksum were valid. To avoid leaking information to someone probing a node, this status MUST be sent in response to any error not covered by one of the other status types. To aid debugging, more detailed error information SHOULD be written to a console or log. INVALID_SPI 11 MAY be sent in a NOTIFY packet when a node receives an ESP=20 packet with an invalid SPI. The Notification Data contains=20 the SPI of the invalid packet. This usually indicates a = node=20 has rebooted and forgotten an SA. If this Informational = Message=20 is sent outside the context of a HIP SA, it should only be = used=20 by the recipient as a "hint" that something might be wrong=20 (because it could easily be forged). NO_DH_PROPOSAL_CHOSEN 14 None of the proposed group IDs was acceptable. INVALID_DH_CHOSEN 15 The D-H Group ID field does not correspond to one offered by the responder. NO_HIP_PROPOSAL_CHOSEN 16 None of the proposed HIP Transform crypto suites was=20 acceptable. INVALID_HIP_TRANSFORM_CHOSEN 17 The HIP Transform crypto suite does not correspond to=20 one offered by the responder. NO_ESP_PROPOSAL_CHOSEN 18 None of the proposed ESP Transform crypto suites was=20 acceptable. INVALID_ESP_TRANSFORM_CHOSEN 19 The ESP Transform crypto suite does not correspond to=20 one offered by the responder. AUTHENTICATION_FAILED 24 Sent in response to a HIP signature failure. CHECKSUM_FAILED 26 Sent in response to a HIP checksum failure. HMAC_FAILED 28 Sent in response to a HIP HMAC failure. INVALID_COOKIE_SOLUTION 30 The responder could not validate the cookie solution. ENCRYPTION_FAILED 32 The responder could not successfully decrypt the=20 ENCRYPTED TLV. INVALID_HIT 40 Sent in response to a failure to validate the peer's HIT from the corresponding HI. =20 NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- (None defined at present) 7.9 NOTIFY - the HIP Notify Packet The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to provide information to a peer. Typically, NOTIFY is used to indicate some type of protocol error or negotiation failure. The HIP header values for the NOTIFY packet: Header: Packet Type =3D XX SRC HIT =3D Sender's HIT DST HIT =3D Recipient's HIT, or zero if unknown IP ( HIP (NOTIFY, HIP_SIGNATURE) ) Valid control bits: None The NOTIFY packet is used to carry a NOTIFY parameter. 8.14 Processing NOTIFY packets Processing NOTIFY packets is OPTIONAL. If processed, any errors=20 noted by the NOTIFY parameter SHOULD be taken into account by the HIP state machine (e.g., by terminating a HIP handshake), and the=20 error SHOULD be logged. From miika@iki.fi Mon Mar 22 03:49:03 2004 From: miika@iki.fi (Miika Komu) Date: Mon Mar 22 03:49:03 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: On Sun, 21 Mar 2004, Henderson, Thomas R wrote: > 6.2.14 NOTIFY > > The NOTIFY parameter is used to transmit informational data, such as > error conditions and state transitions, to a HIP peer. A NOTIFY > parameter may appear in the NOTIFY packet type. The use of the > NOTIFY parameter in other packet types is for further study. > > 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 | Notify Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > / Notification Data / > / +-+-+-+-+-+-+-+-+ > | | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type XX > Length length in octets, excluding Type, Length, and Padding > Reserved zero when sent, ignored when received > Notify Message Specifies the type of notification > Type > Notification Informational or error data transmitted in addition > Data to the Notify Message Type. Values for this field > are type specific (see below). Good stuff! Perhaps there should be also a field in the NOTIFY for indicating the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY packet was sent as a response? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Julien.Laganier@Sun.COM Mon Mar 22 06:03:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Mar 22 06:03:01 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: <200403221248.59533.julien.laganier@sun.com> On Monday 22 March 2004 10:34, Miika Komu wrote: > On Sun, 21 Mar 2004, Henderson, Thomas R wrote: > > 6.2.14 NOTIFY > > > > The NOTIFY parameter is used to transmit informational data, > > such as error conditions and state transitions, to a HIP peer. A > > NOTIFY parameter may appear in the NOTIFY packet type. The use > > of the NOTIFY parameter in other packet types is for further > > study. > > > > 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 | Notify Message Type > > | | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > / Notification Data > > / / > > +-+-+-+-+-+-+-+-+ > > > > | | Padding | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type XX > > Length length in octets, excluding Type, Length, > > and Padding Reserved zero when sent, ignored when received > > Notify Message Specifies the type of notification > > Type > > Notification Informational or error data transmitted in > > addition Data to the Notify Message Type. Values for > > this field are type specific (see below). > > Good stuff! > > Perhaps there should be also a field in the NOTIFY for indicating > the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY > packet was sent as a response? But an implementation receiving a NOTIFY packet knows what packets it send before, right? I fail to see the need... OTOH, it would certainly be useful to be able to notify several error types within different parameters... One could achieve this by replacing the { Reserved (16 bit) | Notify Message Type (16 bit) | Notification data } proposed by Thomas by several Notify chunks: { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit) | Notification Data } The Parameter Type being set to the parameter type which triggered this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's caused by the base HIP header, and the Notify Parameter sub-type being a per parameter defined sub type. For example, the parameter SPI could have the following notify subtypes: o UNKNOWN_SPI 0x01 o ALREADY_USED_SPI 0x02 o EXPIRED_SPI 0x03 IMHO it gives much more flexibility in notifying errors while not being overly complex... Thoughts? Thanks, --julien From miika@iki.fi Mon Mar 22 08:12:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Mar 22 08:12:01 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <200403221248.59533.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403221248.59533.julien.laganier@sun.com> Message-ID: On Mon, 22 Mar 2004, Julien Laganier wrote: > > Perhaps there should be also a field in the NOTIFY for indicating > > the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY > > packet was sent as a response? > > But an implementation receiving a NOTIFY packet knows what packets it > send before, right? I fail to see the need... You are probably right... even if there would be this new field, it would have to be double checked from the state machine. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkousa@cc.hut.fi Tue Mar 23 04:14:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Mar 23 04:14:00 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: On Sun, 21 Mar 2004, Henderson, Thomas R wrote: -> NOTIFY PARAMETER - ERROR TYPES Value -> ----------------------------- ----- -> ... -> INVALID_HIT 40 -> -> Sent in response to a failure to validate the peer's -> HIT from the corresponding HI. And "opportunistic mode not supported" if responder HIT is NULL ? -> 7.9 NOTIFY - the HIP Notify Packet -> -> The NOTIFY packet is OPTIONAL. The NOTIFY packet MAY be used to -> provide information to a peer. Typically, NOTIFY is used to -> indicate some type of protocol error or negotiation failure. -> -> The HIP header values for the NOTIFY packet: -> -> Header: -> Packet Type = XX -> SRC HIT = Sender's HIT -> DST HIT = Recipient's HIT, or zero if unknown -> -> IP ( HIP (NOTIFY, HIP_SIGNATURE) ) -> -> Valid control bits: None -> -> The NOTIFY packet is used to carry a NOTIFY parameter. Would it be useful if NOTIFY packet could contain multiple NOTIFY parameters (eg. to indicate multiple errors in one packet) ? From mkousa@cc.hut.fi Tue Mar 23 04:49:04 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Mar 23 04:49:04 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <200403221248.59533.julien.laganier@sun.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403221248.59533.julien.laganier@sun.com> Message-ID: On Mon, 22 Mar 2004, Julien Laganier wrote: -> On Monday 22 March 2004 10:34, Miika Komu wrote: -> > -> > Perhaps there should be also a field in the NOTIFY for indicating -> > the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY -> > packet was sent as a response? -> -> But an implementation receiving a NOTIFY packet knows what packets it -> send before, right? I fail to see the need... There might be some need. Let's say that two hosts send eg. several UPDATE packets really fast (not a likely scenario but anyway). The other host notices an error in the first UPDATE packet and sends a NOTIFY packet related to this failed UPDATE packet. Then the NOTIFY packet gets stuck somewhere in-between the hosts, but new UPDATE packets keep coming through before the NOTIFY packet is finally received. Now, how can you differentiate which UPDATE of the several received ones contained errors ? -> OTOH, it would certainly be useful to be able to notify several error -> types within different parameters... One could achieve this by -> replacing the -> -> { Reserved (16 bit) | Notify Message Type (16 bit) | Notification -> data } -> -> proposed by Thomas by several Notify chunks: -> -> { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit) -> | Notification Data } Sounds like a good idea to me, too. From petri.jokela@nomadiclab.com Tue Mar 23 07:32:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Mar 23 07:32:01 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: <406038BB.6090708@nomadiclab.com> Henderson, Thomas R wrote: > Below is some candidate text to deal with the HIP Reject issue > discussed at the IETF-59 meeting. It is based the Notify Payload > of the IKEv2 draft. Good text, I will edit this into draft and we'll see how it looks like. > The NOTIFY parameter type code and NOTIFY packet type code are > undefined in the below text-- I do not know the convention for these > assignments (Petri can fill in). The Notify Message Type codes are > based on similar codes in IKEv2, but there is not a 1-to-1 mapping. With the parameter type, we control its place relative to other parameters. In case of NOTIFY packet, we just put it before the HIP_SIGNATURE, with smaller type value. If we do not define the NOTIFY parameter to be used in other packets, the value doesn't matter so much. But, if we look into future, are there currently existing parameters that would require the NOTIFY to be after or before them? /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 Mar 23 07:36:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Mar 23 07:36:01 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: <406039B6.4040809@nomadiclab.com> Miika Komu wrote: > On Sun, 21 Mar 2004, Henderson, Thomas R wrote: > > >>6.2.14 NOTIFY >> >> The NOTIFY parameter is used to transmit informational data, such as >> error conditions and state transitions, to a HIP peer. A NOTIFY >> parameter may appear in the NOTIFY packet type. The use of the >> NOTIFY parameter in other packet types is for further study. >> >> 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 | Notify Message Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> / Notification Data / >> / +-+-+-+-+-+-+-+-+ >> | | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Perhaps there should be also a field in the NOTIFY for indicating the > packet header type (I2, R1, UPDATE, etc) for which the NOTIFY packet was > sent as a response? > Maybe the Notification Data part should contain some information related to the rejected packet? Header of the rejected packet maybe? /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 Mar 23 08:01:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Mar 23 08:01:01 2004 Subject: [Hipsec] Update race condition In-Reply-To: <200403040948.53919.Jan.Melen@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> Message-ID: <40603F89.60806@nomadiclab.com> Related to the UPDATE race condition, I propose some changes to text in 8.10 and 8.10.1. Any comments? /petri Jan Mikael Melen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > The update packets that are crossing each other in the network can not be > handled as specified today in section 8.10.1 because if they are handled as > specified in 8.10.1 then both ends will fetch wrong incoming SA keys and > wrong outgoing SA keys. Host-A expects to receive with the same key as HOST-B > expects to receive not good. Have I understood the draft correctly? > > Solution to this problem would be that the keys would be fetched in predefined > order. When a update packet is received the keys are always fetched in > following way. Compare the HITs and first fetch the key of the host that has > in network byte order smaller HIT and then fetch the key of the host that has > in network byte order greater HIT (this is also used in section 9 generating > HIP Keymat). Comments? I propose to add some text to 8.10: 8.10 Processing UPDATE packets When a system receives a UPDATE packet, its processing depends on whether the packet is a reply to a previously sent UPDATE packet or the UPDATE is a new packet. The order of the keys retrieved from the KEYMAT during rekeying process depends on the HIT value comparison. We denote the host with lower HIT value with HITl and, respectively, the host with greater HIT with HITg. The HITs are compared in network byte order. The keys are retrieved from the KEYMAT in the following order: SA-gl ESP encryption key for HITg's outgoing traffic SA-gl ESP authentication key for HITg's outgoing traffic SA-lg ESP encryption key for HITl's outgoing traffic SA-lg ESP authentication key for HITl's outgoing traffic The following steps define the conceptual processing rules responding handling a received UPDATE packet: ... > There is one corner case which has to be also stated in the draft and that is. > If host A has sent a update containing keymat index 172 to host B. At the > same host B has sent a update packet containing keymat index 220 to host A (B > has for some reason decided not to use the keying material between 172-220 > this is allowed already today). These two packets are crossing each other on > the network. So A has to accept the greater keymat index gotten in update > packet although it does not match with the index sent. Also B has to accept > that the keymat index in update packet is older than what it would like to > use (this is new and should be allowed only if B is in state rekeying). Both > A and B when creating the update reply packet must put the greater keymat > index in to the reply packet. The bigger keymat index always wins. And to fix this potential problem: In 8.10, change the bullet number 5 (to allow also lower Keymat Index if we are in REKEYING state): 5. If the received UPDATE does not contain a Diffie-Hellman parameter, the received Keymat Index MUST be larger or equal to the index of the next byte to be drawn from the current KEYMAT. If the host is in REKEYING state, a smaller Keymat Index value MAY be accepted. If the host is in ESTABLISHED state and this test fails, the packet SHOULD be dropped and the system SHOULD log an error message. And in 8.10.1, a new bullet that defines that in race condition, we select the bigger of the Keymat Indexes: 4. If the host is in REKEYING state, and neither the incoming UPDATE packet nor the sent UPDATE packet required new KEYMAT generation, the bigger Keymat Index number of those two UPDATE packets shall be used. -- 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 mkousa@cc.hut.fi Tue Mar 23 08:08:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Mar 23 08:08:01 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403221248.59533.julien.laganier@sun.com> Message-ID: I might have misunderstood something, but I need some clarifications while I'm trying to implement the UPDATE packet: Example scenario: After the base exchange, host A increments outgoing UPDATE ID counter from value 0 to 1 and sends UPDATE packet to B. Now host B has stored A's incoming UPDATE ID value 1. B responds with corresponding UPDATE packet (with UPDATE ID 1) and host A stores B's incoming UPDATE ID value 1. Both hosts are also again in established state. Then the same process is done again, so the result is that B has stored A's incoming UPDATE ID value 2 and host A has stored B's incoming UPDATE ID value 2. Nothing unclear so far, because I understood that incoming UPDATE IDs are recorded regardless whether the packet is a reply or not (at least draft-09 section 8.10 (Processing UPDATE packets) bulletin point 7. does not differentiate the cases). Then host B sends UPDATE with (its own outgoing) ID 1 to host A. B moves now to rekeying state. When host A receives the UPDATE packet it starts to handle the packet according to draft-09 section 8.10: "1. If the system is in state ESTABLISHED and the UPDATE has the R-bit set in the NES TLV, the packet is silently dropped.". This is not true, because the R-bit is not set. "2. If the UPDATE ID in the received UPDATE is smaller than the stored incoming UPDATE ID, the packet MUST BE dropped." Host A sees that incoming ID value in the reply UPDATE is 1. Also, A sees that the last incoming ID received before from host B was 2, so this reply packet is dropped. Assuming that the implementation follows strictly the steps defined in the draft, this causes problems. Therefore, should section 8.10 bulletin point 2. say "If the UPDATE does not have the R-bit set and the UPDATE ID in the received UPDATE is smaller than the stored incoming UPDATE ID, the packet MUST BE dropped" instead of the current text "If the UPDATE ID in the received UPDATE is smaller than the stored incoming UPDATE ID, the packet MUST BE dropped" ? From thomas.r.henderson@boeing.com Tue Mar 23 11:49:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Mar 23 11:49:00 2004 Subject: [Hipsec] HIP Notify text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060522@xch-nw-27.nw.nos.boeing.com> > > Perhaps there should be also a field in the NOTIFY for=20 > indicating the > > packet header type (I2, R1, UPDATE, etc) for which the=20 > NOTIFY packet was > > sent as a response? > >=20 >=20 > Maybe the Notification Data part should contain some=20 > information related=20 > to the rejected packet? Header of the rejected packet maybe? >=20 Yes, I thought about this too. I think it is reasonable to include. HIP header could be included as Notification Data for error Notifys (except for INVALID_SPI, which is not triggered by a HIP message, and which contains the=20 SPI instead). May not need to include the HITs-- maybe just the first two words. Tom From thomas.r.henderson@boeing.com Tue Mar 23 11:51:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Mar 23 11:51:01 2004 Subject: [Hipsec] HIP Notify text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B65F3@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM]=20 > Sent: Monday, March 22, 2004 3:49 AM > To: hipsec@honor.trusecure.com > Cc: Miika Komu; Henderson, Thomas R > Subject: Re: [Hipsec] HIP Notify text >=20 > OTOH, it would certainly be useful to be able to notify several error=20 > types within different parameters... One could achieve this by=20 > replacing the=20 >=20 > { Reserved (16 bit) | Notify Message Type (16 bit) | Notification=20 > data }=20 >=20 > proposed by Thomas by several Notify chunks: >=20 > { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit) > | Notification Data } >=20 > The Parameter Type being set to the parameter type which triggered=20 > this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's caused by the=20 > base HIP header, and the Notify Parameter sub-type being a per=20 > parameter defined sub type. For example, the parameter SPI could have=20 > the following notify subtypes: >=20 > o UNKNOWN_SPI 0x01 > o ALREADY_USED_SPI 0x02 > o EXPIRED_SPI 0x03 >=20 > IMHO it gives much more flexibility in notifying errors while not=20 > being overly complex... >=20 > Thoughts? Thanks, My sense is that this is overkill-- I don't know how much it matters to have hierarchical error reporting. Allowing different notify parameters to be included in a single packet should be allowed, however. Tom From thomas.r.henderson@boeing.com Tue Mar 23 12:09:04 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Mar 23 12:09:04 2004 Subject: [Hipsec] HIP Notify text Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060523@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Tuesday, March 23, 2004 2:00 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] HIP Notify text >=20 >=20 > On Sun, 21 Mar 2004, Henderson, Thomas R wrote: >=20 > -> NOTIFY PARAMETER - ERROR TYPES Value > -> ----------------------------- ----- > -> ... > -> INVALID_HIT 40 > -> > -> Sent in response to a failure to validate the peer's > -> HIT from the corresponding HI. >=20 > And "opportunistic mode not supported" if responder HIT is NULL ? >=20 Maybe more generally, BLOCKED_BY_POLICY-- host is unwilling to set up an association for some policy reason (doesn't like the HITs). Tom From Julien.Laganier@Sun.COM Tue Mar 23 14:43:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Mar 23 14:43:01 2004 Subject: [Hipsec] HIP Notify text In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65F3@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65F3@xch-nw-27.nw.nos.boeing.com> Message-ID: <200403232128.31904.julien.laganier@sun.com> On Tuesday 23 March 2004 18:35, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM] > > Sent: Monday, March 22, 2004 3:49 AM > > To: hipsec@honor.trusecure.com > > Cc: Miika Komu; Henderson, Thomas R > > Subject: Re: [Hipsec] HIP Notify text > > > > OTOH, it would certainly be useful to be able to notify several > > error types within different parameters... One could achieve this > > by replacing the > > > > { Reserved (16 bit) | Notify Message Type (16 bit) | Notification > > data } > > > > proposed by Thomas by several Notify chunks: > > > > { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit) > > > > | Notification Data } > > > > The Parameter Type being set to the parameter type which > > triggered this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's > > caused by the base HIP header, and the Notify Parameter sub-type > > being a per parameter defined sub type. For example, the > > parameter SPI could have the following notify subtypes: > > > > o UNKNOWN_SPI 0x01 > > o ALREADY_USED_SPI 0x02 > > o EXPIRED_SPI 0x03 > > > > IMHO it gives much more flexibility in notifying errors while not > > being overly complex... > > > > Thoughts? Thanks, > > My sense is that this is overkill-- I don't know how much it > matters to have hierarchical error reporting. Allowing different > notify parameters to be included in a single packet should be > allowed, however. I can understand it is overkill ;-) I first think about this hierarchical error reporting mainly because the notify type allocation would be easier. This would allow: o easier optionnal parameter error handling, because it allows to define error code independently for each parameter o easier alternative informational reporting (apart from error reporting) Anyway your proposal sounds just good to me. I just try to make it more flexible. Thanks, --julien From Gonzalo.Camarillo@ericsson.com Wed Mar 24 09:30:02 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Mar 24 09:30:02 2004 Subject: [Hipsec] [Fwd: WG Action: Host Identity Protocol (hip)] Message-ID: <4061A638.1050902@ericsson.com> FYI. Gonzalo -------- Original Message -------- Subject: WG Action: Host Identity Protocol (hip) Date: Wed, 24 Mar 2004 09:52:48 -0500 From: The IESG To: IETF-Announce: ; CC: David Ward , Gonzalo Camarillo A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Host Identity Protocol (hip) ----------------------------- Current Status: Active Working Group Chair(s): David Ward Gonzalo Camarillo Internet Area Director(s): Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: hipsec@honor.trusecure.com To Subscribe: hipsec-request@honor.trusecure.com In Body: With a subject line: subscribe Archive: http://honor.trusecure.com/pipermail/hipsec/ Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: draft-moskowitz-hip-arch-05.txt (at RFC editor) and draft-moskowitz-hip-08.txt (soon -09.txt) There are five publicly known, interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ In particular, the objective of this working group is to complete the base protocol specification, define one or more DNS resource records for storing HIP related data, to complete the existing work on basic mobility and multi-homing, and produce Experimental RFCs for these. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet in the large. It is expected that there will be a roughly parallel, though perhaps considerably broader, IRTF Research Group that will include efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: 1) Complete the HIP base protocol specification. Starting point: draft-moskowitz-hip-08.txt (or newer) 2) Complete the basic mobility and multi-homing support for HIP. Starting point: draft-nikander-hip-mm-01.txt (or newer) While this work partially overlaps the work in Mobile IP and Multi6 Working Groups, it is very different in the sense that is based on the Experimental HIP specification, and cannot function without it. 3) Define one or more new DNS Resource Records for storing HIP related data, such as Host Identifiers and Host Identity Tags (HITs). This task explicitly excludes the task of defining reverse DNS entries based on HITs. 4) Define a basic HIP rendezvous mechanism. A basic HIP rendezvous server allows mobile and non-mobile HIP hosts to register their current IP addresses at the server. Other hosts can then send the initial I1 packets to the rendezvous server, which forwards the packets to the HIP host's current address. This task explicitly excludes solving more general problems, such as the referral problem. Also excluded is the problem of finding the right rendezvous server. It is expected that the DNS records will be used for that. The Working Group bases all the work on the HIP achitecture specification (as defined above). Goals and Milestones: Mar 04 WG LC on the base protocol specification Mar 04 First version of the HIP basic mobility and multi-homing mechanism specification. Mar 04 First version of the HIP DNS resource record(s) specification. Apr 04 Complete the base protocol specification and submit it to the IESG for Experimental Apr 04 First version of the HIP basic rendezvous mechanism specification. Aug 04 WG LC on the HIP DNS resource record(s) specification. Sep 04 Submit the HIP DNS resource record(s) specification to the IESG for Experimental.Nov 04 WG LC on the HIP basic mobility and multi-homing specification. Nov 04 WG LC on the basic HIP rendezvous mechanism specification. Dec 04 Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Dec 04 Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Jan 05 Recharter or close the WG. 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 Jan.Melen@nomadiclab.com Wed Mar 24 09:35:02 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Wed Mar 24 09:35:02 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> Message-ID: <200403241721.30296.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't quite follow your concept of incoming and outgoing update IDs but h= ere=20 is how I have understood it. When B receives first update from A. B records the value (1) and replys wi= th=20 update ID 1. When B receives second update ID it compares that the received= =20 value in update is greater than in the previous update packet and if so=20 replies with the new value. Now when A receives first update from B. A records the value (1). A replies= =20 with update ID 1. And yet same again as above (2<->2)... So one should have two values in both ends my_update_id peer_update_id my_update_id tells you the ID which you have sent last in UPDATE (not in=20 reply). This should be incremented before sending UPDATE and include this=20 incremented value in to UPDATE packet. When receiving a reply, one should=20 check that the value is same in the reply packet as stored in to this=20 variable. peer_update_id tells you the ID which you have received last in UPDATE (not= =20 reply). When receiving UPDATE, one should check that the value in received= =20 UPDATE ID is greater or same. Store the received value in to this variable.= =20 Make a reply packet and include this value in to the reply packet. In simplified pseudo-code: send_update () { updateID =3D ++my_update_id; send_update_packet (updateID); } receive_update_reply () { updateID =3D parse_updateID(); if ( updateID =3D=3D my_update_id ) then update_reply_ok_now_update_sa(); else discard_update_reply(); fi } receive_update () { updateID =3D parse_updateID(); if (updateID >=3D peer_update_id) then=20 peer_update_id =3D updateID; send_update_reply_packet (peer_update_id); prepare_sa_wait_for_data(); else discard_update(); fi } I hope this helps! Regards, Jan On Tuesday 23 March 2004 15:53, Mika Kousa wrote: > I might have misunderstood something, but I need some clarifications while > I'm trying to implement the UPDATE packet: > > > Example scenario: > > After the base exchange, host A increments outgoing UPDATE ID counter from > value 0 to 1 and sends UPDATE packet to B. Now host B has stored A's > incoming UPDATE ID value 1. B responds with corresponding UPDATE packet > (with UPDATE ID 1) and host A stores B's incoming UPDATE ID value 1. Both > hosts are also again in established state. Then the same process is done > again, so the result is that B has stored A's incoming UPDATE ID value 2 > and host A has stored B's incoming UPDATE ID value 2. Nothing unclear so > far, because I understood that incoming UPDATE IDs are recorded regardless > whether the packet is a reply or not (at least draft-09 section 8.10 > (Processing UPDATE packets) bulletin point 7. does not differentiate the > cases). > > Then host B sends UPDATE with (its own outgoing) ID 1 to host A. B moves > now to rekeying state. When host A receives the UPDATE packet it starts to > handle the packet according to draft-09 section 8.10: > > "1. If the system is in state ESTABLISHED and the UPDATE has the R-bit set > in the NES TLV, the packet is silently dropped.". This is not true, > because the R-bit is not set. > > "2. If the UPDATE ID in the received UPDATE is smaller than the stored > incoming UPDATE ID, the packet MUST BE dropped." > > Host A sees that incoming ID value in the reply UPDATE is 1. Also, A sees > that the last incoming ID received before from host B was 2, so this reply > packet is dropped. Assuming that the implementation follows strictly the > steps defined in the draft, this causes problems. > > Therefore, should section 8.10 bulletin point 2. say "If the UPDATE does > not have the R-bit set and the UPDATE ID in the received UPDATE is smaller > than the stored incoming UPDATE ID, the packet MUST BE dropped" instead of > the current text "If the UPDATE ID in the received UPDATE is smaller than > the stored incoming UPDATE ID, the packet MUST BE dropped" ? > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYad4p4iklvjQtTgRAs9sAJ9WX0jYVCZWQX/ymFkjfRKuOeANcwCgyqoK M/Fto9WndDFaXHsS8qfoyjk=3D =3D00+q =2D----END PGP SIGNATURE----- From jonwood@speakeasy.net Thu Mar 25 01:20:01 2004 From: jonwood@speakeasy.net (Jonathan Wood) Date: Thu Mar 25 01:20:01 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: <200403241721.30296.Jan.Melen@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403241721.30296.Jan.Melen@nomadiclab.com> Message-ID: I agree with Jan's explanation below. However, I also think that the draft is less clear than it could be about how to handle update IDs - perhaps Jan's text could be adapted into a section explicitly addressing update IDs? Also, the draft needs to specify how to handle resetting update ID counters after a resync (if it's in the draft, I must have missed it...). Resetting both peer_update_id and my_update_id to zero should do the trick. Jon On Mar 24, 2004, at 7:21 AM, Jan Mikael Melen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I don't quite follow your concept of incoming and outgoing update IDs > but here > is how I have understood it. > > When B receives first update from A. B records the value (1) and > replys with > update ID 1. When B receives second update ID it compares that the > received > value in update is greater than in the previous update packet and if so > replies with the new value. > > Now when A receives first update from B. A records the value (1). A > replies > with update ID 1. And yet same again as above (2<->2)... > > So one should have two values in both ends > my_update_id > peer_update_id > > my_update_id tells you the ID which you have sent last in UPDATE (not > in > reply). This should be incremented before sending UPDATE and include > this > incremented value in to UPDATE packet. When receiving a reply, one > should > check that the value is same in the reply packet as stored in to this > variable. > > peer_update_id tells you the ID which you have received last in UPDATE > (not > reply). When receiving UPDATE, one should check that the value in > received > UPDATE ID is greater or same. Store the received value in to this > variable. > Make a reply packet and include this value in to the reply packet. > > In simplified pseudo-code: > send_update () { > updateID = ++my_update_id; > send_update_packet (updateID); > } > > receive_update_reply () { > updateID = parse_updateID(); > if ( updateID == my_update_id ) then > update_reply_ok_now_update_sa(); > else > discard_update_reply(); > fi > } > > receive_update () { > updateID = parse_updateID(); > if (updateID >= peer_update_id) then > peer_update_id = updateID; > send_update_reply_packet (peer_update_id); > prepare_sa_wait_for_data(); > else > discard_update(); > fi > } > > I hope this helps! > > Regards, > Jan > From mkousa@cc.hut.fi Thu Mar 25 06:07:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Mar 25 06:07:01 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: <200403241721.30296.Jan.Melen@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403241721.30296.Jan.Melen@nomadiclab.com> Message-ID: On Wed, 24 Mar 2004, Jan Mikael Melen wrote: -> So one should have two values in both ends -> my_update_id -> peer_update_id -> -> ... -> -> peer_update_id tells you the ID which you have received last in UPDATE (not -> reply). When receiving UPDATE, one should check that the value in received -> UPDATE ID is greater or same. Yes, I understood your answer, but this issue of storing incoming/outgoing UPDATE IDs is one of the things I needed clarifications on. Draft section 8.10 bulletin point 7 says that "The system MUST record the UPDATE ID in the received packet, for replay protection.". Note that this does not say anything about if we must care about the R-bit when storing the peer_update_id. When I was implementing UPDATE packet I just blindly followed the draft, and then ran into some problems when packets were dropped. It would be nice if the draft section 8.10 bulletin point 7 would explicitly say that the incoming UPDATE ID is stored only if the packet is not a reply. From petri.jokela@nomadiclab.com Thu Mar 25 06:47:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Mar 25 06:47:01 2004 Subject: [Hipsec] Some UPDATE handling issues In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65D0@xch-nw-27.nw.nos.boeing.com> <200403241721.30296.Jan.Melen@nomadiclab.com> Message-ID: <4062D165.1040509@nomadiclab.com> Jonathan Wood wrote: > > I agree with Jan's explanation below. > > However, I also think that the draft is less clear than it could be > about how to handle update IDs - perhaps Jan's text could > be adapted into a section explicitly addressing update IDs? in 8.10, bullet 7, changing a bit: 7. The system MUST record the UPDATE ID in the received initial UPDATE packet, for replay protection. This should remove the possibility to misunderstand the process. One thing that 8.10 does not say anything about: UPDATE reply packets that have an UPDATE ID that does not match to any sent initial UPDATE packet (or have I missed this somewhere). This reply packet is, of course, dropped. But should it be said in 8.10., e.g. after bullet 1: 2. If the system is in state REKEYING, the UPDATE has the R-bit set, but the UPDATE ID does not match any sent initial UPDATE packet, the packet is silently dropped. > Also, the draft needs to specify how to handle resetting > update ID counters after a resync (if it's in the draft, I must > have missed it...). Resetting both peer_update_id and > my_update_id to zero should do the trick. This will go into resync-draft, if the resync-process is decided to be removed from the base draft. Otherwise, it shall be done here. /petri > Jon -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From petri.jokela@nomadiclab.com Fri Mar 26 03:57:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Mar 26 03:57:00 2004 Subject: [Hipsec] Text for solving the R2 losses problem In-Reply-To: <36208314.1079399626@[192.168.1.249]> References: <6938661A6EDA8A4EA8D1419BCE46F24C040604F4@xch-nw-27.nw.nos.boeing .com> <36208314.1079399626@[192.168.1.249]> Message-ID: <4063FAF2.804@nomadiclab.com> Andrew McGregor wrote: > --On Monday, 15 March 2004 12:02 p.m. +0200 Pekka Nikander > wrote: > >> 1. Do we want to preserve the distinction between the >> initiator and responder once we are in ESTABLISHED? >> The original goal was NOT to have any distinction. > > > Which is, I think, pretty much essential to retain. That way it is > always safe for either end to be the initator of any further mechanisms, > without having to deal with differences to do with who was the initiator > of the whole session. Folks, it's time for shooting: shoot the following ideas down. 1) If we calculate an R2 packet every time we enter the ESTABLISHED state (even if we are originally the Initiator), we could always respond to an incoming I2 with this precalculated R2. We should not make any verification on the I2 packet, just respond to it like in case I1/R1. This reveals our SPI to a possible attacker. Is it a threat? The SPI is visible also in other packets, although not directly sent to an attacker. With this, we don't have to maintain any information about our previous status as an Initiator or Responder. When the SPI changes, also the precalculated R2 must be recalculated. (When traffic arrives on the SA, the R2 could be removed, after which we do not respond to any I2s.) Is there any possibility for a DoS attack? 2) And, in fact, if we are originally Initiator, the precalculated R2 could contain garbage because future incoming I2s are false anyway... 3) Further developing the idea: store R2 when we as responder send it out. As an initiator, we do nothing. Define in ESTABLISHED that respond to an I2 with an R2 if stored, otherwise drop the I2. In this case, I think, we move in the grey zone (as the term is in sports when you use something "almost" doping), because we "know" that we are a responder if we have an R2. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From petri.jokela@nomadiclab.com Fri Mar 26 08:09:02 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Mar 26 08:09:02 2004 Subject: [Hipsec] Base HIP draft 10-pre1 -version available Message-ID: <40643626.6060804@nomadiclab.com> Folks, the pre1 snapshot of the next base HIP draft is now available at: http://hip4inter.net/drafts.php There are txt and html versions of the doc, as well as diff from 09. The diff seems not to work correctly after NOTIFY TLV; htmlwdiff thinks that everything has changed.... Roundup issue tracker is at: http://hip4inter.net/cgi-bin/roundup.cgi/hip-base/index Some notes: - issue 21: REJECT mechanism NOTIFY packet added for sending information (errors etc.) o I modified the original text provided by Thomas and added the possibility to put multiple NOTIFY TLVs in the packet o Proposal to define hierarchical errors is not included o Question: should the NOTIFY TLV be renamed? Just to avoid future confusion between NOTIFY packet and NOTIFY TLV. - issue 30: UPDATE RACE condition text added in 8.10 - (no issue number) UPDATE 8.10: new bullet 2 for handling packets with unknown UPDATE ID, limited the storing of incoming UPDATE ID to INITIAL update packets only. - issue 28: LSI removal included text from Thomas - issue 27: In HOST_ID FQDN is replace with a new Domain Identifier - issue 23: Retransmitted I2s. I added the text and state machine provided earlier by Pekka. There is now a new R2-SENT state in the state machine. This certainly is not the final version, as discussion is still going on. Issues 12, 15, 19, 20, 22, 26 are related to the RESYNC process that may be removed from the base draft. I haven't touched them in the pre1-version. Other open issues Issue 29: Type 2 HITs; how to define these Issue 31: The LSI issue was closed after changing the text, but the 1.0.0.0/8 issue remained. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Mon Mar 29 02:45:05 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 29 02:45:05 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65CE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65CE@xch-nw-27.nw.nos.boeing.com> Message-ID: Nits below: > The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it > easier to differentiate between LSIs and IPv4 addresses at the API > level. The low order 24 bits of an LSI MUST be equal to the low > order 24 bits of the corresponding HIT. I think that we want to say either: a) The default low order 24 bits of an LSI MUST be equal..., or b) The low order 24 bits of an LSI SHOULD be equal.... Otherwise we seem to be painting ourselves into a corner. > A host performing a HIP handshake may discover that the LSI formed > from > the peer's HIT collides with another LSI in use locally (i.e., the > lower > 24 bits of two different HITs are the same). In that case, the > host MUST > handle the LSI collision locally such that application calls can be > disambiguated. One possible means of doing so is to perform a Host > NAT > function to locally convert a peer's LSI into a different LSI > value. This > would require the host to ensure that LSI bits on the wire (i.e., > in the > application data stream) are converted back to match that host's > LSI. Other > alternatives for resolving LSI collisions may be added in the > future. Ok. > Looked ok. --Pekka From pekka.nikander@nomadiclab.com Mon Mar 29 02:58:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 29 02:58:01 2004 Subject: [Hipsec] API and LSI resolution In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B65CE@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B65CE@xch-nw-27.nw.nos.boeing.com> Message-ID: Nits below: > The LSIs MUST be allocated from the 1.0.0.0/8 subnet. That makes it > easier to differentiate between LSIs and IPv4 addresses at the API > level. The low order 24 bits of an LSI MUST be equal to the low > order 24 bits of the corresponding HIT. I think that we want to say either: a) The default low order 24 bits of an LSI MUST be equal..., or b) The low order 24 bits of an LSI SHOULD be equal.... Otherwise we seem to be painting ourselves into a corner. > A host performing a HIP handshake may discover that the LSI formed > from > the peer's HIT collides with another LSI in use locally (i.e., the > lower > 24 bits of two different HITs are the same). In that case, the > host MUST > handle the LSI collision locally such that application calls can be > disambiguated. One possible means of doing so is to perform a Host > NAT > function to locally convert a peer's LSI into a different LSI > value. This > would require the host to ensure that LSI bits on the wire (i.e., > in the > application data stream) are converted back to match that host's > LSI. Other > alternatives for resolving LSI collisions may be added in the > future. Ok. > Looked ok. --Pekka From pekka.nikander@nomadiclab.com Mon Mar 29 02:58:05 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 29 02:58:05 2004 Subject: [Hipsec] Update race condition In-Reply-To: <40603F89.60806@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> Message-ID: <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> > I propose to add some text to 8.10: > > 8.10 Processing UPDATE packets > > When a system receives a UPDATE packet, its processing depends on s/a UPDATE/an UPDATE/ > whether the packet is a reply to a previously sent UPDATE packet or > the UPDATE is a new packet. I find the statement above confusing, since the following text does not specify what is the difference. Maybe the text should be moved into another position (later)? > The order of the keys retrieved from the KEYMAT during rekeying > process depends on the HIT value comparison. We denote the host with > lower HIT value with HITl and, respectively, the host with greater > HIT with HITg. The HITs are compared in network byte order. The keys > are retrieved from the KEYMAT in the following order: Should there be a reference to the KEYMAT generation section here, noting that this is identical to the process of generating the initial KEYMAT? I also find it slightly confusing to call the *hosts* as HITg and HITl, maybe use H_g and H_l or HOST_g and HOST_l instead? > SA-gl ESP encryption key for HITg's outgoing traffic > > SA-gl ESP authentication key for HITg's outgoing traffic > > SA-lg ESP encryption key for HITl's outgoing traffic > > SA-lg ESP authentication key for HITl's outgoing traffic > > The following steps define the conceptual processing rules > responding > handling a received UPDATE packet: Other than the comments above, OK so far. > In 8.10, change the bullet number 5 (to allow also lower Keymat Index > if we are in REKEYING state): > > 5. If the received UPDATE does not contain a Diffie-Hellman > parameter, the received Keymat Index MUST be larger or equal to > the index of the next byte to be drawn from the current KEYMAT. > If the host is in REKEYING state, a smaller Keymat Index value > MAY be accepted. If the host is in ESTABLISHED state and this > test fails, the packet SHOULD be dropped and the system SHOULD > log an error message. I find this lacking of information. I think there should be some description of the reasons for the MAY, i.e., under which condition accepting such a lower index is reasonable. > > > And in 8.10.1, a new bullet that defines that in race condition, we > select the bigger of the Keymat Indexes: > > 4. If the host is in REKEYING state, and neither the incoming > UPDATE > packet nor the sent UPDATE packet required new KEYMAT > generation, > the bigger Keymat Index number of those two UPDATE packets shall > be used. Maybe add: ... generation, /and the Keymat Index numbers in the UPDATE packets are different,/ the bigger... If you add that, you can deleted /of those two UPDATE packets/ --Pekka From Jan.Melen@nomadiclab.com Mon Mar 29 03:48:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Mon Mar 29 03:48:01 2004 Subject: [Hipsec] Rendezvous server Message-ID: <200403291234.35875.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Kristian and others! When rendezvous server receives a valid I1 packet how do we process it and= =20 forward it to the responder? The easiest solution I could come up with would be that as the rendezvous=20 server receives an I1 packet it would check that we have a existing HIP=20 association between RVS and the responder. The rendezvous server then would= =20 create a PAYLOAD packet and set the next header in HIP header as IP or IPV6= ,=20 source HIT would be RVS HIT and destination HIT would be responder's HIT. T= he=20 actual payload of that packet would be the original I1 (unmodified). The=20 payload packet would be used for tunneling packets between RVS and responde= r. The responder would then first process the payload header and then process = the=20 original I1 packet as if it would have been received straight from the=20 initiator. If the I1 is valid and acceptable then the responder could send = an=20 R1 straight back to the initiator. Both initiator and responder could this way learn each others IP addresses= =20 during the HIP negotiation. This way we would not have at least following problems: If rendezvous server would just make a translation for destination address= =20 then the packet could be dropped due egress filtering in the rendezvous=20 servers network. If RVS would change the source IP address as it's own, then a new TLV shoul= d=20 be defined to preserve the initiators IP address. As suggested above as the= =20 I1 is sent unmodified in the payload packet no need to preserve the initiat= or=20 IP address in to a TLV. Comments? Is this a completely stupid idea? Regards, Jan =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAZ+2pp4iklvjQtTgRAkZaAKCg0ApT/0tAV95gD6dLEmG+E/gBHACePsoS omIYAyBtvK46dCO4EjKc7/g=3D =3DbBEU =2D----END PGP SIGNATURE----- From petri.jokela@nomadiclab.com Mon Mar 29 05:40:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Mar 29 05:40:01 2004 Subject: [Hipsec] Update race condition In-Reply-To: <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> References: <200403040948.53919.Jan.Melen@nomadiclab.com> <40603F89.60806@nomadiclab.com> <831065CA-8137-11D8-9AE2-000393CE1E8C@nomadiclab.com> Message-ID: <406807A9.4040800@nomadiclab.com> Pekka Nikander wrote: >> When a system receives a UPDATE packet, its processing depends on > s/a UPDATE/an UPDATE/ Fixed, together with few other similar bugs that were left in the paper after NES -> UPDATE change. >> whether the packet is a reply to a previously sent UPDATE packet or >> the UPDATE is a new packet. > > > I find the statement above confusing, since the following text does > not specify what is the difference. Maybe the text should be moved > into another position (later)? I changed it a bit, see below together with the KEYMAT text. >> The order of the keys retrieved from the KEYMAT during rekeying >> process depends on the HIT value comparison. We denote the host with >> lower HIT value with HITl and, respectively, the host with greater >> HIT with HITg. The HITs are compared in network byte order. The keys >> are retrieved from the KEYMAT in the following order: > > > Should there be a reference to the KEYMAT generation section here, > noting that this is identical to the process of generating the > initial KEYMAT? In the original KEYMAT generation, the HITs are put into the KEYMAT "generator" in a certain order. The key retrieval is done depending on the Initiator / Responder status. In the UPDATE case, we retrieve keys using the HIT comparison. I don't see direct analogy between these processes. Or was this what you meant? Maybe the text should be written like (including modified text due to the earlier comment): 8.10 Processing UPDATE packet When a host receives an UPDATE packet, it indicates that either the host itself has earlier requested rekeying or the peer is initiating rekeying. If either of the hosts requires that a new KEYMAT must be generated, the generation is done as described in 9. HIP KEYMAT. The order of the keys retrieved from the KEYMAT during rekeying process depends on the HIT value comparison. We denote the host with lower HIT value with HOST_l and, respectively, the host with greater HIT with HOST_g. The HITs are compared in network byte order. The keys are retrieved from the KEYMAT in the following order. Note that the retrieval is different than in the case of initial KEYMAT generation (see. 9. HIP KEYMAT) where the retrieval is based on host's Initiator / Responder status. This is not relevat during rekeying process, especially in a possible race situation when both hosts have initiated the rekeying simultaneously. The following steps define the conceptual processing rules for handling a received UPDATE packet (note that the handling is slightly different between initial and reply UPDATE packets): > I also find it slightly confusing to call the *hosts* as HITg and > HITl, maybe use H_g and H_l or HOST_g and HOST_l instead? (Ok, above) >> In 8.10, change the bullet number 5 (to allow also lower Keymat Index >> if we are in REKEYING state): >> >> 5. If the received UPDATE does not contain a Diffie-Hellman >> parameter, the received Keymat Index MUST be larger or equal to >> the index of the next byte to be drawn from the current KEYMAT. >> If the host is in REKEYING state, a smaller Keymat Index value >> MAY be accepted. If the host is in ESTABLISHED state and this >> test fails, the packet SHOULD be dropped and the system SHOULD >> log an error message. > > > I find this lacking of information. I think there should be some > description > of the reasons for the MAY, i.e., under which condition accepting such a > lower index is reasonable. ... a smaller Keymat Index MAY be accepted, if the host itself has skipped part of the KEYMAT and selected a bigger index for the previously sent UPDATE packet. >> And in 8.10.1, a new bullet that defines that in race condition, we >> select the bigger of the Keymat Indexes: >> >> 4. If the host is in REKEYING state, and neither the incoming UPDATE >> packet nor the sent UPDATE packet required new KEYMAT generation, >> the bigger Keymat Index number of those two UPDATE packets shall >> be used. > > > Maybe add: ... generation, /and the Keymat Index numbers in the UPDATE > packets are different,/ the bigger... > > If you add that, you can deleted /of those two UPDATE packets/ 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 kristian.slavov@iki.fi Mon Mar 29 06:20:03 2004 From: kristian.slavov@iki.fi (Kristian Slavov) Date: Mon Mar 29 06:20:03 2004 Subject: [Hipsec] Re: Rendezvous server In-Reply-To: <200403291234.35875.Jan.Melen@nomadiclab.com> References: <200403291234.35875.Jan.Melen@nomadiclab.com> Message-ID: <40681153.7070001@iki.fi> Jan Mikael Melen wrote: > > The easiest solution I could come up with would be that as the rendezvous > server receives an I1 packet it would check that we have a existing HIP > association between RVS and the responder. The rendezvous server then would > create a PAYLOAD packet and set the next header in HIP header as IP or IPV6, > source HIT would be RVS HIT and destination HIT would be responder's HIT. The > actual payload of that packet would be the original I1 (unmodified). The > payload packet would be used for tunneling packets between RVS and responder. > This sounds ok. We haven't implemented PAYLOAD packet yet, so I can't comment on how easy it is to implement IP(v6)-over-HIP. :) Now we need a way to ask the RvS if it is willing to serve us. I could imagine RvSes having ACLs. The NOTIFY packet could be used to inform the result (denied/accepted). -- Kristian Slavov Pohjoiskaari 8 B 43, 00200 Helsinki, Finland GSM: +358-40-7220960 From Julien.Laganier@Sun.COM Mon Mar 29 10:49:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Mar 29 10:49:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200403291234.35875.Jan.Melen@nomadiclab.com> References: <200403291234.35875.Jan.Melen@nomadiclab.com> Message-ID: <200403291836.39325.julien.laganier@sun.com> On Monday 29 March 2004 11:34, Jan Mikael Melen wrote: > > Hi, Kristian and others! Hi, > When rendezvous server receives a valid I1 packet how do we process > it and forward it to the responder? More thoughts below, > The easiest solution I could come up with would be that as the > rendezvous server receives an I1 packet it would check that we have > a existing HIP association between RVS and the responder. Perhaps requiring an HIP association all the time between a HIP node and its RVS is a bit onerous, especially for the RVS. As I1s are not authenticated anyway, we might obtain the same security guarantees by only requiring an HIP Association periodically, in order to create, update or renew a "soft HA", that would only consist in a an associated lifetime, Destination HIT and IP address. This would avoid storing on the RVS a full HA data structure with public keys and so on, thus increasing scalability. > The rendezvous server then would create a PAYLOAD packet and set the > next header in HIP header as IP or IPV6, source HIT would be RVS > HIT and destination HIT would be responder's HIT. The actual > payload of that packet would be the original I1 (unmodified). The > payload packet would be used for tunneling packets between RVS and > responder. > > The responder would then first process the payload header and then > process the original I1 packet as if it would have been received > straight from the initiator. If the I1 is valid and acceptable then > the responder could send an R1 straight back to the initiator. > > Both initiator and responder could this way learn each others IP > addresses during the HIP negotiation. > > This way we would not have at least following problems: > If rendezvous server would just make a translation for destination > address then the packet could be dropped due egress filtering in > the rendezvous servers network. > If RVS would change the source IP address as it's own, then a new > TLV should be defined to preserve the initiators IP address. As > suggested above as the I1 is sent unmodified in the payload packet > no need to preserve the initiator IP address in to a TLV. > > Comments? Is this a completely stupid idea? Well, I don't think it's a stupid idea :-) On one hand, I like the idea of having a generic forwarding facility for IP packet like the one you describe in your mail. Moreover it allows piggybacking as well. But on the other hand, the RVS are just supposed to forward I1, and you need to carry a full IP header while only the source address is useful. AFAICS, because I1 are not authenticated anyway, you could probably just forward them after having rewrote the source address (for egress filtering) and adding a (new) TLV parameter with type FORWARDED_FROM, containing the source address of the initiator. This mechanism can be exploited for DoS attacks (spoofing a RVS for sending I1 and create R1 storms), but it's not that different from the base protocol (the responder answers an I1 with a R1 without crypto checks). Thoughts and comments welcomed. Thanks, --julien From weddy@masaka.cs.ohiou.edu Mon Mar 29 10:52:01 2004 From: weddy@masaka.cs.ohiou.edu (Wesley Eddy) Date: Mon Mar 29 10:52:01 2004 Subject: [Hipsec] max retry counters Message-ID: <20040329163859.GC4846@irg.cs.ohiou.edu> --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The current HIP draft refers to three constants (I1_RETRIES_MAX, I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but I don't see them defined anywhere in the draft, nor do I see any guidance on what their values should be set to in an implementation in the draft. Their purpose is clear, but whether their values should be 3 or 1000 doesn't seem to be discussed. What have implementers gone by? I think there should be some guideline at least. -Wes --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFAaFEizBuYqbnj3IwRAhKdAKCHNxFzpRncpmkOJL1YrMe+bCuM7QCgiYRb GrKkNjDIvPnFb5fiQWZXZcM= =+4wj -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From jeffrey.m.ahrenholz@boeing.com Mon Mar 29 12:31:02 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Mon Mar 29 12:31:02 2004 Subject: [Hipsec] max retry counters Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA270427A76A@xch-nw-09.nw.nos.boeing.com> We set our MAX_RETRIES =3D 5 for the various packets, and have used 3 in the past also. I don't see it defined in current or past drafts either. When testing locally we often turn retransmission off. -Jeff > -----Original Message----- > From: Wesley Eddy [mailto:weddy@masaka.cs.ohiou.edu]=20 > Sent: Monday, March 29, 2004 8:39 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] max retry counters >=20 >=20 > The current HIP draft refers to three constants=20 > (I1_RETRIES_MAX, I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but=20 > I don't see them defined anywhere in the draft, nor do I see=20 > any guidance on what their values should be set to in an=20 > implementation in the draft. Their purpose is clear, but=20 > whether their values should be 3 or 1000 doesn't seem to be=20 > discussed. What have implementers gone by? I think there=20 > should be some guideline at least. >=20 > -Wes >=20 From Jan.Melen@nomadiclab.com Mon Mar 29 23:54:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Mon Mar 29 23:54:01 2004 Subject: [Hipsec] Rendezvous server Message-ID: <200403300840.48337.Jan.Melen@nomadiclab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Monday 29 March 2004 19:36, Julien Laganier wrote: > On Monday 29 March 2004 11:34, Jan Mikael Melen wrote: > > Perhaps requiring an HIP association all the time between a HIP node > and its RVS is a bit onerous, especially for the RVS. As I1s are not > authenticated anyway, we might obtain the same security guarantees by > only requiring an HIP Association periodically, in order to create, > update or renew a "soft HA", that would only consist in a an > associated lifetime, Destination HIT and IP address. This would avoid > storing on the RVS a full HA data structure with public keys and so > on, thus increasing scalability. "soft HA" would be nice and probably enough also in the case of sending payload packets because the payload is not signed. > [ snip... snip... snip... ] > > AFAICS, because I1 are not authenticated anyway, you could probably > just forward them after having rewrote the source address (for > egress filtering) and adding a (new) TLV parameter with type > FORWARDED_FROM, containing the source address of the initiator. Yes, very true but this would mean that the responder should have a separate logic for parsing I1s that have been forwarded and for I1s that have not been forwarded (I'm just trying to save few lines of code ;). > This mechanism can be exploited for DoS attacks (spoofing a RVS for > sending I1 and create R1 storms), but it's not that different from > the base protocol (the responder answers an I1 with a R1 without > crypto checks). Same problem exists with payload packets as well as those are not signed, not at least according to current version of base protocol draft. - Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaQhJp4iklvjQtTgRAjMEAKC5OIzdRYvoloWDQ9jFzILih9f5HQCgvy3p 862f+BO+vvIesLEngdpFv3c= =UEjj -----END PGP SIGNATURE----- From Julien.Laganier@Sun.COM Tue Mar 30 02:21:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Mar 30 02:21:00 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200403300840.48337.Jan.Melen@nomadiclab.com> References: <200403300840.48337.Jan.Melen@nomadiclab.com> Message-ID: <200403300940.03439.julien.laganier@sun.com> On Tuesday 30 March 2004 07:40, Jan Mikael Melen wrote: > On Monday 29 March 2004 19:36, Julien Laganier wrote: > > On Monday 29 March 2004 11:34, Jan Mikael Melen wrote: > > > > Perhaps requiring an HIP association all the time between a HIP > > node and its RVS is a bit onerous, especially for the RVS. As I1s > > are not authenticated anyway, we might obtain the same security > > guarantees by only requiring an HIP Association periodically, in > > order to create, update or renew a "soft HA", that would only > > consist in a an associated lifetime, Destination HIT and IP > > address. This would avoid storing on the RVS a full HA data > > structure with public keys and so on, thus increasing > > scalability. > > "soft HA" would be nice and probably enough also in the case of > sending payload packets because the payload is not signed. Yep. > > [ snip... snip... snip... ] > > > > AFAICS, because I1 are not authenticated anyway, you could > > probably just forward them after having rewrote the source > > address (for egress filtering) and adding a (new) TLV parameter > > with type FORWARDED_FROM, containing the source address of the > > initiator. > > Yes, very true but this would mean that the responder should have a > separate logic for parsing I1s that have been forwarded and for I1s > that have not been forwarded (I'm just trying to save few lines of > code ;). The logics doesn't need to be 'really' separate, it's just a matter of rewriting the source address and strip the TLV FORWARDED_FROM before entering the I1 processing per se. Related to code complexity, while it's true that PAYLOAD can be reused for other tasks (like piggybacking a SYN_SENT with I2), IMHO it's far more complex to implement TLV encapsulation than parsing a 4 or 16-byte length TLV. > > This mechanism can be exploited for DoS attacks (spoofing a RVS > > for sending I1 and create R1 storms), but it's not that different > > from the base protocol (the responder answers an I1 with a R1 > > without crypto checks). > > Same problem exists with payload packets as well as those are not > signed, not at least according to current version of base protocol > draft. Right. Does other HIPpies have an opinion on that topic? --julien From kristian.slavov@iki.fi Tue Mar 30 03:22:01 2004 From: kristian.slavov@iki.fi (Kristian Slavov) Date: Tue Mar 30 03:22:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200403300940.03439.julien.laganier@sun.com> References: <200403300840.48337.Jan.Melen@nomadiclab.com> <200403300940.03439.julien.laganier@sun.com> Message-ID: <40693912.5060400@iki.fi> Julien Laganier wrote: > On Tuesday 30 March 2004 07:40, Jan Mikael Melen wrote: > >>Yes, very true but this would mean that the responder should have a >>separate logic for parsing I1s that have been forwarded and for I1s >>that have not been forwarded (I'm just trying to save few lines of >>code ;). > > > The logics doesn't need to be 'really' separate, it's just a matter of > rewriting the source address and strip the TLV FORWARDED_FROM before > entering the I1 processing per se. > > Related to code complexity, while it's true that PAYLOAD can be reused > for other tasks (like piggybacking a SYN_SENT with I2), IMHO it's far > more complex to implement TLV encapsulation than parsing a 4 or > 16-byte length TLV. > If the new TLV is optional then all hosts might not process it. In this case they will send an R1 to the RvS. The RvS will not reply with I2 as the destination HIT in the R1 will be unknown. If the new TLV is mandatory we will need to modify all implementations. However, I think this modification is trivial. > > Does other HIPpies have an opinion on that topic? > I'd rather extend the I1 than implement the PAYLOAD packet :) Also I don't think extending the I1 will bloat the base protocol. Even if this feature could be done by other means and thus not touch the base mechanism. The RvS is an integral part of the HIP architecture. The protocol should have more or less explicit support for it. -- Kristian Slavov From lars.eggert@netlab.nec.de Tue Mar 30 03:38:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Mar 30 03:38:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <200403300940.03439.julien.laganier@sun.com> References: <200403300840.48337.Jan.Melen@nomadiclab.com> <200403300940.03439.julien.laganier@sun.com> Message-ID: <40693CF8.4010704@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms010707040400020508000003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Julien & others, Julien Laganier wrote: > Does other HIPpies have an opinion on that topic? I've been following the rendezvous thread with great interest. In Seoul, we've talked about splitting draft-eggert-hip-rendezvous into two separate documents, one discussing the I1-only mechanism and a second one focusing on the HIP-to-non-HIP mechanisms. (The second one is targetted at the RG.) Much of the current discussion (run HIP between rendezvous server and mobile HIP node, relay I1 packets between the two, maybe using some sort of tunnel) could go directly into the I1-only document. Unfortunately, I'll probably not be able to spend much time on HIP-related tasks this month, but I may be able to update the ID accordingly in May. If that's too late, I'd be happy to integrate text from the group before then. Lars -- Lars Eggert NEC Network Laboratories --------------ms010707040400020508000003 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMzMwMDkyNTEyWjAjBgkqhkiG 9w0BCQQxFgQU6pq5d2M/PiQtuyC64WDIobQaV/wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA yxW0tXPETFFMjY55eE2z7WRg3OVYbtmXXBqscIfbhL7aK3FfO7OU3XfIYtatZYZSOGR9wqpt pzqWWjYgKwWHOE4CDd5bQkFk8W9ZRY9EWFKTDK7twGkqtAYBzbNlLPtRl8OhkvqdZgR//XKb ve9PwtOby65MRgywenOq654q9+Oo8FKDddAezIIoq4HidST1/nPRGp/UUSrvJT4Efh0i5Udf ChnqCpvEsW0mgWxlA7GYdX25XHeAWHt8VDeX8ap6OJRa7WsPlaERBr9xCPo+uoe1x8LYK89s zcM2qJHd6V3hd8VMQMB9jDaGY8dQqMO7GOXcZidvUK3XAE99Gs6YHgAAAAAAAA== --------------ms010707040400020508000003-- From Julien.Laganier@Sun.COM Tue Mar 30 03:43:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Mar 30 03:43:01 2004 Subject: [Hipsec] Rendezvous server In-Reply-To: <40693912.5060400@iki.fi> References: <200403300840.48337.Jan.Melen@nomadiclab.com> <200403300940.03439.julien.laganier@sun.com> <40693912.5060400@iki.fi> Message-ID: <200403301101.48448.julien.laganier@sun.com> On Tuesday 30 March 2004 11:08, Kristian Slavov wrote: > Julien Laganier wrote: > > On Tuesday 30 March 2004 07:40, Jan Mikael Melen wrote: > >>Yes, very true but this would mean that the responder should have > >> a separate logic for parsing I1s that have been forwarded and > >> for I1s that have not been forwarded (I'm just trying to save > >> few lines of code ;). > > > > The logics doesn't need to be 'really' separate, it's just a > > matter of rewriting the source address and strip the TLV > > FORWARDED_FROM before entering the I1 processing per se. > > > > Related to code complexity, while it's true that PAYLOAD can be > > reused for other tasks (like piggybacking a SYN_SENT with I2), > > IMHO it's far more complex to implement TLV encapsulation than > > parsing a 4 or 16-byte length TLV. > > If the new TLV is optional then all hosts might not process it. In > this case they will send an R1 to the RvS. The RvS will not reply > with I2 as the destination HIT in the R1 will be unknown. Right, they'll drop it (or forward it to the initiator if the RVS have kept some state in between.... not a very good idea though) But, if a HIP node register with a RVS and published its address (e.g., in the DNS), then we can legitimately suppose that this node needs RVS functionnalities. IMHO, such a HIP node MUST support the FORWARDED_FROM TLV, while we can keep it optionnal for other HIP nodes. > If the new TLV is mandatory we will need to modify all > implementations. However, I think this modification is trivial. I think so. > > Does other HIPpies have an opinion on that topic? > > I'd rather extend the I1 than implement the PAYLOAD packet :) > Also I don't think extending the I1 will bloat the base protocol. > Even if this feature could be done by other means and thus not > touch the base mechanism. The RvS is an integral part of the HIP > architecture. The protocol should have more or less explicit > support for it. I agree. --julien