From hipsec-bounces@lists.ietf.org Sat Jul 02 04:09:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dod3e-0008BC-4g; Sat, 02 Jul 2005 04:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dod3b-0008Az-Ke for hipsec@megatron.ietf.org; Sat, 02 Jul 2005 04:08:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18810 for ; Sat, 2 Jul 2005 04:08:57 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DodTi-0003sU-Eb for hipsec@ietf.org; Sat, 02 Jul 2005 04:35:59 -0400 Received: from [10.7.4.31] (adsl-201-11.swiftdsl.com.au [218.214.201.11]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 02 Jul 2005 11:07:45 +0300 id 0008FD2E.42C64B52.00006A3C Message-ID: <42C64B27.1070802@cs.helsinki.fi> Date: Sat, 02 Jul 2005 11:07:03 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Petri Jokela Subject: Re: [Hipsec] Base draft -03 & ESP draft -00 submitted References: <42BAA084.6020600@nomadiclab.com> In-Reply-To: <42BAA084.6020600@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0413677649==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0413677649== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-27196-1120291667-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-27196-1120291667-0001-2 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Petri, Thanks for a good job with editing the draft. Andrei Petri Jokela wrote: >Hi all, > >I just submitted base draft version -03 and ESP draft version -00 to >IETF. Drafts and diffs can also be found from: > >http://hip4inter.net/drafts.php > >BR, Petri > >(I will be on vacation until 25th of July) > > > > --=_courier-27196-1120291667-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC 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/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDcwMjA4MDcwM1owIwYJ KoZIhvcNAQkEMRYEFMcd79mUxmogxw7fQYoW4ZhwCoxQMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBAAkg4VOhxgzUFpjuFPjeKvVdiIdLkdd5zLqHlP3NZHCjPJa4xvwsDxOSmhNwk6m5uLkN MyFlWEy5Di0XYSmNO62YrWV8uM+ZNZ5f7qaxnKA7oXjUMK2wEFZyLbMzq630fzAUlr8o3gAt Izj/ubTsxDJbX3bVf3+v0GwujOPlyCH92v2QJaPPlHQ5seohlA2dTJT9nxHG/u0WsbdiEwOt DqaazqhW1eENxTjaAg7T9SfzUqjM78+EqkADascg2l4w/6NS6c69u3mN/+/TLzOviDjqJssR ZATTeS+RQqnTglgr+YCQY5+TfzaB8pFJpnv5QmPudPb6jwHmamK8ARCzfbQAAAAAAAA= --=_courier-27196-1120291667-0001-2-- --===============0413677649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0413677649==-- From hipsec-bounces@lists.ietf.org Mon Jul 04 06:47:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpOUG-00073t-Nn; Mon, 04 Jul 2005 06:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpOTw-00070j-NZ for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 06:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22938 for ; Mon, 4 Jul 2005 06:47:14 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpOoH-0001Zd-1n for hipsec@ietf.org; Mon, 04 Jul 2005 07:08:22 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7B0074F0015; Mon, 4 Jul 2005 12:40:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Jul 2005 12:40:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Jul 2005 12:40:51 +0200 Received: from [131.160.36.106] (EGIUM000L5C5TEU.lmf.ericsson.se [131.160.36.106]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2083124D0; Mon, 4 Jul 2005 13:40:51 +0300 (EEST) Message-ID: <42C91232.9000206@ericsson.com> Date: Mon, 04 Jul 2005 13:40:50 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2005 10:40:51.0350 (UTC) FILETIME=[D8EEE360:01C58084] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Pekka Nikander , rgm@icsalabs.com, Petri Jokela , David Ward Subject: [Hipsec] WGLC on base spec and ESP draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, as we agreed on the last face-to-face meeting, we intend to have both the base spec and the ESP draft ready to be sent to the IESG right after the upcoming IETF meeting in Paris. Therefore, we would like to start the working group last call on both drafts today. This WGLC will end on July 31st. The idea is to use the face-to-face meeting in Paris to close any remaining WGLC issue that cannot be closed in the mailing list. The drafts are available at: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt http://hip4inter.net/documentation/drafts/draft-ietf-hip-esp-00.txt [there were some problems with the submission of the ESP draft, but it will be available also on the IETF archives shortly] Please, review the drafts (thoroughly) and send your comments to this mailing list. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 10:11:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpRf8-0008Kb-Ug; Mon, 04 Jul 2005 10:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpRf7-0008KK-Ly for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 10:11:05 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20337 for ; Mon, 4 Jul 2005 10:11:03 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58D01212C93; Mon, 4 Jul 2005 17:10:32 +0300 (EEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0112b9dbebe44fa9aeef21b90797c5b4@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Mon, 4 Jul 2005 16:10:32 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... > > I don't think we discussed them yet. > > First of all, even if we stick to integer lifetimes, I think we can at > least reduce the field size from 32-bits (~136 years) to 16-bits (~18 > hours), that it is still enough, in my opinion. > > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: > > 4.1 REG_INFO > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > What does other people think about having a 2^(Lifetime exponent) > lifetime then? Based on the above, I think we should either used 16 bit integers or, preferably, 8 bit integers with the value being interpreted as, e.g., 2^((Lifetime - 64)/8) seconds. That would then cover the range from 4 ms to 178 days, with the granularity of about 0.4%. If people consider that we should have the ability to do longer registrations, the parameters could, of course, be adjusted. >> Minor details: >> >> Sec 3, bullet 3: >>> 3. At this point, the registrar tries to authenticate the >>> requester based on currently available information. The details >>> of this authentication procedure are not specified in this >>> document. If >> >> It would be good to be more specific in the second statement, and >> refer directly to the base spec. Also make the difference between >> authentication (as a part of the base exchange) vs. authorisation >> (which is a matter local to the registrar). > > What about: > > At this point, the registrar is able to authenticate the requester > based on the Host Identity it includes in I2. Then, it has to > verify that this Host Identity is in fact authorized to register for > the requested service(s), based on policy local to the > registrar. The details of this authorization procedure are dependent > on the type of the requested service(s) and on the registrar local > policy, and are therefore not specified in this document. Then, the > registrar includes in its R2 response a REG_RESPONSE parameter > containing the service(s) type(s) for which the registration was > authorized, and one or more REG_FAILED parameter containing the zero > service(s) type(s) for which registration failed or was not > authorized. In particular a REG_FAILED with a failure type of zero , (add a comma here) > would contain the service(s) type(s) for which registration requires > further credentials. Very good. Note the added missing comma and there may be zero REG_FAILED parameters... > What about: > > A host that is capable and willing to act as a registrar includes > a REG_INFO parameter in the R1 packets it sends during base > exchanges, or later in an UPDATE packet when a change of its > registar-related configuration occurs. I would be more strict: A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it send during base exchanges. If it is currently unable to provide any services, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If the registrat-related configuration of such a host is later changed, the host SHOULD send a new REG_INFO, indicating the new set of services. Consider adding a forward reference to the section explaining cancellation policy. >> Sec 3, second list, bullet 3: >> >> Please clarify the authenticate vs. authorise language. I think >> the first sentence uses authenticate while it should use authorise. > > How about: > > The registrar has to verify that the requester is in fact > authorized to register for the requested service(s), based on > policy local to the registrar. Then, the > registrar includes in its UPDATE response a REG_RESPONSE parameter > containing the service(s) type(s) for which the registration was > authorized, and one or more REG_FAILED parameter containing the zero > service(s) type(s) for which registration failed or was not > authorized. In particular a REG_FAILED with a failure type of zero > would contain the service(s) type(s) for which registration > requires further credentials. I would rather make a common section on including both REG_RESPONSES and REG_FAILEDs than copying the same text in multiple places... > >> Sec 3, 2nd para after second list: >>> Both the requester and registrar can cancel the created >>> registration before its expiration. >> >> I don't understand what that is trying to say. I guess this is >> part of the language being too abstract or fluffy... Or otherwise >> I just need more coffee.... > > What about: > > Both the requester and registrar can cancel a registration > before it expires, if the services afforded by this registration > are no longer needed by the requester, or cannot be provided any > longuer by the registrar (for instance because its configuration > changed). Ok. >>> signature. The requester SHOULD support inclusion of multiple >>> instances of the REG_REQUEST parameter in its I2 packets. >> >> What happens if it does not? > > Hhmm... nothing :) So perhaps it is better to say: > > The requester MUST NOT include more than one REG_REQUEST > parameter in its I2 or UPDATE packets, while the registrar > MUST be able to process one or more REG_REQUEST parameters > in received I2 or UPDATE packets. Good! > >> Sec 4.3: >>> The registrar SHOULD include the REG_RESPONSE parameter in its >>> R2 or UPDATE packet only if a registration has successfully >>> completed. >> >> I don't understand why we have here a "SHOULD"?? What is the >> rationale? Doesn't the registrar just include it if and only if the >> rgistration has been succesfully completed? > > Yep. What about: > > The registrar include the REG_RESPONSE parameter in its R2 includes an > or UPDATE packet when a registration has successfully completed. Ok; note the verb form and article use. > And then if we apply the "be (strict in what you sent and) liberal in > what you accept" principle once more, is it okay to modify the > following paragraph like this: > > The registrar MUST NOT include more than one REG_RESPONSE > parameter in its R2 or UPDATE packets, while the requester > MUST be able to process one or more REG_REQUEST parameters > in received R2 or UPDATE packets. Fine with me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 10:10:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpRev-0008II-OA; Mon, 04 Jul 2005 10:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpRet-0008I9-Ug for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 10:10:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20277 for ; Mon, 4 Jul 2005 10:10:50 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpS5T-0005fI-Uz for hipsec@ietf.org; Mon, 04 Jul 2005 10:38:20 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58D01212C93; Mon, 4 Jul 2005 17:10:32 +0300 (EEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0112b9dbebe44fa9aeef21b90797c5b4@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Mon, 4 Jul 2005 16:10:32 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... > > I don't think we discussed them yet. > > First of all, even if we stick to integer lifetimes, I think we can at > least reduce the field size from 32-bits (~136 years) to 16-bits (~18 > hours), that it is still enough, in my opinion. > > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: > > 4.1 REG_INFO > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > What does other people think about having a 2^(Lifetime exponent) > lifetime then? Based on the above, I think we should either used 16 bit integers or, preferably, 8 bit integers with the value being interpreted as, e.g., 2^((Lifetime - 64)/8) seconds. That would then cover the range from 4 ms to 178 days, with the granularity of about 0.4%. If people consider that we should have the ability to do longer registrations, the parameters could, of course, be adjusted. >> Minor details: >> >> Sec 3, bullet 3: >>> 3. At this point, the registrar tries to authenticate the >>> requester based on currently available information. The details >>> of this authentication procedure are not specified in this >>> document. If >> >> It would be good to be more specific in the second statement, and >> refer directly to the base spec. Also make the difference between >> authentication (as a part of the base exchange) vs. authorisation >> (which is a matter local to the registrar). > > What about: > > At this point, the registrar is able to authenticate the requester > based on the Host Identity it includes in I2. Then, it has to > verify that this Host Identity is in fact authorized to register for > the requested service(s), based on policy local to the > registrar. The details of this authorization procedure are dependent > on the type of the requested service(s) and on the registrar local > policy, and are therefore not specified in this document. Then, the > registrar includes in its R2 response a REG_RESPONSE parameter > containing the service(s) type(s) for which the registration was > authorized, and one or more REG_FAILED parameter containing the zero > service(s) type(s) for which registration failed or was not > authorized. In particular a REG_FAILED with a failure type of zero , (add a comma here) > would contain the service(s) type(s) for which registration requires > further credentials. Very good. Note the added missing comma and there may be zero REG_FAILED parameters... > What about: > > A host that is capable and willing to act as a registrar includes > a REG_INFO parameter in the R1 packets it sends during base > exchanges, or later in an UPDATE packet when a change of its > registar-related configuration occurs. I would be more strict: A host that is capable and willing to act as a registrar SHOULD include a REG_INFO parameter in the R1 packets it send during base exchanges. If it is currently unable to provide any services, it SHOULD include an empty REG_INFO, i.e., one with no services listed. If the registrat-related configuration of such a host is later changed, the host SHOULD send a new REG_INFO, indicating the new set of services. Consider adding a forward reference to the section explaining cancellation policy. >> Sec 3, second list, bullet 3: >> >> Please clarify the authenticate vs. authorise language. I think >> the first sentence uses authenticate while it should use authorise. > > How about: > > The registrar has to verify that the requester is in fact > authorized to register for the requested service(s), based on > policy local to the registrar. Then, the > registrar includes in its UPDATE response a REG_RESPONSE parameter > containing the service(s) type(s) for which the registration was > authorized, and one or more REG_FAILED parameter containing the zero > service(s) type(s) for which registration failed or was not > authorized. In particular a REG_FAILED with a failure type of zero > would contain the service(s) type(s) for which registration > requires further credentials. I would rather make a common section on including both REG_RESPONSES and REG_FAILEDs than copying the same text in multiple places... > >> Sec 3, 2nd para after second list: >>> Both the requester and registrar can cancel the created >>> registration before its expiration. >> >> I don't understand what that is trying to say. I guess this is >> part of the language being too abstract or fluffy... Or otherwise >> I just need more coffee.... > > What about: > > Both the requester and registrar can cancel a registration > before it expires, if the services afforded by this registration > are no longer needed by the requester, or cannot be provided any > longuer by the registrar (for instance because its configuration > changed). Ok. >>> signature. The requester SHOULD support inclusion of multiple >>> instances of the REG_REQUEST parameter in its I2 packets. >> >> What happens if it does not? > > Hhmm... nothing :) So perhaps it is better to say: > > The requester MUST NOT include more than one REG_REQUEST > parameter in its I2 or UPDATE packets, while the registrar > MUST be able to process one or more REG_REQUEST parameters > in received I2 or UPDATE packets. Good! > >> Sec 4.3: >>> The registrar SHOULD include the REG_RESPONSE parameter in its >>> R2 or UPDATE packet only if a registration has successfully >>> completed. >> >> I don't understand why we have here a "SHOULD"?? What is the >> rationale? Doesn't the registrar just include it if and only if the >> rgistration has been succesfully completed? > > Yep. What about: > > The registrar include the REG_RESPONSE parameter in its R2 includes an > or UPDATE packet when a registration has successfully completed. Ok; note the verb form and article use. > And then if we apply the "be (strict in what you sent and) liberal in > what you accept" principle once more, is it okay to modify the > following paragraph like this: > > The registrar MUST NOT include more than one REG_RESPONSE > parameter in its R2 or UPDATE packets, while the requester > MUST be able to process one or more REG_REQUEST parameters > in received R2 or UPDATE packets. Fine with me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 10:59:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSQ1-0001wh-Uc; Mon, 04 Jul 2005 10:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSPt-0001wY-5A for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 10:59:25 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27143 for ; Mon, 4 Jul 2005 10:59:20 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69A20008A5C54; Mon, 4 Jul 2005 16:58:49 +0200 From: Julien Laganier To: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 16:58:48 +0200 User-Agent: KMail/1.8 References: <200506271611.21480.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507041658.48754.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, On Wednesday 22 June 2005 14:15, Pekka Nikander wrote: > > It looks like all text on how construct a proper R1 at the > Responder end is missing, as well as how the Initiator > verifies the received R1 with an VIA:RVS parameter. I have a question about constructing the R1. In the current specification, it is said that a responder contacted via a RVS MAY use a LOCATOR parameter, in conformance with [hip-mm]. Is it okay with MAY or should we use SHOULD? And is it right to write: the initiator SHOULD accept packets with or without LOCATOR parameter. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 11:07:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSXJ-0003pC-CG; Mon, 04 Jul 2005 11:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSXI-0003p4-2a for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 11:07:04 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28117 for ; Mon, 4 Jul 2005 11:07:01 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7BA7D212C93; Mon, 4 Jul 2005 18:06:32 +0300 (EEST) In-Reply-To: <200507041658.48754.julien.IETF@laposte.net> References: <200506271611.21480.julien.IETF@laposte.net> <200507041658.48754.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 17:06:32 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> It looks like all text on how construct a proper R1 at the >> Responder end is missing, as well as how the Initiator >> verifies the received R1 with an VIA:RVS parameter. > > I have a question about constructing the R1. In the current > specification, it is said that a responder contacted via a RVS MAY > use a LOCATOR parameter, in conformance with [hip-mm]. Hmm. The source IP address should be correct in any case. If the R1 would be returned via the RVS and include a LOCATOR for the Responder's real IP address, that would sound fine to me. If the R1 would contain the Responder's real IP address and the VIA_RVS parameter (for tracking in the flooding case), that would sound fine with me. Adding a LOCATOR for the Responder's real IP address sounds like redundancy, unless the locator lists alternative IP addresses. > Is it okay with MAY or should we use SHOULD? So, maybe it still should be "MAY" but the draft to be clarified. > And is it right to write: the initiator SHOULD accept packets with or > without LOCATOR parameter. No, LOCATOR will be defined in a different RFC, and IMHO we don't want to have a hard dependency here. The system should work with the LOCATOR being optional in the sense that the association should be formed even if the Initiator does not understand the LOCATOR parameter. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 11:31:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSuT-0001Ok-AY; Mon, 04 Jul 2005 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSuS-0001Of-3C for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 11:31:00 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02131 for ; Mon, 4 Jul 2005 11:30:57 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69584005C7970; Mon, 4 Jul 2005 17:30:27 +0200 From: Julien Laganier To: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 17:30:28 +0200 User-Agent: KMail/1.8 References: <200507041658.48754.julien.IETF@laposte.net> <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> In-Reply-To: <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507041730.28852.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Monday 04 July 2005 17:06, Pekka Nikander wrote: > >> It looks like all text on how construct a proper R1 at the > >> Responder end is missing, as well as how the Initiator > >> verifies the received R1 with an VIA:RVS parameter. > > > > I have a question about constructing the R1. In the current > > specification, it is said that a responder contacted via a RVS > > MAY use a LOCATOR parameter, in conformance with [hip-mm]. > > Hmm. The source IP address should be correct in any case. > > If the R1 would be returned via the RVS and include a LOCATOR > for the Responder's real IP address, that would sound fine to me. In the current version the R1 always goes directly to the Initiator. > If the R1 would contain the Responder's real IP address and > the VIA_RVS parameter (for tracking in the flooding case), > that would sound fine with me. Adding a LOCATOR for the > Responder's real IP address sounds like redundancy, unless > the locator lists alternative IP addresses. Because the R1 always goes directly to the initiator it would always contain the responder's real IP address. So it would always be redundant. > > Is it okay with MAY or should we use SHOULD? > > So, maybe it still should be "MAY" but the draft to be clarified. > > > And is it right to write: the initiator SHOULD accept packets > > with or without LOCATOR parameter. > > No, LOCATOR will be defined in a different RFC, and IMHO we don't > want to have a hard dependency here. The system should work with > the LOCATOR being optional in the sense that the association should > be formed even if the Initiator does not understand the LOCATOR > parameter. Perhaps we could simply remove all references to LOCATOR. That way we have no hard dependency, and no redundancy. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 11:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSuw-0001T7-Mf; Mon, 04 Jul 2005 11:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSuu-0001Sy-TM for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 11:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02198 for ; Mon, 4 Jul 2005 11:31:26 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpTLQ-0004Nq-0X for hipsec@ietf.org; Mon, 04 Jul 2005 11:58:58 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69584005C7970; Mon, 4 Jul 2005 17:30:27 +0200 From: Julien Laganier To: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 17:30:28 +0200 User-Agent: KMail/1.8 References: <200507041658.48754.julien.IETF@laposte.net> <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> In-Reply-To: <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507041730.28852.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Monday 04 July 2005 17:06, Pekka Nikander wrote: > >> It looks like all text on how construct a proper R1 at the > >> Responder end is missing, as well as how the Initiator > >> verifies the received R1 with an VIA:RVS parameter. > > > > I have a question about constructing the R1. In the current > > specification, it is said that a responder contacted via a RVS > > MAY use a LOCATOR parameter, in conformance with [hip-mm]. > > Hmm. The source IP address should be correct in any case. > > If the R1 would be returned via the RVS and include a LOCATOR > for the Responder's real IP address, that would sound fine to me. In the current version the R1 always goes directly to the Initiator. > If the R1 would contain the Responder's real IP address and > the VIA_RVS parameter (for tracking in the flooding case), > that would sound fine with me. Adding a LOCATOR for the > Responder's real IP address sounds like redundancy, unless > the locator lists alternative IP addresses. Because the R1 always goes directly to the initiator it would always contain the responder's real IP address. So it would always be redundant. > > Is it okay with MAY or should we use SHOULD? > > So, maybe it still should be "MAY" but the draft to be clarified. > > > And is it right to write: the initiator SHOULD accept packets > > with or without LOCATOR parameter. > > No, LOCATOR will be defined in a different RFC, and IMHO we don't > want to have a hard dependency here. The system should work with > the LOCATOR being optional in the sense that the association should > be formed even if the Initiator does not understand the LOCATOR > parameter. Perhaps we could simply remove all references to LOCATOR. That way we have no hard dependency, and no redundancy. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 12:45:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpU4O-0000wS-3O; Mon, 04 Jul 2005 12:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpU4L-0000wE-Tx for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 12:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10823 for ; Mon, 4 Jul 2005 12:45:15 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpUUx-0002EW-VE for hipsec@ietf.org; Mon, 04 Jul 2005 13:12:48 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9D6E6212C93; Mon, 4 Jul 2005 19:45:08 +0300 (EEST) In-Reply-To: <200507041730.28852.julien.IETF@laposte.net> References: <200507041658.48754.julien.IETF@laposte.net> <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> <200507041730.28852.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43c9b59d79a21fbe885d5970b29f1c92@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 18:45:06 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Perhaps we could simply remove all references to LOCATOR. That way we > have no hard dependency, and no redundancy. Sounds good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 04 12:45:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpU4k-0000y8-JX; Mon, 04 Jul 2005 12:45:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpU4i-0000xw-Jl for hipsec@megatron.ietf.org; Mon, 04 Jul 2005 12:45:41 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10882 for ; Mon, 4 Jul 2005 12:45:37 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9D6E6212C93; Mon, 4 Jul 2005 19:45:08 +0300 (EEST) In-Reply-To: <200507041730.28852.julien.IETF@laposte.net> References: <200507041658.48754.julien.IETF@laposte.net> <01655812fb8ac6e6d26d201d482cca69@nomadiclab.com> <200507041730.28852.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43c9b59d79a21fbe885d5970b29f1c92@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks, Date: Mon, 4 Jul 2005 18:45:06 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Perhaps we could simply remove all references to LOCATOR. That way we > have no hard dependency, and no redundancy. Sounds good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 08:22:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmRm-0004jQ-KY; Tue, 05 Jul 2005 08:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmRh-0004jK-9W for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 08:22:41 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22171 for ; Tue, 5 Jul 2005 08:22:35 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4D1A0212CAE; Tue, 5 Jul 2005 12:10:01 +0300 (EEST) In-Reply-To: <200507051025.07092.julien.IETF@laposte.net> References: <200507041730.28852.julien.IETF@laposte.net> <43c9b59d79a21fbe885d5970b29f1c92@nomadiclab.com> <200507051025.07092.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 5 Jul 2005 11:10:00 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org Subject: [Hipsec] Re: Requirement keyword for VIA_RVS X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > What requirement keyword should we use about the responder adding the > VIA_RVS to an R1 when I1 was relayed. The current text has MUST, but > I am now confused. Should it be only SHOULD? I think it should be "MUST", as leaving it out might make the system vulnerable to certain kind of reflection attacks. That is, if the R1 is sent to a different address than what I1 was received from, the source address of I1 MUST be included in the R1. VIA_RVS is there exactly for this purpose. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 08:26:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmVg-0005QK-UZ; Tue, 05 Jul 2005 08:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmVf-0005QA-20 for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 08:26:43 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22407 for ; Tue, 5 Jul 2005 08:26:40 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B6A10700C78BA1 for hipsec@lists.ietf.org; Tue, 5 Jul 2005 14:26:09 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Tue, 5 Jul 2005 14:26:09 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_hxnyCZ+bQ+RahiO" Message-Id: <200507051426.09499.julien.IETF@laposte.net> Cc: Subject: [Hipsec] Preliminary X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --Boundary-00=_hxnyCZ+bQ+RahiO Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit Folks, Here is a new version (-03) of draft-ietf-hip-rvs I plan to submit shortly. It takes into account Pekka's comments and the discussion triggered on the ML. I also attached a htmlwdiff against previous version (-02) to help visualize differences. Please let me know if you have any additional comments. Thanks. -- julien --Boundary-00=_hxnyCZ+bQ+RahiO Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-hip-rvs-03.txt" Content-Disposition: attachment; filename="draft-ietf-hip-rvs-03.txt" Content-Transfer-Encoding: 7bit HIP Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: January 6, 2006 L. Eggert NEC July 5, 2005 Host Identity Protocol (HIP) Rendezvous Extension draft-ietf-hip-rvs-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. Laganier & Eggert Expires January 6, 2006 [Page 1] Internet-Draft HIP Rendezvous Extension July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 5 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 4.1 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 4.2 Parameter Formats and Processing . . . . . . . . . . . . . 7 4.2.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7 4.2.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 8 4.2.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9 4.3 Modified Packets Processing . . . . . . . . . . . . . . . 9 4.3.1 Processing Outgoing I1 Packets . . . . . . . . . . . . 9 4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10 4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10 4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 A. Document Revision History . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Laganier & Eggert Expires January 6, 2006 [Page 2] Internet-Draft HIP Rendezvous Extension July 2005 1. Introduction The Host Identity Protocol architecture [1] introduces the rendezvous mechanism to help a HIP node to contact a frequently moving HIP node. The rendezvous mechanism involves a third party, the rendezvous server (RVS), which serves as an initial contact point ("rendezvous point") for its clients. The clients of an RVS are HIP nodes that use the HIP Registration Protocol [2] to register their HIT->IP address mappings with the RVS. After this registration, other HIP nodes can initiate a base exchange using the IP address of the RVS instead of the current IP address of the node they attempt to contact. Essentially, the clients of an RVS become reachable at the RVS' IP addresses. Peers can initiate a HIP base exchange with the IP address of the RVS, which will relay this initial communication such that the base exchange may successfully complete. 2. Terminology This section defines terms used throughout the remainder of this specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. In addition to the terminology defined in [2], this document defines and uses the following terms: Rendezvous Service A HIP service provided by a rendezvous server to its rendezvous clients. The rendezvous server offers to relay some of the arriving base exchange packets between the initiator and responder. [Comment.1] Rendezvous Server (RVS) A HIP registrar providing rendezvous service. Rendezvous Client A HIP requester that has registered for rendezvous service at a rendezvous server. Rendezvous Registration A HIP registration for rendezvous service, established between a rendezvous server and a rendezvous client. Laganier & Eggert Expires January 6, 2006 [Page 3] Internet-Draft HIP Rendezvous Extension July 2005 3. Overview of Rendezvous Server Operation Figure 1 shows a simple HIP base exchange without a rendezvous server, in which the initiator initiates the exchange directly with the responder by sending an I1 packet to the responder's IP address, as per the HIP base specification [4]. +-----+ +-----+ | |-------I1------>| | | I |<------R1-------| R | | |-------I2------>| | | |<------R2-------| | +-----+ +-----+ Figure 1: HIP base exchange without rendezvous server. Proposed extensions for mobility and multi-homing [5] allow a HIP node to notify its peers about changes in its set of IP addresses. These extensions require an established HIP association between two nodes, i.e., a completed HIP base exchange. However, such a HIP node MAY also want to be reachable to other future correspondent peers that are unaware of its location change. The HIP architecture [1] introduces rendezvous servers with whom a HIP node MAY register its host identity tags (HITs) and current IP addresses. An RVS relays HIP packets arriving for these HITs to the node's registered IP addresses. When a HIP node has registered with an RVS, it SHOULD record the IP address of its RVS in its DNS record, using the HIPRVS DNS record type defined in [6]. +-----+ +--I1--->| RVS |---I1--+ | +-----+ | | v +-----+ +-----+ | |<------R1-------| | | I |-------I2------>| R | | |<------R2-------| | +-----+ +-----+ Figure 2: HIP base exchange with a rendezvous server. Figure 2 shows a HIP base exchange involving a rendezvous server. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP registration protocol [2]. When the initiator I tries to establish contact with the responder R, it MAY send the I1 of the base exchange either to one of R's DNS addresses or it MAY send it to the address of one of R's rendezvous Laganier & Eggert Expires January 6, 2006 [Page 4] Internet-Draft HIP Rendezvous Extension July 2005 servers instead. Here, I obtains the IP address of R's rendezvous server from R's DNS record and then sends the I1 packet of the HIP base exchange to RVS. RVS, noticing that the HIT contained in the arriving I1 packet is not one of its own, MUST check its current registrations to determine if if needs to relay the packets. Here, it determines that the HIT belongs to R and then relays the I1 packet to the registered IP address. R then completes the base exchange without further assistance from RVS by sending an R1 directly to the I's IP address, as obtained from the I1 packet. 3.1 Diagram Notation Notation Significance -------- ------------ I, R I and R are the respective source and destination IP addresses in the IP header. HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the responder's HITs in the packet, respectively. REG_REQ A REG_REQUEST parameter is present in the HIP header. REG_RES A REG_RESPONSE parameter is present in the HIP header. FROM:I A FROM parameter containing the IP address I is present in the HIP header. RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the appropriate registration key is present in the HIP header. VIA:RVS A VIA_RVS parameter containing the IP address RVS of a rendezvous server is present in the HIP header. 3.2 Rendezvous Client Registration Before a rendezvous server starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with it to receive rendezvous service by using the HIP registration extension [2] as illustrated in the following schema: Laganier & Eggert Expires January 6, 2006 [Page 5] Internet-Draft HIP Rendezvous Extension July 2005 +-----+ +-----+ | | I1 | | | |--------------------------->| | | |<---------------------------| | | I | R1(REG_INFO) | RVS | | | I2(REG_REQ) | | | |--------------------------->| | | |<---------------------------| | | | R2(REG_RES) | | +-----+ +-----+ 3.3 Relaying the Base Exchange If a HIP node and one of its rendezvous servers have a rendezvous registration, the rendezvous servers relay inbound I1 packets that contain one of the client's HITs by rewriting the IP header. They replace the destination IP address of the I1 packet with one of the IP addresses of the owner of the HIT, i.e., the rendezvous client. They MUST also recompute the IP checksum accordingly. Because of egress filtering on the path from the RVS to the client [10][11], a HIP rendezvous server SHOULD replace the source IP address, i.e., the IP address of I, with one of its own IP addresses. The replacement IP address SHOULD be chosen according to [7] and, when IPv6 is used, to [8]. Because this replacement conceals the initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet. This FROM parameter MUST be integrity protected by a RVS_HMAC keyed with the corresponding rendezvous registration integrity key [2]. I1(RVS, R, HIT-I, HIT-R I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) +----------------------->| |--------------------+ | | RVS | | | | | | | +---------+ | | V +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ | |<---------------------------------------------| | | | | | | I | I2(I, R, HIT-I, HIT-R) | R | | |--------------------------------------------->| | | |<---------------------------------------------| | +-----+ R2(R, I, HIT-R, HIT-I) +-----+ This modification of HIP packets at a rendezvous server can be problematic because the HIP protocol uses integrity checks. Because Laganier & Eggert Expires January 6, 2006 [Page 6] Internet-Draft HIP Rendezvous Extension July 2005 the I1 does not include HMAC or SIGNATURE parameters, these two end- to-end integrity checks are unaffected by the operation of rendezvous servers. The RVS SHOULD verify the checksum field of an I1 packet before doing any modifications. After modification, it MUST recompute the checksum field using the updated HIP header, which possibly included new FROM and RVS_HMAC parameters, and a pseudo-header containing the updated source and destination IP addresses. This enables the responder to validate the checksum of the I1 packet "as is", without having to parse any FROM parameters. 4. Rendezvous Server Extensions The following sections describe extensions to the HIP registration protocol [2], allowing a HIP node to register with a rendezvous server for rendezvous service and notify the RVS aware of changes to its current location. It also describes an extension to the HIP protocol [4] itself, allowing establishment of HIP associations via one or more HIP rendezvous server(s). 4.1 RENDEZVOUS Registration Type This specification defines an additional registration for the HIP registration protocol [2] that allows registering with a rendezvous server for rendezvous service. Number Registration Type ------ ----------------- 1 RENDEZVOUS 4.2 Parameter Formats and Processing 4.2.1 RVS_HMAC Parameter The RVS_HMAC is an OPTIONAL parameter whose only difference with the HMAC parameter defined in [4] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC): Laganier & Eggert Expires January 6, 2006 [Page 7] Internet-Draft HIP Rendezvous Extension July 2005 Type [ TBD by IANA (65472 = 2^16 - 2^6) ] Length 20 HMAC 160 low order bits of a HMAC keyed with the appropriate HIP integrity key (HIP_lg or HIP_gl), established when rendezvous registration happened. This HMAC is computed over the HIP packet, excluding RVS_HMAC and any following parameters. The "checksum" field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameter when the "authenticator" field is calculated. To allow a rendezvous client and its RVS to verify the integrity of packets flowing between them, both SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity key established while registration occured. A valid RVS_HMAC SHOULD be present on every packets flowing between a client and a server and MUST be present when a FROM parameters is processed. 4.2.2 FROM Parameter 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (65470 = 2^16 - 2^6 - 2) ] Length 16 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. A rendezvous server MUST add a FROM parameter containing the original source IP address of a HIP packet whenever the source IP address in the IP header is rewritten. If one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones. Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC protecting the packet integrity, especially the IP address included in the FROM parameter. Laganier & Eggert Expires January 6, 2006 [Page 8] Internet-Draft HIP Rendezvous Extension July 2005 4.2.3 VIA_RVS Parameter 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA (65474 = 2^16 - 2^6 + 2) ] Length Variable Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address After the responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the initiator's IP address, without further assistance from an RVS. For debugging purposes, it MAY include a subset of the IP addresses of its RVSs in some of these packets. When a responder does so, it MUST append a newly created VIA_RVS parameter at the end of the HIP packet. The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues encountered while establishing a HIP association via a RVS. 4.3 Modified Packets Processing The following subsections describe the differences of processing of I1 and R1 while a rendezvous server is involved in the base exchange. 4.3.1 Processing Outgoing I1 Packets An initiator SHOULD not send an opportunistic I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address, unless it wants to establish a HIP association with the rendezvous server itself and does not know its HIT. When an RVS rewrites the source IP address of an I1 packet due to Laganier & Eggert Expires January 6, 2006 [Page 9] Internet-Draft HIP Rendezvous Extension July 2005 egress filtering, it MUST add a FROM parameter to the I1 that contains the initiator's source IP address. This FROM parameter MUST be protected by a RVS_HMAC keyed with the integrity key established at rendezvous registration. 4.3.2 Processing Incoming I1 packets When a rendezvous server receives an I1 whose destination HIT is not its own, it consults its registration database to find a registration for the rendezvous service established by the HIT owner. If it finds an appropriate registration, it relays the packet to the registered IP address. If it does not find an appropriate registration, it drops the packet. A rendezvous server SHOULD interpret any incoming opportunistic I1 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself and SHOULD NOT attempt to relay it to one of its clients. When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM parameter is present, the packet MUST be dropped. A rendezvous client acting as responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed. 4.3.3 Processing Outgoing R1 Packets When a responder replies to an I1 relayed via a RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVS's. 4.3.4 Processing Incoming R1 packets The HIP base specification [4] mandates that a system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it is in state I1-SENT). When the R1 is replying to a relayed I1, this check SHOULD be based on HITs only. In case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter. 5. Security Considerations The security aspects of different HIP rendezvous mechanisms are currently being investigated. This section describes the known threats introduced by these HIP extensions and implications on the overall security of HIP and IP. In particular, it argues that the Laganier & Eggert Expires January 6, 2006 [Page 10] Internet-Draft HIP Rendezvous Extension July 2005 extensions described in this document do not introduce additional threats to the Internet infrastructure. It is difficult to encompass the whole scope of threats introduced by rendezvous servers, because their presence has implications both at the IP and HIP layers. In particular, these extensions might allow for redirection, amplification and reflection attacks at the IP layer, as well as attacks on the HIP layer itself, for example, man- in-the-middle attacks against HIP's SIGMA protocol. If an initiator has a priori knowledge of the responder's host identity when it first contacts it via an RVS, it has a means to verify the signatures in the HIP exchange, thus conforming to the SIGMA protocol which is resilient to man-in-the-middle attacks. If an initiator does not have a priori knowledge of the responder's host identiy (so-called "opportunistic initiators"), it is almost impossible to defend the HIP exchange against these attacks, because the public keys exchanged cannot be authenticated. The only approach would be to mitigate hijacking threats on HIP state by requiring an R1 answering an opportunistic I1 to come from the same IP address that originally sent the I1. This procedure retains a level of security which is equivalent to what exists in the Internet today. However, for reasons of simplicity, this specification does not allow to establish a HIP association via a rendezvous server in an opportunistic manner. 6. IANA Considerations This section is to be interpreted according to [9]. This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in Section 4.2: o RVS_HMAC (defined in Section 4.2.1) o FROM (defined in Section 4.2.2) o VIA_RVS (defined in Section 4.2.3) 7. Acknowledgments The following people have provided thoughtful and helpful discussions and/or suggestions that have improved this document: Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Laganier & Eggert Expires January 6, 2006 [Page 11] Internet-Draft HIP Rendezvous Extension July 2005 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Stiemerling and Juergen Quittek. Lars Eggert is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 8. References 8.1 Normative References [1] Moskowitz, R., "Host Identity Protocol Architecture", draft-ietf-hip-arch-02 (work in progress), January 2005. [2] Koponen, T. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", draft-koponen-hip-registration-00 (work in progress), February 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [5] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-ietf-hip-mm-01 (work in progress), February 2005. [6] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01 (work in progress), February 2005. [7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [8] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 8.2 Informative References [10] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Laganier & Eggert Expires January 6, 2006 [Page 12] Internet-Draft HIP Rendezvous Extension July 2005 Address Spoofing", BCP 38, RFC 2827, May 2000. [11] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000. [12] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [13] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. Editorial Comments [Comment.1] In this specification the client of the RVS is always the responder. However, there might be reasons to allow a client to initiate a base exchange through its own RVS, like NAT and firewall traversal. This specification does not address such scenarios which should be specified in other documents. Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Lars Eggert NEC Network Laboratories Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 Email: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ Laganier & Eggert Expires January 6, 2006 [Page 13] Internet-Draft HIP Rendezvous Extension July 2005 Appendix A. Document Revision History +-----------+-------------------------------------------------------+ | Revision | Comments | +-----------+-------------------------------------------------------+ | 02 | Removed multiple relaying techniques but simple I1 | | | header rewriting. Updated new HIP parameters type | | | numbers (consistent with new layout and assigning | | | rules from draft-ietf-hip-base.) Updated IANA | | | Considerations. | | 01 | Splitted out the registration sub-protocol. Simplify | | | typology of relaying techniques (keep only TUNNEL, | | | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. | | 00 | Initial version as a HIP WG item. | +-----------+-------------------------------------------------------+ Laganier & Eggert Expires January 6, 2006 [Page 14] Internet-Draft HIP Rendezvous Extension July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Laganier & Eggert Expires January 6, 2006 [Page 15] --Boundary-00=_hxnyCZ+bQ+RahiO Content-Type: text/html; charset="us-ascii"; name="diff.html" Content-Disposition: attachment; filename="diff.html" Content-Transfer-Encoding: 7bit wdiff MORGUE/draft-ietf-hip-rvs-02.txt draft-ietf-hip-rvs-03.txt 



HIP Working Group                                            J. Laganier
Internet-Draft                                          DoCoMo Euro-Labs
Expires: December 12, 2005 January 6, 2006                                       L. Eggert
                                                                     NEC
                                                           June 10,
                                                            July 5, 2005


           Host Identity Protocol (HIP) Rendezvous Extension
                         draft-ietf-hip-rvs-02
                         draft-ietf-hip-rvs-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 12, 2005. January 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document discusses defines a rendezvous extension for the Host Identity
   Protocol (HIP).  The rendezvous extension extends HIP and the HIP
   registration extension for initiating communication between HIP nodes
   via HIP rendezvous servers.  Rendezvous servers improve reachability
   and operation when HIP nodes are multi-homed or mobile.





Laganier & Eggert        Expires December 12, 2005 January 6, 2006                [Page 1]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   3.  Overview of Rendezvous Server Operation  . . . . . . . . . . .  4
     3.1   Diagram Notation . . . . . . . . . . . . . . . . . . . . .  6  5
     3.2   Rendezvous Client Registration . . . . . . . . . . . . . .  6  5
     3.3   Relaying the Base Exchange . . . . . . . . . . . . . . . .  7  6
   4.  Rendezvous Server Extensions . . . . . . . . . . . . . . . . .  8  7
     4.1   LOCATOR Parameter   RENDEZVOUS Registration Type . . . . . . . . . . . . . . .  7
     4.2   Parameter Formats and Processing . . . . .  8
     4.2   RENDEZVOUS Registration Type . . . . . . . .  7
       4.2.1   RVS_HMAC Parameter . . . . . . .  8
     4.3   New Parameter Formats and Processing . . . . . . . . . . .  9
       4.3.1   RVS_HMAC  7
       4.2.2   FROM Parameter . . . . . . . . . . . . . . . . . .  9
       4.3.2   FROM . .  8
       4.2.3   VIA_RVS Parameter  . . . . . . . . . . . . . . . . . .  9
     4.3   Modified Packets Processing  . . . . . . . . . . . . . . .  9
       4.3.3   VIA_RVS Parameter
       4.3.1   Processing Outgoing I1 Packets . . . . . . . . . . . .  9
       4.3.2   Processing Incoming I1 packets . . . . . . . . . . . . 10
     4.4
       4.3.3   Processing Outgoing I1 R1 Packets . . . . . . . . . . . . . . 10
     4.5
       4.3.4   Processing Incoming I1 R1 packets . . . . . . . . . . . . . . 11 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12 11
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 13 12
     8.2   Informative References . . . . . . . . . . . . . . . . . . 13 12
       Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 13
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16 15






















Laganier & Eggert        Expires December 12, 2005 January 6, 2006                [Page 2]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


1.  Introduction

   The current Internet uses IP addresses for two purposes.  First, they
   are topological locators for network attachment points.  Second, they
   act as names for the attached network interfaces.  Saltzer [9]
   discusses these naming concepts in detail.  Routing and other
   network-layer mechanisms are based on the locator aspects of IP
   addresses.  Transport-layer protocols and mechanisms typically use IP
   addresses in their role as names for communication endpoints.  This
   dual use of IP addresses limits the flexibility of the Internet
   architecture.  The need to avoid readdressing in order to maintain
   existing transport-layer connections complicates advanced
   functionality, such as mobility, multi-homing, or network
   composition.

   The Host Identity Protocol (HIP) architecture [1] defines a new third
   namespace.  The Host Identity namespace decouples the name and
   locator roles currently filled by IP addresses.  Transport-layer
   mechanisms operate on Host Identities instead of using IP addresses
   as endpoint names.  Network-layer mechanisms continue to use IP
   addresses as pure locators.  Because of this decoupling introduces the HIP layer
   needs rendezvous
   mechanism to map Host Identities into IP addresses.

   Without HIP, help a HIP node needs to know its peer's IP address to make
   initial contact. contact a frequently moving HIP node.
   The Host Identity Protocol architecture [1] does
   not change this basic property, but introduces an additional,
   optional piece of infrastructure, rendezvous mechanism involves a third party, the rendezvous
   server (RVS).  An
   RVS (RVS), which serves as an additional initial contact point ("rendezvous
   point") for its clients.  The clients of an RVS are HIP nodes that
   use the HIP Registration Protocol [2] to register their HIT->IP
   address mappings with the RVS.  After this registration, other HIP
   nodes can initiate a base exchange using the IP address of the RVS
   instead of the current IP address of the node they attempt to
   contact.  Essentially, the clients of an RVS become reachable at the
   RVS' IP addresses.  Peers can initiate a HIP base exchange with the
   IP address of the RVS, which will relay this initial communication
   such that the base exchange may successfully complete.

   When HIP nodes frequently change their network attachment points,
   using a RVS can improve reachability and operation.  Without an RVS,
   a HIP node needs to update its DNS entry with its current IP address
   before it becomes reachable to its peers.  Although the DNS offers
   mechanisms for dynamic updates to records[10][11], they may not be
   suitable when a record changes frequently.  Caching, state lifetimes
   and deficiences in existing DNS implementations limit the rate-of-
   change for a given record.  When using an RVS - which is assumed to
   be reachable at a static or at least infrequently changing IP address
   - HIP nodes need not update their DNS records whenever their local IP



Laganier & Eggert       Expires December 12, 2005               [Page 3]

Internet-Draft          HIP Rendezvous Extension               June 2005


   addresses change.  Instead, they register the IP address of their RVS
   in their DNS entry and then update only their RVS when their IP
   addresses change.  Because the RVS is specifically designed to
   support high-rate updates, this indirection can improve reachability
   of HIP nodes.

2.  Terminology

   This section defines terms used throughout the remainder of this
   specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

   In addition to the terminology defined in [2], this document defines
   and uses the following terms:

   Rendezvous Service
      A HIP service provided by a rendezvous server to its rendezvous
      clients.  The rendezvous server offers to relay some of the
      arriving base exchange packets between the initiator and
      responder.  [Comment.1]

   Rendezvous Server (RVS)
      A HIP registrar providing rendezvous service.

   Rendezvous Client
      A HIP requester that has registered for rendezvous service at a
      rendezvous server.

   Rendezvous Registration
      A HIP registration for rendezvous service, established between a
      rendezvous server and a rendezvous client.


3.  Overview of Rendezvous Server Operation

   HIP decouples domain names from IP addresses.  Because transport
   protocols bind to host identities, they remain unaware if the set of
   IP addresses associated with a host identity changes.  This change
   can have various reasons, including, but not limited to, mobility and
   multi-homing.







Laganier & Eggert        Expires December 12, 2005 January 6, 2006                [Page 4] 3]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


                       +-----+                +-----+
                       |     |-------I1------>|     |
                       |  I  |<------R1-------|  R  |
                       |     |-------I2------>|     |
                       |     |<------R2-------|     |
                       +-----+                +-----+

          Figure 1: HIP base exchange without rendezvous server.


3.  Overview of Rendezvous Server Operation

   Figure 2 1 shows a simple HIP base exchange without a rendezvous
   server, in which the initiator initiates the exchange directly with
   the responder by sending an I1 packet to the responder's IP address,
   as per the HIP base specification [4].

                       +-----+                +-----+
                       |     |-------I1------>|     |
                       |  I  |<------R1-------|  R  |
                       |     |-------I2------>|     |
                       |     |<------R2-------|     |
                       +-----+                +-----+

          Figure 1: HIP base exchange without rendezvous server.

   Proposed extensions for mobility and multi-homing [5] allow a HIP
   node to notify its peers about changes in its set of IP addresses.
   These extensions require an established HIP association between two
   nodes, i.e., a completed HIP base exchange.

   However, such a HIP node MAY also want to be reachable to other
   future correspondent peers that are unaware of its location change.
   The HIP architecture [1] introduces rendezvous servers with whom a
   HIP node MAY register its host identity tags (HITs) and current IP
   addresses.  An RVS relays HIP packets arriving for these HITs to the
   node's registered IP addresses.  When a HIP node has registered with
   an RVS, it SHOULD record the IP address of its RVS in its DNS record,
   using the HIPRVS DNS record type defined in [12]. [6].

                                   +-----+
                          +--I1--->| RVS |---I1--+
                          |        +-----+       |
                          |                      v
                       +-----+                +-----+
                       |     |<------R1-------|     |
                       |  I  |-------I2------>|  R  |
                       |     |<------R2-------|     |
                       +-----+                +-----+

           Figure 2: HIP base exchange with a rendezvous server.

   Figure 2 shows a HIP base exchange involving a rendezvous server.  It
   is assumed that HIP node R previously registered its HITs and current
   IP addresses with the RVS, using the HIP registration protocol [2].
   When the initiator I tries to establish contact with the responder R,
   it MAY send the I1 of the base exchange either to one of R's DNS
   addresses or it MAY send it to the address of one of R's rendezvous



Laganier & Eggert        Expires January 6, 2006                [Page 4]

Internet-Draft          HIP Rendezvous Extension               July 2005


   servers instead.  Here, I obtains the IP address of R's rendezvous
   server from R's DNS record and then sends the I1 packet of the HIP



Laganier & Eggert       Expires December 12, 2005               [Page 5]

Internet-Draft          HIP Rendezvous Extension               June 2005
   base exchange to RVS.  RVS, noticing that the HIT contained in the
   arriving I1 packet is not one of its own, MUST check its current
   registrations to determine if if needs to relay the packets.  Here,
   it determines that the HIT belongs to R and then relays the I1 packet
   to the registered IP address.  R then completes the base exchange
   without further assistance from RVS by sending an R1 directly to the
   I's IP address, as obtained from the I1 packet.

3.1  Diagram Notation

   Notation       Significance
   --------       ------------

   I, R           I and R are the respective source and destination IP
                  addresses in the IP header.

   HIT-I, HIT-R   HIT-I and HIT-R are the initiator's and the
                  responder's HITs in the packet, respectively.

   LOC:I

   REG_REQ        A LOCATOR REG_REQUEST parameter containing is present in the IP address I HIP header.

   REG_RES        A REG_RESPONSE parameter is present in the HIP header.

   FROM:I         A FROM parameter containing the IP address I is
                  present in the HIP header.

   VIA:RVS

   RVS_HMAC       A VIA_RVS RVS_HMAC parameter containing a HMAC keyed with the IP addresses of an
                  RVS
                  appropriate registration key is present in the HIP
                  header.

   REG_REQ

   VIA:RVS        A REG_REQUEST VIA_RVS parameter is present in containing the HIP header.

   REG_RES        A REG_RESPONSE parameter IP address RVS of a
                  rendezvous server is present in the HIP header.


3.2  Rendezvous Client Registration

   Before a rendezvous server starts to relay HIP packets to a
   rendezvous client, the rendezvous client needs to register with it to
   receive rendezvous service by using the HIP registration extension
   [2] as illustrated in the following schema:









Laganier & Eggert        Expires December 12, 2005 January 6, 2006                [Page 6] 5]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


                 +-----+                            +-----+
                 |     |            I1              |     |
                 |     |--------------------------->|     |
                 |     |<---------------------------|     |
                 |  I  |         R1(REG_INFO)       | RVS |
                 |     |         I2(REG_REQ)        |     |
                 |     |--------------------------->|     |
                 |     |<---------------------------|     |
                 |     |         R2(REG_RES)        |     |
                 +-----+                            +-----+


3.3  Relaying the Base Exchange

   If a HIP node and one of its rendezvous servers have a rendezvous
   registration, the rendezvous servers MUST relay inbound I1 packets that
   contain one of the client's HITs by rewriting the IP header.  They
   replace the destination IP address of the I1 packet with one of the
   IP addresses of the owner of the HIT, i.e., the rendezvous client.
   They MUST also recompute the IP checksum accordingly.

   Because of egress filtering on the path from the RVS to the client, client
   [10][11], a HIP rendezvous server MAY also need to SHOULD replace the source IP
   address, i.e., the IP address of I, with one of its own IP addresses.
   The replacement IP address SHOULD be chosen according to [6] [7] and,
   when IPv6 is used,  to [7]. [8].  Because this replacement conceals the
   initiator's IP address, the RVS MUST append a FROM parameter
   containing the original source IP address of the packet.  This FROM
   parameter MUST be integrity protected by a RVS_HMAC keyed with the
   corresponding rendezvous registration integrity key [2].

                                               I1(RVS, R, HIT-I, HIT-R
         I1(I, RVS, HIT-I, HIT-R) +---------+     FROM:I, VIA:RVS) RVS_HMAC)
         +----------------------->|         |--------------------+
         |                        |   RVS   |                    |
         |                        |         |                    |
         |                        +---------+                    |
         |                                                       V
        +-----+        R1(R, I, HIT-R, HIT-I, LOC:R, VIA:RVS)       +-----+
        |     |<---------------------------------------------|     |
        |     |                                              |     |
        |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
        |     |--------------------------------------------->|     |
        |     |<---------------------------------------------|     |
        +-----+             R2(R, I, HIT-R, HIT-I)           +-----+

            Figure 5: Rendezvous server rewriting IP addresses



Laganier & Eggert       Expires December 12, 2005               [Page 7]

Internet-Draft          HIP Rendezvous Extension               June 2005

   This modification of HIP packets at a rendezvous server can be
   problematic.  The
   problematic because the HIP protocol uses two kinds of packet integrity
   checks: hop-by-hop and end-to-end.  The checks.  Because



Laganier & Eggert        Expires January 6, 2006                [Page 6]

Internet-Draft          HIP checksum is a hop-by-hop
   check and SHOULD be verified and recomputed by each of Rendezvous Extension               July 2005


   the on-path
   HIP-enabled middleboxes, such as rendezvous servers.  The I1 does not include HMAC and or SIGNATURE are end-to-end parameters, these two end-
   to-end integrity checks and MUST be computed by the sender
   and verified are unaffected by the receiver. operation of rendezvous
   servers.

   The RVS MUST SHOULD verify the checksum field of an I1 packet before doing
   any modifications.  After modification, it MUST recompute the
   checksum field using the updated HIP header, which possibly included
   new FROM and RVS_HMAC parameters, and a pseudo-header containing the
   updated source and destination IP addresses.  This enables the
   responder to validate the checksum of the I1 packet "as is", without
   having to parse any FROM parameters.

   The SIGNATURE and HMAC verification MUST NOT cover any FROM and
   RVS_HMAC parameters added by rendezvous servers.  Hence, HMAC and
   SIGNATURE are unaffected by the modifications performed by an RVS.
   The computation and verification of HMAC and SIGNATURE MUST only
   cover the original HIP header with a checksum field set to zero, MUST
   NOT cover the pseudo header that contains modified IP addresses, and
   mUST NOT cover any new FROM and RVS_HMAC parameters that MAY be
   situated after the HMAC and SIGNATURE in the HIP header.

4.  Rendezvous Server Extensions

   The following sections describe extensions to the HIP registration
   protocol [2], allowing a HIP node to register with a rendezvous
   server for rendezvous service and notify the RVS aware of changes to
   its current location.  It also describes an extension to the HIP
   protocol [4] itself, allowing establishment of HIP associations via
   one or more HIP rendezvous server(s).

4.1  LOCATOR Parameter

   A HIP responder contacted via an RVS MAY use a LOCATOR parameter in
   the R1 packet to notify the initiator of its current IP address, in
   conformance with the guidelines specified in [5].

4.2 the HIP
   protocol [4] itself, allowing establishment of HIP associations via
   one or more HIP rendezvous server(s).

4.1  RENDEZVOUS Registration Type

   This specification defines an additional registration for the HIP
   registration protocol [2] that allows registering with a rendezvous
   server for rendezvous service.

   Number   Registration Type
   ------   -----------------



Laganier & Eggert       Expires December 12, 2005               [Page 8]

Internet-Draft          HIP Rendezvous Extension               June 2005
   1        RENDEZVOUS


4.3  New


4.2  Parameter Formats and Processing

4.3.1

4.2.1  RVS_HMAC Parameter

   The RVS_HMAC is an OPTIONAL parameter whose only difference with the
   HMAC parameter defined in [4] is its "type" code.  This change causes
   it to be located after the FROM parameter (as opposed to the HMAC):












Laganier & Eggert        Expires January 6, 2006                [Page 7]

Internet-Draft          HIP Rendezvous Extension               July 2005


   Type        [ TBD by IANA (65472 = 2^16 - 2^6) ]
   Length      20
   HMAC        160 low order bits of a HMAC keyed with the
               appropriate HIP integrity key (HIP_lg or HIP_gl),
               established when rendezvous registration happened.
               This HMAC is computed over the HIP packet, excluding
               RVS_HMAC and any following parameters. The
               "checksum" field MUST be set to zero and the HIP header
               length in the HIP common header MUST be calculated
               not to cover any excluded parameter when the
               "authenticator" field is calculated.

   To allow a rendezvous client and its RVS to verify the integrity of
   packets flowing between them, both SHOULD protect packets with an
   added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity
   key.
   key established while registration occured.  A valid RVS_HMAC SHOULD
   be present on every packets flowing between a client and a server and
   MUST be present when a FROM parameters is processed.

4.3.2

4.2.2  FROM Parameter

     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                             Address                           |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type        [ TBD by IANA (65470 = 2^16 - 2^6 - 2) ]
    Length      16
    Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address.

   A rendezvous server MUST add a FROM parameter containing the original



Laganier & Eggert       Expires December 12, 2005               [Page 9]

Internet-Draft          HIP Rendezvous Extension               June 2005
   source IP address of a HIP packet whenever the source IP address in
   the IP header is rewritten.  If one or more FROM parameters are
   already present, the new FROM parameter MUST be appended after the
   existing ones.

   Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
   protecting the packet integrity, especially the IP address included
   in the FROM parameter.

4.3.3






Laganier & Eggert        Expires January 6, 2006                [Page 8]

Internet-Draft          HIP Rendezvous Extension               July 2005


4.2.3  VIA_RVS Parameter

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                               .                               .
     .                               .                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA (65474 = 2^16 - 2^6 + 2) ]
     Length      Variable
     Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address

   After the responder receives a relayed I1 packet, it can begin to
   send HIP packets addressed to the initiator's IP address, without
   further assistance from an RVS.  For debugging purposes, it MAY
   include a subset of the IP addresses of its RVSs in some of these
   packets.  When a responder does so, it MUST append a newly created
   VIA_RVS parameter at the end of the HIP packet.  The main goal of
   using the VIA_RVS parameter is to allow operators to diagnose
   possible issues encountered while establishing a HIP association via
   a RVS.

4.4

4.3  Modified Packets Processing

   The following subsections describe the differences of processing of
   I1 and R1 while a rendezvous server is involved in the base exchange.

4.3.1  Processing Outgoing I1 Packets

   An initiator SHOULD not send an opportunistic I1 with a NULL
   destination HIT to an IP address which is known to be a rendezvous



Laganier & Eggert       Expires December 12, 2005              [Page 10]

Internet-Draft          HIP Rendezvous Extension               June 2005
   server address, unless it wants to establish a HIP association with
   the rendezvous server itself and does not know its HIT.

   If

   When an RVS needs to rewrite rewrites the source IP address of an I1 packet due to



Laganier & Eggert        Expires January 6, 2006                [Page 9]

Internet-Draft          HIP Rendezvous Extension               July 2005


   egress filtering, then it MUST add a FROM parameter to the I1 that
   contasins
   contains the initiator's source IP address.  This FROM parameter MUST
   be protected by a RVS_HMAC keyed with the integrity key established
   at rendezvous registration.

4.5

4.3.2  Processing Incoming I1 packets

   When a rendezvous server receives an I1 whose destination HIT is not
   its own, it MUST consult consults its registration database to find a registration
   for the rendezvous service established by the HIT owner.  If it finds
   an appropriate registration, it MUST relay relays the packet to the registered
   IP address.  If it does not find an appropriate registration, is MUST drop it
   drops the packet.

   A rendezvous server SHOULD interpret any incoming opportunistic I1
   (i.e., an I1 with a NULL destination HIT) as an I1 addressed to
   itself and SHOULD NOT attempt to relay it to one of its clients.

   When a rendezvous client receives an I1, it MUST validate any present
   RVS_HMAC parameter.  If the RVS_HMAC cannot be verified, the packet
   SHOULD be dropped.  If the RVS_HMAC cannot be verified and a FROM
   parameter is present, the packet MUST be dropped.

   A rendezvous client acting as responder SHOULD drop opportunistic I1s
   that include a FROM parameter, because this indicates that dropped.

   A rendezvous client acting as responder SHOULD drop opportunistic I1s
   that include a FROM parameter, because this indicates that the I1 has
   been relayed.

4.3.3  Processing Outgoing R1 Packets

   When a responder replies to an I1 relayed via a RVS, it MUST append
   to the regular R1 header a VIA_RVS parameter containing the IP
   addresses of the traversed RVS's.

4.3.4  Processing Incoming R1 packets

   The HIP base specification [4] mandates that a system receiving an R1
   MUST first check to see if it has sent an I1 to the originator of the
   R1 (i.e., it is in state I1-SENT).  When the R1 is replying to a
   relayed I1, this check SHOULD be based on HITs only.  In case the IP
   addresses are also checked, then the source IP address MUST be
   checked against the I1 has
   been relayed. IP address included in the VIA_RVS parameter.

5.  Security Considerations

   The security aspects of different HIP rendezvous mechanisms are
   currently being investigated.  This section describes the known
   threats introduced by these HIP extensions and implications on the
   overall security of HIP and IP.  In particular, it argues that the



Laganier & Eggert        Expires January 6, 2006               [Page 10]

Internet-Draft          HIP Rendezvous Extension               July 2005


   extensions described in this document do not introduce additional
   threats to the Internet infrastructure.

   It is difficult to encompass the whole scope of threats introduced by
   rendezvous servers, because their presence has implications both at
   the IP and HIP layers.  In particular, these extensions might allow
   for redirection, amplification and reflection attacks at the IP
   layer, as well as attacks on the HIP layer itself, for example, man-
   in-the-middle attacks against HIP's SIGMA protocol.

   If an initiator has a priori knowledge of the responder's host



Laganier & Eggert       Expires December 12, 2005              [Page 11]

Internet-Draft          HIP Rendezvous Extension               June 2005
   identity when it first contacts it via an RVS, it has a means to
   verify the signatures in the HIP exchange, thus conforming to the
   SIGMA protocol which is resilient to man-in-the-middle attacks.

   If an initiator does not have a priori knowledge of the responder's
   host identiy (so-called "opportunistic initiators"), it is almost
   impossible to defend the HIP exchange against these attacks, because
   the public keys exchanged cannot be authenticated.  The only approach
   would be to mitigate hijacking threats on HIP state by requiring an
   R1 answering an opportunistic I1 to come from the same IP address
   that originally sent the I1.  This procedure retains a level of
   security which is equivalent to what exists in the Internet today.

   However, for reasons of simplicity, this specification does not allow
   to establish a HIP association via a rendezvous server in an
   opportunistic manner.

6.  IANA Considerations

   This section is to be interpreted according to [8]. [9].

   This document updates the IANA Registry for HIP Parameters Types by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in Section 4.3: 4.2:

   o  RVS_HMAC (defined in Section 4.3.1) 4.2.1)

   o  FROM (defined in Section 4.3.2) 4.2.2)

   o  VIA_RVS (defined in Section 4.3.3) 4.2.3)


7.  Acknowledgments

   The following people have provided thoughtful and helpful discussions
   and/or suggestions that have improved this document: Marcus Brunner,
   Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino



Laganier & Eggert        Expires January 6, 2006               [Page 11]

Internet-Draft          HIP Rendezvous Extension               July 2005


   Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
   Stiemerling and Juergen Quittek.

   Lars Eggert is partly funded by Ambient Networks, a research project
   supported by the European Commission under its Sixth Framework
   Program.  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the Ambient Networks project or the European Commission.

8.  References



Laganier & Eggert       Expires December 12, 2005              [Page 12]

Internet-Draft          HIP Rendezvous Extension               June 2005

8.1  Normative References

   [1]  Moskowitz, R., "Host Identity Protocol Architecture",
        draft-ietf-hip-arch-02 (work in progress), January 2005.

   [2]  Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
        Registration Extension", draft-koponen-hip-registration-00 (work
        in progress), February 2005.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02 draft-ietf-hip-base-03
        (work in progress), February June 2005.

   [5]  Nikander, P., "End-Host Mobility and Multi-Homing with Host
        Identity Protocol", draft-ietf-hip-mm-01 (work in progress),
        February 2005.

   [6]  Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
        Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01
        (work in progress), February 2005.

   [7]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

   [7]

   [8]  Draves, R., "Default Address Selection for Internet Protocol
        version 6 (IPv6)", RFC 3484, February 2003.

   [8]

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8.2  Informative References

   [9]   Saltzer, J., "On the Naming and Binding of Network
         Destinations", RFC 1498, August 1993.

   [10]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

   [12]  Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
         Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01
         (work in progress), February 2005.

   [13]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.



Laganier & Eggert        Expires December 12, 2005 January 6, 2006               [Page 13] 12]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


   [14]


         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [11]  Killalea, T., "Recommended Internet Service Provider Security
         Services and Procedures", BCP 46, RFC 3013, November 2000.

   [12]  Saltzer, J., "On the Naming and Binding of Network
         Destinations", RFC 1498, August 1993.

   [13]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

Editorial Comments

   [Comment.1]  In this specification the client of the RVS is always
                the responder.  However, there might be reasons to allow
                a client to initiate a base exchange through its own
                RVS, like NAT and firewall traversal. This specification
                does not address such scenarios which should be
                specified in other documents.


Authors' Addresses

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687
   Germany

   Phone: +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/


   Lars Eggert
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   Email: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/







Laganier & Eggert        Expires January 6, 2006               [Page 13]

Internet-Draft          HIP Rendezvous Extension               July 2005


Appendix A.  Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 02        | Removed multiple relaying techniques but simple I1    |
   |           | header rewriting. Updated new HIP parameters type     |
   |           | numbers (consistent with new layout and assigning     |
   |           | rules from draft-ietf-hip-base.) Updated IANA         |
   |           | Considerations.                                       |




Laganier & Eggert       Expires December 12, 2005              [Page 14]

Internet-Draft          HIP Rendezvous Extension               June 2005
   | 01        | Splitted out the registration sub-protocol. Simplify  |
   |           | typology of relaying techniques (keep only TUNNEL,    |
   |           | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
   | 00        | Initial version as a HIP WG item.                     |
   +-----------+-------------------------------------------------------+




































Laganier & Eggert        Expires December 12, 2005 January 6, 2006               [Page 15] 14]

Internet-Draft          HIP Rendezvous Extension               June               July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Laganier & Eggert        Expires December 12, 2005 January 6, 2006               [Page 16] 15]
--Boundary-00=_hxnyCZ+bQ+RahiO Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Boundary-00=_hxnyCZ+bQ+RahiO-- From hipsec-bounces@lists.ietf.org Tue Jul 05 08:46:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmoM-00007o-Vp; Tue, 05 Jul 2005 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmoI-00006Z-IM for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 08:45:58 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23703 for ; Tue, 5 Jul 2005 08:45:57 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B6958400610683; Tue, 5 Jul 2005 10:25:05 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Tue, 5 Jul 2005 10:25:06 +0200 User-Agent: KMail/1.8 References: <200507041730.28852.julien.IETF@laposte.net> <43c9b59d79a21fbe885d5970b29f1c92@nomadiclab.com> In-Reply-To: <43c9b59d79a21fbe885d5970b29f1c92@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507051025.07092.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert Subject: [Hipsec] Requirement keyword for VIA_RVS X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, What requirement keyword should we use about the responder adding the VIA_RVS to an R1 when I1 was relayed. The current text has MUST, but I am now confused. Should it be only SHOULD? Tnx. -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 08:48:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmqH-0000Rc-Je; Tue, 05 Jul 2005 08:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmqD-0000PO-3d for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 08:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23903 for ; Tue, 5 Jul 2005 08:47:55 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpnEX-0002BH-Nu for hipsec@ietf.org; Tue, 05 Jul 2005 09:13:07 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 32A06212C93; Tue, 5 Jul 2005 15:45:06 +0300 (EEST) In-Reply-To: <200507051426.09499.julien.IETF@laposte.net> References: <200507051426.09499.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7b6cc1f822c46203a7ce961b0d25690d@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Preliminary Date: Tue, 5 Jul 2005 14:45:06 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Here is a new version (-03) of draft-ietf-hip-rvs I plan to submit > shortly. It takes into account Pekka's comments and the discussion > triggered on the ML. I also attached a htmlwdiff against previous > version (-02) to help visualize differences. > > Please let me know if you have any additional comments. I think the mm draft should now be informational. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 14:41:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpsMX-0001C1-1g; Tue, 05 Jul 2005 14:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpsMH-000146-3k for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 14:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05024 for ; Tue, 5 Jul 2005 14:41:21 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpshN-0001wQ-7s for hipsec@ietf.org; Tue, 05 Jul 2005 15:03:15 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA25211; Tue, 5 Jul 2005 11:35:20 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j65IZJ116901; Tue, 5 Jul 2005 11:35:19 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 11:35:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Preliminary Date: Tue, 5 Jul 2005 11:35:19 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095AD2@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Preliminary Thread-Index: AcWBXRGricmvqwTRQHqOx5KIuXyh5AALzWtw From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 05 Jul 2005 18:35:19.0552 (UTC) FILETIME=[4BB78800:01C58190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, I just had a few comments: - In section 3, it is more correct to state that the mm draft presumes initial reachability of the two nodes with respect to each other, rather than saying that the mm- extensions require an established HIP association, because it is discussed in the mm- draft how to piggyback some LOC parameters on the base exchange messages. - " When the initiator I tries to establish contact with the responder R, it MAY send the I1 of the base exchange either to one of R's DNS addresses or it MAY send it to the address of one of R's rendezvous servers instead." (suggested change-- "When the initiator I tries to establish contact with the responder R, it must send the I1 of the base exchange either to one of R's IP addresses (if known via DNS or other means) or to one of R's rendezvous servers instead.") =20 - I would recommend promoting the editorial "Comment.1" to somewhere in Section 3 (it is really a comment about the scope of this document). =20 - HIP architecture document is slated to become Informational (or even Historic) document, so perhaps should be moved to Informative references section. - Section 4.2.1-- it is confusing that RVS_HMAC is here described as "OPTIONAL" when in previous sections, it is described as a "MUST" to include. - In section 5, I suggest change "SIGMA" to "base exchange" protocol, or else reference the SIGMA work. s/an RVS/a RVS/g=20 s/SHOULD not/SHOULD NOT/g Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 14:41:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpsMY-0001DX-Oe; Tue, 05 Jul 2005 14:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpsMG-00013q-Dv for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 14:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04997 for ; Tue, 5 Jul 2005 14:41:20 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpsho-0001x8-8k for hipsec@ietf.org; Tue, 05 Jul 2005 15:03:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA21542; Tue, 5 Jul 2005 13:35:44 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j65IZh117682; Tue, 5 Jul 2005 11:35:43 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 11:35:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Preliminary Date: Tue, 5 Jul 2005 11:35:41 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095AD3@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Preliminary Thread-Index: AcWBYgRo/Qwzg1iDSnyHT3BVqITVMAAKVokw From: "Henderson, Thomas R" To: "Pekka Nikander" , "Julien Laganier" X-OriginalArrivalTime: 05 Jul 2005 18:35:42.0317 (UTC) FILETIME=[594931D0:01C58190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, July 05, 2005 5:45 AM > To: Julien Laganier > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] Preliminary >=20 > > > > Please let me know if you have any additional comments. >=20 > I think the mm draft should now be informational. >=20 > --Pekka Could you elaborate? Do you mean eventual Informational rather than Experimental status for the mm draft, or something else? Tom=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 14:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpsbg-0001e7-43; Tue, 05 Jul 2005 14:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpsbb-0001MO-NP for hipsec@megatron.ietf.org; Tue, 05 Jul 2005 14:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06640 for ; Tue, 5 Jul 2005 14:57:14 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpt0B-0003Og-Bp for hipsec@ietf.org; Tue, 05 Jul 2005 15:22:39 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA29475; Tue, 5 Jul 2005 11:54:41 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j65Isdv29148; Tue, 5 Jul 2005 13:54:40 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 11:54:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: Requirement keyword for VIA_RVS Date: Tue, 5 Jul 2005 11:54:38 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095AD4@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Re: Requirement keyword for VIA_RVS Thread-Index: AcWBXG2WBWRWUj/NQx2psDiadvfxSQANPRnA From: "Henderson, Thomas R" To: "Pekka Nikander" , "Julien Laganier" X-OriginalArrivalTime: 05 Jul 2005 18:54:39.0372 (UTC) FILETIME=[FF0604C0:01C58192] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, July 05, 2005 2:10 AM > To: Julien Laganier > Cc: Lars Eggert; hipsec@ietf.org > Subject: [Hipsec] Re: Requirement keyword for VIA_RVS >=20 > > What requirement keyword should we use about the responder=20 > adding the > > VIA_RVS to an R1 when I1 was relayed. The current text has MUST, but > > I am now confused. Should it be only SHOULD? >=20 > I think it should be "MUST", as leaving it out might make the > system vulnerable to certain kind of reflection attacks. > That is, if the R1 is sent to a different address than what I1 > was received from, the source address of I1 MUST be included in > the R1. VIA_RVS is there exactly for this purpose. >=20 I agree with this enforcement on the Responder behavior. On the initiator side, it seems like things would interoperate fine with an initiator that ignored the VIA_RVS parameter, so that seems fine too. (The base draft does not require that the IP addresses be checked on incoming R1s). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 05 18:57:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwLt-0000zP-8y; Tue, 05 Jul 2005 18:57:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwLH-0000Lc-2f; Tue, 05 Jul 2005 18:56:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12513; Tue, 5 Jul 2005 18:56:34 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpwfk-0007Ig-CI; Tue, 05 Jul 2005 19:17:49 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DpwEr-0007bE-Fn; Tue, 05 Jul 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 05 Jul 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-esp-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using ESP transport format with HIP Author(s) : P. Jokela Filename : draft-ietf-hip-esp-00.txt Pages : 33 Date : 2005-7-5 This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-esp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-esp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-5163820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-esp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-esp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-5163820.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Jul 06 02:22:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3It-0006zF-He; Wed, 06 Jul 2005 02:22:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3Iq-0006y5-Us for hipsec@megatron.ietf.org; Wed, 06 Jul 2005 02:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28138 for ; Wed, 6 Jul 2005 02:22:35 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq3ji-0002U5-BZ for hipsec@ietf.org; Wed, 06 Jul 2005 02:50:23 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 78C47212C93; Wed, 6 Jul 2005 09:22:19 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095AD3@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D095AD3@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Preliminary Date: Wed, 6 Jul 2005 08:22:18 +0200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>> Please let me know if you have any additional comments. >> >> I think the mm draft should now be informational. > > Could you elaborate? Do you mean eventual Informational rather than > Experimental status for the mm draft, or something else? Sorry, I was in haste. I meant it should be an informational reference instead of being normative. Sorry about the confusion. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jul 06 12:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCaP-0003jS-Bk; Wed, 06 Jul 2005 12:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCaL-0003cp-TP for hipsec@megatron.ietf.org; Wed, 06 Jul 2005 12:17:18 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16511 for ; Wed, 6 Jul 2005 12:17:12 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5CC000E24C8; Wed, 6 Jul 2005 18:16:43 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Wed, 6 Jul 2005 18:16:07 +0200 User-Agent: KMail/1.8 References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> In-Reply-To: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507061816.07506.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert Subject: [Hipsec] Preliminary HIP Registration I-D (Was: HIP Registration Extension) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 22 June 2005 15:50, Pekka Nikander wrote: > I read this document again, and in general it looks good to me. > > The language could be improved, now it is a little bit too > "abstract" or fluffy to my taste. Changing some of the terminology > and especially the definitions of terms would make it easier to > read. Also considering advice from draft-iab-model-XX.txt might > help. But content-wise, once a proper security considerations > section is added, I think the document starts to be ready > for a WG LC, though most probably we have to wait for the base spec > to first advance to WG LC. Folks, I have taken in account Pekka's comments, added security considerations and try to clarify the terminology. You will find it here: Please let me know if you have any comments. --julien PS: there is also a htmlwdiff but it's messy cuz I've reorganized the text a lot. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 08 10:35:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtxJ-0007OO-3A; Fri, 08 Jul 2005 10:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtxG-0007N2-KM for hipsec@megatron.ietf.org; Fri, 08 Jul 2005 10:35:50 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07081 for ; Fri, 8 Jul 2005 10:35:47 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5CF002967F6 for hipsec@lists.ietf.org; Fri, 8 Jul 2005 16:35:16 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Fri, 8 Jul 2005 16:35:16 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_k8ozCzjkMQnK3UV" Message-Id: <200507081635.16916.julien.IETF@laposte.net> Cc: Subject: [Hipsec] Fwd: Cross Area Review: draft-ietf-hip-dns-01 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --Boundary-00=_k8ozCzjkMQnK3UV Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit Folks, I forward to the list a cross area review by Olaf Kolkman (dnsext co-chair) of draft-ietf-hip-dns-01. He is proposing some text changes to clarify the resolver behavior. If nobody objects I'll integrate the proposed change before submission. Thanks. --julien --Boundary-00=_k8ozCzjkMQnK3UV Content-Type: message/rfc822; name="forwarded message" Content-Description: "Olaf M. Kolkman" : Re: Cross Area Review: draft-ietf-hip-dns-01 Content-Disposition: inline Return-Path: Original-Recipient: rfc822;julien.IETF@laposte.net Received: from smtp.laposte.net (10.150.9.35) by mx.laposte.net (7.2.060.1) id 42CAC5D100185351 for julien.IETF@laposte.net; Thu, 7 Jul 2005 13:24:01 +0200 Received: from postman.ripe.net (193.0.0.199) by smtp.laposte.net (7.2.056.2) id 42AF4BCD010B25AF for julien.IETF@laposte.net; Thu, 7 Jul 2005 13:24:00 +0200 Received: by postman.ripe.net (Postfix, from userid 4008) id 96DAE242AF; Thu, 7 Jul 2005 13:23:48 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CBFD224539; Thu, 7 Jul 2005 13:23:45 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j67BNjmq008574; Thu, 7 Jul 2005 13:23:45 +0200 Date: Thu, 7 Jul 2005 13:23:45 +0200 From: "Olaf M. Kolkman" To: Pekka Nikander , Julien Laganier Cc: namedroppers@ops.ietf.org Subject: Re: Cross Area Review: draft-ietf-hip-dns-01 Message-Id: <20050707132345.6e2f4f5c.olaf@ripe.net> In-Reply-To: <20050705093248.7613d225.olaf@ripe.net> References: <20050705093248.7613d225.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_50 X-RIPE-Spam-Status: U 0.496110 / -3.3 X-RIPE-Signature: 5a7cc1b5bafac12a3e03f22b96a91f91 X-UID: 27912 X-Length: 47105 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on klee X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Content-Transfer-Encoding: 7bit On Tue, 5 Jul 2005 09:32:48 +0200 olaf wrote to namedroppers: > > Help from this group on reviewing draft-ietf-hip-dns-01 would be highly > appreciated. Hello Julian and Pekka, I've CC-ed namedroppers to avoid to much duplication of effort. I'v read your document and most issues are "style" issues. I have not read the other HIP docs recently and I tried to understand this document as "self-contained", some of my remarks come from that. There are some "real" DNS issues that can be easilly dealth with. I've tried to provide document text wherever I could. Comments are in-line. I've tried to mark my comments starting with on lines with "*" Albeit the comments this is a very readable and complete document, congrats! --Olaf HIP Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab Expires: August 21, 2005 J. Laganier LIP / Sun Microsystems February 20, 2005 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions draft-ietf-hip-dns-01 * (...) Abstract This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers * (...) 1. Introduction This document specifies two new resource records (RRs) for the Domain Name System (DNS) [1], and how to use them with the Host Identity Protocol (HIP) [10]. These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Name or IP addresses of its Rendezvous Servers (RVS) [13]. The current Internet architecture defines two global namespaces: IP addresses and domain names. The Domain Name System provides a two way lookup between these two namespaces. The HIP architecture [11] defines a new third namespace, called the Host Identity Namespace. This namespace is composed of Host Identifiers (HI) of HIP nodes. The Host Identity Tag (HIT) is one representation of an HI. This representation is obtained by taking the output of a secure hash function applied to the HI, truncated to the IPv6 address size. HITs are supposed to be used in the place of IP addresses within most ULPs and applications. +-----+ +-----+ | |-------I1------>| | | I |<------R1-------| R | | |-------I2------>| | | |<------R2-------| | +-----+ +-----+ The Host Identity Protocol [10] allows two HIP nodes to establish together a HIP Association. A HIP association is bound to the nodes HIs rather than to their IP address(es). * STYLE: At first reading this confused me a bit. The diagram above * commes out of the blue and is not refered to. I would rephrase this * a bit. And explain the I1, I2. * Something like: * The Host Identity Protocol [10] allows two HIP nodes to establish * together a HIP Association. A HIP association is bound to the * nodes HIs rather than to their IP address(es). * A HIP node initiates a HIP association through a 4 way handshake * where two parties, the Initiatior and Responder, exchange of I1, * I2, R1 and R2 HIP packets (see section 5.3 of [10]) * * * +-----+ +-----+ * | |-------I1------>| | * | I |<------R1-------| R | * | |-------I2------>| | * | |<------R2-------| | * +-----+ +-----+ Although a HIP node can initiate HIP communication "opportunistically", i.e., without a priori knowledge of its peer's HI, doing so exposes both endpoints to Man-in-the-Middle attacks on the HIP handshake and its cryptographic protocol. Hence, there is a desire to gain knowledge of peers' HI before applications and ULPs initiate communication. Because many applications use the Domain Name System [1] to name nodes, DNSSEC [3] is a straightforward way to * STYLE: I would not say "DNSSEC" is a straightforward way. * DNS is a straightforward way to provision nodes provision nodes with * the HIP informations (i.e. HI and possibly RVS) of nodes named in * the DNS tree, without introducing or relying on an additional piece * of infrastructure. Note that without DNSSEC[3] the * Man-in-the-Middle attack to privide a false HI has moved from the * HIP handshake to the DNS name resolution, also see . Nikander & Laganier Expires August 21, 2005 [Page 3] Internet-Draft HIP DNS Extensions February 2005 * * STYLE: move the diagram down a bit * The proposed HIP multi-homing mechanisms [12] allow a node to dynamically change its set of underlying IP addresses while maintaining IPsec SA and transport layer session survivability. The HIP rendezvous extensions [13] proposal allows a HIP node to maintain HIP reachability while it is changing its current location (the node IP address(es)). This rendezvous service is provided by a third party, the node's Rendezvous Server (RVS). * moved to here: +-----+ +--I1--->| RVS |---I1--+ | +-----+ | | v +-----+ +-----+ | |<------R1-------| | | I |-------I2------>| R | | |<------R2-------| | +-----+ +-----+ An initiator (I) willing to establish a HIP association with a responder (R) would typically initiate a HIP exchange by sending an I1 towards the RVS IP address rather than towards the responder IP address. Then, the RVS, noticing that the receiver HIT is not its own, but the HIT of a HIP node registered for the rendezvous Service, would relay the I1 to the responder. Typically the responder would then complete the exchange without further assistance from the RVS by sending an R1 directly to the initiator IP address. Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP address(es). This step occurs prior to communication with the remote host, and relies on a DNS lookup. With HIP, IP addresses are expected to be used mostly for on-the-wire communication between end hosts, while most ULPs and applications uses HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a new HIPHI (HIP HI) resource record. Upon query by an application or ULP for a FQDN -> IP lookup, the resolver would then additionally perform an FQDN -> HI lookup, and use it to construct the resulting HI -> IP mapping (which is internal to the HIP layer). The HIP layer uses the HI -> IP mapping to translate HIs and their local representations (HITs, IPv4 and IPv6-compatible LSIs) into IP addresses and vice versa. This draft introduces the following new DNS Resource Records: - HIPHI, for storing Host Identifiers and Host Identity Tags - HIPRVS, for storing rendezvous server information Nikander & Laganier Expires August 21, 2005 [Page 4] Internet-Draft HIP DNS Extensions February 2005 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [4]. Nikander & Laganier Expires August 21, 2005 [Page 5] Internet-Draft HIP DNS Extensions February 2005 3. Usage Scenarios In this section, we briefly introduce a number of usage scenarios where the DNS is useful with the Host Identity Protocol. With HIP, most application and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for fail-over, redundancy, mobility, or renumbering, in a manner which is transparent to most ULPs and applications (because they are bound to HIs, hence they are agnostic to these IP address changes). In these situations, a node wishing to be reachable by reference to its FQDN should store the following informations in the DNS: * STYLE: allready introduce the RRs * o A set of IP address(es) through A and AAAA RRs * o A Host Identity (HI) and/or Host Identity Tag (HIT) through HIPHI * RRs * o An IP address or DNS name of its Rendezvous Server(s) (RVS) * through HIPRVS RRs When a HIP node wants to initiate a communication with another HIP node, it first needs to perform a HIP base exchange to set-up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without a priori knowledge of the responder's HI, by doing so both nodes knowingly risk man-in-the-middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the initiator first obtain the HI of the responder, and then initiate the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a new HIPHI RR is introduced. When a HIP node is frequently changing its IP address(es), the dynamic DNS update latency may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP architecture introduces Rendezvous Servers (RVS). A HIP host uses a Rendezvous Server as a Rendezvous point, to maintain reachability with possible HIP initiators. Such a HIP node would publish in the DNS its RVS IP address or DNS name in a HIPRVS RR, while keeping its RVS up-to-date with its current set of IP addresses. * STYLE: I had to read this a couple of times. And what could be useful in * this stage of the document is to discribe the "query" behaviour for * the Initiator. * * * I'd replace the following paragraph Then, when some other node wants to initiate a HIP exchange with such a responder, it retrieves the RVS IP address by looking up a HIPRVS RR at the FQDN of the responder, and sends an I1 to this IP address. The I1 will then be relayed by the RVS to the responder, which will then complete the HIP exchange, either directly or via the RVS [13]. * by [and I hope I have correcty understood this]: * When an some HIP node wants to initiate a HIP exchange with a * responder it will perform a number of DNS lookups. * First the initiator will need to query for an A or AAAA record at * the responders FQDN. * * If the query for the A and/or AAAA was responded to with a DNS * answer with RCOCE=3 (Name Error) than the responder's information * is not present in the DNS and further queries SHOULD not be made. * * In case the query for the address records returned a a DNS answer * with RCODE=0 (No Error) the initiator sends out two queries. One * for the HIPHI and one for the HIPRSV type at the responders FQDN. * * Depending on the combinations of answer the situations described in * 3.1, 3.2 and 3.3 can occur. * [See text suggestions there too] * [From the diagrams I get the impression that you would like to * receive all this information through one query. That is not * possible. The "ANY" query is not suitable. I can explain if were not * aware of this] Note that storing HIP RR information in the DNS at a FQDN which is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes. Nikander & Laganier Expires August 21, 2005 [Page 6] Internet-Draft HIP DNS Extensions February 2005 3.1 Simple static singly homed end-host * Moved the paragraph up A HIP node (R) with a single static network attachment, wishing to be reachable by reference to its FQDN (www.example.com), would store in the DNS, in addition to its IP address(es) (IP-R), its Host Identity (HI-R) in a HIPHI resource record. * The initiator would issue the following queries * * QNAME=www.example.com, QTYPE=A * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and an empty answer section. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +-------------------------------->| | | | DNS | | +-------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [A IP-R ] | | [HIPHI 10 3 2 HIT-R HI-R] | v +-----+ +-----+ | |--------------I1------------->| | | I |<-------------R1--------------| R | | |--------------I2------------->| | | |<-------------R2--------------| | +-----+ +-----+ Nikander & Laganier Expires August 21, 2005 [Page 7] Internet-Draft HIP DNS Extensions February 2005 3.2 Mobile end-host *Moved: A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R) in a HIPHI RR, and the IP address(es) of its Rendezvous Server(s) (IP-RVS) in HIPRVS resource record(s). The mobile HIP node also need to notify its Rendezvous Servers of any change in its set of IP address(es). * The initiator would go through the following DNS queries/answers: * * QNAME=www.example.com, QTYPE=A * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPRSV RRs containing * an the FQDN or IP address of the RSV. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +--------------------------------->| | | | DNS | | +--------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [HIPRVS 1 2 IP-RVS ] | | [HIPHI 10 3 2 HIT-R HI-R] | | | | +-----+ | | +------I1----->| RVS |-----I1------+ | | | +-----+ | | | | | | | | | | v | v +-----+ +-----+ | |<---------------R1------------| | | I |----------------I2----------->| R | | |<---------------R2------------| | +-----+ +-----+ A host wanting to reach this mobile host would then send an I1 to one of its RVS. Following, the RVS will relay the I1 up to the mobile node, which will complete the HIP exchange. Nikander & Laganier Expires August 21, 2005 [Page 8] Internet-Draft HIP DNS Extensions February 2005 3.3 Mixed Scenario * Moved up A HIP node might be configured with more than one IP address (multi-homed), or Rendezvous Server (multi-reachable). In these cases, it is possible that the DNS returns multiples A or AAAA RRs, * s/multiples/multiple as well as HIPRVS containing one or multiple Rendezvous Servers. In addition to its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host would store in the DNS its HI (HI-R) in a HIPHI RR, and possibly the IP address(es) of its RVS(s) (IP-RVS1, IP-RVS2) in HIPRVS RRs. * For example: * QNAME=www.example.com, QTYPE=A (QCLASS=IN is assumed and * ommitted from the examples) * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPRSV RRs containing * an the FQDN or IP address of the RSV. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +--------------------------------->| | | | DNS | | +--------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [A IP-R1 ] | | [A IP-R2 ] | | [HIPRVS 1 2 IP-RVS1 ] | | [HIPRVS 1 2 IP-RVS2 ] | | [HIPHI 10 3 2 HIT-R HI-R] | | | | +------+ | | +-----I1----->| RVS1 |------I1------+ | | | +------+ | | v | v +-----+ +-----+ | |---------------I1------------->| | | | | | | I |<--------------R1--------------| R | | |---------------I2------------->| | | |<--------------R2--------------| | +-----+ +-----+ | ^ | +------+ | +-----I1----->| RVS2 |------I1------+ +------+ Nikander & Laganier Expires August 21, 2005 [Page 9] Internet-Draft HIP DNS Extensions February 2005 4. Overview of using the DNS with HIP 4.1 Storing HI and HIT in DNS Any conforming implementation may store Host Identifiers in a DNS HIPHI RDATA format. An implementation may also store a HIT along with its associated HI. If a particular form of an HI or HIT does not already have a specified RDATA format, a new RDATA-like format SHOULD be defined for the HI or HIT. 4.1.1 Different types of HITs * It would be good to indicate where those HIT types are described that would * help implementors: * Currently [REF] defines two types of HITs more HIT types may be * defined in the future; HIT types are maintained in the IANA registry * called "foo" There are _currently_ two types of HITs. HITs of the first type consists just of the least significant bits of the hash of the public key. HITs of the second type consist of a binary prefix Host Assigning Authority (HAA) field, and only the last bits come from a hash of the Host Identity. This latter format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in directories like DNS. * this confuses me a bit... "a resolution mechanism for these names in * directories like DNS". I read it as that those names are mapped into some * domain, like IP5 into in-addr.arpa. But I do not think that is what you mean. * I'd remove the last sentence. * * If I am not mistaken than I think that the next sentence could be less * ambiguously phrased as: * Note that the format how HITs are stored in the HIPHI RRs may be (...) Note that the format how HITs are stored in the DNS may be different form the format actually used in protocols, the HIP base exchange [10] included. This is because the DNS RR explicitly contains the HIT type and algorithm, while some protocols may prefer to use a prefix to indicate the HIT type. The implementations are expected to use the actual HI when comparing Host Identities. 4.1.1.1 Host Assigning Authority (HAA) field The 64 bits of HAA supports two levels of delegation. The first is a registered assigning authority (RAA). The second is a registered identity (RI, commonly a company). The RAA is 24 bits with values assign sequentially by ICANN. The RI is 40 bits, also assigned sequentially but by the RAA. * 4.1.1.2 Storing HAA in HITHI Resource Records. 4.1.1.2 Storing HAA in DNS Any conforming implementation may store a domain name Host Assigning Authority (HAA) in a DNS HIPHI RDATA format. A HAA MUST be stored like a Type 2 HIT, while the least significant bits of the HIT extracted from the HI hash output are set to zero, the Host Identity Length is set zero, and the Host Identity field is omitted. If a particular form of a HAA does not already have an associated HIT specified RDATA format, a new RDATA-like format SHOULD be defined for the HIT/HAA. Nikander & Laganier Expires August 21, 2005 [Page 10] Internet-Draft HIP DNS Extensions February 2005 4.1.1.3 HI and HIT verification Upon return of a HIPHI RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in the HIP architecture [11], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g. table lookup). 4.2 Storing Rendezvous Servers in the DNS The HIP Rendezvous server (HIPRVS) resource record indicates an address or a domain name of a RendezVous Server, towards which a HIP I1 packet might be sent to trigger the establishment of an association with the entity named by this resource record [13]. An RVS receiving such an I1 would then relay it to the appropriate responder (the owner of the I1 receiver HIT). The responder will then complete the exchange with the initiator, typically without ongoing help from the RVS. Any conforming implementation may store Rendezvous Server's IP address(es) or DNS name in a DNS HIPRVS RDATA format. If a particular form of a RVS reference does not already have a specified RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 4.3 Initiating connections based on DNS names On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever an Upper Layer Protocol attempt to communicate with an entity and the DNS lookup returns HIPHI and/or HIPRVS resource records. If a DNS lookup returns one or more HIPRVS RRs and no A nor AAAA RRs, the afore mentioned HIP exchange SHOULD be initiated towards one of these RVS [10]. Since some hosts may choose not to have HIPHI information in DNS, hosts MAY implement support for opportunistic HIP. Nikander & Laganier Expires August 21, 2005 [Page 11] Internet-Draft HIP DNS Extensions February 2005 5. Storage Format 5.1 HIPHI RDATA format The RDATA for a HIPHI RR consists of a HIT type, an algorithm type, a HIT, and a public key. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HIT type | HIT algorithm | PK algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 5.1.1 HIT type format The HIT type field indicates the Host Identity Tag (HIT) type and the implied HIT format. The following values are defined: 0 No HIT is present 1 A Type 1 HIT is present 2 A Type 2 HIT is present 3-6 Unassigned 7 A HAA is present 5.1.2 HIT algorithm format The HIT algorithm indicates the hash algorithm used to generate the Host Identity Tag (HIT) from the HI. The following values are defined: 0 Reserved 1 SHA1 2-255 Unassigned 5.1.3 PK algorithm format The PK algorithm field indicates the public key cryptographic Nikander & Laganier Expires August 21, 2005 [Page 12] Internet-Draft HIP DNS Extensions February 2005 algorithm and the implied public key field format. This document reuse the values defined for the 'algorithm type' of the IPSECKEY RR [14] 'gateway type' field. The presently defined values are given only informally: 1 A DSA key is present, in the format defined in RFC2536 [5]. 2 A RSA key is present, in the format defined in RFC3110 [6]. 5.1.4 HIT format There's currently two types of HITs, and a single type of HAA. Both of them are stored in network byte order within a self-describing variable length wire-encoded (as per Section 3.3 of [2]): o A *Type 1* HIT: least significant bits of the hash (e.g., SHA1) of the public key (Host Identity), which is possibly following in the HIPHI RR. o A *Type 2* HIT: binary prefix (HAA) concatenated with a the least significant bits of the hash (e.g., SHA1) of the public key (Host Identity), which is possibly following in the HIPHI RR. o A HAA: binary prefix (HAA) concatenated with 0, up to the associated HIT length. 5.1.5 Public key format Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [14] (which in turns contains the algorithm-specific portion of the KEY RR RDATA, all of the KEY RR DATA after the first four octets, corresponding to the same portion of the KEY RR that must be specified by documents that define a DNSSEC algorithm). In the future, if a new algorithm is to be used both by IPSECKEY RR and HIPHI RR, it would probably use the same public key encodings for both RRs. Unless specified otherwise, the HIPHI public key field would use the same public key format as the IPSECKEY RR RDATA for the corresponding algorithm. The DSA key format is defined in RFC2536 [5]. The RSA key format is defined in RFC3110 [6] and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [14] specification. 5.2 HIPRVS RDATA format The RDATA for a HIPRVS RR consists of a preference value, a Nikander & Laganier Expires August 21, 2005 [Page 13] Internet-Draft HIP DNS Extensions February 2005 Rendezvous server type and either one or more Rendezvous server address, or one Rendezvous server domain name. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preference | type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rendezvous server | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.1 Preference format * This is problematic. If you require the server to return data based * on preference than you expect the server to understand and parse all * the RDATA before shuffing it on the wire. That sort of special * processing is expensive. It is the DNS client that should do the * work, that scales better too. * I reworded the paragraph a bit: This is an unsigned 8-bit value, used to specify the preference given to the RSV in the HIPRSV RR amongst others at the same owner. RSVs with lower values are preferred. If there is a tie within some RR subset, the initiating HIP host should pick one of the RSV randomly from the set of RRs, such that the requester load is fairly balanced amongst all RSVs of the set. 5.2.2 Rendezvous server type format The Rendezvous server type indicates the format of the information stored in the Rendezvous server field. This document reuses the type values for the 'gateway type' field of the IPSECKEY RR [14]. The presently defined values are given only informally: 1. One or more 4-byte IPv4 address(es) in network byte order are present. 2. One or more 16-byte IPv6 address(es) in network byte order are present. 3. One or more variable length wire-encoded domain names as described in section 3.3 of RFC1035 [2]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. 5.2.3 Rendezvous server format The Rendezvous server field indicates one or more Rendezvous Server(s) IP address(es), or domain name(s). A HIP I1 packet sent to any of these RVS would reach the entity named by this resource record. This document reuses the format used for the 'gateway' field of the IPSECKEY RR [14], but allows to concatenate several IP (v4 or v6) Nikander & Laganier Expires August 21, 2005 [Page 14] Internet-Draft HIP DNS Extensions February 2005 addresses. The presently defined formats for the data portion of the Rendezvous server field are given only informally: o One or more 32-bit IPv4 address(es) in network byte order. o One or more 128-bit IPv6 address(es) in network byte order. o One or more variable length wire-encoded domain names as described in section 3.3 of RFC1035 [2]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. Nikander & Laganier Expires August 21, 2005 [Page 15] Internet-Draft HIP DNS Extensions February 2005 6. Presentation Format This section specifies the representation of the HIPHI and HIPRVS RR in a zone data master file. 6.1 HIPHI Representation The HIT Type, HIT algorithm, PK algorithm, and Public Key are REQUIRED. The HIT field is OPTIONAL. * I think that is not correctly phrased. It either contains Base64 data * or a "." but it is always there. The HIT Type, HIT algorithm, and PK algorithm are represented as unsigned integers. The HIT field is represented as the Base16 encoding [8] (a.k.a. hex or hexadecimal) of the public key. If no HIT is to be indicated, then the HIT algorithm MUST be zero and the HIT field must be ".". * I'd add '(a single dot character)' there will always be folk that * read such spec as 'a double-quote, a dot and a double quote' (I've * been there and I've done it, I'm affraid to confess :-) The Public Key field is represented as the Base64 encoding [8] of the public key. The complete representation of the HPIHI record is: IN HIPHI ( hit-type hit-algorithm pk-algorithm base16-encoded-hit base64-encoded-public-key ) * Since the HIT is rather short and the public key can become a beast. I'd say * whitespace is not allowed in the base16-encoded-hit while whitespace * is ignored in the base64-encoded-public-key 6.2 HIPRVS Representation The Preference and RVS Type fields are REQUIRED. At least one RVS field MUST be present. The HIT Type, HIT algorithm, and PK algorithm are represented as unsigned integers. The RVS field is represented by one or more: o IPv4 dotted decimal address(es) o IPv6 colon hex address(es) o uncompressed domain name(s) The complete representation of the HPIRVS record is: IN HIPRVS ( preference rendezvous-server-type rendezvous-server[1] ... rendezvous-server[n] ) Nikander & Laganier Expires August 21, 2005 [Page 16] Internet-Draft HIP DNS Extensions February 2005 6.3 Examples Example of a node with a HI but no HIT: www.example.com IN HIPHI ( 0 1 2 . AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) * With the ignore whitespace clause above you can actually sattisfy the * 72 characters ID criteria :-) * * www.example.com IN HIPHI ( 0 1 2 * . * AB3NzaC1kc3MAAACBAOBhKn * TCPOuFBzZQX/N3O9dm9P9iv * UIMoId== ) * Example of a node with a HI and a HIT: www.example.com IN HIPHI ( 1 1 2 120cf10ea842e0ba53320f1fe0ba5d3a3 AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) Example of a node with an IPv6 RVS: www.example.com IN HIPRVS ( 10 2 2001:0db8:0200:1:20c:f1ff:fe0b:a533 ) Example of a node with three IPv4 RVS: www.example.com IN HIPRVS ( 10 1 192.0.2.2 192.0.99.2 192.0.199.2) Example of a node with two named RVS: www.example.com IN HIPRVS ( 10 3 rvs.uk.example.com rvs.us.example.com ) Nikander & Laganier Expires August 21, 2005 [Page 17] Internet-Draft HIP DNS Extensions February 2005 7. Retrieving Multiple HITs and IPs from the DNS If a host receives multiple HITs in a response to a DNS query, those HITs MUST be considered to denote a single service, and be semantically equivalent from that point of view. When initiating a base exchange with the denoted service, the host SHOULD be prepared to accept any of HITs as the peer's identity. A host MAY implement this by using the opportunistic mode (destination HIT null in I1), or by sending multiple I1s, if needed. In particular, if a host receives multiple HITs and multiple IP addresses in response to a DNS query, the host cannot know how the HITs are reachable at the listed IP addresses. The mapping may be any, i.e., all HITs may be reachable at all of the listed IP addresses, some of the HITs may be reachable at some of the IP addresses, or there may even be one-to-one mapping between the HITs and IP addresses. In general, the host cannot know the mapping and MUST NOT expect any particular mapping. It is RECOMMENDED that if a host receives multiple HITs, the host SHOULD first try to initiate the base exchange by using the opportunistic mode. If the returned HIT does not match with any of the expected HITs, the host SHOULD retry by sending further I1s, one at time, trying out all of the listed HITs. If the host receives an R1 for any of the I1s, the host SHOULD continue to use the successful IP address until an R1 with a listed HIT is received, or the host has tried all HITs, and try the other IP addresses only after that. A host MAY also send multiple I1s in parallel, but sending such I1s MUST be rate limited to avoid flooding (as per Section 8.4.1 of [10]). Nikander & Laganier Expires August 21, 2005 [Page 18] Internet-Draft HIP DNS Extensions February 2005 8. Transition mechanisms * This paragraph only makes sense as long as there is no type * code. As soon as IANA has assigned type codes you can use the * RFC3597 notation if your server does not provide for a parser of * the HIPHI and HIPRVS presentation format. * * When this document andvances and you have a type code you can do without * this paragraph. I'd take it out. During a transition period, to allows to store the HIP informations of a node in a DNS server which does not support the HIPHI and HIPRVS RRs, A and AAAA RRs MAY be overloaded. A HIT would typically be stored in a AAAA RR and a RVS in either a A or AAAA RR. If such a situation occurs, the overloaded RRs MUST be returned as the last items of the returned RRs set (A or AAAA), to avoid as most as possible conflicts with non-HIP IPv6 nodes. Nikander & Laganier Expires August 21, 2005 [Page 19] Internet-Draft HIP DNS Extensions February 2005 9. Security Considerations Though the security considerations of the HIP DNS extensions still need to be more investigated and documented, this section contains a description of the known threats involved with the usage of the HIP DNS extensions. In a manner similar to the IPSECKEY RR [14], the HIP DNS Extensions allows to provision two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extensions introduce the same kind of threats that IPSECKEY does, plus threats caused by the possibility given to a HIP node to initiate or accept a HIP exchange using "Opportunistic" or "Unpublished Initiator HI" modes. A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted party trough a secure channel insuring proper data integrity of the RRs. DNSSEC [3] provides such a secure channel. In the absence of a proper secure channel, both parties are vulnerable to MitM and DoS attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections. 9.1 Attacker tampering with an unsecure HIPHI RR The HIPHI RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIPHI RR (e.g., using DNS spoofing) is able to mount Man-in-the-Middle attacks on the cryptographic core of the eventual HIP exchange (responder's HIPHI and HIPRVS rewritten by the attacker). 9.2 Attacker tampering with an unsecure HIPRVS RR The HIPRVS RR contains a destination IP address where the named peer is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR [13] ). Thus, an attacker able to tamper with this RRs is able to redirect I1 packets sent to the named peer to a chosen IP address, for DoS or MitM attacks. Note that this kind of attacks are not specific to HIP and exist independently to whether or not HIP and the HIPRVS RR are used. Such an attacker might tamper with A and AAAA RRs as well. An attacker might obviously use these two attacks in conjunction: It will replace the responder's HI and RVS IP address by its owns in a spoofed DNS packet sent to the initiator HI, then redirect all Nikander & Laganier Expires August 21, 2005 [Page 20] Internet-Draft HIP DNS Extensions February 2005 exchanged packets through him and mount a MitM on HIP. In this case HIP won't provide confidentiality nor initiator HI protection from eavesdroppers. 9.3 Opportunistic HIP A HIP initiator may not be aware of its peer's HI, and/or its HIT (e.g., because the DNS does not contains HIP material, or the resolver isn't HIP-enabled), and attempt an opportunistic HIP exchange towards its known IP address, filling the responder HIT field with zeros in the I1 header. Such an initiator is vulnerable to a MitM attack because it can't validate the HI and HIT contained in a replied R1. Hence, an implementation MAY choose not to use opportunistic mode. 9.4 Unpublished Initiator HI A HIP initiator may choose to use an unpublished HI, which is not stored in the DNS by means of a HIPHI RR. A responder associating with such an initiator knowingly risks a MitM attack because it cannot validate the initiator's HI. Hence, an implementation MAY choose not to use unpublished mode. 9.5 Hash and HITs Collisions As many cryptographic algorithm, some secure hashes (e.g. SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with a reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from DNS, but SHOULD rather use HI-based authentication. * I'd add a paragraph like below. I am not a very strong security * considerations writer but I think it'l do. * 9.6 DNSSEC * * In absence of DNSSEC the HIPHI and HIPRVS RRs are subject to the * threads in rfc3833. Nikander & Laganier Expires August 21, 2005 [Page 21] Internet-Draft HIP DNS Extensions February 2005 10. IANA Considerations IANA needs to allocate two new RR type code for HIPHI and HIPRVS from the standard RR type space. IANA needs to open a new registry for the HIPHI RR HIT type. Defined types are: 0 No HIT is present 1 A Type 1 HIT is present 2 A Type 2 HIT is present 3-6 Unassigned 7 A HAA is present Adding new reservations requires IETF consensus RFC2434 [16]. IANA needs to open a new registry for the HIPHI RR HIT algorithm. Defined types are: 0 Reserved 1 SHA1 2-255 Unassigned Adding new reservations requires IETF consensus RFC2434 [16]. IANA does not need to open a new registry for the HIPHI RR type for public key algorithms because the HIPHI RR reuse 'algorithms types' defined for the IPSECKEY RR [14]. The presently defined numbers are given here only informally: 0 is reserved 1 is RSA 2 is DSA IANA does not need to open a new registry for the HIPRVS RR Rendezvous server type because the HIPHI RR reuse the 'gateway types' defined for the IPSECKEY RR [14]. The presently defined numbers are given here only informally: 0 is reserved 1 is IPv4 2 is IPv6 3 is a wire-encoded uncompressed domain name *** * No further comments... --Boundary-00=_k8ozCzjkMQnK3UV Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --Boundary-00=_k8ozCzjkMQnK3UV-- From hipsec-bounces@lists.ietf.org Fri Jul 08 14:28:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxZw-0001lj-6H; Fri, 08 Jul 2005 14:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxZt-0001XH-Ln for hipsec@megatron.ietf.org; Fri, 08 Jul 2005 14:27:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03986 for ; Fri, 8 Jul 2005 14:27:56 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqy1G-0000qg-Il for hipsec@ietf.org; Fri, 08 Jul 2005 14:56:19 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA06502; Fri, 8 Jul 2005 11:27:21 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j68IRTs13166; Fri, 8 Jul 2005 11:27:29 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 11:27:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Fwd: Cross Area Review: draft-ietf-hip-dns-01 Date: Fri, 8 Jul 2005 11:27:28 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095AF9@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Fwd: Cross Area Review: draft-ietf-hip-dns-01 Thread-Index: AcWDzDrBGiDbq2q5T6el9XRjVcYcTQAHgc+g From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 08 Jul 2005 18:27:28.0625 (UTC) FILETIME=[B2430610:01C583EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Julien, I had a question on the below suggested change: > * I'd replace the following paragraph=20 > Then, when some other node wants to initiate a HIP=20 > exchange with such > a responder, it retrieves the RVS IP address by looking up a HIPRVS > RR at the FQDN of the responder, and sends an I1 to this=20 > IP address. > The I1 will then be relayed by the RVS to the responder, which will > then complete the HIP exchange, either directly or via the=20 > RVS [13]. >=20 > * by [and I hope I have correcty understood this]: > * When an some HIP node wants to initiate a HIP exchange with a > * responder it will perform a number of DNS lookups.=20 > * First the initiator will need to query for an A or AAAA record at > * the responders FQDN. > * =20 > * If the query for the A and/or AAAA was responded to with a DNS > * answer with RCOCE=3D3 (Name Error) than the responder's = information > * is not present in the DNS and further queries SHOULD not be made. > * > * In case the query for the address records returned a a DNS answer > * with RCODE=3D0 (No Error) the initiator sends out two queries. = One > * for the HIPHI and one for the HIPRSV type at the responders FQDN. > *=20 > * Depending on the combinations of answer the situations=20 > described in=20 > * 3.1, 3.2 and 3.3 can occur.=20 I think you were proposing to fetch A, HIPHI, and HIPRSV all at the same time (or else leaving the fetching order ambiguous), while Olaf suggests that you fetch them all individually, and further, that you fetch the A record first, then only if that succeeds, then you fetch the HIPRSV record. But what if there is no A record and only HIPHI and HIPRSV? Also, do we want to specify when (in what order) records should be fetched? Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 11 03:40:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsuI-0005VG-Hd; Mon, 11 Jul 2005 03:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsuH-0005V9-G0 for hipsec@megatron.ietf.org; Mon, 11 Jul 2005 03:40:49 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19227 for ; Mon, 11 Jul 2005 03:40:47 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5D100453EB2; Mon, 11 Jul 2005 09:40:17 +0200 From: Julien Laganier To: hipsec@ietf.org, "Henderson, Thomas R" Subject: Re: [Hipsec] Fwd: Cross Area Review: draft-ietf-hip-dns-01 Date: Mon, 11 Jul 2005 09:40:22 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D095AF9@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095AF9@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507110940.22453.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Friday 08 July 2005 20:27, Henderson, Thomas R wrote: > Julien, I had a question on the below suggested change: (...) > > When an some HIP node wants to initiate a HIP exchange with a > > responder it will perform a number of DNS lookups. First the > > initiator will need to query for an A or AAAA record at the > > responders FQDN. > > > > If the query for the A and/or AAAA was responded to with a DNS > > answer with RCOCE=3 (Name Error) than the responder's information > > is not present in the DNS and further queries SHOULD not be made. > > > > In case the query for the address records returned a a DNS answer > > with RCODE=0 (No Error) the initiator sends out two queries. One > > for the HIPHI and one for the HIPRSV type at the responders FQDN. > > > > Depending on the combinations of answer the situations described > > in 3.1, 3.2 and 3.3 can occur. > > I think you were proposing to fetch A, HIPHI, and HIPRSV all at the > same time (or else leaving the fetching order ambiguous), I was proposing to fetch A, AAAA, HIPHI, and HIPRVS in parallel, without specifying a particular order. You cannot fetch all of them in the same query with QTYPE=*, because then authoritative answers are not available [RFC1035]. So you have to make individuals requests with A, AAAA, HIPHI, and HIPRVS. My present understanding is that's still leaves us with the choice of doing them in parallel or sequentially, or a mix of both... the choice seems to be left to the resolver implementor, but I am still waiting for a clarification from Olaf on that specific point. The problem with parallel queries is that if the domain name does not exist, 4 queries would be issued for nothing. But see below... > Olaf suggests that you fetch them all individually, and further, > that you fetch the A record first, then only if that succeeds, then > you fetch the HIPRSV record. But what if there is no A record and > only HIPHI and HIPRSV? Also, do we want to specify when (in what > order) records should be fetched? What Olaf wrote is that if RCODE=3 (Name Error) occurs, that means that the domain name referenced in the query does not exist [RFC1035]. So if there is no A record but HIPHI and HIPRVS, when queried for QTYPE=A, the DNS server would answer with RCODE=0 and no A RR. Then the resolver knows the domain exist and can issue further HIPRVS queries. I am not sure that we want to specify an order. From what I observed with the related A vs AAAA query, the resolver on BSD (I guess it's based on ISC's BIND) always query A, then AAAA, sequentially, i.e. the AAAA query is not issued before the A query answer is received. This makes sense because if the domain name does not exist two queries would be issued from nothing. So back to Olaf's proposed: It's a mix of sequential and parallel queries. First you only issue a query for one of the RRs (A in his example), and if the domain name exists, then you issue parallel queries with the remaining RRs (AAAA, HIPHI, and HIPRVS). It is the most efficient way of querying multiple RRs, without wasting resources in case the domain name is non-existent. Concerning Olaf's suggested change, when I get more information from him, perhaps it would alsoo be good to explain the rationale for querying for an A RR, then the remaining RRs. -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 14 15:52:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9kp-0008VO-7O; Thu, 14 Jul 2005 15:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9is-0007iM-61; Thu, 14 Jul 2005 15:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13750; Thu, 14 Jul 2005 15:50:15 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABJ-0008Qk-Uq; Thu, 14 Jul 2005 16:19:45 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9id-0006EW-9d; Thu, 14 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extension Author(s) : J. Laganier, L. Eggert Filename : draft-ietf-hip-rvs-03.txt Pages : 15 Date : 2005-7-14 This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-rvs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-rvs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-14121011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-rvs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-rvs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14121011.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Thu Jul 14 15:52:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9lI-0000JJ-Gh; Thu, 14 Jul 2005 15:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9iu-0007k5-UO; Thu, 14 Jul 2005 15:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13787; Thu, 14 Jul 2005 15:50:18 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABL-0008Rp-Ha; Thu, 14 Jul 2005 16:19:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ie-0006IG-Lr; Thu, 14 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-02.txt Pages : 28 Date : 2005-7-14 This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-dns-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-dns-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-14153241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14153241.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Fri Jul 15 02:52:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtK43-00078Z-EZ; Fri, 15 Jul 2005 02:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNJH-0006St-Md; Wed, 06 Jul 2005 23:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329; Wed, 6 Jul 2005 23:44:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNkO-0003bt-Gl; Thu, 07 Jul 2005 00:12:24 -0400 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 15 Jul 2005 02:52:50 -0400 Cc: Subject: [Hipsec] NEW!! Internet Area Mailing List X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jul 16 16:03:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtssT-0004cq-9f; Sat, 16 Jul 2005 16:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtssR-0004cT-S3 for hipsec@megatron.ietf.org; Sat, 16 Jul 2005 16:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28749 for ; Sat, 16 Jul 2005 16:03:09 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DttLW-0007b6-HF for hipsec@ietf.org; Sat, 16 Jul 2005 16:33:15 -0400 Received: from [10.59.1.21] (adsl-69-224-26-237.dsl.pltn13.pacbell.net [69.224.26.237]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 16 Jul 2005 23:02:57 +0300 id 0008BDB0.42D967F2.000015E2 Message-ID: <42D967D2.2090403@cs.helsinki.fi> Date: Sat, 16 Jul 2005 23:02:26 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Mime-Version: 1.0 To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-arch-02.txt References: <200501112034.PAA24255@ietf.org> In-Reply-To: <200501112034.PAA24255@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0123156023==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0123156023== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-5602-1121544179-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-5602-1121544179-0001-2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Apparently the publication and expiration dates for this draft should be in 2005 and not in 2004? I was a bit confused with -00 draft having a more recent date than this one. What is the current status, did you get IESG comments already? Are you submitting a new version since this one is about to expire. Andrei Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol Architecture > Author(s) : R. Moskowitz, P. Nikander > Filename : draft-ietf-hip-arch-02.txt > Pages : 24 > Date : 2005-1-11 > >This memo describes a snapshot of the reasoning behind a proposed new > namespace, the Host Identity namespace, and a new protocol layer, the > Host Identity Protocol, between the internetworking and transport > layers. Herein are presented the basics of the current namespaces, > their strengths and weaknesses, and how a new namespace will add > completeness to them. The roles of this new namespace in the > protocols are defined. The memo describes the thinking of the > authors as of Fall 2003. The architecture may have evolved since. > This document represents one stable point in that evolution of > understanding. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-hip-arch-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-hip-arch-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > --=_courier-5602-1121544179-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC 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/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDcxNjIwMDIyNlowIwYJ KoZIhvcNAQkEMRYEFKR0eS8lDeEcbzHZMwSS9Wj9PLPwMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBALfTaE5OOEr2mYcifQkTo7VJ98H9XmCDHDdEw64rHmOSmr5o5oeOtqLs9lsA8KRgCpkP nijht2k/Q7weUrx426zkvd5g6mQFZEfWPbWuthkuZHhLBiceq2bKYDtNSKe1ZfNflcYaF5lh 2JHo95T6ViGkPCRycEgLK7sBPzIgYSid7G/u9udrTcLiVOIw9pSS0BBxan8Y91O+3NGKycEC IcuCm5RXFCzwLNd419MaxSKOIr9lCg+eLoniJpUII2w+YgzWriJz+4Bd4lcYq856vw67yMcf yXVNAcxCYj8sQ9VnohlLWBFn/wQqNyOX+gzsFIUg7TlPaGmmJk9GY63bgEcAAAAAAAA= --=_courier-5602-1121544179-0001-2-- --===============0123156023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0123156023==-- From hipsec-bounces@lists.ietf.org Sat Jul 16 17:48:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuW6-0007z7-Gh; Sat, 16 Jul 2005 17:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuW3-0007yu-1a for hipsec@megatron.ietf.org; Sat, 16 Jul 2005 17:48:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03362 for ; Sat, 16 Jul 2005 17:48:08 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtuz8-00038e-NI for hipsec@ietf.org; Sat, 16 Jul 2005 18:18:15 -0400 Received: from [10.59.1.21] (adsl-69-224-26-237.dsl.pltn13.pacbell.net [69.224.26.237]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sun, 17 Jul 2005 00:48:01 +0300 id 0009010C.42D98091.00001B7B Message-ID: <42D98070.7010602@cs.helsinki.fi> Date: Sun, 17 Jul 2005 00:47:28 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Mime-Version: 1.0 To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-dns-02.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1343363090==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1343363090== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-7035-1121550482-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-7035-1121550482-0001-2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julien, Thanks for updating the draft. Below are minor editorial comments that should be checked. I'm not sure if keywords MAY, MUST, etc. can be used in non-standard track RFCs. Andrei "rendezvous Service" "applications uses" "Man-in-the-Middle attack evocated before has moved" - difficult to parse "following informations" "at the responders FQDN" "ommitted" "node also need" "e.g" "different form the format" "assign sequentially" "RendezVous" "On a HIP node" "document reuse" "one or more Rendezvous server address" "section 3.3" "unsecure" "this RRs" "this kind of attacks are" "a collaboration" "through him" - through it or, maybe, her? ;) Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions > Author(s) : P. Nikander, J. Laganier > Filename : draft-ietf-hip-dns-02.txt > Pages : 28 > Date : 2005-7-14 > >This document specifies two new resource records (RRs) for the Domain > Name System (DNS), and how to use them with the Host Identity > Protocol (HIP). These RRs allow a HIP node to store in the DNS its > Host Identity (HI, the public component of the node public-private > key pair), Host Identity Tag (HIT, a truncated hash of its public > key), and the Domain Name or IP addresses of its Rendezvous Servers > (RVS). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-02.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-hip-dns-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-hip-dns-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >------------------------------------------------------------------------ > >_______________________________________________ >Hipsec mailing list >Hipsec@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/hipsec > > --=_courier-7035-1121550482-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC 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/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDcxNjIxNDcyOFowIwYJ KoZIhvcNAQkEMRYEFF0WMWI9xJIo+fIqoHkWYqhSvZ5iMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBAEUEzS1Qe7XhVN8gk9vOZQaHHT2h+lsRXfjVL+6d4O3wjwtp2bnfSdwLOYN2H8KW4uQw I1qlMXv7VHIX3UUFVZDhPzKMkULgexWlTyG0fxoH1RSAKi8QiU3bcpqalToD7Xb3AaIsmWse qSsLH+GFkU94tTLTGNqK5osiMdG+qsycpN55l/fSAh/EEtAcgIThxanqT1qM8SPPr+0PxNP7 +8BZ0cOwL/ya8w19pHrsyhkLsNiMwbfEBZdITr0992jH4fJ0uxDQq6EQaMB6VCMH/XeUI69o dLRUkgyzmC5uD5yg6SxARSeWsmbNmH17osn8RGExElCw/oV9IH7XyYC7ungAAAAAAAA= --=_courier-7035-1121550482-0001-2-- --===============1343363090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1343363090==-- From hipsec-bounces@lists.ietf.org Tue Jul 19 02:46:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dulrx-0004dp-Ln; Tue, 19 Jul 2005 02:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dulrv-0004dk-AZ for hipsec@megatron.ietf.org; Tue, 19 Jul 2005 02:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14387 for ; Tue, 19 Jul 2005 02:46:18 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DumLU-0006o6-5b for hipsec@ietf.org; Tue, 19 Jul 2005 03:16:53 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BA30D1023; Tue, 19 Jul 2005 08:46:16 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 08:46:16 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 08:46:15 +0200 Received: from [131.160.36.106] (EGIUM000L5C5TEU.lmf.ericsson.se [131.160.36.106]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AECBE2500; Tue, 19 Jul 2005 09:46:15 +0300 (EEST) Message-ID: <42DCA1B7.7080802@ericsson.com> Date: Tue, 19 Jul 2005 09:46:15 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2005 06:46:15.0969 (UTC) FILETIME=[8F8C7110:01C58C2D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Agenda requests, IETF 63 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, we are officially starting to gather agenda requests for the HIP WG meeting in Paris. The agenda needs to be ready by July 25th. So, please, send your requests by the end of this week (Friday, July 22nd). You should send your agenda request to the chairs indicating: 1) the topic you want to present 2) related Internet-Drafts 3) length of the requested agenda-slot Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 19 10:34:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutAY-0003mV-F6; Tue, 19 Jul 2005 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutAX-0003m5-GL for hipsec@megatron.ietf.org; Tue, 19 Jul 2005 10:34:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18889 for ; Tue, 19 Jul 2005 10:33:59 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dute8-0001KB-NK for hipsec@ietf.org; Tue, 19 Jul 2005 11:04:40 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA19998; Tue, 19 Jul 2005 09:33:42 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6JEXfs22700; Tue, 19 Jul 2005 07:33:42 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 07:33:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] I-D ACTION:draft-ietf-hip-arch-02.txt Date: Tue, 19 Jul 2005 07:33:39 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095B77@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] I-D ACTION:draft-ietf-hip-arch-02.txt Thread-Index: AcWKQa5kKYtQBskaRiyetolJP48hXQCLN4Mg From: "Henderson, Thomas R" To: "Andrei Gurtov" X-OriginalArrivalTime: 19 Jul 2005 14:33:39.0884 (UTC) FILETIME=[DB0646C0:01C58C6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org We are close to getting all DISCUSS comments resolved in IESG review. A new draft will be published around the time of the Paris meeting. Tom=20 > -----Original Message----- > From: Andrei Gurtov [mailto:gurtov@cs.helsinki.fi]=20 > Sent: Saturday, July 16, 2005 1:02 PM > To: hipsec@ietf.org > Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-arch-02.txt >=20 > Hi, >=20 > What is the current status, did you get IESG comments already? > Are you submitting a new version since this one is about to expire. >=20 > Andrei _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 19 15:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy7m-0002z3-FQ; Tue, 19 Jul 2005 15:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6P-0002UI-Dx; Tue, 19 Jul 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27910; Tue, 19 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya3-0001Yi-J7; Tue, 19 Jul 2005 16:20:45 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6L-0002Il-Mu; Tue, 19 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multihoming with the Host Identity Protocol Author(s) : P. Nikander Filename : draft-ietf-hip-mm-02.txt Pages : 44 Date : 2005-7-19 This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19105629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19105629.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Jul 20 20:37:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvP4A-0000no-Of; Wed, 20 Jul 2005 20:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvP48-0000nb-Pg for hipsec@megatron.ietf.org; Wed, 20 Jul 2005 20:37:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19031 for ; Wed, 20 Jul 2005 20:37:30 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvPY3-00014V-MN for hipsec@ietf.org; Wed, 20 Jul 2005 21:08:29 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA16644 for ; Wed, 20 Jul 2005 19:37:15 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6L0bFv04148 for ; Wed, 20 Jul 2005 19:37:15 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 17:37:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2005 17:37:14 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: base-03 state machine, notify Thread-Index: AcWNjFaYvk7zFYrjR8ulm42WwZSnaw== From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 21 Jul 2005 00:37:14.0800 (UTC) FILETIME=[5735AB00:01C58D8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] base-03 state machine, notify X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org All, I have been looking at the base-03 (and esp-00, mm-02) draft more carefully while upgrading our HIP implementation, and have some comments. I have attempted to organize these few comments with numbers and by category... --- state machine --- (1) What happened to the REKEYING state? It is mentioned once in base-03 and twice in mm-02. It seems that REKEYING was (mostly) stripped out along with the ESP stuff starting with base-02, but never made a reappearance into esp-00. (2) To transition out of the state R2-SENT you need to receive incoming data or timeout. In the conceptual state machine, it mentions that after "no packet sent/received during UAL minutes" (sect. 4.4.2) we transition to CLOSE. What about the case where we are sending data to the peer but receiving nothing? (Note that this is unlikely, since the Initiator usually sends something to trigger; but I do not think this is a requirement for the Initiator to have to send data.) If we are a Responder that is sending but not receiving, we will not time out of state R2-SENT (since packets are being sent) but we also will not transition out of R2-SENT (since no packets are received) and are stuck there. Maybe I'm misreading this, and "packet sent/received" doesn't refer to the user data packets. --- NOTIFY packets --- (3) In 6.14, Processing CLOSE_ACK packets: "...the state changes to UNASSOCIATED and, after that, NOTIFY is sent as a response to a CLOSE message." Do we really want to send NOTIFY here? Doesn't UNASSOCIATED mean that we no longer really have any state with the peer? The draft (sect. 4.3) mentions that NOTIFY should generally be used if there is an existing HIP association. Maybe ICMP is more appropriate, or further CLOSE_ACKs are simply dropped. (4) Under the NOTIFY parameter with INVALID_SYNTAX 7, the draft says "this status may only be returned for and in an encrypted packet if the message ID and cryptographic checksum were valid". What is meant by "message ID"? What about the "cryptographic checksum", is that the HIP checksum? (nowhere is this referred to as a "cryptographic checksum") Does this mean we need an ENCRYPTED TLV in the NOTIFY? (5) It probably should be noted that the NOTIFY code AUTHENTICATION_FAILED should not be sent in response to a failed signature in another NOTIFY. This may be common sense. Imagine two implementations and one has a bug in the RSA signing/verification that crops up after the SA is established; the buggy host later sends an UPDATE, the verify fails causing a NOTIFY to be sent, and a NOTIFY is sent in response to that NOTIFY, etc., the two might potentially go back and forth. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 03:58:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVwg-00021Q-Qx; Thu, 21 Jul 2005 03:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVwe-000208-Qf for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 03:58:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09867 for ; Thu, 21 Jul 2005 03:58:15 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvWQc-0003gl-DF for hipsec@ietf.org; Thu, 21 Jul 2005 04:29:16 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5E60C2D40; Thu, 21 Jul 2005 10:58:04 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1609A2D39; Thu, 21 Jul 2005 10:58:04 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j6L7vx925821; Thu, 21 Jul 2005 10:57:59 +0300 (EEST) Date: Thu, 21 Jul 2005 10:57:58 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Ahrenholz, Jeffrey M" Subject: Re: [Hipsec] base-03 state machine, notify In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote: > (2) To transition out of the state R2-SENT you need to receive incoming > data or timeout. In the conceptual state machine, it mentions that after > "no packet sent/received during UAL minutes" (sect. 4.4.2) we transition > to CLOSE. What about the case where we are sending data to the peer but > receiving nothing? (Note that this is unlikely, since the Initiator > usually sends something to trigger; but I do not think this is a > requirement for the Initiator to have to send data.) If we are a > Responder that is sending but not receiving, we will not time out of > state R2-SENT (since packets are being sent) but we also will not > transition out of R2-SENT (since no packets are received) and are stuck > there. Maybe I'm misreading this, and "packet sent/received" doesn't > refer to the user data packets. I found this out too when implementing and playing with CLOSE. There are some use cases where the responder can be stuck to R2-SENT, so there should be some text in R2-SENT: User data to send, move to ESTABLISHED -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 08:51:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaWH-00024P-7R; Thu, 21 Jul 2005 08:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaWE-00023E-Uz for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 08:51:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26527 for ; Thu, 21 Jul 2005 08:51:17 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvb0D-0005WD-Lh for hipsec@ietf.org; Thu, 21 Jul 2005 09:22:21 -0400 Received: from [192.168.10.111] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5C800937FB8; Thu, 21 Jul 2005 14:50:50 +0200 From: Julien Laganier To: hipsec@ietf.org, Miika Komu , "Ahrenholz, Jeffrey M" Subject: Re: [Hipsec] base-03 state machine, notify Date: Thu, 21 Jul 2005 14:51:02 +0200 User-Agent: KMail/1.8 References: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211451.03099.julien.IETF@laposte.net> X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 21 July 2005 09:57, Miika Komu wrote: > On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote: > > (2) To transition out of the state R2-SENT you need to receive > > incoming data or timeout. In the conceptual state machine, it > > mentions that after "no packet sent/received during UAL minutes" > > (sect. 4.4.2) we transition to CLOSE. What about the case where > > we are sending data to the peer but receiving nothing? (Note that > > this is unlikely, since the Initiator usually sends something to > > trigger; but I do not think this is a requirement for the > > Initiator to have to send data.) If we are a Responder that is > > sending but not receiving, we will not time out of state R2-SENT > > (since packets are being sent) but we also will not transition > > out of R2-SENT (since no packets are received) and are stuck > > there. Maybe I'm misreading this, and "packet sent/received" > > doesn't refer to the user data packets. > > I found this out too when implementing and playing with CLOSE. > There are some use cases where the responder can be stuck to > R2-SENT, so there should be some text in R2-SENT: > > User data to send, move to ESTABLISHED Actually I think I made a mistake when I adapted the original CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow to change Erik's sentence: When no packet has been received on the association for X minutes the association transitions to "closing" state. A "close" message is transmitted to the peer. Into the sentence below, present in both R2_SENT and ESTABLISHED state desription: No packet sent/received during UAL minutes, send CLOSE and go to CLOSING After reading more carefully the HIP base specification and the thread on "Recovery from state loss", I think it should be: No packet received during UAL minutes, send CLOSE and go to CLOSING That way the responder would not be stuck in R2_SENT. What does the WG think? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 09:23:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb1I-000761-Fz; Thu, 21 Jul 2005 09:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb1H-00075t-3B for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 09:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28763 for ; Thu, 21 Jul 2005 09:23:21 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvbVI-0007Tl-AO for hipsec@ietf.org; Thu, 21 Jul 2005 09:54:25 -0400 Received: from [193.234.219.62] (n62.nomadiclab.com [193.234.219.62]) by n2.nomadiclab.com (Postfix) with ESMTP id 10191212C8E; Thu, 21 Jul 2005 16:22:57 +0300 (EEST) Message-ID: <42DFA1B1.8090205@iki.fi> Date: Thu, 21 Jul 2005 16:22:57 +0300 From: Kristian Slavov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Julien Laganier Subject: Re: [Hipsec] base-03 state machine, notify References: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> <200507211451.03099.julien.IETF@laposte.net> In-Reply-To: <200507211451.03099.julien.IETF@laposte.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Julien Laganier wrote: > On Thursday 21 July 2005 09:57, Miika Komu wrote: >> >>I found this out too when implementing and playing with CLOSE. >>There are some use cases where the responder can be stuck to >>R2-SENT, so there should be some text in R2-SENT: >> >> User data to send, move to ESTABLISHED > > [snip] > After reading more carefully the HIP base specification and the thread > on "Recovery from state loss", I think it should be: > > No packet received during UAL minutes, send CLOSE and go to CLOSING > > That way the responder would not be stuck in R2_SENT. What does the WG > think? Depending on the semantics of the HIP association, Miika's suggestion is valid too. I.e. if it is ok to just create a HIP association without actually transferring anything over the tunnel. In that case the responder might very well be the one who actually sends first data. On the otherhand, if the initiator of the HIP association is always assumed to actually send some transport data, then Miika's suggestion is invalid. So how about? If no packet is received nor sent in UAL minutes, send CLOSE and go to CLOSING, otherwise go to ESTABLISHED. -- Kristian Slavov _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 09:43:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvbKZ-00005y-3w; Thu, 21 Jul 2005 09:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvbKX-00005t-WF for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 09:43:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00292 for ; Thu, 21 Jul 2005 09:43:16 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvboa-0000PV-Uw for hipsec@ietf.org; Thu, 21 Jul 2005 10:14:21 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5BE00935222; Thu, 21 Jul 2005 15:43:04 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] base-03 state machine, notify Date: Thu, 21 Jul 2005 15:43:17 +0200 User-Agent: KMail/1.8 References: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> <200507211451.03099.julien.IETF@laposte.net> <42DFA1B1.8090205@iki.fi> In-Reply-To: <42DFA1B1.8090205@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211543.17268.julien.IETF@laposte.net> X-Spam-Score: 2.2 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 21 July 2005 15:22, Kristian Slavov wrote: > Julien Laganier wrote: > > On Thursday 21 July 2005 09:57, Miika Komu wrote: > >>I found this out too when implementing and playing with CLOSE. > >>There are some use cases where the responder can be stuck to > >>R2-SENT, so there should be some text in R2-SENT: > >> > >> User data to send, move to ESTABLISHED > > [snip] > > > After reading more carefully the HIP base specification and the > > thread on "Recovery from state loss", I think it should be: > > > > No packet received during UAL minutes, send CLOSE and go to > > CLOSING (...) > Depending on the semantics of the HIP association, Miika's > suggestion is valid too. I.e. if it is ok to just create a HIP > association without actually transferring anything over the tunnel. This situation is possible with my proposal too, it is just that the initiator needs to send something before the association timeout. If it really want the association to stay without sending user data, it can sends "keepalive" HIP packets, for example empty UPDATEs. > On the otherhand, if the initiator of the HIP association is always > assumed to actually send some transport data, then Miika's > suggestion is invalid. > So how about? > > If no packet is received nor sent in UAL minutes, send CLOSE and > go to CLOSING, otherwise go to ESTABLISHED. Actually what I was proposing was to remove the word "sent" from both R2_SENT _and_ ESTABLISHED descriptions. This is to avoid sending user-data in the void (e.g. other peer is dead). --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 10:40:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcDU-0000IH-0q; Thu, 21 Jul 2005 10:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcDR-00008f-7r for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 10:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06355 for ; Thu, 21 Jul 2005 10:39:59 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvchS-0004K2-GZ for hipsec@ietf.org; Thu, 21 Jul 2005 11:11:04 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA14032; Thu, 21 Jul 2005 09:39:28 -0500 (CDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6LEdSs13511; Thu, 21 Jul 2005 07:39:28 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Jul 2005 07:39:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] base-03 state machine, notify Date: Thu, 21 Jul 2005 07:39:27 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095BA6@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] base-03 state machine, notify Thread-Index: AcWN8y7PLbZUQWddT4+aE8RSfkZg4QADJc6Q From: "Henderson, Thomas R" To: "Julien Laganier" , , "Miika Komu" , "Ahrenholz, Jeffrey M" X-OriginalArrivalTime: 21 Jul 2005 14:39:28.0212 (UTC) FILETIME=[FF786940:01C58E01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Thursday, July 21, 2005 5:51 AM > To: hipsec@ietf.org; Miika Komu; Ahrenholz, Jeffrey M > Subject: Re: [Hipsec] base-03 state machine, notify >=20 >=20 > On Thursday 21 July 2005 09:57, Miika Komu wrote: > > On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote: > > > (2) To transition out of the state R2-SENT you need to receive > > > incoming data or timeout. In the conceptual state machine, it > > > mentions that after "no packet sent/received during UAL minutes" > > > (sect. 4.4.2) we transition to CLOSE. What about the case where > > > we are sending data to the peer but receiving nothing? (Note that > > > this is unlikely, since the Initiator usually sends something to > > > trigger; but I do not think this is a requirement for the > > > Initiator to have to send data.) If we are a Responder that is > > > sending but not receiving, we will not time out of state R2-SENT > > > (since packets are being sent) but we also will not transition > > > out of R2-SENT (since no packets are received) and are stuck > > > there. Maybe I'm misreading this, and "packet sent/received" > > > doesn't refer to the user data packets. > > > > I found this out too when implementing and playing with CLOSE. > > There are some use cases where the responder can be stuck to > > R2-SENT, so there should be some text in R2-SENT: > > > > User data to send, move to ESTABLISHED >=20 > Actually I think I made a mistake when I adapted the original=20 > CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow to=20 > change Erik's sentence: >=20 > When no packet has been received on the association for X minutes > the association transitions to "closing" state. A "close" message > is transmitted to the peer. >=20 > Into the sentence below, present in both R2_SENT and=20 > ESTABLISHED state=20 > desription: >=20 > No packet sent/received during UAL minutes, send CLOSE and go to=20 > CLOSING >=20 > After reading more carefully the HIP base specification and=20 > the thread=20 > on "Recovery from state loss", I think it should be: >=20 > No packet received during UAL minutes, send CLOSE and go=20 > to CLOSING=20 >=20 > That way the responder would not be stuck in R2_SENT. What=20 > does the WG=20 > think? >=20 If you make that change, change also the definition of UAL in section 2. I generally support your recommendation (of eliminating "send" from the = criteria), but I think that transition out of R2_SENT to ESTABLISHED is = a bit different case than transition out of ESTABLISHED to CLOSING. =20 - in R2_SENT case, this is just a small substate for a short period of = time (e.g., some multiple of (a conservative assumption of) the peer's = retransmit timeout for I2) for which we will handle an I2 as a = retransmission attempt and not as a new I2. I don't think it has to be = tied to UAL. Instead, I would think that a conceptual = "EXCHANGE_COMPLETE" timer could be implemented, and that transition from = R2_SENT to ESTABLISHED happens when either this timer expires or some = packet is received that implies that the peer got the R2. - UAL timescale should be much larger than this so maybe the above UAL sentence does not need to go in the state machine = description of R2_SENT. Tom =20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 11:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcpL-0001xy-NU; Thu, 21 Jul 2005 11:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcpJ-0001wy-7r for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 11:19:09 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09100 for ; Thu, 21 Jul 2005 11:19:06 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5CC00C9F8DE; Thu, 21 Jul 2005 17:17:23 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] base-03 state machine, notify Date: Thu, 21 Jul 2005 17:17:35 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D095BA6@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095BA6@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211717.35877.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 21 July 2005 16:39, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > Sent: Thursday, July 21, 2005 5:51 AM > > To: hipsec@ietf.org; Miika Komu; Ahrenholz, Jeffrey M > > Subject: Re: [Hipsec] base-03 state machine, notify > > > > On Thursday 21 July 2005 09:57, Miika Komu wrote: > > > On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote: > > > > (2) To transition out of the state R2-SENT you need to > > > > receive incoming data or timeout. In the conceptual state > > > > machine, it mentions that after "no packet sent/received > > > > during UAL minutes" (sect. 4.4.2) we transition to CLOSE. > > > > What about the case where we are sending data to the peer but > > > > receiving nothing? (Note that this is unlikely, since the > > > > Initiator usually sends something to trigger; but I do not > > > > think this is a requirement for the Initiator to have to send > > > > data.) If we are a Responder that is sending but not > > > > receiving, we will not time out of state R2-SENT (since > > > > packets are being sent) but we also will not transition out > > > > of R2-SENT (since no packets are received) and are stuck > > > > there. Maybe I'm misreading this, and "packet sent/received" > > > > doesn't refer to the user data packets. > > > > > > I found this out too when implementing and playing with CLOSE. > > > There are some use cases where the responder can be stuck to > > > R2-SENT, so there should be some text in R2-SENT: > > > > > > User data to send, move to ESTABLISHED > > > > Actually I think I made a mistake when I adapted the original > > CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow > > to change Erik's sentence: > > > > When no packet has been received on the association for X > > minutes the association transitions to "closing" state. A "close" > > message is transmitted to the peer. > > > > Into the sentence below, present in both R2_SENT and > > ESTABLISHED state > > desription: > > > > No packet sent/received during UAL minutes, send CLOSE and go > > to CLOSING > > > > After reading more carefully the HIP base specification and > > the thread > > on "Recovery from state loss", I think it should be: > > > > No packet received during UAL minutes, send CLOSE and go > > to CLOSING > > > > That way the responder would not be stuck in R2_SENT. What > > does the WG > > think? > > If you make that change, change also the definition of UAL in > section 2. > > I generally support your recommendation (of eliminating "send" from > the criteria), but I think that transition out of R2_SENT to > ESTABLISHED is a bit different case than transition out of > ESTABLISHED to CLOSING. - in R2_SENT case, this is just a small > substate for a short period of time (e.g., some multiple of (a > conservative assumption of) the peer's retransmit timeout for I2) > for which we will handle an I2 as a retransmission attempt and not > as a new I2. I don't think it has to be tied to UAL. Instead, I > would think that a conceptual "EXCHANGE_COMPLETE" timer could be > implemented, and that transition from R2_SENT to ESTABLISHED > happens when either this timer expires or some packet is received > that implies that the peer got the R2. - UAL timescale should be > much larger than this > > so maybe the above UAL sentence does not need to go in the state > machine description of R2_SENT. I think you are right. The UAL sentence should be present only in ESTABLISHED. In R2_SENT we should have something along: Exchange Complete Timeout, transition to ESTABLISHED. And perhaps specifies that Exchange Complete Timeout = n * Retransmission Timeout, with n ~ I2_RETRIES_MAX ? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 21 11:19:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvcpa-00024W-24; Thu, 21 Jul 2005 11:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcpZ-00022l-8P for hipsec@megatron.ietf.org; Thu, 21 Jul 2005 11:19:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09116 for ; Thu, 21 Jul 2005 11:19:23 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvdJc-0006sq-VC for hipsec@ietf.org; Thu, 21 Jul 2005 11:50:29 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5CC00C9F8DE; Thu, 21 Jul 2005 17:17:23 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] base-03 state machine, notify Date: Thu, 21 Jul 2005 17:17:35 +0200 User-Agent: KMail/1.8 References: <77F357662F8BFA4CA7074B0410171B6D095BA6@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095BA6@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211717.35877.julien.IETF@laposte.net> X-Spam-Score: 2.2 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 21 July 2005 16:39, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > Sent: Thursday, July 21, 2005 5:51 AM > > To: hipsec@ietf.org; Miika Komu; Ahrenholz, Jeffrey M > > Subject: Re: [Hipsec] base-03 state machine, notify > > > > On Thursday 21 July 2005 09:57, Miika Komu wrote: > > > On Wed, 20 Jul 2005, Ahrenholz, Jeffrey M wrote: > > > > (2) To transition out of the state R2-SENT you need to > > > > receive incoming data or timeout. In the conceptual state > > > > machine, it mentions that after "no packet sent/received > > > > during UAL minutes" (sect. 4.4.2) we transition to CLOSE. > > > > What about the case where we are sending data to the peer but > > > > receiving nothing? (Note that this is unlikely, since the > > > > Initiator usually sends something to trigger; but I do not > > > > think this is a requirement for the Initiator to have to send > > > > data.) If we are a Responder that is sending but not > > > > receiving, we will not time out of state R2-SENT (since > > > > packets are being sent) but we also will not transition out > > > > of R2-SENT (since no packets are received) and are stuck > > > > there. Maybe I'm misreading this, and "packet sent/received" > > > > doesn't refer to the user data packets. > > > > > > I found this out too when implementing and playing with CLOSE. > > > There are some use cases where the responder can be stuck to > > > R2-SENT, so there should be some text in R2-SENT: > > > > > > User data to send, move to ESTABLISHED > > > > Actually I think I made a mistake when I adapted the original > > CLOSE/CLOSE-ACK handshake proposal from Erik; I managed somehow > > to change Erik's sentence: > > > > When no packet has been received on the association for X > > minutes the association transitions to "closing" state. A "close" > > message is transmitted to the peer. > > > > Into the sentence below, present in both R2_SENT and > > ESTABLISHED state > > desription: > > > > No packet sent/received during UAL minutes, send CLOSE and go > > to CLOSING > > > > After reading more carefully the HIP base specification and > > the thread > > on "Recovery from state loss", I think it should be: > > > > No packet received during UAL minutes, send CLOSE and go > > to CLOSING > > > > That way the responder would not be stuck in R2_SENT. What > > does the WG > > think? > > If you make that change, change also the definition of UAL in > section 2. > > I generally support your recommendation (of eliminating "send" from > the criteria), but I think that transition out of R2_SENT to > ESTABLISHED is a bit different case than transition out of > ESTABLISHED to CLOSING. - in R2_SENT case, this is just a small > substate for a short period of time (e.g., some multiple of (a > conservative assumption of) the peer's retransmit timeout for I2) > for which we will handle an I2 as a retransmission attempt and not > as a new I2. I don't think it has to be tied to UAL. Instead, I > would think that a conceptual "EXCHANGE_COMPLETE" timer could be > implemented, and that transition from R2_SENT to ESTABLISHED > happens when either this timer expires or some packet is received > that implies that the peer got the R2. - UAL timescale should be > much larger than this > > so maybe the above UAL sentence does not need to go in the state > machine description of R2_SENT. I think you are right. The UAL sentence should be present only in ESTABLISHED. In R2_SENT we should have something along: Exchange Complete Timeout, transition to ESTABLISHED. And perhaps specifies that Exchange Complete Timeout = n * Retransmission Timeout, with n ~ I2_RETRIES_MAX ? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 24 07:06:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DweJc-00082w-8h; Sun, 24 Jul 2005 07:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DweJY-00082l-L9 for hipsec@megatron.ietf.org; Sun, 24 Jul 2005 07:06:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20579 for ; Sun, 24 Jul 2005 07:06:33 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DweoB-0007Sf-9S for hipsec@ietf.org; Sun, 24 Jul 2005 07:38:16 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 791C9134D; Sun, 24 Jul 2005 13:06:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 13:06:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 13:06:21 +0200 Received: from [131.160.126.11] (rvi2-126-11.lmf.ericsson.se [131.160.126.11]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CFFEF250D; Sun, 24 Jul 2005 14:06:20 +0300 (EEST) Message-ID: <42E3762B.1010801@ericsson.com> Date: Sun, 24 Jul 2005 14:06:19 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] WGLC on base spec and ESP draft References: <42C91232.9000206@ericsson.com> In-Reply-To: <42C91232.9000206@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2005 11:06:21.0207 (UTC) FILETIME=[B90F8A70:01C5903F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "Pekka Nikander \(JO/LMF\)" , rgm@icsalabs.com, David Ward , "Petri Jokela \(JO/LMF\)" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, note that the WGLCs below will end in a week. This is your last chance to provide comments on these drafts. Thanks, Gonzalo Gonzalo Camarillo wrote: > Folks, > > as we agreed on the last face-to-face meeting, we intend to have both > the base spec and the ESP draft ready to be sent to the IESG right after > the upcoming IETF meeting in Paris. Therefore, we would like to start > the working group last call on both drafts today. This WGLC will end on > July 31st. > > The idea is to use the face-to-face meeting in Paris to close any > remaining WGLC issue that cannot be closed in the mailing list. The > drafts are available at: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt > http://hip4inter.net/documentation/drafts/draft-ietf-hip-esp-00.txt > > [there were some problems with the submission of the ESP draft, but it > will be available also on the IETF archives shortly] > > Please, review the drafts (thoroughly) and send your comments to this > mailing list. > > Thanks, > > Gonzalo > HIP co-chair > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 24 07:13:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwePr-0000Vb-FL; Sun, 24 Jul 2005 07:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwePp-0000VV-TJ for hipsec@megatron.ietf.org; Sun, 24 Jul 2005 07:13:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20835 for ; Sun, 24 Jul 2005 07:13:02 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DweuS-0007bu-9A for hipsec@ietf.org; Sun, 24 Jul 2005 07:44:45 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA4F41E2; Sun, 24 Jul 2005 13:12:54 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 13:12:53 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 13:12:53 +0200 Received: from [131.160.126.11] (rvi2-126-11.lmf.ericsson.se [131.160.126.11]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2AE76250D; Sun, 24 Jul 2005 14:12:53 +0300 (EEST) Message-ID: <42E377B4.1030107@ericsson.com> Date: Sun, 24 Jul 2005 14:12:52 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2005 11:12:53.0460 (UTC) FILETIME=[A2DC9940:01C59040] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: David Ward Subject: [Hipsec] Draft agenda X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, this is the draft agenda for the upcoming face-to-face meeting: http://hip.piuha.net/meetings/ietf63/agenda-hip.html Any comments? Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 25 08:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2Hd-0005Iu-Mg; Mon, 25 Jul 2005 08:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx2HZ-0005IU-I8 for hipsec@megatron.ietf.org; Mon, 25 Jul 2005 08:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15375 for ; Mon, 25 Jul 2005 08:42:08 -0400 (EDT) Received: from pegasus.hiit.fi ([212.68.1.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx2mN-0000hR-TY for hipsec@ietf.org; Mon, 25 Jul 2005 09:14:02 -0400 Received: from [128.214.113.174] (odysse.hiit.fi [128.214.113.174]) by pegasus.hiit.fi (Postfix) with ESMTP id 1F1F1220013; Mon, 25 Jul 2005 15:41:48 +0300 (EEST) From: Diego Beltrami To: netdev@oss.sgi.com Content-Type: text/plain Organization: HIIT Message-Id: <1122295307.14873.37.camel@odysse> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 25 Jul 2005 15:41:48 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b382e0fda7380faa630530317e47f8e4 Content-Transfer-Encoding: 7bit Cc: hipl-users@freelists.org, hipsec@ietf.org, infrahip@HIIT.FI, kristian.slavov@nomadiclab.com Subject: [Hipsec] [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: diego.beltrami@HIIT.FI List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi folks, we have been working for three months to implement a new IPsec mode, the "BEET" mode, for Linux. Below is a link to the BEET specification and the abstract: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt Abstract This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. The BEET mode is required by the Host Identity Protocol (HIP), which provides authenticated Diffie-Hellman for end-hosts, as well as mobility and multihoming support. The BEET mode is also useful for other similar protocols being developed at the IETF. Ericsson has already developed a BEET patch for *BSD. Our patch provides the similar functionality, but using the XFRM architecture. The patch is included at the end of this email and also at the following URL: http://hipl.hiit.fi/beet/beet-patch-v1.0-2.6.12.2 We have made some testing in order to assure the quality of the patch. All the tests passed, and below is a list of them: * Does not break transport and tunnel mode (with CONFIG_XFRM_BEET on/off) * All inner-outer combinations with varying test applications: ICMP, ICMPv6, FTP, SSH, nc, nc6 * Works with fragmented packets * Interoperability with HIPL * Real machines, virtual machines (vmware) * Tested with long data streams The BEET development team: * Abhinav Pathak (InfraHIP/HIIT) * Diego Beltrami (InfraHIP/HIIT) * Kristian Slavov (Ericsson) * Miika Komu (InfraHIP/HIIT) * Jeff Ahrenholz (Boeing) On the behalf of the BEET development team, Signed-off-by: Diego Beltrami diff -urN linux-2.6.12.2/Documentation/README.BEET linux-beet-2.6.12.2/Documentation/README.BEET --- linux-2.6.12.2/Documentation/README.BEET 1970-01-01 02:00:00.000000000 +0200 +++ linux-beet-2.6.12.2/Documentation/README.BEET 2005-07-25 14:39:36.000000000 +0300 @@ -0,0 +1,465 @@ +Linux BEET-mode ESP patch + +Authors: Miika Komu + Kristian Slavov + Jeff Ahrenholz + Abhinav Pathak + Diego Beltrami + +Changelog: May 25, 2005 this document created + + +Description +----------- +This patch extends the native Linux 2.6 kernel IPsec to support +Bound-End-to-End-Tunnel (BEET) mode for ESP: + +Abstract + + This document specifies a new mode, called Bound End-to-End Tunnel + (BEET) mode, for IPsec ESP. The new mode augments the existing ESP + tunnel and transport modes. For end-to-end tunnels, the new mode + provides limited tunnel mode semantics without the regular tunnel + mode overhead. The mode is intended to support new uses of ESP, + including mobility and multi-address multi-homing. + +http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt + +BEET mode architecture +---------------------- + +Below are some control flow diagrams to illustrate how BEET works. + +Sending (inner IPv4, outer IPv4)(4-4) +===================================== +inet_sendmsg + raw_sendmsg + ip_route_output_flow + __ip_route_output_key + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm4_bundle_create + ip_push_pending_frames + dst_output(skb) //this calls skb->dst->output(); + xfrm4_output //This finally returns 4 (NET_XMIT_BYPASS) to dst_output(); + xfrm4_encap + esp_output + xfrm_beet_output //change the ip header to outer. + dst_output(skb) + ip_output + ip_finish_output Or ip_fragment //depending on size of packet + // Returns 0 to dst_output(); which makes dst_output to come out of infinite loop. + dev_queue_xmit + + +Receiving (inner IPv4, outer IPv4)(4-4) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() + nf_hook() + ip_rcv_finish() + ip_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv4 header + ip_input_finish + ret = ipprot->handler(&skb, &nhoff); + xfrm4_rcv() + xfrm4_rcv_encap() + xfrm4_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp_input + esp_input() // process ESP based on inner address + returns 0 ; + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb //Now we have an IPv4 packet. So the input flow is for v4 packet. + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() + nf_hook() //This calls ip_rcv_finish(skb) + ip_rcv_finish() //Here the skb->dst is NULL and so is filled for the input side. + ip6_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv4 header + ip_input_finish + ... + ... + ... + + +Sending (inner IPv6, outer IPv4)(6-4) +===================================== +inet_sendmsg + rawv6_sendmsg + ip6_dst_lookup + ip6_route_output + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm6_bundle_create + rawv6_push_pending_frames + ip6_push_pending_frames + dst_output(skb) + xfrm6_output + xfrm6_encap + esp6_output //esp calculation is done on inner addresses !! + xfrm_beet_output //Change the ip header to outer IP Header + dst_output(skb) + ip_output + ip_finish_output Or ip_fragment //depending on size of packet + // Returns 0 to dst_output(); which makes dst_output to come out of infinite loop. + dev_queue_xmit + + +Receiving (inner IPv6, outer IPv4)(6-4) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() // skb len = 140 + nf_hook() + ip_rcv_finish() + ip_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv6 header + ip_input_finish // calls recursively the ->handler = xfrm6_rcv + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi + xfrm4_rcv() + xfrm4_rcv_encap() + xfrm4_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp6_input + esp6_input() // process ESP based on inner address + returns 0 ; + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip6_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip6_rcv() // skb len = 104 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish + xfrm6_policy_check() + .. + __xfrm_policy_check + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi +tcp_v6_rcv() // or icmpv6_rcv(), anyway, deliver to upper layer + + +Sending (inner IPv4, outer IPv6)(4-6) +===================================== + +inet_sendmsg + raw_sendmsg + ip_route_output_flow + __ip_route_output_key + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm4_bundle_create + ip_push_pending_frames + dst_output(skb) //this calls skb->dst->output(); + xfrm4_output //This finally returns 4 (NET_XMIT_BYPASS) to dst_output(); + xfrm4_encap + esp_output + xfrm_beet_output + dst_output(skb) + ip6_output + ip6_output2 + ip6_output_finish // Returns 0 to dst_output(); which makes dst_output to come out of infinite loop. + dev_queue_xmit + + +Receiving (inner IPv4, outer IPv6)(4-6) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ipv6_rcv() // skb len = 140 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish // calls recursively the ->handler = xfrm6_rcv + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi + xfrm6_rcv() + xfrm6_rcv_spi() + xfrm_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp_input + esp_input() // process ESP + returns iph->protocol ; + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip6_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb //Now we have an IPv4 packet. So the input flow is for v4 packet. + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ip_rcv() + nf_hook() //This calls ip_rcv_finish(skb) + ip_rcv_finish() //Here the skb->dst is NULL and so is filled for the input side. + ip_route_input() + dst_input()->ip_forward() or ip_input() + ip_input // remove the IPv4 header + ip_input_finish + ... + ... + ... + +Sending (inner IPv6, outer IPv6)(6-6) +============= + +(When sending the first packet!) + +inet_sendmsg + rawv6_sendmsg + ip6_dst_lookup + ip6_route_output + xfrm_lookup + flow_cache_lookup + xfrm_policy_lookup // lookup IPsec policy + xfrm_find_bundle // lookup IPsec SA + __xfrm_selector_match + xfrm_tmpl_resolve // only if bundle was not found! + xfrm_state_find + xfrm_bundle_create // create output (dst) chain if bundle was not found + __xfrm6_bundle_create + rawv6_push_pending_frames + ip6_push_pending_frames + dst_output(skb) + xfrm6_output + xfrm6_encap + esp6_output + xfrm_beet_output + dst_output(skb) + ip6_output + ip6_output2 + ip6_output_finish + dev_queue_xmit + +when are these called? + ip6_xmt() + dst_output() + + +Receiving (inner IPv6, outer IPv6)(6-6) +=========== + +net_rx_action() +e1000_clean() // dependent on network hardware +e1000_clean_rx_irq() +netif_receive_skb() + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ipv6_rcv() // skb len = 140 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish // calls recursively the ->handler = xfrm6_rcv + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi + xfrm6_rcv() + xfrm6_rcv_spi() + xfrm_parse_spi() + xfrm_state_lookup() // lookup IPsec SA + xfrm_beet_input(skb, x) //To change to inner IP header. + nexthdr = x->type->input(x, xfrm.decap, skb) // == esp6_input + esp6_input() // process ESP + returns 58 (ICMPv6) //returns the nexthdr in the ipv6 packet. + /* beet handling in xfrm_rcv_spi */ + netif_rx() + // ip6_input_finish returns 0 + // netif_receive_skb returns 0 +netif_receive_skb + deliver_skb() + ret = pt_prev->func(skb, skb->dev, pt_prev); + ipv6_rcv() // skb len = 104 + nf_hook_slow() + ip6_rcv_finish() + ip6_route_input() + dst_input()->ip6_forward() or ip6_input() + ip6_input // remove the IPv6 header + ip6_input_finish + xfrm6_policy_check() + .. + __xfrm_policy_check + ret = ipprot->handler(&skb, &nhoff); // handler = xfrm6_rcv_spi +tcp_v6_rcv() // or icmpv6_rcv(), anyway, deliver to upper layer + + +output path +ip6_datagram_connect() + ip6_dst_lookup() // success + xfrm_lookup() // lookup policy using inner IP, matching selectors in SP and + flow information + xfrm_sk_policy_lookup() // success + flow_cache_lookup() // success + xfrm_find_bundle() // check for a bundle, if found use it, or create new + xfrm_tmpl_resolve() // when creating new, search for SA for each transform + // once valid SA found, use it to create bundle and link + // to SP. modify skbuff's dst-pointer pointing to next + // xfrmX_output(), after encaps/trans dst is consulted + // to route the packet + xfrm_state_find() // + xfrm_selector_match() // + km_query() // + + + + app app + | | + inner inner + \ / + - / + \ / + \--outer outer--/ + \ / + \======/ + + +Files Added +-------------- +This is a list of the included files for the BEET patch + +net/xfrm/xfrm_beet.c +- This file contains the functions xfrm_beet_input() and xfrm_beet_output() + which deals with the incoming and the outgoing BEET packets, respectively. + The purpose of these functions is to interchange the inner addresses with + the outer addresses in the IP header (in case of outgoing packets) and viceversa + (in case of incoming packets). + The file describes two functions: + 1. xfrm_beet_input + Used in receiving side, changes the ip header to inner ip header + 2. xfrm_beet_output + Used in sending side, changes the ip header to outer ip header + +Files changed +------------- +This is a list of changes made by the BEET patch. + +include/linux/ipsec.h + - IPSEC_MODE_BEET added + This is the new type of SA that may be created. + XXX note: are we overusing XFRM_MODE_BEET where IPSEC_MODE_BEET should be + used instead? + +include/linux/xfrm.h + - enum XFRM_MODE_{TRANSPORT|TUNNEL|BEET} added + Mode needed to distinguish from tunnel mode in xfrm code. + +include/net/xfrm.h + - u16 beet_family added to struct xfrm_state + For the outgoing SA, this is the family of the outer address. + For the incoming SA, this is the family of the inner address. + - unsigned short family added to struct xfrm_tmpl + family is required because the family may differ from the one in the selector + - possible change to xfrm_selector_match() (commented out) + +net/ipv4/xfrm4_input.c + - in xfrm4_rcv_encap() call is made to xfrm_beet_input(), to change the + ip header to inner before going for esp test. + - in xfrm4_rcv_encap() check x->props.mode for XFRM_MODE_TUNNEL, _BEET + checks address family (x->props.beet_family), and makes final adjustments + to packet before requeing it. + +net/ipv4/xfrm4_output.c + - xfrm4_encap(), note to fix the BEET case, like xfrm6_encap + - xfrm4_output(), added a call to xfrm_beet_output() to change the ip header + +net/ipv4/esp4.c + - in esp_init_state(), check if x->props.mode == XFRM_MODE_TUNNEL, + then x->props.header_len += sizeof(struct ipv6hdr), not if (x->props.mode) + - in esp_input(), while returning, if the outer family is AF_INET6, then return + iph->protocol, else return 0. + +net/ipv6/esp6.c + - in esp6_init_state(), check if x->props.mode == XFRM_MODE_TUNNEL, + then x->props.header_len += sizeof(struct ipv6hdr), not if (x->props.mode) + - in esp6_input(), while returning, if the outer family is AF_INET, then + set next header field and return 0, else return ret. + + +net/ipv6/xfrm6_input.c + - in xfrm6-rcv_spi(), call is made to xfrm_beet_input(), which changes to + inner ip header before sending to esp decapsulation. + - in xfrm6_rcv_spi(), handle x->props.mode = XFRM_MODE_BEET + checks address family (x->props.beet_family), makes final adjustments to + packet before requeing it. + +net/ipv6/xfrm6_output.c + - xfrm6_encap() add ipv4 header vars, check if (x->props.mode==XFRM_MODE_BEET) + makes space for appropriate esp header and sends to espX_output where X depends + on inner family of beet. + - xfrm6_output() change if(x->props.mode) to (x->props.mode==XFRM_MODE_TUNNEL) + Also a call is made to xfrm_beet_output after esp calculations, to change the + ip header to outer ip header. + +net/ipv6/xfrm6_policy.c + (on output...) + - in __xfrm6_bundle_create() added remotebeet, localbeet vars, + get the IPv6 headers from xfrm[i]->id.daddr (remote) and + xfrm[i]->props.saddr (local) + copy IPv4 or IPv6 addresses from remote/localbeet to fl_tunnel.fl4/6_dst/src + then do xfrm_dst_lookup() passing in xfrm[i]->props.beet_family + +net/key/af_key.c + - commented-out code in pfkey_msg2xfrm_state(): + check x->props.beet_family for x->props.family? + + - parse_ipsecrequest() check if (t->mode==IPSEC_MODE_TUNNEL-1) + handle if (t->mode==IPSEC_MODE_BEET-1) + populate t->saddr.a4 or t->saddr.a6, t->family, etc + This supports adding a new type of beet mode SA. + +net/xfrm/Kconfig + - added XFRM_BEET config variable option and text + This allows you to compile BEET mode into your kernel. + +net/xfrm/xfrm_policy.c + - note from Miika - fns added just for testing, removed for BEET + ipv6_addr_is_hit(), hip_xfrm_handler_notify(), hip_xfrm_handler_acquire(), + hip_xfrm_handler_policy_notify(), hip_register_xfrm_km_handler(), etc diff -urN linux-2.6.12.2/include/linux/ipsec.h linux-beet-2.6.12.2/include/linux/ipsec.h --- linux-2.6.12.2/include/linux/ipsec.h 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/include/linux/ipsec.h 2005-07-25 14:39:01.000000000 +0300 @@ -13,6 +13,9 @@ IPSEC_MODE_ANY = 0, /* We do not support this for SA */ IPSEC_MODE_TRANSPORT = 1, IPSEC_MODE_TUNNEL = 2 +#ifdef CONFIG_XFRM_BEET + ,IPSEC_MODE_BEET = 3 +#endif }; enum { diff -urN linux-2.6.12.2/include/linux/xfrm.h linux-beet-2.6.12.2/include/linux/xfrm.h --- linux-2.6.12.2/include/linux/xfrm.h 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/include/linux/xfrm.h 2005-07-25 14:39:01.000000000 +0300 @@ -102,6 +102,15 @@ XFRM_SHARE_UNIQUE /* Use once */ }; +enum +{ + XFRM_MODE_TRANSPORT = 0, + XFRM_MODE_TUNNEL +#ifdef CONFIG_XFRM_BEET + ,XFRM_MODE_BEET +#endif +}; + /* Netlink configuration messages. */ enum { XFRM_MSG_BASE = 0x10, diff -urN linux-2.6.12.2/include/net/xfrm.h linux-beet-2.6.12.2/include/net/xfrm.h --- linux-2.6.12.2/include/net/xfrm.h 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/include/net/xfrm.h 2005-07-25 15:03:01.000000000 +0300 @@ -113,6 +113,14 @@ xfrm_address_t saddr; int header_len; int trailer_len; +#ifdef CONFIG_XFRM_BEET + /* beet_family_out = family of outer addresses + * beet_family_in = family of inner addresses + */ + u16 beet_family_in; + u16 beet_family_out; + +#endif } props; struct xfrm_lifetime_cfg lft; @@ -241,6 +249,12 @@ /* Source address of tunnel. Ignored, if it is not a tunnel. */ xfrm_address_t saddr; +/* family of the addresses. In BEET-mode the family may differ from + the one in selector */ +#ifdef CONFIG_XFRM_BEET + unsigned short family; +#endif + __u32 reqid; /* Mode: transport/tunnel */ @@ -835,6 +849,12 @@ extern void xfrm6_tunnel_free_spi(xfrm_address_t *saddr); extern u32 xfrm6_tunnel_spi_lookup(xfrm_address_t *saddr); extern int xfrm6_output(struct sk_buff *skb); +#ifdef CONFIG_XFRM_BEET +extern struct xfrm_state * xfrm_lookup_bydst(u8 mode, xfrm_address_t *daddr, xfrm_address_t *saddr, unsigned short family); +extern int xfrm_beet_output(struct sk_buff *skb); +extern int xfrm_beet_input(struct sk_buff *skb, struct xfrm_state *x); + +#endif #ifdef CONFIG_XFRM extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type); diff -urN linux-2.6.12.2/net/ipv4/esp4.c linux-beet-2.6.12.2/net/ipv4/esp4.c --- linux-2.6.12.2/net/ipv4/esp4.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv4/esp4.c 2005-07-25 14:39:11.000000000 +0300 @@ -1,3 +1,13 @@ +/* + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * + */ + #include #include #include @@ -23,7 +33,7 @@ struct iphdr *top_iph; struct ip_esp_hdr *esph; struct crypto_tfm *tfm; - struct esp_data *esp; + struct esp_data *esp = x->data; struct sk_buff *trailer; int blksize; int clen; @@ -31,7 +41,15 @@ int nfrags; /* Strip IP+ESP header. */ - __skb_pull(skb, skb->h.raw - skb->data); +#ifdef CONFIG_XFRM_BEET + int hdr_len = skb->h.raw - skb->data + sizeof(*esph) + esp->conf.ivlen; + if (x->props.mode == XFRM_MODE_BEET) + __skb_pull(skb, hdr_len); + else + __skb_pull(skb, skb->h.raw - skb->data); +#else + __skb_pull(skb, skb->h.raw - skb->data); +#endif /* Now skb is pure payload to encrypt */ err = -ENOMEM; @@ -39,7 +57,6 @@ /* Round to block size */ clen = skb->len; - esp = x->data; alen = esp->auth.icv_trunc_len; tfm = esp->conf.tfm; blksize = (crypto_tfm_alg_blocksize(tfm) + 3) & ~3; @@ -59,7 +76,14 @@ *(u8*)(trailer->tail + clen-skb->len - 2) = (clen - skb->len)-2; pskb_put(skb, trailer, clen - skb->len); +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) + __skb_push(skb, hdr_len); + else + __skb_push(skb, skb->data - skb->nh.raw); +#else __skb_push(skb, skb->data - skb->nh.raw); +#endif top_iph = skb->nh.iph; esph = (struct ip_esp_hdr *)(skb->nh.raw + top_iph->ihl*4); top_iph->tot_len = htons(skb->len + alen); @@ -238,7 +262,14 @@ skb->nh.iph->tot_len = htons(skb->len); } +#ifdef CONFIG_XFRM_BEET + if(x->props.mode == XFRM_MODE_BEET && x->props.beet_family_out == AF_INET6) + return iph->protocol ; + else + return 0; +#else return 0; +#endif out: return -EINVAL; @@ -428,7 +459,11 @@ if (crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len)) goto error; x->props.header_len = sizeof(struct ip_esp_hdr) + esp->conf.ivlen; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) +#else if (x->props.mode) +#endif x->props.header_len += sizeof(struct iphdr); if (x->encap) { struct xfrm_encap_tmpl *encap = x->encap; diff -urN linux-2.6.12.2/net/ipv4/xfrm4_input.c linux-beet-2.6.12.2/net/ipv4/xfrm4_input.c --- linux-2.6.12.2/net/ipv4/xfrm4_input.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv4/xfrm4_input.c 2005-07-25 14:39:11.000000000 +0300 @@ -7,6 +7,13 @@ * Derek Atkins * Add Encapsulation support * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -78,6 +85,14 @@ goto drop_unlock; xfrm_vec[xfrm_nr].decap.decap_type = encap_type; + +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header with the inner data */ + if (xfrm_beet_input(skb, x)) + goto drop_unlock; + } +#endif if (x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb)) goto drop_unlock; @@ -96,7 +111,11 @@ iph = skb->nh.iph; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif if (iph->protocol != IPPROTO_IPIP) goto drop; if (!pskb_may_pull(skb, sizeof(struct iphdr))) @@ -115,9 +134,69 @@ decaps = 1; break; } +#ifdef CONFIG_XFRM_BEET + else if (x->props.mode == XFRM_MODE_BEET) { + struct iphdr *iph = skb->nh.iph; + struct ipv6hdr *ip6h = skb->nh.ipv6h; + int size = 0; + + if (skb_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + goto drop; + + if (x->props.beet_family_in == AF_INET) + size = sizeof(struct iphdr); + else if (x->props.beet_family_in == AF_INET6) + size = sizeof(struct ipv6hdr); + else + BUG_ON(1); + + skb_push(skb, size); + + memmove(skb->data, skb->nh.raw, size); + skb->mac.raw = memmove(skb->data - skb->mac_len, + skb->mac.raw, skb->mac_len); + skb->nh.raw = skb->data; - if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) + switch(x->props.beet_family_in) { + case AF_INET: + + iph->tot_len = htons(skb->len); + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + skb->protocol = htons(ETH_P_IP); + dst_release(skb->dst); + skb->dst = NULL; + decaps = 1; + + break; + case AF_INET6: + ip6h = skb->nh.ipv6h; + + skb->nh.ipv6h->payload_len = htons(ntohs(skb->nh.ipv6h->payload_len) + size); + skb->protocol = htons(ETH_P_IPV6); + + dst_release(skb->dst); + skb->dst = NULL; + decaps = 1; + break; + default: + BUG_ON(1); + } + break; + } + + if (x->props.mode == XFRM_MODE_BEET && x->props.beet_family_in == AF_INET6) { + if ((err = xfrm_parse_spi(skb, skb->nh.ipv6h->nexthdr, &spi, &seq)) < 0) + goto drop; + } else { + if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) + goto drop; + } +#else + if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) goto drop; +#endif } while (!err); /* Allocate new secpath or COW existing one. */ diff -urN linux-2.6.12.2/net/ipv4/xfrm4_output.c linux-beet-2.6.12.2/net/ipv4/xfrm4_output.c --- linux-2.6.12.2/net/ipv4/xfrm4_output.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv4/xfrm4_output.c 2005-07-25 14:39:11.000000000 +0300 @@ -6,6 +6,14 @@ * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -26,7 +34,8 @@ * check * * On exit, skb->h will be set to the start of the payload to be processed - * by x->type->output and skb->nh will be set to the top IP header. + * by x->type->output and skb->nh, as well as skb->data, will point to + * the top IP header. */ static void xfrm4_encap(struct sk_buff *skb) { @@ -35,15 +44,36 @@ struct iphdr *iph, *top_iph; iph = skb->nh.iph; - skb->h.ipiph = iph; +#ifdef CONFIG_XFRM_BEET + /* + * This is because otherwise the BEET patch crashes in any case with Inner=4 + */ + if (x->props.mode != XFRM_MODE_BEET) + skb->h.ipiph = iph; +#else + skb->h.ipiph = iph; +#endif skb->nh.raw = skb_push(skb, x->props.header_len); top_iph = skb->nh.iph; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TRANSPORT) { +#else if (!x->props.mode) { +#endif + skb->h.raw += iph->ihl*4; memmove(top_iph, iph, iph->ihl*4); return; +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + + skb->h.raw = skb->data + sizeof(struct iphdr); + memmove(top_iph, iph, iph->ihl*4); + return; + +#endif /* CONFIG_XFRM_BEET */ } top_iph->ihl = 5; @@ -103,7 +133,11 @@ goto error_nolock; } +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif err = xfrm4_tunnel_check_size(skb); if (err) goto error_nolock; @@ -120,6 +154,15 @@ if (err) goto error; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header */ + err = xfrm_beet_output(skb); + if (err) + goto error; + } +#endif + x->curlft.bytes += skb->len; x->curlft.packets++; diff -urN linux-2.6.12.2/net/ipv4/xfrm4_policy.c linux-beet-2.6.12.2/net/ipv4/xfrm4_policy.c --- linux-2.6.12.2/net/ipv4/xfrm4_policy.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv4/xfrm4_policy.c 2005-07-25 15:03:01.000000000 +0300 @@ -6,6 +6,14 @@ * YOSHIFUJI Hideaki @USAGI * Split up af-specific portion * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -66,6 +74,12 @@ } } }; +#ifdef CONFIG_XFRM_BEET + union { + struct in6_addr *in6; + struct in_addr *in; + } remotebeet, localbeet; +#endif int i; int err; int header_len = 0; @@ -78,6 +92,9 @@ struct dst_entry *dst1 = dst_alloc(&xfrm4_dst_ops); struct xfrm_dst *xdst; int tunnel = 0; +#ifdef CONFIG_XFRM_BEET + unsigned short beet_family = 0; +#endif if (unlikely(dst1 == NULL)) { err = -ENOBUFS; @@ -98,11 +115,28 @@ dst1->next = dst_prev; dst_prev = dst1; +#ifdef CONFIG_XFRM_BEET + if (xfrm[i]->props.mode == XFRM_MODE_TUNNEL) { +#else if (xfrm[i]->props.mode) { +#endif remote = xfrm[i]->id.daddr.a4; local = xfrm[i]->props.saddr.a4; tunnel = 1; } +#ifdef CONFIG_XFRM_BEET + else if (xfrm[i]->props.mode == XFRM_MODE_BEET) { + + beet_family = xfrm[i]->props.beet_family_out; + if(beet_family == AF_INET6){ + remotebeet.in6 = (struct in6_addr*)&xfrm[i]->id.daddr; + localbeet.in6 = (struct in6_addr*)&xfrm[i]->props.saddr; + } else if(beet_family == AF_INET){ + remotebeet.in = (struct in_addr*)&xfrm[i]->id.daddr; + localbeet.in = (struct in_addr*)&xfrm[i]->props.saddr; + } + } +#endif header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; @@ -113,6 +147,28 @@ &fl_tunnel, AF_INET); if (err) goto error; +#ifdef CONFIG_XFRM_BEET + } else if (beet_family) { + switch(beet_family) { + case AF_INET: + fl_tunnel.fl4_dst = remotebeet.in->s_addr; + fl_tunnel.fl4_src = localbeet.in->s_addr; + break; + case AF_INET6: + ipv6_addr_copy(&fl_tunnel.fl6_dst, remotebeet.in6); + ipv6_addr_copy(&fl_tunnel.fl6_src, localbeet.in6); + break; + default: + BUG_ON(1); + } + + err = xfrm_dst_lookup((struct xfrm_dst **) &rt, + &fl_tunnel, beet_family); + /* Without this, the BEET mode crashes + indeterministically -Abi */ + rt->peer = NULL; + rt_bind_peer(rt,1); +#endif } else dst_hold(&rt->u.dst); } diff -urN linux-2.6.12.2/net/ipv6/esp6.c linux-beet-2.6.12.2/net/ipv6/esp6.c --- linux-2.6.12.2/net/ipv6/esp6.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv6/esp6.c 2005-07-25 14:39:11.000000000 +0300 @@ -22,6 +22,16 @@ * Kunihiro Ishiguro * * This file is derived from net/ipv4/esp.c + * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * + * */ #include @@ -225,6 +235,13 @@ memcpy(skb->nh.raw, tmp_hdr, hdr_len); skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); ret = nexthdr[1]; +#ifdef CONFIG_XFRM_BEET + if(x->props.mode == XFRM_MODE_BEET && + x->props.beet_family_out == AF_INET) { + skb->nh.ipv6h->nexthdr = nexthdr[1]; + ret = 0;//This is because xfrm4_encap expects 0 if every thing is correct + } +#endif } out: @@ -365,7 +382,11 @@ if (crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len)) goto error; x->props.header_len = sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) +#else if (x->props.mode) +#endif x->props.header_len += sizeof(struct ipv6hdr); x->data = esp; return 0; diff -urN linux-2.6.12.2/net/ipv6/xfrm6_input.c linux-beet-2.6.12.2/net/ipv6/xfrm6_input.c --- linux-2.6.12.2/net/ipv6/xfrm6_input.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv6/xfrm6_input.c 2005-07-25 14:39:11.000000000 +0300 @@ -64,6 +64,12 @@ if (xfrm_state_check_expire(x)) goto drop_unlock; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + if (xfrm_beet_input(skb, x)) + goto drop_unlock; + } +#endif nexthdr = x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb); if (nexthdr <= 0) goto drop_unlock; @@ -80,7 +86,11 @@ xfrm_vec[xfrm_nr++].xvec = x; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { /* XXX */ +#endif if (nexthdr != IPPROTO_IPV6) goto drop; if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) @@ -97,6 +107,64 @@ skb->nh.raw = skb->data; decaps = 1; break; +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + struct iphdr *iph = skb->nh.iph; // miika: this masks input arg + struct ipv6hdr *ip6h = skb->nh.ipv6h; + int size=0; + __u8 proto=0; + __u8 hops=0; + __u16 total = ntohs(ip6h->payload_len); + + /* is the buffer a clone? + * then create identical copy of header of skb */ + if (skb_cloned(skb) && + pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) + goto drop; + if (x->props.beet_family_in == AF_INET) { + size = sizeof(struct iphdr); + proto = ip6h->nexthdr; + hops = ip6h->hop_limit; + } else if (x->props.beet_family_in == AF_INET6) + size = sizeof(struct ipv6hdr); + else + BUG_ON(1); + /* add data to the start of the buffer */ + skb_push(skb, size); + /* move the raw header into new space */ + memmove(skb->data, skb->nh.raw, size); + /* move MAC header */ + skb->mac.raw = memmove(skb->data - skb->mac_len, + skb->mac.raw, skb->mac_len); + skb->nh.raw = skb->data; + + switch(x->props.beet_family_in) { + case AF_INET: + + iph = (struct iphdr *)skb->nh.raw; + + skb->protocol = htons(ETH_P_IP); + iph->tot_len = htons(skb->len); + iph->frag_off = htons(IP_DF); + iph->check=0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + dst_release(skb->dst); + skb->dst = NULL; + + decaps = 1; + break; + + case AF_INET6: + ip6h->payload_len = htons(total + size); + --ip6h->hop_limit; + decaps = 1; + break; + default: + BUG_ON(1); + } + break; +#endif } if ((err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) < 0) diff -urN linux-2.6.12.2/net/ipv6/xfrm6_output.c linux-beet-2.6.12.2/net/ipv6/xfrm6_output.c --- linux-2.6.12.2/net/ipv6/xfrm6_output.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv6/xfrm6_output.c 2005-07-25 14:39:11.000000000 +0300 @@ -7,6 +7,14 @@ * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -17,6 +25,10 @@ #include #include +#ifdef CONFIG_XFRM_BEET +#include +#endif + /* Add encapsulation header. * * In transport mode, the IP header and mutable extension headers will be moved @@ -42,7 +54,12 @@ skb_push(skb, x->props.header_len); iph = skb->nh.ipv6h; + +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TRANSPORT) { +#else if (!x->props.mode) { +#endif u8 *prevhdr; int hdr_len; @@ -51,6 +68,16 @@ skb->h.raw = skb->data + hdr_len; memmove(skb->data, iph, hdr_len); return; + +#ifdef CONFIG_XFRM_BEET + } else if (x->props.mode == XFRM_MODE_BEET) { + + memmove(skb->data, skb->nh.raw, sizeof(struct ipv6hdr)); + skb->nh.raw = &((struct ipv6hdr *)skb->data)->nexthdr; + skb->h.ipv6h = ((struct ipv6hdr *)skb->data) + 1; + return; + +#endif /* CONFIG_XFRM_BEET */ } skb->nh.raw = skb->data; @@ -104,7 +131,11 @@ goto error_nolock; } +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_TUNNEL) { +#else if (x->props.mode) { +#endif err = xfrm6_tunnel_check_size(skb); if (err) goto error_nolock; @@ -121,6 +152,15 @@ if (err) goto error; +#ifdef CONFIG_XFRM_BEET + if (x->props.mode == XFRM_MODE_BEET) { + /* Change the outer header */ + err = xfrm_beet_output(skb); + if (err) + goto error; + } +#endif + x->curlft.bytes += skb->len; x->curlft.packets++; diff -urN linux-2.6.12.2/net/ipv6/xfrm6_policy.c linux-beet-2.6.12.2/net/ipv6/xfrm6_policy.c --- linux-2.6.12.2/net/ipv6/xfrm6_policy.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/ipv6/xfrm6_policy.c 2005-07-25 15:03:01.000000000 +0300 @@ -8,7 +8,14 @@ * IPv6 support * YOSHIFUJI Hideaki * Split up af-specific portion - * + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -84,6 +91,12 @@ } } }; +#ifdef CONFIG_XFRM_BEET + union { + struct in6_addr *in6; + struct in_addr *in; + } remotebeet, localbeet; +#endif int i; int err = 0; int header_len = 0; @@ -96,6 +109,9 @@ struct dst_entry *dst1 = dst_alloc(&xfrm6_dst_ops); struct xfrm_dst *xdst; int tunnel = 0; +#ifdef CONFIG_XFRM_BEET + unsigned short beet_family = 0; +#endif if (unlikely(dst1 == NULL)) { err = -ENOBUFS; @@ -118,11 +134,22 @@ dst1->next = dst_prev; dst_prev = dst1; +#ifdef CONFIG_XFRM_BEET + if (xfrm[i]->props.mode == XFRM_MODE_TUNNEL) { +#else if (xfrm[i]->props.mode) { +#endif remote = (struct in6_addr*)&xfrm[i]->id.daddr; local = (struct in6_addr*)&xfrm[i]->props.saddr; tunnel = 1; } +#ifdef CONFIG_XFRM_BEET + else if (xfrm[i]->props.mode == XFRM_MODE_BEET) { + beet_family = xfrm[i]->props.beet_family_out; + remotebeet.in6 = (struct in6_addr*)&xfrm[i]->id.daddr; + localbeet.in6 = (struct in6_addr*)&xfrm[i]->props.saddr; + } +#endif header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; @@ -133,6 +160,23 @@ &fl_tunnel, AF_INET6); if (err) goto error; +#ifdef CONFIG_XFRM_BEET + } else if (beet_family) { + switch(beet_family) { + case AF_INET: + fl_tunnel.fl4_dst = remotebeet.in->s_addr; + fl_tunnel.fl4_src = localbeet.in->s_addr; + break; + case AF_INET6: + ipv6_addr_copy(&fl_tunnel.fl6_dst, remotebeet.in6); + ipv6_addr_copy(&fl_tunnel.fl6_src, localbeet.in6); + break; + default: + BUG_ON(1); + } + err = xfrm_dst_lookup((struct xfrm_dst **) &rt, + &fl_tunnel, beet_family); +#endif } else dst_hold(&rt->u.dst); } diff -urN linux-2.6.12.2/net/key/af_key.c linux-beet-2.6.12.2/net/key/af_key.c --- linux-2.6.12.2/net/key/af_key.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/key/af_key.c 2005-07-25 14:39:12.000000000 +0300 @@ -12,6 +12,14 @@ * Kunihiro Ishiguro * Kazunori MIYAZAWA / USAGI Project * Derek Atkins + * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -28,6 +36,10 @@ #include #include +#ifdef CONFIG_XFRM_BEET +#include +#endif + #include #define _X2KEY(x) ((x) == XFRM_INF ? 0 : (x)) @@ -1584,7 +1596,11 @@ } /* addresses present only in tunnel mode */ +#ifdef CONFIG_XFRM_BEET + if (t->mode == IPSEC_MODE_TUNNEL-1) { +#else if (t->mode) { +#endif switch (xp->family) { case AF_INET: sin = (void*)(rq+1); @@ -1612,6 +1628,40 @@ return -EINVAL; } } +#ifdef CONFIG_XFRM_BEET + else if (t->mode == IPSEC_MODE_BEET-1) { + struct sockaddr *sa; + + sa = (struct sockaddr *)(rq+1); + switch(sa->sa_family) { + case AF_INET: + sin = (struct sockaddr_in *)sa; + t->saddr.a4 = sin->sin_addr.s_addr; + sin++; + if (sin->sin_family != AF_INET) + return -EINVAL; + t->id.daddr.a4 = sin->sin_addr.s_addr; + t->family = AF_INET; + + break; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + case AF_INET6: + sin6 = (struct sockaddr_in6 *)sa; + memcpy(t->saddr.a6, &sin6->sin6_addr, sizeof(struct in6_addr)); + sin6++; + if (sin6->sin6_family != AF_INET6) + return -EINVAL; + memcpy(t->id.daddr.a6, &sin6->sin6_addr, sizeof(struct in6_addr)); + t->family = AF_INET6; + + break; +#endif /* CONFIG_IPV6 */ + default: + return -EINVAL; + } + } +#endif /* CONFIG_XFRM_BEET */ + /* No way to set this via kame pfkey */ t->aalgos = t->ealgos = t->calgos = ~0; xp->xfrm_nr++; @@ -1935,6 +1985,78 @@ (err = parse_ipsecrequests(xp, pol)) < 0) goto out; +#ifdef CONFIG_XFRM_BEET + /* lookup the SA (xfrm_state) and copy the inner addresses from + * the policy (xfrm_policy) to the selector within the state + */ + if (xp->xfrm_vec[0].mode == IPSEC_MODE_BEET-1) { + struct xfrm_state *x; + if (xp->family == AF_INET6) { + if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET6))) { + /* Inner = 6, Outer = 6 */ + x->props.beet_family_out = AF_INET6; + x->props.beet_family_in = AF_INET6; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + else if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET))) { + /* Inner = 6, Outer = 4 */ + x->props.beet_family_out = AF_INET; + x->props.beet_family_in = AF_INET6; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + } else if (xp->family == AF_INET) { + if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET))) + { + /* Inner = 4, Outer = 4 */ + x->props.beet_family_out = AF_INET; + x->props.beet_family_in = AF_INET; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + else if ((x = xfrm_lookup_bydst(XFRM_MODE_BEET, + &xp->xfrm_vec[0].id.daddr, + &xp->xfrm_vec[0].saddr, + AF_INET6))) + { + /* Inner = 4, Outer = 6 */ + x->props.beet_family_out = AF_INET6; + x->props.beet_family_in = AF_INET; + /* insert inner addresses into the selector */ + memcpy( &x->sel.daddr, &xp->selector.daddr, + sizeof(xfrm_address_t)); + memcpy( &x->sel.saddr, &xp->selector.saddr, + sizeof(xfrm_address_t)); + x->type = xfrm_get_type(x->id.proto, x->props.beet_family_in); + } + + } else { + BUG_ON(1); + } + } +#endif out_skb = pfkey_xfrm_policy2msg_prep(xp); if (IS_ERR(out_skb)) { err = PTR_ERR(out_skb); diff -urN linux-2.6.12.2/net/xfrm/Kconfig linux-beet-2.6.12.2/net/xfrm/Kconfig --- linux-2.6.12.2/net/xfrm/Kconfig 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/xfrm/Kconfig 2005-07-25 15:04:36.000000000 +0300 @@ -10,3 +10,11 @@ If unsure, say Y. +config XFRM_BEET + bool "IPsec BEET mode" + depends on XFRM + ---help--- + IPsec BEET mode is combination of IPsec transport and tunnel mode. + Currently, it is used only by HIP. + + If unsure, say N. diff -urN linux-2.6.12.2/net/xfrm/Kconfig~ linux-beet-2.6.12.2/net/xfrm/Kconfig~ --- linux-2.6.12.2/net/xfrm/Kconfig~ 1970-01-01 02:00:00.000000000 +0200 +++ linux-beet-2.6.12.2/net/xfrm/Kconfig~ 2005-07-25 14:39:13.000000000 +0300 @@ -0,0 +1,28 @@ +# +# XFRM configuration +# +config XFRM_USER + tristate "IPsec user configuration interface" + depends on INET && XFRM + ---help--- + Support for IPsec user configuration interface used + by native Linux tools. + + If unsure, say Y. + +config XFRM_BEET + bool "IPsec BEET mode" + depends on XFRM + ---help--- + IPsec BEET mode is combination of IPsec transport and tunnel mode. + Currently, it is used only by HIP. + + If unsure, say N. + +config XFRM_BEET_DEBUG + bool "IPsec BEET mode debugging" + depends on XFRM_BEET + ---help--- + Enables BEET mode debugging via syslog. + + If unsure, say N. diff -urN linux-2.6.12.2/net/xfrm/Makefile linux-beet-2.6.12.2/net/xfrm/Makefile --- linux-2.6.12.2/net/xfrm/Makefile 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/xfrm/Makefile 2005-07-25 14:39:13.000000000 +0300 @@ -2,6 +2,6 @@ # Makefile for the XFRM subsystem. # -obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o +obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_input.o xfrm_algo.o xfrm_beet.o obj-$(CONFIG_XFRM_USER) += xfrm_user.o diff -urN linux-2.6.12.2/net/xfrm/xfrm_beet.c linux-beet-2.6.12.2/net/xfrm/xfrm_beet.c --- linux-2.6.12.2/net/xfrm/xfrm_beet.c 1970-01-01 02:00:00.000000000 +0200 +++ linux-beet-2.6.12.2/net/xfrm/xfrm_beet.c 2005-07-25 15:03:01.000000000 +0300 @@ -0,0 +1,227 @@ +/* + * xfrm_beet.c: allows for receiving and transmitting packet in BEET mode + * + * Authors: + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#ifdef CONFIG_XFRM_BEET + +/* xfrm_beet_output: deals with the outgoing BEET packets. + * It changes the outer ip header and correctly set + * the header fields + * + * @skb: structure sk_buff which contains the packet to be transmitted + * skb->data points to the ip header +*/ +int xfrm_beet_output(struct sk_buff *skb) +{ + int err = 0; + struct xfrm_state *x = skb->dst->xfrm; + + if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET){ + /* Inner = 4, Outer = 4 */ + struct iphdr *iph = (struct iphdr*)skb->data; + + iph->saddr = x->props.saddr.a4; + iph->daddr = x->id.daddr.a4; + + skb->local_df = 1; //I am a bit unsure on how to implement this -Abi + + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + } else if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET6){ + /* Inner = 4, Outer = 6 */ + struct iphdr *iph = (struct iphdr*)skb->data; + __u8 protocol, ttl; + + protocol = iph->protocol; + ttl = iph->ttl; + + if (skb_headroom(skb) < sizeof(struct ipv6hdr) - sizeof(struct iphdr)){ + if (pskb_expand_head(skb, sizeof(struct ipv6hdr) - sizeof(struct iphdr),0, GFP_ATOMIC)) + return -EINVAL; //Just returning from here. + + skb->len += sizeof(struct ipv6hdr) - sizeof(struct iphdr); + skb->nh.raw = skb->h.raw - sizeof(struct ipv6hdr); + skb->data = skb->nh.raw; + + } else { + skb_push(skb, sizeof(struct ipv6hdr) - sizeof(struct iphdr)); + skb->nh.raw = skb->h.raw - sizeof(struct ipv6hdr); + skb->data = skb->nh.raw; + } + + skb->protocol = htons(ETH_P_IPV6); + + skb->nh.ipv6h = (struct ipv6hdr*)(skb->data); + + skb->nh.ipv6h->version = 6; + skb->nh.ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); + skb->nh.ipv6h->nexthdr = protocol; + skb->nh.ipv6h->hop_limit = ttl; + ipv6_addr_copy(&skb->nh.ipv6h->saddr,(struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&skb->nh.ipv6h->daddr, (struct in6_addr *)&x->id.daddr); + + skb->nh.ipv6h->priority = 0; + skb->nh.ipv6h->flow_lbl[0] = 0; + skb->nh.ipv6h->flow_lbl[1] = 0; + skb->nh.ipv6h->flow_lbl[2] = 0; + + } else if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET){ + /* Inner = 6, Outer = 4 */ + struct ipv6hdr *iph = (struct ipv6hdr*)skb->data; + int delta = sizeof(struct ipv6hdr) - sizeof(struct iphdr); + u8 hop, proto; + u16 payload; + struct iphdr *ip4; + hop = iph->hop_limit; + proto = iph->nexthdr; + + payload = ntohs(iph->payload_len) + sizeof(struct iphdr); + + skb_pull(skb, delta); + + skb->protocol = htons(ETH_P_IP); + ip4 = (struct iphdr *)skb->data; + + ip4->ihl = (sizeof(struct iphdr) >> 2); + ip4->version = 4; + ip4->tos = 0; + ip4->tot_len = htons(payload); + ip4->id = 0; + ip4->frag_off = htons(IP_DF); + ip4->ttl = hop; + ip4->protocol = proto; + ip4->check = 0; + ip4->saddr = x->props.saddr.a4; + ip4->daddr = x->id.daddr.a4; + ip4->check = ip_fast_csum((unsigned char *)ip4, ip4->ihl); + /* The esp6_output assumes that skb->data points to outer IP header, + * skb->nh points eventual new ext hdrs and skb->h points to the ESP header + */ + skb->nh.raw = skb->data; // there is no extension header + + } else if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET6){ + /* Inner = 6, Outer = 6 */ + struct ipv6hdr *iph = (struct ipv6hdr*)skb->data; + ipv6_addr_copy(&iph->saddr, (struct in6_addr *)&x->props.saddr); + ipv6_addr_copy(&iph->daddr, (struct in6_addr *)&x->id.daddr); + } + + return err; +} +EXPORT_SYMBOL(xfrm_beet_output); + + +/* xfrm_beet_input: deals with the incoming BEET packets. + * It changes the outer ip header with the corresponding inner ip header and addresses + * + * @skb: structure sk_buff. skb->nh.raw points to the outer ip address + * skb->data and skb->h.raw point to the ESP to be decapsulated + * + * @x : struct xfrm_state containing the state information + * +*/ +int xfrm_beet_input(struct sk_buff *skb, struct xfrm_state *x) +{ + int err = 0; + + if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET){ + /* Inner = 4, Outer = 4 */ + struct iphdr *iph = (struct iphdr *)skb->nh.iph; + + iph->daddr = x->sel.daddr.a4; + iph->saddr = x->sel.saddr.a4; + iph->ttl--; + iph->tot_len = htons(skb->len); + iph->frag_off = htons(IP_DF); + iph->check = 0; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + } else if (x->props.beet_family_in == AF_INET && x->props.beet_family_out == AF_INET6){ + /* Inner = 4, Outer = 6 */ + struct iphdr *iph; + __u8 proto = skb->nh.ipv6h->nexthdr; + __u8 hops = skb->nh.ipv6h->hop_limit; + + + skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr) - sizeof(struct iphdr); + memmove(skb->h.raw, skb->data, skb->len); + skb->data = skb->h.raw; + + + eth_hdr(skb)->h_proto=htons(ETH_P_IP); + + iph = (struct iphdr *)skb->nh.raw; + memset(iph, 0, sizeof(struct iphdr)); + iph->daddr = x->sel.daddr.a4; + iph->saddr = x->sel.saddr.a4; + iph->ttl = hops--; + iph->protocol = proto; + iph->tot_len = htons(skb->len); + iph->frag_off = htons(IP_DF); + iph->ihl = 5; + iph->version = 4; + iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); + + skb->protocol = htons(ETH_P_IP); + + } else if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET){ + /* Inner = 6, Outer = 4 */ + struct ipv6hdr *ip6h; + int proto = skb->nh.iph->protocol; + int hops = skb->nh.iph->ttl; + int total = skb->len - sizeof(struct iphdr); + + if (skb_tailroom(skb) < sizeof(struct ipv6hdr) - sizeof(struct iphdr)){ + if (pskb_expand_head(skb, 0, sizeof(struct ipv6hdr) - sizeof(struct iphdr), GFP_ATOMIC)) + return -EINVAL; //Just returning from here. + } + + skb->h.raw = skb->nh.raw + sizeof(struct ipv6hdr); + memmove(skb->h.raw, skb->data, skb->len); + skb->data = skb->h.raw; + skb->tail += sizeof(struct ipv6hdr) - sizeof(struct iphdr); + + eth_hdr(skb)->h_proto=htons(ETH_P_IPV6); + ip6h = skb->nh.ipv6h; + + memset(ip6h, 0, sizeof(struct ipv6hdr)); + ipv6_addr_copy(&ip6h->saddr, (struct in6_addr *)&x->sel.saddr.a6); + ipv6_addr_copy(&ip6h->daddr, (struct in6_addr *)&x->sel.daddr.a6); + ip6h->payload_len = htons(total); + ip6h->hop_limit = hops-1; + ip6h->version = 6; + ip6h->nexthdr = proto; + + skb->protocol = htons(ETH_P_IPV6); + + } else if (x->props.beet_family_in == AF_INET6 && x->props.beet_family_out == AF_INET6){ + /* Inner = 6, Outer = 6 */ + struct ipv6hdr *ip6h = (struct ipv6hdr *)skb->nh.raw; + ipv6_addr_copy(&ip6h->daddr, + (struct in6_addr *) &x->sel.daddr.a6); + ipv6_addr_copy(&ip6h->saddr, + (struct in6_addr *) &x->sel.saddr.a6); + } + + return err; +} +EXPORT_SYMBOL(xfrm_beet_input); + +#endif /* CONFIG_XFRM_BEET */ diff -urN linux-2.6.12.2/net/xfrm/xfrm_policy.c linux-beet-2.6.12.2/net/xfrm/xfrm_policy.c --- linux-2.6.12.2/net/xfrm/xfrm_policy.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/xfrm/xfrm_policy.c 2005-07-25 14:39:13.000000000 +0300 @@ -11,6 +11,13 @@ * Split up af-specific portion * Derek Atkins Add the post_input processor * + * Changes: BEET support + * Abhinav Pathak + * Diego Beltrami + * Kristian Slavov + * Miika Komu + * Jeff Ahrenholz + * */ #include @@ -643,6 +650,10 @@ struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i]; if (tmpl->mode) { +#ifdef CONFIG_XFRM_BEET + if(tmpl->mode == XFRM_MODE_BEET) + family = tmpl->family; +#endif remote = &tmpl->id.daddr; local = &tmpl->saddr; } diff -urN linux-2.6.12.2/net/xfrm/xfrm_state.c linux-beet-2.6.12.2/net/xfrm/xfrm_state.c --- linux-2.6.12.2/net/xfrm/xfrm_state.c 2005-06-30 02:00:53.000000000 +0300 +++ linux-beet-2.6.12.2/net/xfrm/xfrm_state.c 2005-07-25 14:39:13.000000000 +0300 @@ -1036,3 +1036,31 @@ INIT_WORK(&xfrm_state_gc_work, xfrm_state_gc_task, NULL); } +#ifdef CONFIG_XFRM_BEET + +struct xfrm_state * +xfrm_lookup_bydst(u8 mode, xfrm_address_t *daddr, xfrm_address_t *saddr, unsigned short family) +{ + struct xfrm_state *x; + unsigned h = xfrm_dst_hash(daddr, family); + + list_for_each_entry(x, xfrm_state_bydst+h, bydst){ + + if (x->props.family == AF_INET6 && + ipv6_addr_equal((struct in6_addr *)daddr, (struct in6_addr *)x->id.daddr.a6) && + mode == x->props.mode && + ipv6_addr_equal((struct in6_addr *)saddr, (struct in6_addr *)x->props.saddr.a6)) { + return(x); + } + + if (x->props.family == AF_INET && + daddr->a4 == x->id.daddr.a4 && + mode == x->props.mode && + saddr->a4 == x->props.saddr.a4) + return(x); + + } + return(NULL); +} + +#endif //CONFIG_XFRM_BEET _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 26 11:34:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRSJ-0005Wv-FA; Tue, 26 Jul 2005 11:34:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxRSI-0005VL-0M for hipsec@megatron.ietf.org; Tue, 26 Jul 2005 11:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28305 for ; Tue, 26 Jul 2005 11:34:51 -0400 (EDT) Message-Id: <200507261534.LAA28305@ietf.org> Received: from mail-02.iinet.net.au ([203.59.3.34] helo=mail.iinet.net.au) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxRxG-0008J9-3c for hipsec@ietf.org; Tue, 26 Jul 2005 12:07:01 -0400 Received: (qmail 8309 invoked from network); 26 Jul 2005 15:34:30 -0000 Received: from unknown (HELO T40) (203.217.39.9) by mail.iinet.net.au with SMTP; 26 Jul 2005 15:34:21 -0000 From: "Joseph" To: Date: Wed, 27 Jul 2005 01:34:03 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcWPk32hHmK1X51kThy/dCS/telUug== X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Hipsec] Question about using SRTP transport formation with HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1198557285==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1198557285== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C5924B.47D5BEC0" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C5924B.47D5BEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I'm very interested in this new draft about SRTP with HIP. Is the mobility management in this scheme similar to that of ESP scheme in HIP? Thanks a lot Yours, Joseph ------=_NextPart_000_001C_01C5924B.47D5BEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
   I'm very=20 interested in this new draft about SRTP with HIP.  Is the = mobility=20 management in this scheme similar to that of ESP scheme in HIP? Thanks a = lot
Yours,
Joseph
------=_NextPart_000_001C_01C5924B.47D5BEC0-- --===============1198557285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1198557285==-- From hipsec-bounces@lists.ietf.org Tue Jul 26 16:22:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxVwR-0007qy-Kz; Tue, 26 Jul 2005 16:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxVwP-0007pT-Tx for hipsec@megatron.ietf.org; Tue, 26 Jul 2005 16:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21021 for ; Tue, 26 Jul 2005 16:22:15 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxWRW-0000tX-6R for hipsec@ietf.org; Tue, 26 Jul 2005 16:54:27 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6QKM4PG018833; Tue, 26 Jul 2005 22:22:04 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j6QKM4YA017686; Tue, 26 Jul 2005 22:22:04 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Jul 2005 22:22:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hipsec] Question about using SRTP transport formation with HIP Date: Tue, 26 Jul 2005 22:22:03 +0200 Message-ID: Thread-Topic: [Hipsec] Question about using SRTP transport formation with HIP Thread-Index: AcWPk32hHmK1X51kThy/dCS/telUugCi8GxA From: "Tschofenig, Hannes" To: "Joseph" , X-OriginalArrivalTime: 26 Jul 2005 20:22:04.0390 (UTC) FILETIME=[AFF90060:01C5921F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org hi joseph,=20 yes, the idea was to reuse the mobility management based on hip.=20 this effort was part of our investigation on the sip & hip interaction described in ciao hannes Dear All, I'm very interested in this new draft about SRTP with HIP. Is the mobility management in this scheme similar to that of ESP scheme in HIP? Thanks a lot Yours, Joseph _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 26 17:01:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWYJ-0002O8-HR; Tue, 26 Jul 2005 17:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWYF-0002O3-DW for hipsec@megatron.ietf.org; Tue, 26 Jul 2005 17:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23754 for ; Tue, 26 Jul 2005 17:01:20 -0400 (EDT) Received: from as2.itesm.mx ([200.34.200.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxX3M-000239-4R for hipsec@ietf.org; Tue, 26 Jul 2005 17:33:33 -0400 X-IronPort-AV: i="3.95,144,1120453200"; d="scan'208"; a="39780799:sNHT24020216" Received: from [10.17.130.20] by itesm.mx with HTTP; Tue, 26 Jul 2005 16:01:07 -0500 Date: Tue, 26 Jul 2005 15:01:07 -0600 Message-ID: <42E4C5810000169E@mailserver1.itesm.mx> From: "Alejandro Parra Briones" To: hipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] =?iso-8859-1?q?=BFIs_there_any_linux_based_NAT/FW_HIP_a?= =?iso-8859-1?q?ware_version=3F?= X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Dear HIP comunity: I am a HIP newbie. I am a full time professor at a University in Mexic= o. I have been reading the hip drafts. I am interested in the middle boxes p= roblem. I wonder if you have already working any NAT/FW HIP aware version. If not= I could help to make a prototype of a FW xor a NAT. Regards Alejandro Parra Briones Centro de Investigacion en Informatica CETEC 6to. Piso Torre norte 83284012 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 26 17:51:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxXKs-0007Cy-F5; Tue, 26 Jul 2005 17:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxXKr-0007CL-BX for hipsec@megatron.ietf.org; Tue, 26 Jul 2005 17:51:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26974 for ; Tue, 26 Jul 2005 17:51:34 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXpy-0003VL-JV for hipsec@ietf.org; Tue, 26 Jul 2005 18:23:47 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 412AC2D15; Wed, 27 Jul 2005 00:51:24 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E84352D11; Wed, 27 Jul 2005 00:51:23 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j6QLpNv29602; Wed, 27 Jul 2005 00:51:23 +0300 (EEST) Date: Wed, 27 Jul 2005 00:51:23 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Alejandro Parra Briones Subject: Re: [Hipsec] =?iso-8859-1?q?=BFIs_there_any_linux_based_NAT/FW_HIP_a?= =?iso-8859-1?q?ware_version=3F?= In-Reply-To: <42E4C5810000169E@mailserver1.itesm.mx> Message-ID: References: <42E4C5810000169E@mailserver1.itesm.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tue, 26 Jul 2005, Alejandro Parra Briones wrote: > Dear HIP comunity: > I am a HIP newbie. I am a full time professor at a University in Mexico. > I have been reading the hip drafts. I am interested in the middle boxes problem. > I wonder if you have already working any NAT/FW HIP aware version. If not > I could help to make a prototype of a FW xor a NAT. See e.g. http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-hip-natfw-traversal-02.txt for the references for SPINAT. Please ask the authors for more information. InfraHIP is working on FW and NAT on Linux. Please send further queries to "infrahip@hiit.fi". -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jul 27 02:08:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf5i-0000cH-UG; Wed, 27 Jul 2005 02:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf5f-0000Ze-SK for hipsec@megatron.ietf.org; Wed, 27 Jul 2005 02:08:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02077 for ; Wed, 27 Jul 2005 02:08:26 -0400 (EDT) Received: from web32512.mail.mud.yahoo.com ([68.142.207.222]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dxfar-0007kN-8B for hipsec@ietf.org; Wed, 27 Jul 2005 02:40:42 -0400 Received: (qmail 83637 invoked by uid 60001); 27 Jul 2005 06:08:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lZMbS55V9meejlV75HhV9yrGAgKmPRN2dQ4DEO6RysbgsTDbya80dZcdbKnrjZvp7+sroUAdk8NVB163QYRNfeFF0n6mGDs2WqTG28feSNcrLCZUZ6YGdBqwl4bKpiEu/uGBMPhWuYGb61M1kF3HXYP4YSAWMcxvQyL4sqoYY/w= ; Message-ID: <20050727060814.83635.qmail@web32512.mail.mud.yahoo.com> Received: from [84.154.47.131] by web32512.mail.mud.yahoo.com via HTTP; Tue, 26 Jul 2005 23:08:14 PDT Date: Tue, 26 Jul 2005 23:08:14 -0700 (PDT) From: Murugaraj Subject: [Hipsec] Is there any linux based NAT/FW HIP aware version? To: "Tschofenig, Hannes" , hipsec@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 4.1 (++++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1789718137==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1789718137== Content-Type: multipart/alternative; boundary="0-702116384-1122444494=:82268" --0-702116384-1122444494=:82268 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA02077 Hi, =20 We have already developed a initial version prototype for the HIP Regist= ration Protocol (without the inclusion of SPKI CERT). This is derived fro= m Boeing HIP Implementation (Linux). =20 ciao, Raj. "Tschofenig, Hannes" wrote: hi raj,=20 what could we tell him?=20 we have developed something.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: hipsec-bounces@lists.ietf.org [mailto:hipsec-bounces@lists.ietf.org]= Im Auftrag von Alejandro Parra Briones Gesendet: Dienstag, 26. Juli 2005 23:01 An: hipsec@ietf.org Betreff: [Hipsec] =BFIs there any linux based NAT/FW HIP aware version? Dear HIP comunity: I am a HIP newbie. I am a full time professor at a University in Mexico. I have been reading the hip drafts. I am interested in the middle boxes p= roblem. I wonder if you have already working any NAT/FW HIP aware version. If not I could help to make a prototype of a FW xor a NAT. Regards Alejandro Parra Briones Centro de Investigacion en Informatica CETEC 6to. Piso Torre norte 83284012 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec ADDRESS ::=20 =20 MURUGARAJ SHANMUGAM=20 Hoffanger Strasse 173,=20 D-81735 MUNICH,=20 GERMANY=20 Phone=20 Mobile : 0176-24025280 =09 --------------------------------- Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. --0-702116384-1122444494=:82268 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA02077
Hi,
 
 We have already developed a initial version prototype for the&= nbsp;HIP Registration Protocol (without the inclusion of SPKI CERT). This= is derived from Boeing HIP Implementation (Linux).
 
ciao,
Raj.

"Tschofenig, Hannes" <hannes.tschofenig@siemens= .com> wrote:
hi raj,

what could we tell him? <= BR>we have developed something.

ciao
hannes

-----Urspr=FC= ngliche Nachricht-----
Von: hipsec-bounces@lists.ietf.org [mailto:hips= ec-bounces@lists.ietf.org] Im Auftrag von Alejandro Parra Briones
Ges= endet: Dienstag, 26. Juli 2005 23:01
An: hipsec@ietf.org
Betreff: [= Hipsec] =BFIs there any linux based NAT/FW HIP aware version?


= Dear HIP comunity:
I am a HIP newbie. I am a full time professor at a = University in Mexico.
I have been reading the hip drafts. I am interes= ted in the middle boxes problem.
I wonder if you have already working = any NAT/FW HIP aware version. If not
I could help to make a prototype = of a FW xor a NAT.


Regards
Alejandro Parra Briones
Centr= o de Investigacion en Informatica
CETEC 6to. Piso Torre norte

83284012


_______________________________________= ________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.= ietf.org/mailman/listinfo/hipsec


ADDRESS ::
 
MURUGARAJ SHANMUGAM
Hoffanger Stra= sse 173,
D-81735 MUNICH,
GERMANY
Phone 
  &= nbsp;      Mobile : 0176-24025280

Do you Yahoo!?
=20 Yahoo! Mail - Helps pro= tect you from nasty viruses. --0-702116384-1122444494=:82268-- --===============1789718137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1789718137==-- From hipsec-bounces@lists.ietf.org Wed Jul 27 12:30:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoo5-0007Pl-UM; Wed, 27 Jul 2005 12:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoo4-0007Pc-MZ for hipsec@megatron.ietf.org; Wed, 27 Jul 2005 12:30:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12327 for ; Wed, 27 Jul 2005 12:30:53 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxpJL-0002vH-VM for hipsec@ietf.org; Wed, 27 Jul 2005 13:03:17 -0400 Received: from ganymede.students (ganymede.students [10.1.2.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 052CBDC57 for ; Wed, 27 Jul 2005 18:30:25 +0200 (CEST) Received: from esteban.students ([10.1.2.130]) by ganymede.students with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jul 2005 18:30:25 +0200 From: miriam.esteban@netlab.nec.de To: hipsec@ietf.org Date: Wed, 27 Jul 2005 18:30:23 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507271830.23948.miriam.esteban@netlab.nec.de> X-OriginalArrivalTime: 27 Jul 2005 16:30:25.0906 (UTC) FILETIME=[7E3E6520:01C592C8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] registration protocol - reg_failed parameter and update X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Dear all, while implementing the registration protocol, I have found some problems which I would like to report. DESCRIPTION: Once the RVS sends the R2 packet with the REG_FAILED parameter, the RVS hip machine remains in R2-SENT state until: - Some data is sent from the initiator. - Certain r2_sent_timeout has passed. The INITIATOR tries to re-register after the REG_FAILED, sending an update packet with a REG_REQUEST parameter. PROBLEM: RVS doesn't accept any update packets during the R2_SENT state (only in ESTABLISHED state). Impossible finishing the registration properly. SUGGESTION: a) Create a new transition between the R2-SENT state and ESTABLISHED state, when RVS receives an update packet. It could be implemented that only a HIP node acting as a RVS could accept this update packet in a R2-SENT state (or being more precise, only update packet including a REG_REQUEST parameter). If not, being more general (an easier to implement), any node could have this new transition. Do you see any downside for the normal base exchange with this addition? b) Forced the Initator to send some data so then RVS will move from R2-SENT to ESTABLISHED state. In this case, I don't see any downside will happen in the regular base exchange. Any comments? Thanks Miriam _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jul 27 15:03:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrC4-00079D-Vi; Wed, 27 Jul 2005 15:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrC2-00078p-4V for hipsec@megatron.ietf.org; Wed, 27 Jul 2005 15:03:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24007 for ; Wed, 27 Jul 2005 15:03:47 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxrhK-00083a-AY for hipsec@ietf.org; Wed, 27 Jul 2005 15:36:11 -0400 Received: from [192.150.187.154] (wifi154.icsi.berkeley.edu [192.150.187.154]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 27 Jul 2005 22:03:43 +0300 id 000A44F1.42E7DA8F.00004C7A Message-ID: <42E7DA68.40301@cs.helsinki.fi> Date: Wed, 27 Jul 2005 22:03:04 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Alejandro Parra Briones Subject: Re: [Hipsec] =?ISO-8859-1?Q?=BFIs_there_any_linux_based_?= =?ISO-8859-1?Q?NAT/FW_HIP_aware_version=3F?= References: <42E4C5810000169E@mailserver1.itesm.mx> In-Reply-To: <42E4C5810000169E@mailserver1.itesm.mx> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1531197468==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1531197468== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-19578-1122491024-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-19578-1122491024-0001-2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think it would be useful to have several implementations. Hence, it would be great if you can provide an open source NAT/FW traversal e.g. using STUN, see http://openhip.sourceforge.net/develop.html Andrei Alejandro Parra Briones wrote: >Dear HIP comunity: > I am a HIP newbie. I am a full time professor at a University in Mexico. >I have been reading the hip drafts. I am interested in the middle boxes problem. >I wonder if you have already working any NAT/FW HIP aware version. If not >I could help to make a prototype of a FW xor a NAT. > > >Regards >Alejandro Parra Briones >Centro de Investigacion en Informatica >CETEC 6to. Piso Torre norte > >83284012 > > >_______________________________________________ >Hipsec mailing list >Hipsec@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/hipsec > > --=_courier-19578-1122491024-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC AvAwggJZoAMCAQICAw6O2TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDI1MTAxMDI4WhcNMDYwNDI1MTAxMDI4 WjBgMQ8wDQYDVQQEEwZHdXJ0b3YxDzANBgNVBCoTBkFuZHJlaTEWMBQGA1UEAxMNQW5kcmVp IEd1cnRvdjEkMCIGCSqGSIb3DQEJARYVZ3VydG92QGNzLmhlbHNpbmtpLmZpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv/HBlES2QI1Dd00OrqhRWyfaw/779M7nBpaVaOwr TvumJ45t9b80teI3r5DFb7H4Ddvdsa+fYrzhhNwYyz6UHED/fvIiC3GEiYmz/9o6k8lrr8nU ch1NIgvcQvateZ9Vug5RaEy9AhRhxbITmevk+1kmpXJGxT/7IwyoN5H1Yl4P+usCBJYYK8o4 v/Dh4mpDT+drwKB7FRmXsYExDlDeY76K+E6u15rIL0KsU8NPTb3+R/0Pg/QCDeLu6/dILRhS 8nJCYZiXTPt+lqjhCRF/2kgcWknbyxssprdjxH4is1Up4m0vFLPlUAKllIW9Q1XK8z2qkMUk fUWO3WvglPc0/QIDAQABozIwMDAgBgNVHREEGTAXgRVndXJ0b3ZAY3MuaGVsc2lua2kuZmkw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAluIZsj/uZ3du6ZtzmvvqGEMFFAcRP N2HBHfR8H4kUmdGDYJ5U1BCUv6ELoKXXl/fyljyZnSSWWaxvUuSHldn8gWc9oGEkJoFaS+Bo 6L+8H9PzyD32AxrQSZ/UaAQsPqHRg+dy+M4ikmxVLzK+1xTFB2sIl5PmnRFsQUm2I10pbDCC 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/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDcyNzE5MDMwNFowIwYJ KoZIhvcNAQkEMRYEFGBqYgaWodNLTmUFyILDfGFdeEc7MFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOjtkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDo7ZMA0GCSqGSIb3DQEBAQUA BIIBAKerQtoOrO0ubqW0YRyeGjlLb5RQIriFj+DPh2fQZYmzpmT7WEtXQmIaKYPv8Dwo8WqI DqONffwSVBqNlxYfCqrwJIq8w32QFB9TTzjckk5u2bt/a4GCJYdaqiFdO7SuMSd6YUAN6RtI yzs2zX8yshZWrWFcLYqcDv1AYck//Et2MXp9Q5qkERXY3s2SWVEQBJEYojBgXfuLQgMVL9d2 aa/SFE4Q7xV/Ijl9Wbue4FFNgjVy/jQ5zhoUmOIrXvEuc9qgoBSN6EASae9O0tNrlB1101EK tBjMmuv3g7wOMpEjnywxLdEUHTatzqj7b5mMPfqvrKVJDVY/vo4ywpCnjpUAAAAAAAA= --=_courier-19578-1122491024-0001-2-- --===============1531197468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1531197468==-- From hipsec-bounces@lists.ietf.org Wed Jul 27 15:44:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxrpj-0002gn-S5; Wed, 27 Jul 2005 15:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxrpi-0002gi-Tq for hipsec@megatron.ietf.org; Wed, 27 Jul 2005 15:44:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27616 for ; Wed, 27 Jul 2005 15:44:48 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxsKz-0000vp-B3 for hipsec@ietf.org; Wed, 27 Jul 2005 16:17:12 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA05190; Wed, 27 Jul 2005 14:44:29 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6RJiTs27444; Wed, 27 Jul 2005 12:44:29 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 12:44:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] registration protocol - reg_failed parameter and update Date: Wed, 27 Jul 2005 12:44:28 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7FED@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] registration protocol - reg_failed parameter and update Thread-Index: AcWSyNkpz1O75JmYSEKcuC1K7BAWvwAGbtlg From: "Ahrenholz, Jeffrey M" To: , X-OriginalArrivalTime: 27 Jul 2005 19:44:28.0846 (UTC) FILETIME=[99FA0CE0:01C592E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a similar but different problem than R2_SENT in the base draft. I think (a) would be fine, relaxing the accepted states for UPDATEs for RVS nodes only. (Then this could be specified in the RVS draft.) I don't like (b) since the Initiator would be sending data even though it received REG_FAILED. -Jeff > SUGGESTION: > a) Create a new transition between the R2-SENT state and ESTABLISHED > state, when RVS receives an update packet. > It could be implemented that only a HIP node acting as a RVS=20 > could accept this=20 > update packet in a R2-SENT state (or being more precise, only=20 > update packet=20 > including a REG_REQUEST parameter). If not, being more=20 > general (an easier to=20 > implement), any node could have this new transition. Do you see any=20 > downside for the normal base exchange with this addition? > b) Forced the Initator to send some data so then RVS will=20 > move from R2-SENT to=20 > ESTABLISHED state. In this case, I don't see any downside=20 > will happen in the=20 > regular base exchange. >=20 > Any comments? >=20 > Thanks >=20 > Miriam >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 03:14:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2bS-0000hv-Lm; Thu, 28 Jul 2005 03:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2bN-0000fn-QS for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 03:14:46 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01623 for ; Thu, 28 Jul 2005 03:14:43 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42E619940011BAC8; Thu, 28 Jul 2005 09:14:13 +0200 From: Julien Laganier To: hipsec@ietf.org, miriam.esteban@netlab.nec.de Subject: Re: [Hipsec] registration protocol - reg_failed parameter and update Date: Thu, 28 Jul 2005 09:15:27 +0200 User-Agent: KMail/1.8 References: <200507271830.23948.miriam.esteban@netlab.nec.de> In-Reply-To: <200507271830.23948.miriam.esteban@netlab.nec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507280915.28094.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, [Thanks Miriam for bringing this issue to the list!] More below: On Wednesday 27 July 2005 18:30, miriam.esteban@netlab.nec.de wrote: > > DESCRIPTION: > Once the RVS sends the R2 packet with the REG_FAILED parameter, the > RVS hip machine remains in R2-SENT state until: > - Some data is sent from the initiator. > - Certain r2_sent_timeout has passed. > The INITIATOR tries to re-register after the REG_FAILED, sending an > update packet with a REG_REQUEST parameter. > > PROBLEM: > RVS doesn't accept any update packets during the R2_SENT state > (only in ESTABLISHED state). Impossible finishing the registration > properly. After reading more [I-D.ietf-base], I'd suggest the WG to change, in the R2-SENT description, the sentence "Receive data, move to ESTABLISHED" into "Receive data or UPDATE, move to ESTABLISHED". It doesn't seems no negatively impact the base exchange (R2_SENT was created to allow to retransmit R2 without dropping the current assoication, which is still possible with this addition) and allows to solve the issue Miriam found with the registration protocol (no user data is sent so the RVS is stuck in R2-SENT until timeout). Here is the modified text (along with the removal of UAL text in R2-SENT I proposed earlier in ): ------------------------------------------------------------- +---------+ | R2-SENT | Waiting to finish HIP +---------+ Receive I1, send R1 and stay at R2-SENT 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 data or UPDATE, move to ESTABLISHED Exchange Complete Timeout, transition to ESTABLISHED. ------------------------------------------------------------- Opinions welcomed. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 05:27:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4fa-0006DS-7T; Thu, 28 Jul 2005 05:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4fY-0006Cr-HL for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 05:27:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09366 for ; Thu, 28 Jul 2005 05:27:10 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5Aw-000659-MK for hipsec@ietf.org; Thu, 28 Jul 2005 05:59:42 -0400 Received: from ganymede.students (ganymede.students [10.1.2.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A44E915245 for ; Thu, 28 Jul 2005 11:26:59 +0200 (CEST) Received: from esteban.students ([10.1.2.130]) by ganymede.students with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 11:26:59 +0200 From: Miriam Esteban To: hipsec@ietf.org Date: Thu, 28 Jul 2005 11:26:58 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200507281126.58755.miriam.esteban@netlab.nec.de> X-OriginalArrivalTime: 28 Jul 2005 09:26:59.0657 (UTC) FILETIME=[815A3390:01C59356] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] registration protocol - failure types X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Dear all again, I have also found this while implementing the registration protocol: DESCRIPTION: =46ailure types described in the hip-registration draft don't include a pos= sible=20 error while requesting lifetime or registration types not offered by the=20 registrar. Case 1. =A0=A0=A0=A0=A0=A0=A0=A0Lifetime requested < Minimum Lifetime offer= ed or =A0=A0=A0=A0=A0=A0Lifetime requested > Maximum Lifetime offered =20 Case 2. =A0=A0=A0=A0=A0=A0=A0=A0Registration type !=3D Registration type of= fered (In the case of=20 RVS type 1)=A0 SUGGESTION: Create two more failure types for these cases.=20 In our implementation we use: Case 1. Failure Type: 1 Case 2. Failure Type: 2 I have read in the list that other implementations of the the registration= =20 protocol have been done. Did you find any more error cases? What values do= =20 you use? Any comments are welcome. Thanks. Miriam _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 05:57:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy58Q-0006mn-E2; Thu, 28 Jul 2005 05:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy58K-0006li-DN for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 05:57:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11442 for ; Thu, 28 Jul 2005 05:56:53 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5di-00076N-Re for hipsec@ietf.org; Thu, 28 Jul 2005 06:29:26 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EDA67212C8E; Thu, 28 Jul 2005 12:56:34 +0300 (EEST) In-Reply-To: <200507280915.28094.julien.IETF@laposte.net> References: <200507271830.23948.miriam.esteban@netlab.nec.de> <200507280915.28094.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <011A956D-D70D-4124-9718-0BB04C5257FA@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] registration protocol - reg_failed parameter and update Date: Thu, 28 Jul 2005 11:56:34 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> DESCRIPTION: >> Once the RVS sends the R2 packet with the REG_FAILED parameter, the >> RVS hip machine remains in R2-SENT state until: >> - Some data is sent from the initiator. >> - Certain r2_sent_timeout has passed. >> The INITIATOR tries to re-register after the REG_FAILED, sending an >> update packet with a REG_REQUEST parameter. >> >> PROBLEM: >> RVS doesn't accept any update packets during the R2_SENT state >> (only in ESTABLISHED state). Impossible finishing the registration >> properly. >> > > After reading more [I-D.ietf-base], I'd suggest the WG to change, in > the R2-SENT description, the sentence "Receive data, move to > ESTABLISHED" into "Receive data or UPDATE, move to ESTABLISHED". Sounds fine to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 06:04:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5FY-0000Kq-Ek; Thu, 28 Jul 2005 06:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5FW-0000Ki-35 for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 06:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12235 for ; Thu, 28 Jul 2005 06:04:19 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5kw-0007S3-Je for hipsec@ietf.org; Thu, 28 Jul 2005 06:36:51 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E00EA212C93; Thu, 28 Jul 2005 13:04:11 +0300 (EEST) In-Reply-To: <200507281126.58755.miriam.esteban@netlab.nec.de> References: <200507281126.58755.miriam.esteban@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1395B672-B544-4AB5-8A7D-27B08BB5341F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] registration protocol - failure types Date: Thu, 28 Jul 2005 12:04:12 +0200 To: Miriam Esteban X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > I have also found this while implementing the registration protocol: > > DESCRIPTION: > Failure types described in the hip-registration draft don't include > a possible > error while requesting lifetime or registration types not offered > by the > registrar. > Case 1. Lifetime requested < Minimum Lifetime offered or > Lifetime requested > Maximum Lifetime offered I think in these cases just use the minimum or maximum lifetime, and accept the registration. No error code is needed, AFAIK. The draft apparently needs to be updated. > Case 2. Registration type != Registration type offered (In > the case of > RVS type 1) Yes, I think there should be an error code for this. A table for failure types needs to be added, and the IANA considerations section needs to be updated. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From dlvjybvseokyre@hotmail.com Thu Jul 28 06:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5Lh-0002eb-58; Thu, 28 Jul 2005 06:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12582; Thu, 28 Jul 2005 06:10:42 -0400 (EDT) Received: from [219.146.111.90] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy5r6-0007eQ-Dx; Thu, 28 Jul 2005 06:43:14 -0400 Received: from .webhost6.alterusa.com id CFB62604DE; Thu, 28 Jul 2005 14:11:05 +0300 Received: by .webhost6.starnetusa.net (Postfix, from userid 891) id CFB60784DE; Thu, 28 Jul 2005 04:07:05 -0700 Date: Thu, 28 Jul 2005 10:11:05 -0100 Message-Id: <29061130090241.CFB4673DE@.starnetusa.net> From: "Marlene Boone" To: rserpool-request@ietf.org Cc: rsvp-archive@ietf.org, saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, secdir@ietf.org Subject: Cailis Softabs is the Best zFeoSh X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a "Ci-ialis Softabs" is better than Pfizer Viiagrra and normal Ci-ialis because: - Guaaraantees 36 hours lasting - Safe to take, no side effects at all - Boost and increase se-xual performance - Haarder e-rectiions and quick recharge - Proven and certified by experts and doctors - only $3.99 per tabs Cllick heree: http://pockmarked.com/cs/?ronn o-ut of mai-lling lisst: http://pockmarked.com/rm.php?ronn Cz8V From hipsec-bounces@lists.ietf.org Thu Jul 28 06:12:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5N6-000383-17; Thu, 28 Jul 2005 06:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5N5-00037y-FI for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 06:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12694 for ; Thu, 28 Jul 2005 06:12:08 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5sT-0007ht-SM for hipsec@ietf.org; Thu, 28 Jul 2005 06:44:41 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2A7CD2D65; Thu, 28 Jul 2005 13:11:54 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C51122D5D for ; Thu, 28 Jul 2005 13:11:53 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j6SABrC01208; Thu, 28 Jul 2005 13:11:53 +0300 (EEST) Date: Thu, 28 Jul 2005 13:11:53 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Hipsec] base exchange implementation feedback X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org We had interops with Jeff yesterday. Once again, OpenHIP and HIPL base exchange interoperated successfully. Jeff said that OpenHIP and Ericsson's BSD HIP base exchange interoperated as well. I hope we get an RFC soon because the draft seems quite mature and technically sound to me. All of the changes introduced between base-02 and base-03 were implementable and reasonable. We have few editorial suggestion based on some minor implementation caveats we run into: * ESP_INFO usage in the base exchange: mention explicitly what to fill in the fields in both the initiator and responder * Parameter type order strictly enforced, except for 2048-4095 * Put this explicitly separate sentence rather than in a in the subordinate clause ("The type-field value also describes the order of these fields in the packet, except..) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From ima-bounces@ietf.org Thu Jul 28 06:12:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5NG-00038z-MK; Thu, 28 Jul 2005 06:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5N9-00038J-7i for ima@megatron.ietf.org; Thu, 28 Jul 2005 06:12:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12699 for ; Thu, 28 Jul 2005 06:12:12 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy5sQ-0007h9-Uu for ima@ietf.org; Thu, 28 Jul 2005 06:44:44 -0400 Received: (eyou send program); Thu, 28 Jul 2005 18:11:25 +0800 Message-ID: <322545485.24511@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Thu, 28 Jul 2005 18:11:25 +0800 Message-ID: <004301c5935c$8bc1b7d0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "John C Klensin" , "yangwoo ko" References: <42E84BFB.10903@icu.ac.kr> <322525649.01966@cnnic.cn> Subject: Re: [Ima] ALT-address Date: Thu, 28 Jul 2005 18:10:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2063443344==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============2063443344== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQppZiBhbHQtYWRkcmVzcyBpcyB1c2VkLCBhcyBhbiBJTUEgdXNlciwgSSBwcmVmZXIgdGhhdCB0 aGUgYWRkcmVzcyBpcyBjb21wdXRlZCBpbnN0ZWFkIG9mIGlucHV0aW5nIGl0Lg0KDQpKaWFua2Fu ZyBZQU8NCkNOTklDDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4g QyBLbGVuc2luIiA8a2xlbnNpbkBqY2suY29tPg0KVG86ICJ5YW5nd29vIGtvIiA8bmV3Y2F0QGlj dS5hYy5rcj47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVseSAyOCwgMjAwNSAx MjozOSBQTQ0KU3ViamVjdDogUmU6IFtJbWFdIEFMVC1hZGRyZXNzDQoNCg0KPiANCj4gDQo+IC0t T24gVGh1cnNkYXksIDI4IEp1bHksIDIwMDUgMTI6MDcgKzA5MDAgeWFuZ3dvbyBrbw0KPiA8bmV3 Y2F0QGljdS5hYy5rcj4gd3JvdGU6DQo+IA0KPiA+IA0KPiA+IFJlc2VuZGluZyBqdXN0IHRvIHRl c3Qgd2hldGhlciB0aGUgbWFpbGlzdCBsaXN0IHdvcmtzIGZvcg0KPiA+IG1lIGFuZCB0byBnZXQg c29tZSByZXNwb25kcyBmcm9tIG90aGVycyByZWdhcmRpbmcgdGhpcw0KPiA+IGlzc3VlLg0KPiAN Cj4gSSBhcG9sb2dpemUgZm9yIG5vdCByZXNwb25kaW5nIHRvIHRoZSBlYXJsaWVyIGNvcHkgb2Yg dGhpcyBub3RlDQo+IHdoaWNoIHlvdSBzZW50IG1lIHNlcGFyYXRlbHkgKHByb2JhYmx5IGFmdGVy IGRpc2NvdmVyaW5nIHRoYXQgSQ0KPiB3YXNuJ3Qgb24gdGhlIG90aGVyIGxpc3QpLiAgIEZvciB5 b3VyIGluZm9ybWF0aW9uIGFuZCB0aGF0IG9mDQo+IG90aGVycywgSSBhbSB3b3JraW5nIHZlcnkg aGFyZCB0byBnZXQgcmVhZHkgdG8gbGVhdmUgZm9yIFBhcmlzDQo+IGFuZCB0byBmaW5pc2ggb3Ro ZXIgd29yayB0aGF0IG5lZWRzIHRvIGJlIGRvbmUgZmlyc3QuICBUaGVzZQ0KPiB0ZWNobmljYWwg bm90ZXMgb24gdGhlIElNQSB0b3BpYyB0YWtlIG1lIGEgbG9uZyB0aW1lIHRvIHdyaXRlDQo+IGJl Y2F1c2UgdGhlIGlzc3VlcyBhcmUgY29tcGxleCBhbmQgSSB3YW50IHRvIGFuc3dlciBwcmVjaXNl bHkuDQo+IEJ1dCB0aGF0IG1lYW5zIHlvdSB3aWxsIHByb2JhYmx5IHNlZSBmZXdlciBhbmQgZmV3 ZXIgcmVzcG9uc2VzDQo+IGJldHdlZW4gbm93IGFuZCBuZXh0IHdlZWsuDQo+IA0KPiBNb3JlIGJl bG93Lg0KPiANCj4gPi4uLiANCj4gPiBJIHdvdWxkIGxpa2UgdG8gYXNrL3JhaXNlIHRocmVlIHF1 ZXN0aW9ucy9pc3N1ZXMgcmVnYXJkaW5nDQo+ID4gdGhlIEFMVC1hZGRyZXNzLiBUaG91Z2ggc29t ZSBvZiB0aGVtIG1heSBiZSBiZXlvbmQgdGhlIHNjb3BlDQo+ID4gb2Ygb3VyIGRyYWZ0IGFuZCB5 b3Vycywgd2UgbmVlZCB0byBjb25zaWRlciB0aGVtIHRvIG1ha2UNCj4gPiBJLWVtYWlsIHdvcmth YmxlIGluIHJlYWwgd29ybGQuDQo+ID4gDQo+ID4gKDEpIEhvdyB0byBlbnRlciBpdD8NCj4gPiAN Cj4gPiBBY2NvcmRpbmcgdG8geW91ciBkcmFmdCwgd2Ugc2hvdWxkIG5vdCB0cnkgdG8gZ2VuZXJh dGUgYW4NCj4gPiBBTFQtYWRkcmVzcyBmcm9tIGFuIEktZW1haWwtYWRkcmVzcy4gSXQgbWVhbnMg dGhlcmUgc2hvdWxkDQo+ID4gYmUgYSB3YXkgZm9yIGEgdXNlciB0byBvYnRhaW4gdGhlIEFMVC1h ZGRyZXNzIGFuZCBpbnB1dCBpdA0KPiA+IGludG8gTVVBLiBPbmUgb2YgcG9zc2libGUgd2F5cyBp cyB0byB1c2UgZWxlY3Ryb25pYyBuYW1lDQo+ID4gY2FyZCAoZS5nLiB2Q2FyZCkuIEFzIG9mIHRv ZGF5LCB3ZSBvYnRhaW4gZW1haWwgYWRkcmVzc2VzDQo+ID4gaW4gdmFyaW91cyB3YXlzLiBXZSBt YXkgY29weSBhbmQgcGFzdGUgdGhlbSBmcm9tICh3ZWIpDQo+ID4gZG9jdW1lbnRzLiBXZSBtYXkg Z2V0IHRoZW0gZHVyaW5nIHBob25lIGNhbGxzLiBGb3IgdGhvc2UNCj4gPiBub24gc3RydWN0dXJl ZCBvciBvZmYtbGluZSBzaXR1YXRpb25zLCBob3cgY2FuIHdlIGRlbGl2ZXINCj4gPiB0aGUgQUxU LWFkZHJlc3Mgd2l0aG91dCB0b28gbXVjaCBwYWluPw0KPiANCj4gUGxlYXNlIHNlZSBteSBub3Rl IGZyb20geWVzdGVyZGF5LiAgVGFrZSBhIHBob25lIGNhbGwgYXMgYW4NCj4gZXhhbXBsZS4gIElm IHlvdSBzcGVhayBvbiB0aGUgcGhvbmUgdG8gYSBjb2xsZWFndWUgaW4gS29yZWEsIHlvdQ0KPiB3 aWxsIHByZXN1bWFibHkgZ2l2ZSBoaW0gb3IgaGVyIHlvdXIgYWRkcmVzcyBpbiBLb3JlYW4uICBZ b3UgY2FuDQo+IGFsc28gdmVyaWZ5IHRoYXQgYWRkcmVzcyBjYW4gYmUgdXNlZCBieSBib3RoIG9m IHlvdS4gIFNvIHRoZXJlDQo+IGlzIG5vIG5lZWQgdG8gaGF2ZSBhbiBBbHQtQWRkcmVzcyBhdCBh bGwuICAgQnkgY29udHJhc3QsIGlmIHlvdQ0KPiBhbmQgSSB0YWxrIG9uIHRoZSBwaG9uZSwgeW91 IGFyZSBnb2luZyB0byBnaXZlIG1lIGFuIEFTQ0lJDQo+IGFkZHJlc3MgYmVjYXVzZSwgaWYgeW91 IHByb25vdW5jZWQgeW91ciBLb3JlYW4gYWRkcmVzcyB0byBtZSwgSQ0KPiB3b3VsZCBoYXZlIG5v IGlkZWEgd2hhdCB0byBkbyB3aXRoIGl0LCBzaW5jZSBJIGNhbm5vdCB3cml0ZSwgb3INCj4gZXZl biBlZmZlY3RpdmVseSBsb29rIHVwLCBlaXRoZXIgSGFuamkgb3IgSGFuZ3VsIGNoYXJhY3RlcnMu DQo+IFNvLCBhZ2FpbiwgeW91IHdvdWxkIG5vdCBuZWVkIGFuIEFsdC1BZGRyZXNzLiAgIA0KPiAN Cj4gSW4gcHJhY3RpY2UsIEkgYmVsaWV2ZSB0aGF0IHRoZSBBbHQtQWRkcmVzc2VzIGFyZSBuZWVk ZWQgb25seQ0KPiB3aGVuIChpKSB5b3UgYXJlIGNvbW11bmljYXRpbmcgd2l0aCBzb21lb25lIGZv ciB3aG9tIHlvdXINCj4gbmF0aXZlLXNjcmlwdCBhZGRyZXNzIGlzIGludGVsbGlnaWJsZSBhbmQg KGlpKSB5b3UgZG8ga25vdyB0aGUNCj4gc3RhdGUgb2YgZWFjaCBvdGhlcidzIG1haWwgc2VydmVy cyBvciB0aGUgcGF0aCBiZXR3ZWVuIHRoZW0uDQo+IFRoYXQgY2FzZSB3aWxsIGNlcnRhaW5seSBv Y2N1ciwgYnV0IGl0IG1heSBub3QgYmUgY29tbW9uIGluDQo+IHByYWN0aWNlLg0KPiANCj4gVGhl cmUgYXJlIGFjdHVhbGx5IGEgdmVyeSBsYXJnZSBudW1iZXIgb2Ygd2F5cyBieSB3aGljaCB0aGUN Cj4gcHVycG9zZSBvZiBhbiBBbHQtQWRkcmVzcyBjb3VsZCBiZSBhY2NvbXBsaXNoZWQuICBXaGF0 IEkgZG9uJ3QNCj4gdGhpbmsgYW55b25lIGhhcyBkb25lIGlzIHRvIHJlYWxseSB3b3JrIHRocm91 Z2ggYWxsIG9mIHRoZSBjYXNlcw0KPiAoY2VydGFpbmx5IEkgaGF2ZSBub3QpLiAgV2hpY2ggb25l cyBhcmUgbW9zdCBlZmZlY3RpdmUgZGVwZW5kIG9uDQo+IGFzc3VtcHRpb25zIGFib3V0IGFkZHJl c3MgYm9va3MsIHNlcnZlciBhdmFpbGFiaWxpdHksIGFuZCBzbyBvbi4NCj4gRm9yIHRoYXQgcHVy cG9zZSwgSSB0aGluayB3ZSBhcmUgZ29pbmcgdG8gbmVlZCBhIGZhY2UtdG8tZmFjZQ0KPiBtZWV0 aW5nIGFuZCBhIHdoaXRlYm9hcmQgdG8gYWN0dWFsbHkgdHJ5IHRvIGRvIHNvbWUgZW5naW5lZXJp bmcNCj4gZGVzaWduIHdvcmsgdG9nZXRoZXIuDQo+IA0KPiBMZXQgbWUgZ2l2ZSB0d28gZXhhbXBs ZXMgd2hpY2ggYXJlIGFjdHVhbGx5IGFsdGVybmF0aXZlcyB0byB0aGUNCj4gQWx0LUFkZHJlc3Mg aWRlYSwgcmF0aGVyIHRoYW4gYW5zd2VycyB0byB0aGUgcXVlc3Rpb24gb2YgaG93IG9uZQ0KPiBv YnRhaW5zIG9uZToNCj4gDQo+IChpKSBJbnN0ZWFkIG9mIHB1dHRpbmcgYW4gYWx0LWFkZHJlc3Mg aW4gYXMgYSBwYXJhbWV0ZXIsDQo+IG9uZSB1c2VzIGFuIExEQVAgKG9yIGVxdWl2YWxlbnQpIHNl cnZlciB3aG9zZSBhZGRyZXNzDQo+IGVpdGhlciBhcHBlYXJzIGFzIGEgcGFyYW1ldGVyIG9yIGlz IG9idGFpbmVkIGJ5IGENCj4gc2VydmljZS1sb2NhdGlvbiBETlMgcXVlcnkgYXNzb2NpYXRlZCB3 aXRoIHRoZSBkb21haW4NCj4gcGFydCBvZiB0aGUgYWRkcmVzcy4gIElmIHRoZSBwcmltYXJ5LCBp bnRlcm5hdGlvbmFsaXplZCwNCj4gYWRkcmVzcyBpcyB1bnVzYWJsZSwgdGhlIFNNVFAgc2VuZGVy IHF1ZXJpZXMgdGhlIExEQVANCj4gc2VydmVyIHdpdGggdGhlIGkxOG4gYWRkcmVzcyBhbmQgZ2V0 cyBiYWNrIGENCj4gY29ycmVzcG9uZGluZyBBU0NJSSBzdHJpbmcuICBPZiBjb3Vyc2UsIHRoaXMg d291bGQNCj4gcmVxdWlyZSB0aGF0IHRoZSBMREFQIHNlcnZlciBleGlzdCBhbmQgYmUgcG9wdWxh dGVkIHdpdGgNCj4gdGhlIHJlbGV2YW50IHJlY29yZHMsIGJ1dCBpdCBjb21wbGV0ZWx5IHJlbW92 ZXMgdGhlDQo+IGJ1cmRlbiBmcm9tIHRoZSBlbmQgdXNlci4NCj4gDQo+IChpaSkgSW5zdGVhZCBv ZiBwdXR0aW5nIGFuIGFsdC1hZGRyZXNzIGluIGFzIGENCj4gcGFyYW1ldGVyLCB3ZSB1c2UgdGhl IGV4aXN0aW5nIFZSRlkgY29tbWFuZCB0byBzdXBwb3J0IGENCj4gc2xpZ2h0bHkgbmV3IGZ1bmN0 aW9uLCBidXQgb25lIHRoYXQgaXMgY29uc2lzdGVudCB3aXRoDQo+IGl0cyBkZWZpbml0aW9uIChh cyBsb25nIGFzIFVURi04IFZSRlkgYXJndW1lbnRzIGFyZQ0KPiBwZXJtaXR0ZWQgYnkgd2hhdGV2 ZXIgRVNNVFAgZXh0ZW5zaW9uIHBlcm1pdHMgaTE4bg0KPiBhZGRyZXNzZXMgYXQgYWxsKS4gICBJ ZiB0aGUgcHJpbWFyeSwgaW50ZXJuYXRpb25hbGl6ZWQsDQo+IGkxOG4gYWRkcmVzcyBpcyB1bnVz YWJsZSwgdGhlIGNsaWVudCBzZW5kcyBWUkZZIHdpdGgNCj4gdGhhdCBhZGRyZXNzIHRvIHRoZSBz ZXJ2ZXIgZm9yIHRoZSBtYWlsYm94IGRvbWFpbiBhbmQNCj4gdGhhdCBzZXJ2ZXIgcmV0dXJucyBh biBhcHByb3ByaWF0ZSBBU0NJSSBhZGRyZXNzLiANCj4gDQo+IFRoZSBzZWNvbmQgb2YgdGhlc2Ug ZG9lcyBub3QgcmVxdWlyZSBlbmQgdXNlciBpbnRlcnZlbnRpb24gb3INCj4ga25vd2xlZGdlLCBh bHRob3VnaCBpdCBwcm9iYWJseSByZXF1aXJlcyB0aGUgYWJpbGl0eSB0byByZWFkIHRoZQ0KPiBs b2NhbCBhbGlhcyB0YWJsZS4gIEluIGJvdGggY2FzZXMsIHRoZXJlIGFyZSBpc3N1ZXMgd2l0aCBy ZWxheXMNCj4gYW5kIG9mZmxpbmUgdXNlcnMgdGhhdCBJIGhhdmUgbm90IGV4cGxvcmVkLiAgQnV0 IHRoZSBwb2ludCBpcw0KPiB0aGF0IHRoZXJlIGFyZSBtYW55IG9wdGlvbnMgcG9zc2libGUuDQo+ IA0KPiA+ICgyKSBDYW4gSSBleHRyYWN0IGJvdGggSS1lbWFpbC1hZGRyZXNzIGFuZCBBTFQtYWRk cmVzcyBmcm9tDQo+ID4gZW1haWwgbWVzc2FnZXM/DQo+ID4gDQo+ID4gQUxULWFkZHJlc3NlcyBh cmUgZGVmaW5lZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgU01UUC4gVGh1cywNCj4gPiB3ZSBkbyBu b3QgaGF2ZSB0aGVtIGluIG1haWwgbWVzc2FnZXMgaW4gbXkgYm94LiBUaGVuLCBob3cNCj4gPiBj YW4gSSBnZW5lcmF0ZSB0aGUgcHJvcGVyIEFMVC1hZGRyZXNzZXMgKG9yIEktZW1haWwtYWRkcmVz c2VzKQ0KPiA+IGZyb20gZW1haWwgYWRkcmVzc2VzIGFwcGVhcmVkIGluIG1lc3NhZ2UgaGVhZGVy PyBZb3UgZHJhZnQNCj4gPiBtZW50aW9ucyBvbmx5IFJldHVybi1QYXRoIGZpZWxkLiBXaGF0IGFi b3V0IG90aGVyIGZpZWxkcz8NCj4gDQo+IExhcmdlbHkgYmVjYXVzZSBJIGp1c3QgcmFuIG91dCBv ZiB0aW1lLCBidXQgcGFydGlhbGx5IGJlY2F1c2UsDQo+IGFnYWluLCB0aGUgaXNzdWVzIGhhdmUg bm90IGJlZW4gZXhwbG9yZWQgZnVsbHkgZW5vdWdoLCB0aGUgZHJhZnQNCj4gZG9lcyBzb21lIGhh bmQgd2F2aW5nIGFib3V0IGhlYWRlcnMgYW5kIHRoZW4gcG9pbnRzIHRvIFBhdWwNCj4gSG9mZm1h bidzIGxvbmctZXhwaXJlZCBkcmFmdCBhYm91dCBqdXN0IG1ha2luZyB0aGUgZW50aXJlIGhlYWRl cg0KPiBjb2xsZWN0aW9uIGludG8gVVRGLTguICBNeSByZWNvbGxlY3Rpb24gb2YgdGhlIGRpc2N1 c3Npb24gb2YgMTgNCj4gbW9udGhzIG9yIHNvIGFnbyB3YXMgdGhhdCB3ZSBjb25zaWRlcmVkIGJv dGggdGhlIG9wdGlvbiBvZg0KPiBoYXZpbmcgc29tZSBoZWFkZXJzIGV4aXN0IGluIGJvdGggQVND SUkgZm9ybSBhbmQgVVRGLTggZm9ybS4gIFdlDQo+IGFsc28gdGFsa2VkIGFib3V0IHVzaW5nIG1l c3NhZ2UgZW5jYXBzdWxhdGlvbiB0byBoYW5kbGUgdGhlIHJlYWwNCj4gKGkuZS4sIGludGVybmF0 aW9uYWxpemVkKSBoZWFkZXJzIGlmIGl0IHdhcyBuZWNlc3NhcnkgdG8NCj4gZG93bmdyYWRlIHRv IEFTQ0lJLiAgIFNpbmNlIHRoZSByZXN0cmljdGlvbnMgb24gbm9uLUFTQ0lJDQo+IGNoYXJhY3Rl cnMgaW4gaGVhZGVycyB1bHRpbWF0ZWx5IGFwcGx5IG9ubHkgdG8gdGhlIDgyMi8yODIyIHNldA0K PiBhbmQgb3RoZXIgcnVsZXMgY2FuIGJlIGNyZWF0ZWQgZm9yIGFueXRoaW5nIHRoYXQgaXMgZW1i ZWRkZWQgaW4NCj4gTUlNRSBzdHJ1Y3R1cmVzLCBlbmNhcHN1bGF0ZWQgVVRGLTggaGVhZGVycyBj b3VsZCBzdGF5IGluIFVURi04LA0KPiBwcmVzdW1hYmx5IHdpdGggc29tZSB0eXBlIG9mIGNvbnRl bnQtdHJhbnNmZXItZW5jb2RpbmcuICAgIElmIHdlDQo+IHNoaWZ0IHRoZSBlbnRpcmUgaGVhZGVy IGNvbGxlY3Rpb24gaW50byBVVEYtOCBhbmQgZW5jYXBzdWxhdGUgaWYNCj4gbmVlZGVkLCB0aGVu IHRoZXJlIGlzIHN0aWxsIGFuIGlzc3VlIGFib3V0IHN1cHBsZW1lbnRhbCBoZWFkZXJzDQo+IChv ciBzdXBwbGVtZW50YWwgc3ViZmllbGRzKSBmb3IgdGhlIEFsdC1hZGRyZXNzIGlmIHRoYXQgaXMN Cj4gbmVlZGVkLCBidXQgdGhlIHByaW1hcnkgYWRkcmVzc2VzIGFyZSB1bmNoYW5nZWQuICBJZiB3 ZSBkbyBub3QsDQo+IHRoZW4gd2UgaGF2ZSBhIGZhaXJseSBsb25nIGxpc3Qgb2Ygb3RoZXIgaXNz dWVzLg0KPiANCj4gPiAoMykgQXJlIHRoZXkgc2FtZT8NCj4gPiANCj4gPiBZb3VyIGRyYWZ0IGFs bG93cyBhbiBJLWVtYWlsLWFkZHJlc3MgYW5kIGFuIEFMVC1hZGRyZXNzIG1heSBiZQ0KPiA+IGRl c2lnbmF0ZWQgdG8gZGlmZmVyZW50IG1haWxib3hlcy4gSG93ZXZlciwgd2UgdGhpbmsgdGhhdA0K PiA+IHRob3NlIHR3byBib3hlcyBhcmUgZm9yIHRoZSAobG9naWNhbGx5KSBzYW1lIHVzZXIuDQo+ IA0KPiBJIHRoaW5rIHRoZXkgdXN1YWxseSB3aWxsIGJlLiAgUGVyaGFwcyBldmVuICJhbG1vc3Qg YWx3YXlzIi4NCj4gQnV0LCBnaXZlbiBvdGhlciBjb25zdHJhaW50cyBpbXBvc2VkIGJ5IHRoZSBl bWFpbCBzeXN0ZW0sIHRoZXJlDQo+IGlzIG5vIHJlYXNvbiB0byBtYWtlIHRoYXQgYSBwcm90b2Nv bCByZXF1aXJlbWVudCBhbmQsIEkgYmVsaWV2ZSwNCj4gc2V2ZXJhbCByZWFzb25zIG5vdCB0by4g ICAgT25lIGV4YW1wbGUgaGFzIHRvIGRvIHdpdGggc29tZSBvZg0KPiB0aGUgImFkZGl0aW9uYWwg cHJvY2Vzc2luZyIgbWVudGlvbmVkIGluIHRoZSBkcmFmdCBhbmQgYW4NCj4gZWFybGllciBub3Rl LiAgTGV0IG1lIHRha2UgYSBmYXItZmV0Y2hlZCBleGFtcGxlLCBqdXN0IHRvDQo+IGlsbHVzdHJh dGUgd2hhdCBtaWdodCBoYXBwZW4gaGVyZS4gIFN1cHBvc2UgeW91IHRvbGQgbWUgdGhhdCBpdA0K PiB3b3VsZCBiZSB2ZXJ5IGNvbnZlbmllbnQgZm9yIHlvdSBpZiBJIHByb3ZpZGVkIGEgbWFpbGJv eCBuYW1lIGluDQo+IEhhbmd1bC4gIE9rLCBieSBwYXRjaGluZyBvciBjb25maWd1cmluZyBteSBN VEEgdG8gZGlzYWJsZSBpdHMNCj4gQVNDSUktb25seSBjaGVja3MgYW5kIGdldHRpbmcgaXQgdG8g c3VwcG9ydCB0aGUgcmVsZXZhbnQgU01UUA0KPiBvcHRpb24sIEkgY291bGQgcHJlc3VtYWJseSBh cnJhbmdlIHRoYXQsIG1ha2luZyBhbiBhbGlhcyB0aGF0DQo+IHBvaW50cyB0byBteSBzdGFuZGFy ZCBtYWlsYm94LiAgU28gZmFyLCBvbmUgdXNlciwgb25lIG1haWxib3guDQo+IA0KPiBCdXQgdGhl IG5hdHVyZSBvZiB0aGVzZSB0aGluZ3MgaXMgc3VjaCB0aGF0LCBpZiBJIHN1cHBvcnQgYQ0KPiBI YW5ndWwgYWRkcmVzcyBmb3IgbXlzZWxmLCBzb29uZXIgb3IgbGF0ZXIgeW91IG9yIHNvbWVvbmUg ZWxzZQ0KPiBpbiBLb3JlYSB3aWxsIGFjY2lkZW50YWxseSBzZW5kIGEgbWVzc2FnZSB3aG9zZSBi b2R5IGlzIGluDQo+IEhhbmd1bCB0byBtZS4gIFJlbWVtYmVyIEkgY2FuJ3QgcmVhZCBzdWNoIG1l c3NhZ2UgYm9kaWVzLCBldmVuDQo+IHRvIHByb25vdW5jZSB0aGUgc3lsbGFibGVzIHdpdGhvdXQg dW5kZXJzdGFuZGluZyB0aGUgdm9jYWJ1bGFyeS4NCj4gQnV0LCBpZiB0aGF0IGhhcHBlbnMgc2V2 ZXJhbCB0aW1lcyBhbmQgSSBjYW4gZmluZCBhIGRlY2VudA0KPiBhdXRvbWF0aWMgdHJhbnNsYXRp b24gcHJvZ3JhbSB0aGF0IGNhbiBoYW5kbGUgS29yZWFuIGluIEhhbmd1bC0+DQo+IEVuZ2xpc2gs IEknbSBnb2luZyB0byBoYXZlIGEgbG90IG9mIGluY2VudGl2ZSB0byBhdHRhY2ggbXkNCj4gSGFu Z3VsIGFkZHJlc3MgdG8gYW4gYWdlbnQgdGhhdCB3aWxsIGluc3BlY3QgdGhlIG1lc3NhZ2UgYm9k eQ0KPiBsb29raW5nIGZvciBVbmljb2RlIGNoYXJhY3RlciByYW5nZXMgdGhhdCBjb3JyZXNwb25k IHRvIEhhbmd1bA0KPiBhbmQsIGlmIGl0IGZpbmRzIHRoZW0sIHNlbmQgdGhlIHRleHQgb2ZmIGZv ciB0cmFuc2xhdGlvbiBiZWZvcmUNCj4gZGVwb3NpdGluZyB0aGUgbWVzc2FnZSBpbiBteSBtYWls Ym94LiAgU3RpbGwgdGhlIHNhbWUgbWFpbGJveCwNCj4gb2YgY291cnNlLCBidXQgdGhlIHByb2Nl c3NpbmcgZm9yIG9uZSBhZGRyZXNzIGlzIGRpZmZlcmVudCBmcm9tDQo+IHRoZSBwcm9jZXNzaW5n IGZvciBhbm90aGVyLg0KPiANCj4gRm9yIHRob3NlIG9mIHVzIHdobyBoYXZlIGJlZW4gdXNpbmcg ZW1haWwgaW50ZW5zZWx5IGZvciBtYW55DQo+IHllYXJzLCB0aGUgaWRlYSBvZiAib25lIHVzZXIg LSBvbmUgbWFpbGJveCIgaXMsIGl0c2VsZiwgdG9vDQo+IG5hcnJvdy4gIE9mZmhhbmQsIEkgZG9u J3Qga25vdyBob3cgbWFueSBkaWZmZXJlbnQgbWFpbGJveGVzIEkNCj4gaGF2ZSBzZXQgdXAgYXQg dGhlIG1vbWVudCwgYnV0IGl0IGlzIG1vcmUgdGhhbiBmaXZlIG9yIHNpeC4NCj4gQWxsIHNvcnRz IG9mIHJvdXRpbmcgb2NjdXJzIGFtb25nIG1haWxib3hlcyBhbmQgZm9sZGVycywNCj4gZGlmZmVy ZW50IHByb2Nlc3Npbmcgb2NjdXJzIGF0IGRpZmZlcmVudCBhZGRyZXNzZXMsIGFuZCBzbyBvbi4N Cj4gQW5kIEkgdXNlIGRvbWFpbnMgdG8gcmVjZWl2ZSBtYWlsIHRoYXQgaXQgaXMgbGlrZWx5IHRo YXQgeW91DQo+IGhhdmUgbm90IGhlYXJkIG9mLiAgVGhpcyBzaG91bGQgbm90IGJlIHJlbGV2YW50 LCBidXQgaXQgbWlnaHQgYmUuDQo+IA0KPiA+IFRoZXJlIGlzIG5vIGFsZ29yaXRobWljIHdheSB0 byB1bmlxdWVseSBnZW5lcmF0ZSBhbg0KPiA+IEFMVC1hZGRyZXNzIGZyb20gYSBnaXZlbiBJLWVt YWlsLWFkZHJlc3MuIFRodXMsIHRoZXJlIGlzDQo+ID4gbm8gd2F5IHRvIHZlcmlmeSB0aGF0IGFu IEktZW1haWwtYWRkcmVzcyBhbmQgYW4gQUx0LWFkZHJlc3MNCj4gPiBhcmUgZGVzdGluZWQgdG8g dGhlIHNhbWUgdXNlci4NCj4gDQo+IFRoYXQgaXMgY29ycmVjdC4gIEdpdmVuIG90aGVyIGVsZW1l bnRzIG9mIHRoZSBlbWFpbCBzeXN0ZW0sDQo+IHRoZXJlIGlzLCBvZiBjb3Vyc2UsIG5vIHdheSB0 byB2ZXJpZnkgdGhhdCBhbiBBU0NJSSBlbWFpbA0KPiBhZGRyZXNzIHdpbGwgZ28gdG8gdGhlIHVz ZXIgeW91IGV4cGVjdC4gIFRoYXQgaXMgd2h5LCB3aGVuDQo+IHRoaW5ncyBhcmUgaW1wb3J0YW50 LCB3ZSAgaGF2ZSBtZWNoYW5pc21zIGZvciBlbmNyeXB0aW5nDQo+IG1lc3NhZ2VzIGFuZCB2YXJp b3VzICJkZWxpdmVyIFVSTCByYXRoZXIgdGhhbiBtZXNzYWdlIHRleHQiDQo+IHRlY2huaXF1ZXMg YXJlIHBvcHVsYXIgaW4gc29tZSBjYXNlcy4NCj4gDQo+ID4gV2hhdCBpZiBhbiBJLWVtYWlsLWFk ZHJlc3MgYW5kIGFuIEFMVC1hZGRyZXNzIGluIGFuIGVtYWlsDQo+ID4gZGVzaWduYXRlIGRpZmZl cmVudCB1c2Vycz8gVGhlIG1haWwgd2lsbCBiZSBkZWxpdmVyZWQgdG8NCj4gPiBkaWZmZXJlbnQg dXNlcnMgZGVwZW5kaW5nIG9uIHRoZSBzdGF0dXMgb2YgSS1lbWFpbA0KPiA+IGNhcGFiaWxpdHkg b24gdGhlIHJvdXRlLiBUaGlzIG1heSBoYXBwZW4gZHVlIHRvIGVycm9ycyBvZg0KPiA+IHNlbmRp bmcgdXNlcnMgb3IgZXZlbiBhdHRhY2tzIGJ5IG1hbGljaW91cyB1c2Vycy4gSSBoYXZlDQo+ID4g bm90IHlldCBmb3VuZCBhbnkgcG9zc2libGUgYXR0YWNrIHRocm91Z2ggdGhpcyBkaXNjcmVwYW5j eS4NCj4gPiBCdXQsIHRoZXJlIGNvdWxkIGJlIC4uLg0KPiANCj4gT2YgY291cnNlLiAgQnV0IGVp dGhlciB0aGUgc2VuZGluZyB1c2VyIGhhcyB0byBiZSBkZWNlaXZlZCBvcg0KPiBzb21ldGhpbmcg aGFzIHRvIHRhbXBlciB3aXRoIHRoZSBtZXNzYWdlIGVuIHJvdXRlLiAgSW4gdGhlIGZpcnN0DQo+ IGNhc2UsIHRoZSBkZWNlcHRpb24gY291bGQgb2NjdXIgd2l0aCB0aGUgQVNDSUkgYWRkcmVzcyB0 b2RheS4NCj4gSW4gdGhlIHNlY29uZCwgYW55dGhpbmcgdGhhdCBjYW4gZG8gdGhhdCBzb3J0IG9m IHRhbXBlcmluZyBjYW4NCj4gZG8gc28gbW9yZSBnZW5lcmFsbHkuDQo+IA0KPiBBZ2Fpbiwgc3Vw cG9zZSBJIGFzayB5b3UgdG8gc2VuZCBtZSBhIHBpZWNlIG9mIG1haWwgYWRkcmVzc2VkIHRvDQo+ IGpvaG5AYm9ndXMuZG9tYWluLm5hbWUgZm9yIHNvbWUgcmVhc29uIG9mIGNvbnZlbmllbmNlLiAg U2luY2UNCj4gdGhpcyBtZXNzYWdlIGlzIG5vdCBkaWdpdGFsbHkgc2lnbmVkIGFuZCB5b3UgaGF2 ZW4ndCB2ZXJpZmllZA0KPiB0aGUgc2lnbmF0dXJlIHRocm91Z2ggc29tZSBtZWNoYW5pc20geW91 IHRydXN0LCB5b3UgY2Fubm90IGJlDQo+IGNlcnRhaW4gdGhhdCB0aGUgcmVxdWVzdCB0byB1c2Ug dGhhdCBhZGRyZXNzIGluc3RlYWQgaXMgdmFsaWQNCj4gYW5kIGNvbWluZyBmcm9tIG1lLiAgQXNz dW1pbmcgaXQgaXMgYSB2YWxpZCByZXF1ZXN0IGZyb20gbWUsIHlvdQ0KPiBzdGlsbCBoYXZlIG5v IHdheSB0byBrbm93IHdoZXJlIHRoYXQgYWRkcmVzcyBpcyBnb2luZywgdG8gd2hvbQ0KPiBpdCBp cyBiZWluZyBmb3J3YXJkZWQsIGV0Yy4gIEFsbCBvZiB0aG9zZSBpc3N1ZXMgYXJlIG1hdHRlcnMg Zm9yDQo+IHRoZSBtYWlsIHNlcnZlciB0aGF0IGFuc3dlcnMgdG8gYWRkcmVzc2VzIGF0IGJvZ3Vz LmRvbWFpbi5uYW1lLA0KPiBhbmQgaXQgaXMgZmFpcmx5IHNlY3JldGl2ZS4gICBJZiB5b3Ugd2Fu dCB0byBiZSBzdXJlIHRoYXQgb25seSBJDQo+IGNhbiByZWFkIHRoZSBtYWlsLCB3ZSBrbm93IGhv dyB0byBwcm92aWRlIHRoYXQgcHJvdGVjdGlvbi4gIEJ1dCwNCj4gaWYgeW91IHdhbnQgdG8gYmUg c3VyZSB0aGUgbWFpbCBpcywgaW4gZmFjdCwgZ29pbmcgdG8gYQ0KPiBkZXN0aW5hdGlvbiB3aGlj aCB5b3UgY2FuIGd1YXJhbnRlZSBhbmQgb3ZlciB3aGljaCB5b3UgaGF2ZQ0KPiBjb250cm9sLi4u IHdlbGwsIG5vdCB3aXRoIFNNVFAuDQo+IA0KPiBTbywgeWVzLCB0aGVyZSBpcyBhbiBhdHRhY2sg aW4gdGhpcyBhcmVhLCBidXQgbmVpdGhlciBpMThuDQo+IGFkZHJlc3NlcyBub3IgQWx0LUFkZHJl c3NlcyBjaGFuZ2UgdGhlIHByb3BlcnRpZXMgb2YgdGhhdCBhdHRhY2sNCj4gYXQgYWxsLg0KPiAN Cj4gIGJlc3QgcmVnYXJkcywNCj4gICAgICBqb2huDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSW1hIG1haWxpbmcgbGlzdA0KPiBJ bWFAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaW1hDQo+IA== --===============2063443344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ima mailing list Ima@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============2063443344==-- From hipsec-bounces@lists.ietf.org Thu Jul 28 06:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5Tr-0004p1-MB; Thu, 28 Jul 2005 06:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5Tp-0004nJ-09 for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 06:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13142 for ; Thu, 28 Jul 2005 06:19:06 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5zF-0007vp-Fj for hipsec@ietf.org; Thu, 28 Jul 2005 06:51:38 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 48EF9212C86; Thu, 28 Jul 2005 13:18:58 +0300 (EEST) In-Reply-To: <200507110940.22453.julien.IETF@laposte.net> References: <77F357662F8BFA4CA7074B0410171B6D095AF9@XCH-NW-5V1.nw.nos.boeing.com> <200507110940.22453.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: Cross Area Review: draft-ietf-hip-dns-01 Date: Thu, 28 Jul 2005 12:18:58 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Olaf M. Kolkman" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > You cannot fetch all of them in the same query with QTYPE=*, because > then authoritative answers are not available [RFC1035]. > > So you have to make individuals requests with A, AAAA, HIPHI, and > HIPRVS. > > [...] that if RCODE=3 (Name Error) occurs, that means > that the domain name referenced in the query does not exist > [RFC1035]. So if there is no A record but HIPHI and HIPRVS, when > queried for QTYPE=A, the DNS server would answer with RCODE=0 and no > A RR. Then the resolver knows the domain exist and can issue further > HIPRVS queries. > > I am not sure that we want to specify an order. From what I observed > with the related A vs AAAA query, the resolver on BSD (I guess it's > based on ISC's BIND) always query A, then AAAA, sequentially, i.e. > the AAAA query is not issued before the A query answer is received. > This makes sense because if the domain name does not exist two > queries would be issued from nothing. > > So back to Olaf's proposed: It's a mix of sequential and parallel > queries. First you only issue a query for one of the RRs (A in his > example), and if the domain name exists, then you issue parallel > queries with the remaining RRs (AAAA, HIPHI, and HIPRVS). It is the > most efficient way of querying multiple RRs, without wasting > resources in case the domain name is non-existent. Sounds good but I would suggest first querying for HIPHI and then the rest in parallel. If you get a HIPHI, you can return the HIT/LSI to the app then while the rest of the info is still being received. If you don't get a HIPHI, depending on the API you perpaps can indicate that no HI exists for the given DN and ask whether the app wants to establish an insecure connection. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 09:11:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8Aa-0004qk-Se; Thu, 28 Jul 2005 09:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8AZ-0004qf-Tc for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 09:11:28 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24281 for ; Thu, 28 Jul 2005 09:11:25 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5BE00CFBB6C; Thu, 28 Jul 2005 15:10:55 +0200 From: Julien Laganier To: hipsec@ietf.org, Pekka Nikander , Miriam Esteban Subject: Re: [Hipsec] registration protocol - failure types Date: Thu, 28 Jul 2005 15:12:09 +0200 User-Agent: KMail/1.8 References: <200507281126.58755.miriam.esteban@netlab.nec.de> <1395B672-B544-4AB5-8A7D-27B08BB5341F@nomadiclab.com> In-Reply-To: <1395B672-B544-4AB5-8A7D-27B08BB5341F@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507281512.09897.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 28 July 2005 12:04, Pekka Nikander wrote: > > I have also found this while implementing the registration > > protocol: > > > > DESCRIPTION: > > Failure types described in the hip-registration draft don't > > include a possible > > error while requesting lifetime or registration types not offered > > by the > > registrar. > > Case 1. Lifetime requested < Minimum Lifetime offered > > or Lifetime requested > Maximum Lifetime offered > > I think in these cases just use the minimum or maximum lifetime, > and accept the registration. No error code is needed, AFAIK. > > The draft apparently needs to be updated. I propose to add the following sentence in the REG_REQUEST processing: When the registrar is requested a registration which lifetime is either smaller or greater than the minimum or maximum lifetime, respectively, then it MUST grant the registration for the minimum or maximum lifetime, respectivelly. Is MUST okay? > > Case 2. Registration type != Registration type offered > > (In the case of > > RVS type 1) > > Yes, I think there should be an error code for this. > > A table for failure types needs to be added, and the IANA > considerations section needs to be updated. Here's the table until I can submit an updated version: Failure Type Reason ------------ -------------------------------------------- 0 Registration requires additional credentials 1 Registration type unavailable 2-200 Reserved by IANA 201-255 Reserved by IANA for private use --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 28 09:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8bf-0005JL-IE; Thu, 28 Jul 2005 09:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8bd-0005J6-Gh for hipsec@megatron.ietf.org; Thu, 28 Jul 2005 09:39:25 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26600 for ; Thu, 28 Jul 2005 09:39:21 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 23261212C72; Thu, 28 Jul 2005 16:38:51 +0300 (EEST) In-Reply-To: <200507281512.09897.julien.IETF@laposte.net> References: <200507281126.58755.miriam.esteban@netlab.nec.de> <1395B672-B544-4AB5-8A7D-27B08BB5341F@nomadiclab.com> <200507281512.09897.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C0710FD-EB72-4596-B217-06A4B34D05F9@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] registration protocol - failure types Date: Thu, 28 Jul 2005 15:38:50 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.733) Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>> Case 1. Lifetime requested < Minimum Lifetime offered >>> or Lifetime requested > Maximum Lifetime offered >>> >> >> I think in these cases just use the minimum or maximum lifetime, >> and accept the registration. No error code is needed, AFAIK. >> >> The draft apparently needs to be updated. > > I propose to add the following sentence in the REG_REQUEST processing: > > When the registrar is requested a registration which lifetime is > either smaller or greater than the minimum or maximum lifetime, > respectively, then it MUST grant the registration for the minimum > or maximum lifetime, respectivelly. > > Is MUST okay? I think SHOULD would be fine. Sure, it could also provide some other lifetime on its discretion, independent on what it announced, without any ill effects. Please fix the spelling of the last word. However, in the REG_RESPONSE section I'd add The client MUST be prepared to receive any registration lifetime, included ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. It MUST NOT expect that the returned lifetime will be the requested one, even in the case that the requested lifetime falls within the announced minimum and maximum. (Again, be flexible in what you expect.) >>> Case 2. Registration type != Registration type offered >> >> Yes, I think there should be an error code for this. >> >> A table for failure types needs to be added, and the IANA >> considerations section needs to be updated. >> > > Here's the table until I can submit an updated version: > > Failure Type Reason > ------------ -------------------------------------------- > 0 Registration requires additional credentials > 1 Registration type unavailable > 2-200 Reserved by IANA > 201-255 Reserved by IANA for private use Looks good. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 02:50:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyOhl-0001XL-FX; Fri, 29 Jul 2005 02:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyOhj-0001X8-38 for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 02:50:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16553 for ; Fri, 29 Jul 2005 02:50:45 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyPDE-0006Ln-SQ for hipsec@ietf.org; Fri, 29 Jul 2005 03:23:27 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42CAC5CF012061D0; Fri, 29 Jul 2005 08:50:19 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Fri, 29 Jul 2005 08:51:34 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507290851.34390.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Type 1 and 2 HITs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, Currently [I-D.ietf-hip-base] defines Type 1 HITs only: ---------------------------------------------------------------------- 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (8 bits) - Fixed prefix, TBD. All other values reserved. 0x40 - SHA-1 hash algorithm All other values reserved. Hash (120 bits) - Lower-order bits of the hash (as specified by the hash algorithm) of the public key Additional values for the prefix (including different hash algorithms, or other information) may be defined in the future. A host may receive a HIT for which it does not understand the prefix. In such a case, it will not be able to check the mapping between HI and HIT. ---------------------------------------------------------------------- Then, Type 2 HITs are defined in [I-D.ietf-hip-dns] as 64 bits of HAA followed by 64 bits of the low order bits of the hash of the public key. I have the feeling that these two definitions are inconsistent because a node cannot determine the type of a HIT based on the HIT itself. I propose the following resolution: o In [I-D.ietf-hip-base], replace "0x40 - SHA-1 hash algorithm" by "0x40 - Type 1 HIT with SHA-1 hash algorithm" o In [I-D.ietf-hip-dns], defines Type 2 HITs as: 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | HAA | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x80 - Type 2 HIT with SHA-1 hash algorithm HAA (56 bits) - Host Assigning Authority supporting two levels of delegation. The first is a registered assigning authority (RAA). The second is a registered identity (RI, commonly a company). The RAA is 16 bits with values assigned sequentially by ICANN. The RI is 40 bits, also assigned sequentially but by the RAA. Hash (64 bits) - Lower-order bits of the hash (as specified by the hash algorithm) of the public key Do you think it is sensible? or perhaps we should get rid of Type 2 HITs... Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 05:17:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQzO-0006vy-1N; Fri, 29 Jul 2005 05:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQzI-0006vZ-QI for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 05:17:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23007 for ; Fri, 29 Jul 2005 05:17:02 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyRUv-000225-A2 for hipsec@ietf.org; Fri, 29 Jul 2005 05:49:46 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D3614212C72; Fri, 29 Jul 2005 12:16:42 +0300 (EEST) In-Reply-To: <200507290851.34390.julien.IETF@laposte.net> References: <200507290851.34390.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B5E097C-11A7-4E82-91B0-7F4017269A2F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 29 Jul 2005 11:16:42 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: Type 1 and 2 HITs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Currently [I-D.ietf-hip-base] defines Type 1 HITs only:... > > Then, Type 2 HITs are defined in [I-D.ietf-hip-dns] as 64 bits of HAA > followed by 64 bits of the low order bits of the hash of the public > key. > > I have the feeling that these two definitions are inconsistent because > a node cannot determine the type of a HIT based on the HIT itself. > Earlier on we had a discussion where we decided to go from encoding the HIT type in the HIT itself external to the HIT. The idea was that you need to HIT type only for being able to verify the relationship between a given HIT and a given HI public key. That led to a design where Type 1 HITs were 128 bits long plain hashes. IIRC, the rationale more-or-less was that you would get the HIT type along with the HI public key. Then, more recently, it became clear that for security reasons we do need to encode the hash function into the HIT itself. The potential attack here is that one of the hash functions used for creating HITs becomes weak. If that happens, then an attacker that wants to attack the binding with a given HIT and the intended HI could use the weak hash algorithm to create another HI' so that HIT == weakhash(HI') while the intended binding was HIT == stronghash(HI). To prevent that, we have to encode the hash algorithm to the HIT itself. Now, consider a situation where Type_1_HIT == 0x40 | lowbits(120, stronghash(HI)) Consider an attacker that creates a Type 2 HIT so that Type_2_HIT == 0x40 | HAA | lowbits(64, stronghash(HI')) where HAA = highbits(120-64, lowbits(120, stronghash(HI)) In this scenario the attacker only needs to create a public key HI' whose hash has only same low order 64 bits and not 120 bits than the HIT being attacked. That is clearly something that we do not want to have. Hence, I think you are right. We need to have another code point for the different encoding of the hash in the Type 2 HITs. In general, it looks like that we need to encode in the HIT itself the exact method that was used to generate the hash of the public key in the HIT. Now, this goes back to the discussion whether to divide the first byte in the HIT into two fields, one being fixed for now ("This is a HIT" and not an IPv6 address) and the other creating a new IANA registry, for easier definition of new hash encodings. As I have stated before, I still think that instead of defining a single 8-bit prefix (to be allocated from the IPv6 address space) it is probably a better idea to have an e.g. 5-bit prefix and then have initially 3 bits (8 choices) for encoding the hash. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 07:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DySsK-0005RM-BD; Fri, 29 Jul 2005 07:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DySsI-0005RH-Qv for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 07:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29150 for ; Fri, 29 Jul 2005 07:17:55 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyTNx-0005K9-7M for hipsec@ietf.org; Fri, 29 Jul 2005 07:50:41 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 49F862D3B; Fri, 29 Jul 2005 14:17:46 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D50292CC8 for ; Fri, 29 Jul 2005 14:17:45 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j6TBHjP06595; Fri, 29 Jul 2005 14:17:45 +0300 (EEST) Date: Fri, 29 Jul 2005 14:17:45 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Hipsec] keymat / state machine problem with packet retransmission X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I discovered a problem in the state machine that may be worthy of noting the draft. I discovered a hint for the problem during interops, and later I could confirm it by running base exchange with the HIPL implementation so that each HIP control packet sent was repeated always N x times. The problem is caused by the following things: a) i and j were added to the keymaterial (draft 02 -> 03) b) both the initiator and responder must take care of detecting properly retransmitted packets, or otherwise they can generate new keymaterial different from the other, especially if the initiator does not save the cookie j c) (the initiator and responder must take care of creating new SPI values if the packet was a retransmission - may be this is already include in the draft text somewhere) The solution to the problem is scetched in pseudo C code below because I am preparing to go for a holiday and I don't have the time to provide text. I will leave it for the reader to analyze the problem; is it the state machine specification that needs some fine tuning or is it just our code that was buggy?) hip_handle_r1(struct hip_control_msg *r1, struct hip_host_association *entry) { if (state == HIP_STATE_I2_SENT) retransmission = 1; else retransmission = 0; /* solve puzzle: if this is a retransmission, we have to preserve the old solution */ if (!retransmission) { struct hip_puzzle *pz = NULL; pz = hip_get_param(r1, HIP_PARAM_PUZZLE); solved_puzzle = hip_solve_puzzle(pz, r1, HIP_SOLVE_PUZZLE); I = pz->I; entry->puzzle_solution = solved_puzzle; entry->puzzle_i = pz->I; } else { I = entry->puzzle_i; solved_puzzle = entry->puzzle_solution; } /* keymaterial producing can be skipped if retransmission */ hip_produce_keying_material(I, solved_puzzle, etc); // do rest of the stuff, send i2 } hip_handle_i2(struct hip_control_msg *i2, struct hip_host_association *entry) { if (entry && (entry->state == HIP_STATE_R2_SENT || entry->state == HIP_STATE_ESTABLISHED)) { /* If the I2 packet is a retransmission, we need reuse the the SPI/keymat that was setup already when the first I2 was received. */ retransmission = 1; } else { retransmission = 0; } /* keymaterial producing can be skipped if retransmission */ hip_produce_keying_material(I, J, etc); // do rest of the stuff hip_add_SAs(); /* reuse SPI if retransmission! */ // do rest of the stuff, send r2 } hip_handle_r2(struct hip_control_msg *r2, struct hip_host_association *entry) { if (entry->state == HIP_STATE_ESTABLISHED) { retransmission = 1; HIP_DEBUG("Retransmission\n"); } else { retransmission = 0; } // do rest of the stuff hip_add_SAs(); /* reuse SPI if retransmission! */ // do rest of the stuff, transition to established } I tested above code in our HIPL implementation. It worked fine with and without retransmission. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 07:58:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTVZ-0006rb-1Q; Fri, 29 Jul 2005 07:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTVY-0006rV-4c for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 07:58:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01134 for ; Fri, 29 Jul 2005 07:58:30 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyU1B-0006SK-S9 for hipsec@ietf.org; Fri, 29 Jul 2005 08:31:15 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 6452F212C72; Fri, 29 Jul 2005 14:58:12 +0300 (EEST) Message-ID: <42EA19D4.7040808@nomadiclab.com> Date: Fri, 29 Jul 2005 14:58:12 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] base exchange implementation feedback References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Miika Komu wrote: > * ESP_INFO usage in the base exchange: mention explicitly what to fill in > the fields in both the initiator and responder > * Parameter type order strictly enforced, except for 2048-4095 > * Put this explicitly separate sentence rather than in a in the > subordinate clause ("The type-field value also describes the order of > these fields in the packet, except..) Both listed as open issues in tracker. I'll make required clarifications to the text. /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 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 08:17:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTnm-0004FF-6y; Fri, 29 Jul 2005 08:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTnk-0004FA-Uo for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 08:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02586 for ; Fri, 29 Jul 2005 08:17:18 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyUJO-00074q-Io for hipsec@ietf.org; Fri, 29 Jul 2005 08:50:04 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id E29FF212C72; Fri, 29 Jul 2005 15:17:09 +0300 (EEST) Message-ID: <42EA1E45.4080004@nomadiclab.com> Date: Fri, 29 Jul 2005 15:17:09 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> <200506271611.21480.julien.IETF@laposte.net> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org, Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >>>> Because the state is indexed by source and destination HI/HITs, >>>> and not IP address, I assume that we don't need specific text on >>>> how to handle an R1 when a RVS was involved in I1 delivery, with >>>> or without presence of a VIA_RVS parameter. >>>> >>>> Is that correct or I am missing something? >>> >>> >>> Hmm. I can see some implementations checking also the IP >>> fields in incoming R1s in order to weed out potential replay >>> attacks. Hence, I think we should include a few sentences here >>> stating the perhaps obvious: that incoming R1s SHOULD be verified >>> based on state on HITs only, and if IP addresses are checked, >>> also include RVS to the check.... >>> >>> Or what do you think? Perhaps I am missing something? >> >> >> No that is fine. Do you think we should have also a SHOULD requirement >> for the case where IP address are also checked? > > > FWIW, I think that the base spec should simply say that when matching > an incoming R1, the IP addresses SHOULD be ignored and the match > SHOULD be based on HITs only. Of course, that is usually impossible > for opportunistic connections, though. The RVS spec could then state > that if an implementation checks the IP addresses anyway, it MUST check > for an VIA_RVS parameter and use that for matching. I made a small addition to the incoming R1 packet handling: A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it has a HIP association that is in state I1-SENT and that is associated with the HITs in the R1. IP addresses in the received R1 packet SHOULD be ignored and the match SHOULD be based on HITs only). If so, it should process the R1 as described below. Is this 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 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 08:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTvv-000629-B2; Fri, 29 Jul 2005 08:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTvu-0005zf-26 for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 08:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03010 for ; Fri, 29 Jul 2005 08:25:44 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyURZ-0007Jo-3C for hipsec@ietf.org; Fri, 29 Jul 2005 08:58:29 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 94132212C72; Fri, 29 Jul 2005 15:25:36 +0300 (EEST) Message-ID: <42EA2040.4040901@nomadiclab.com> Date: Fri, 29 Jul 2005 15:25:36 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" Subject: Re: [Hipsec] base-03 state machine, notify References: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7FD5@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Ahrenholz, Jeffrey M wrote: > All, > I have been looking at the base-03 (and esp-00, mm-02) draft more > carefully while upgrading our HIP implementation, and have some > comments. I have attempted to organize these few comments with numbers > and by category... > > --- state machine --- > (1) What happened to the REKEYING state? It is mentioned once in base-03 > and twice in mm-02. It seems that REKEYING was (mostly) stripped out > along with the ESP stuff starting with base-02, but never made a > reappearance into esp-00. I'll remove the REKEYING-word from the base specification. In the ESP draft, there is no state machine described, and it doesn't define a new state related to rekeying. I think that it doesn't need that, but what do others think? > > --- NOTIFY packets --- > (3) In 6.14, Processing CLOSE_ACK packets: > "...the state changes to UNASSOCIATED and, after that, NOTIFY is sent as > a response to a CLOSE message." > Do we really want to send NOTIFY here? Doesn't UNASSOCIATED mean that we > no longer really have any state with the peer? The draft (sect. 4.3) > mentions that NOTIFY should generally be used if there is an existing > HIP association. Maybe ICMP is more appropriate, or further CLOSE_ACKs > are simply dropped. NOTIFY seems to be unnecessary here. ICMP would (maybe) shorten the time that the peer host stays at CLOSED state. Without any response to the CLOSE_ACK, the host waits until timeout and moves to UNASSOCIATED. I think that we should not send anything. Sending something would be directly acking ot the ack (which could be defined as a new HIP message :-) > (5) It probably should be noted that the NOTIFY code > AUTHENTICATION_FAILED should not be sent in response to a failed > signature in another NOTIFY. This may be common sense. Imagine two > implementations and one has a bug in the RSA signing/verification that > crops up after the SA is established; the buggy host later sends an > UPDATE, the verify fails causing a NOTIFY to be sent, and a NOTIFY is > sent in response to that NOTIFY, etc., the two might potentially go back > and forth. I'll change the text. /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 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 08:28:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTyE-0006jD-R8; Fri, 29 Jul 2005 08:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTyC-0006j2-Ni for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 08:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03324 for ; Fri, 29 Jul 2005 08:28:06 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyUTr-0007Qe-IP for hipsec@ietf.org; Fri, 29 Jul 2005 09:00:52 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DCD98212C72; Fri, 29 Jul 2005 15:27:58 +0300 (EEST) In-Reply-To: <42EA1E45.4080004@nomadiclab.com> References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> <200506271611.21480.julien.IETF@laposte.net> <42EA1E45.4080004@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt Date: Fri, 29 Jul 2005 14:27:57 +0200 To: Petri Jokela X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org, Julien Laganier X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> FWIW, I think that the base spec should simply say that when matching >> an incoming R1, the IP addresses SHOULD be ignored and the match >> SHOULD be based on HITs only. Of course, that is usually impossible >> for opportunistic connections, though. The RVS spec could then state >> that if an implementation checks the IP addresses anyway, it MUST >> check >> for an VIA_RVS parameter and use that for matching. >> > > I made a small addition to the incoming R1 packet handling: > > A system receiving an R1 MUST first check to see if it has > sent an I1 to the originator of the R1 (i.e., it has a HIP > association that is in state I1-SENT and that is > associated with the HITs in the R1. IP addresses in the > received R1 packet SHOULD be ignored and the match SHOULD > be based on HITs only). If so, it should process the R1 as > described below. > > Is this ok? Mention opportunistic mode, can't use HITs there? Other than that OK. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 09:22:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyUoO-0006cd-Hb; Fri, 29 Jul 2005 09:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyUoN-0006bz-L8 for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 09:22:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07546 for ; Fri, 29 Jul 2005 09:22:01 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyVK2-0000xg-EN for hipsec@ietf.org; Fri, 29 Jul 2005 09:54:47 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id E351C2DAE; Fri, 29 Jul 2005 16:21:49 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 98BDF2CAB for ; Fri, 29 Jul 2005 16:21:49 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j6TDLnw14014; Fri, 29 Jul 2005 16:21:49 +0300 (EEST) Date: Fri, 29 Jul 2005 16:21:49 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Subject: Re: [Hipsec] keymat / state machine problem with packet retransmission In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4-niksula20040914 X-Spam-Niksula: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Fri, 29 Jul 2005, Miika Komu wrote: > I discovered a problem in the state machine that may be worthy of noting > the draft. I discovered a hint for the problem during interops, and later > I could confirm it by running base exchange with the HIPL implementation > so that each HIP control packet sent was repeated always N x times. Let me elaborate more with two examples: Example A: C and D happen simultaneously: a) ----> I1 b) <---- R1 c) -----> I2 d) <---- R1 reflection of R1 (exactly the same as in b): initiator processes again! e) ------> I2 the cookie solution must be same as in c, otherwise end-up with mismatching keymat e) <---- R2 Example B: d and e happen simultaneously: init resp a) ----> I1 b) <---- R1 c) -----> I2 d) <---- R2 e) -----> I2 the cookie solution must be same as c, otherwise end-up with mismatching keymat Unless my thinking is incorrect, some text should be added that the initiator must remember the cookie solution it sent in I2 (and not to calculate a new one) upon retransmissions. The same applies for the SPI value. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 11:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWxE-0006Oe-OH; Fri, 29 Jul 2005 11:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWxD-0006OZ-Cg for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 11:39:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17635 for ; Fri, 29 Jul 2005 11:39:16 -0400 (EDT) Received: from pegasus.hiit.fi ([212.68.1.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXSt-0005Gj-BP for hipsec@ietf.org; Fri, 29 Jul 2005 12:12:04 -0400 Received: from [128.214.113.174] (odysse.hiit.fi [128.214.113.174]) by pegasus.hiit.fi (Postfix) with ESMTP id BAB8B220077; Fri, 29 Jul 2005 18:38:53 +0300 (EEST) From: Diego Beltrami To: hipl-users@freelists.org, hipsec@ietf.org Content-Type: text/plain Organization: HIIT Message-Id: <1122651533.25842.73.camel@odysse> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 29 Jul 2005 18:38:53 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: diego.beltrami@HIIT.FI List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Diego Beltrami wrote: > > > > we have been working for three months to implement a new IPsec mode, > > the "BEET" mode, for Linux. Below is a link to the BEET specification > > and > > the abstract: > > > > http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt > > Thanks for the patch guys, this is really interesting. Thanks Herbert for your feedback! > > Although the document only talks about ESP, as far as I can see > the encapsulation can be applied to AH/IPComp just as well. > So how about moving this stuff to the generic xfrm_input/xfrm_output > functions? The BEET code is already present in xfrm_input/xfrm_output functions and it applies ESP encapsulation merely because of SA and SP set by means setkey. As a consequence, if SA and SP are correctly set for AH the flow goes through the AH functions. The modifications in the ESP functions are due to the hybrid cases when Inner and Outer address families are different; in those cases the values returned by espX functions are not coherent. I tried to change SA and SP so that AH is used and the flow correctly goes through AH functions but the problem has been revealed to be something else. In particular, it seems that the AH functions deal with the pointers contained in skb (skb->data, skb->nh, skb->h etc) in a slightly different way than ESP functions. (Can anyone say more?) Surely BEET will work also for AH with minor changes, even though we only tried the ESP encapsulation. This will require some time to inspect and analyze the exact situation. In any case, as a result, I would say the code is already generic itself. On the other hand I don't know about IPComp, so I wouldn't say anything. Hence if You could please give some hints, they will be more than appreciated. > > Also, if you're going to do cross-family transforms, it should be > done for both BEET and plain tunnel-mode. Potentially it could be possible also for plain tunnel-mode: this will require further analysis. For further discussion and advice, please give feedback. Thank You very much! Cheers, --Diego _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 11:44:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyX20-0007j7-7x; Fri, 29 Jul 2005 11:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyX1z-0007iy-Bw for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 11:44:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17995 for ; Fri, 29 Jul 2005 11:44:12 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXXe-0005Pu-6Z for hipsec@ietf.org; Fri, 29 Jul 2005 12:17:00 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA03867; Fri, 29 Jul 2005 08:43:30 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6TFhes12485; Fri, 29 Jul 2005 08:43:40 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 08:43:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] keymat / state machine problem with packet retransmission Date: Fri, 29 Jul 2005 08:43:38 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7FF3@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] keymat / state machine problem with packet retransmission Thread-Index: AcWUQKSkqYPa0cWDQiGDmppo6oANJQAEh/sA From: "Ahrenholz, Jeffrey M" To: "Miika Komu" , X-OriginalArrivalTime: 29 Jul 2005 15:43:39.0797 (UTC) FILETIME=[4A7FA450:01C59454] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I don't know if this is a problem -- upon receiving the second R1, you = can compare the R1 generation counter and decide that it is not greater = than before, and drop the packet. Also, R1s are not retransmitted, so = this "reflection" would have to be some effect of the network. = Alternatively, if you receive the same R1 and you're in I2_SENT, it = seems like you can retransmit your same I2 again, containing the same = solution. As your example B shows, it seems like your retransmitted I2s have = different solutions. I would think that the retransmitted I2 is just a = copy of the previous packet. -Jeff > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Friday, July 29, 2005 6:22 AM > To: hipsec@ietf.org > Subject: Re: [Hipsec] keymat / state machine problem with=20 > packet retransmission >=20 >=20 > On Fri, 29 Jul 2005, Miika Komu wrote: >=20 > > I discovered a problem in the state machine that may be=20 > worthy of noting > > the draft. I discovered a hint for the problem during=20 > interops, and later > > I could confirm it by running base exchange with the HIPL=20 > implementation > > so that each HIP control packet sent was repeated always N x times. >=20 > Let me elaborate more with two examples: >=20 > Example A: C and D happen simultaneously: >=20 > a) ----> I1 > b) <---- R1 > c) -----> I2 > d) <---- R1 reflection of R1 (exactly the same as in b): initiator > processes again! > e) ------> I2 the cookie solution must be same as in c, otherwise > end-up with mismatching keymat > e) <---- R2 >=20 > Example B: d and e happen simultaneously: >=20 > init resp >=20 > a) ----> I1 > b) <---- R1 > c) -----> I2 > d) <---- R2 > e) -----> I2 the cookie solution must be same as c, otherwise > end-up with mismatching keymat >=20 > Unless my thinking is incorrect, some text should be added that the > initiator must remember the cookie solution it sent in I2 (and not to > calculate a new one) upon retransmissions. The same applies=20 > for the SPI > value. >=20 > --=20 > Miika Komu miika@iki.fi http://www.iki.fi/miika/ >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 11:47:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyX58-0001Ds-TU; Fri, 29 Jul 2005 11:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyX56-0001D4-E8 for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 11:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18365 for ; Fri, 29 Jul 2005 11:47:25 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXam-0005XX-7s for hipsec@ietf.org; Fri, 29 Jul 2005 12:20:13 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 71B17212C72; Fri, 29 Jul 2005 18:47:08 +0300 (EEST) To: diego.beltrami@HIIT.FI Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resent-Date: Fri, 29 Jul 2005 17:47:08 +0200 Message-Id: <700E4871-0A4A-470A-BE51-7804BBE8B359@nomadiclab.com> Content-Transfer-Encoding: 7bit Resent-To: hipsec@ietf.org, hipl-users@freelists.org From: Pekka Nikander Resent-From: Pekka Nikander Resent-Message-Id: Date: Fri, 29 Jul 2005 17:45:24 +0200 X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, herbert@gondor.apana.org.au Subject: [Hipsec] Re: [Infrahip] Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Surely BEET will work also for AH with minor changes, even though we > only tried the ESP encapsulation. > I wouldn't be so sure. IIRC, tunnel mode is not specified for AH but for ESP only. Consequently, defining BEET mode for AH might be pretty tricky. OTOH, I don't know the linux IPsec implementation so that it might be possible to make BEET to "work" for AH, for some value of "work", but it probably would require some careful thinking to define the exact semantics, like what addresses (inner or outer) are covered by the AH integrity protection, what does the integrity protection really assert, etc. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 11:55:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXCo-0002ke-3N; Fri, 29 Jul 2005 11:55:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXCl-0002kZ-Rq for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 11:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18805 for ; Fri, 29 Jul 2005 11:55:20 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXiN-0005kl-Oq for hipsec@ietf.org; Fri, 29 Jul 2005 12:28:09 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA23923; Fri, 29 Jul 2005 08:55:06 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6TFt5v20135; Fri, 29 Jul 2005 10:55:06 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 08:54:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] base-03 state machine, notify Date: Fri, 29 Jul 2005 08:54:54 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7FF4@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] base-03 state machine, notify Thread-Index: AcWUOKFJTQKHXGkeR1KRI7GpyCxMmgAHARQw From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" X-OriginalArrivalTime: 29 Jul 2005 15:54:55.0776 (UTC) FILETIME=[DD69DA00:01C59455] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Petri, > I'll remove the REKEYING-word from the base specification. In the ESP > draft, there is no state machine described, and it doesn't=20 > define a new state related to rekeying. I think that it doesn't need > that, but what do others think? It does seem like the REKEYING state is no longer needed. You remain in = ESTABLISHED, but keep track of your outstanding UPDATEs that need to be = ACKed. The rekeying UPDATE is one of these packets. (Likewise, for mm-02 = there is no "READDRESSING" state, and you keep track of which address is = preferred...) > I think that we should not send anything. Sending something would be > directly acking ot the ack (which could be defined as a new=20 > HIP message :-) Yes, that sounds right -- don't send anything. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 29 16:32:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybXK-0001nJ-BG; Fri, 29 Jul 2005 16:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybXI-0001nE-E3 for hipsec@megatron.ietf.org; Fri, 29 Jul 2005 16:32:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07546 for ; Fri, 29 Jul 2005 16:32:49 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyc2x-000544-QC for hipsec@ietf.org; Fri, 29 Jul 2005 17:05:40 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA09037; Fri, 29 Jul 2005 13:32:15 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6TKWOs18759; Fri, 29 Jul 2005 13:32:25 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 13:32:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: Type 1 and 2 HITs Date: Fri, 29 Jul 2005 13:32:24 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512A88@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Re: Type 1 and 2 HITs Thread-Index: AcWUHnI5DoZ0irNWQbWwW/rxdmCGyAAW78GQ From: "Henderson, Thomas R" To: "Pekka Nikander" , "Julien Laganier" X-OriginalArrivalTime: 29 Jul 2005 20:32:24.0650 (UTC) FILETIME=[A0EA6AA0:01C5947C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, July 29, 2005 2:17 AM > To: Julien Laganier > Cc: hipsec@ietf.org > Subject: [Hipsec] Re: Type 1 and 2 HITs >=20 >=20 > In general, it looks like that we need to encode in the HIT=20 > itself the exact method that was used to generate the hash of=20 > the public key in the HIT. >=20 > Now, this goes back to the discussion whether to divide the=20 > first byte in the HIT into two fields, one being fixed for=20 > now ("This is a HIT" and not an IPv6 address) and the other=20 > creating a new IANA registry, for easier definition of new=20 > hash encodings. >=20 > As I have stated before, I still think that instead of=20 > defining a single 8-bit prefix (to be allocated from the IPv6=20 > address space) it is probably a better idea to have an e.g.=20 > 5-bit prefix and then have initially 3 bits (8 choices) for=20 > encoding the hash. >=20 > --Pekka IIRC, the reason that it is rather loosely worded is two-fold: i) not wanting to prematurely nail down the boundary between prefix and hash type ii) not knowing what IANA would like to do: assign HIP a /5 or a /8 out of the IPv6 space, or neither. It would help me to decide if I understood the process by which IANA will grant or deny such requests, and whether we can leave the issue "pending IANA resolution" for now. We then might be able to state it as follows: 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD (to be determined) (8 bits) Hash (120 bits) - Lower-order bits of the hash (as specified by the hash algorithm) of the public key Note: The leading bits of a HIT are pending future IANA resolution. For experimental purposes, the following values are suggested: Prefix (5 bits): binary 01000, all other values reserved. HIT type (1 bit): 0 ("Type 0 HIT") and 1 ("Type 1 HIT") (was Type 1 and Type 2) Hash algorithm (2 bits): 00 (SHA-1 hash algorithm), all other values reserved. =20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jul 30 02:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dykao-0008Rv-SZ; Sat, 30 Jul 2005 02:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dykan-0008Rn-2d for hipsec@megatron.ietf.org; Sat, 30 Jul 2005 02:13:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15037 for ; Sat, 30 Jul 2005 02:13:04 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyl6Z-0005Wd-Bx for hipsec@ietf.org; Sat, 30 Jul 2005 02:45:57 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF0B5212C72; Sat, 30 Jul 2005 09:12:42 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D512A88@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D512A88@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DE97CF4-C588-4B4C-9FF8-055DAB5EB9E8@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sat, 30 Jul 2005 08:12:42 +0200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] The HIT prefix once again (was Re: Re: Type 1 and 2 HITs) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> In general, it looks like that we need to encode in the HIT >> itself the exact method that was used to generate the hash of >> the public key in the HIT. >> >> Now, this goes back to the discussion whether to divide the >> first byte in the HIT into two fields, one being fixed for >> now ("This is a HIT" and not an IPv6 address) and the other >> creating a new IANA registry, for easier definition of new >> hash encodings. >> >> As I have stated before, I still think that instead of >> defining a single 8-bit prefix (to be allocated from the IPv6 >> address space) it is probably a better idea to have an e.g. >> 5-bit prefix and then have initially 3 bits (8 choices) for >> encoding the hash. > > IIRC, the reason that it is rather loosely worded is two-fold: > i) not wanting to prematurely nail down the boundary between prefix > and > hash type > ii) not knowing what IANA would like to do: assign HIP a /5 or a / > 8 out > of the IPv6 space, or neither. > > It would help me to decide if I understood the process by which IANA > will grant or deny such requests, and whether we can leave the issue > "pending IANA resolution" for now. My (perhaps flawed) understanding of the situation is that IANA more or less does whatever the IETF/IESG asks it to do. See Section 4 of RFC3513. Based on that my understanding of the situation is that we need to achieve IETF consensus on the prefix anyway. In practise, that probably means convincing the following bodies, roughly in this order: IPv6 WG chairs (Bob Hinden and Steve Deering) IPv6 WG (IAB) INT area ADs INT area IESG IETF in the large So, I would suggest that we start talking to Bob and Steve ASAP, and once we've got some opinion from them, ask for cross-WG review from the IPv6 WG. I'll try to remember to take this up with Bob on Sunday. (Please remind me during the week.) Personally, I would imagine that getting a time-limited experimental assingment for a /5 would not be that hard. That also looks like the right way to me, since HIP is chartered to be experimental, and if the experiment fails (for whatever reason), the default should be to withdraw the assignment. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jul 30 04:39:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymsJ-0000r6-NM; Sat, 30 Jul 2005 04:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymsG-0000qy-74 for hipsec@megatron.ietf.org; Sat, 30 Jul 2005 04:39:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28578 for ; Sat, 30 Jul 2005 04:39:14 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynO5-0001mz-Pt for hipsec@ietf.org; Sat, 30 Jul 2005 05:12:10 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j6U8cpR06935; Sat, 30 Jul 2005 10:38:51 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j6U8coY7001856; Sat, 30 Jul 2005 10:38:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200507300838.j6U8coY7001856@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander Subject: Re: [Hipsec] The HIT prefix once again (was Re: Re: Type 1 and 2 HITs) In-reply-to: Your message of Sat, 30 Jul 2005 08:12:42 +0200. <1DE97CF4-C588-4B4C-9FF8-055DAB5EB9E8@nomadiclab.com> Date: Sat, 30 Jul 2005 10:38:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In your previous mail you wrote: >> Now, this goes back to the discussion whether to divide the >> first byte in the HIT into two fields, one being fixed for >> now ("This is a HIT" and not an IPv6 address) => HIP is not the only protocol which could take avantage from a dedicated prefix marked as not an address/not routable. I wrote a short I-D draft-dupont-ipv6-cgpref-01.txt which could work for at least HIP and a TMSI-like location privacy solution for MIPv6. I consulted IANA at an IETF meeting just before writing the first version. The idea is both to get such a prefix ASAP and "to be enough" in order to get a very short one. IMHO alone we have no chance to get better than a 16 bit prefix... >> As I have stated before, I still think that instead of >> defining a single 8-bit prefix (to be allocated from the IPv6 >> address space) it is probably a better idea to have an e.g. >> 5-bit prefix and then have initially 3 bits (8 choices) for >> encoding the hash. => I believe it could be better to share the prefix with other (and with weaker requirements) usages, i.e., to win one bit (2 x) at the cost of 1/8? > ii) not knowing what IANA would like to do: assign HIP a /5 or a / > 8 out of the IPv6 space, or neither. => I am afraid someone is dreaming... at least you should get strong support! (:-) > It would help me to decide if I understood the process by which IANA > will grant or deny such requests, and whether we can leave the issue > "pending IANA resolution" for now. => easy, we need an IPv6 WG RFC. My (perhaps flawed) understanding of the situation is that IANA more or less does whatever the IETF/IESG asks it to do. See Section 4 of RFC3513. Based on that my understanding of the situation is that we need to achieve IETF consensus on the prefix anyway. => IMHO we need a bit more. In practise, that probably means convincing the following bodies, roughly in this order: IPv6 WG chairs (Bob Hinden and Steve Deering) IPv6 WG (IAB) INT area ADs INT area IESG IETF in the large => there are not (or at least should not be :-) kings at the IETF. The path should be the IPv6 WG (chairs should follow the WG), IESG and the IETF in the large. The first step is to have an I-D (so I propose to join us), the second is to get support of the IPv6 WG about it (WG item, WG last call, etc). So, I would suggest that we start talking to Bob and Steve ASAP, and once we've got some opinion from them, ask for cross-WG review from the IPv6 WG. I'll try to remember to take this up with Bob on Sunday. (Please remind me during the week.) => so you need an I-D. IMHO it will be easier with a short one than with an "en passant" paragraph in a HIP architecture one. Regards Francis.Dupont@enst-bretagne.fr PS: if you agree to join us, we can ask the IPv6 WG chairs to poll the IPv6 WG about a WG item. I can't see technical concerns so it should be easy and the discussion (in the mailing list about the WG item) should only be about the length of the prefix. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jul 30 07:01:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyp5w-00069z-Gq; Sat, 30 Jul 2005 07:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyp5u-00069u-Ci for hipsec@megatron.ietf.org; Sat, 30 Jul 2005 07:01:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03575 for ; Sat, 30 Jul 2005 07:01:28 -0400 (EDT) Received: from pegasus.hiit.fi ([212.68.1.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dypbj-0006OB-Kp for hipsec@ietf.org; Sat, 30 Jul 2005 07:34:25 -0400 Received: from [128.214.113.174] (odysse.hiit.fi [128.214.113.174]) by pegasus.hiit.fi (Postfix) with ESMTP id 5E1CA220011; Sat, 30 Jul 2005 14:01:18 +0300 (EEST) From: Diego Beltrami To: Herbert Xu In-Reply-To: <20050729234859.GA27325@gondor.apana.org.au> References: <1122651216.25842.67.camel@odysse> <20050729234859.GA27325@gondor.apana.org.au> Content-Type: text/plain Organization: HIIT Message-Id: <1122721278.3696.28.camel@odysse> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 30 Jul 2005 14:01:18 +0300 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, infrahip@HIIT.FI, hipl-users@freelists.org, hipsec@ietf.org Subject: [Hipsec] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: diego.beltrami@HIIT.FI List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > On Fri, Jul 29, 2005 at 05:45:24PM +0200, Pekka Nikander wrote: > > >Surely BEET will work also for AH with minor changes, even though we > > >only tried the ESP encapsulation. > > > > I wouldn't be so sure. IIRC, tunnel mode is not specified for AH but > > for ESP only. Consequently, defining BEET mode for AH might be > > Well plain tunnel mode certainly is specified for AH as well as IPComp. > But you're right the semantics of BEET mode for AH needs to be thought > out. > The Linux patch which has been presented (see URL: http://infrahip.hiit.fi/beet/beet-patch-v1.0-2.6.12.2 ), has been developed based upon the design given by the draft http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt As a result BEET patch considers the ESP encapsulation as it has been designed. OTOH we believe the implementation is usable more or less as it is now for AH and perhaps IPComp in the future. But, as already mentioned both by Pekka and Herbert, this would need more thinking and designing. The implementation is flexible enough to finetune once the semantics for similar optimizations have been considered for AH and IPComp. --Diego _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jul 30 15:15:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dywo1-0005i3-Eb; Sat, 30 Jul 2005 15:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dywnz-0005ho-JE for hipsec@megatron.ietf.org; Sat, 30 Jul 2005 15:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24556 for ; Sat, 30 Jul 2005 15:15:29 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyxJt-0005rf-Ge for hipsec@ietf.org; Sat, 30 Jul 2005 15:48:30 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Dywns-0002LP-8J for hipsec@ietf.org; Sat, 30 Jul 2005 15:15:24 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BB768212C72; Sat, 30 Jul 2005 22:09:45 +0300 (EEST) In-Reply-To: <200507300838.j6U8coY7001856@givry.rennes.enst-bretagne.fr> References: <200507300838.j6U8coY7001856@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <452C95C4-1813-4B6B-B394-1FCF9469D197@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] The HIT prefix once again (was Re: Re: Type 1 and 2 HITs) Date: Sat, 30 Jul 2005 21:09:43 +0200 To: Francis Dupont X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Francis, > HIP is not the only protocol which could take avantage from > a dedicated prefix marked as not an address/not routable. > I wrote a short I-D draft-dupont-ipv6-cgpref-01.txt which could > work for at least HIP and a TMSI-like location privacy solution > for MIPv6. I consulted IANA at an IETF meeting just before writing > the first version.... > > I believe it could be better to share the prefix with other (and > with weaker requirements) usages, i.e., to win one bit (2 x) at the > cost of 1/8?... > > so you need an I-D. IMHO it will be easier with a short one than > with an "en passant" paragraph in a HIP architecture one.... > > PS: if you agree to join us, we can ask the IPv6 WG chairs to poll > the IPv6 WG about a WG item. I can't see technical concerns so it > should be easy and the discussion (in the mailing list about the > WG item) should only be about the length of the prefix. In principle, I think it would be good to join forces, and at least make the cases at the same time rather than one after another. However, what HIP needs now is an experimental prefix which, IMHO, should have a default timeout after which it is returned to IANA unless the IETF decides otherwise. I don't know what are your desires w.r.t the time frame for the prefix, i.e., whether you are trying to get a permanent prefix or just an assignment that would be returned unless the IETF decides otherwise. There also may be differences in whether the prefix is supposed to ever get out in IPv6 headers. In the HIP case it is not, i.e., it is supposed to appear only in HIP control packets in the network. IMHO those two issues may make a big difference that may also have affect to the length of the prefix that the IPv6 WG and the IETF are willing to issue. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 31 03:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz8VQ-0001y8-FX; Sun, 31 Jul 2005 03:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz8VO-0001xe-5t for hipsec@megatron.ietf.org; Sun, 31 Jul 2005 03:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10933 for ; Sun, 31 Jul 2005 03:45:04 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dz91O-0003Xz-Vc for hipsec@ietf.org; Sun, 31 Jul 2005 04:18:12 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j6V7iWR02668; Sun, 31 Jul 2005 09:44:32 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j6V7iWl6004438; Sun, 31 Jul 2005 09:44:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200507310744.j6V7iWl6004438@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander Subject: Re: [Hipsec] The HIT prefix once again (was Re: Re: Type 1 and 2 HITs) In-reply-to: Your message of Sat, 30 Jul 2005 21:09:43 +0200. <452C95C4-1813-4B6B-B394-1FCF9469D197@nomadiclab.com> Date: Sun, 31 Jul 2005 09:44:32 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In your previous mail you wrote: In principle, I think it would be good to join forces, and at least make the cases at the same time rather than one after another. => this is my idea. However, what HIP needs now is an experimental prefix which, IMHO, should have a default timeout after which it is returned to IANA unless the IETF decides otherwise. => I am not convinced it is faster to get an experimental prefix than a real/permanent one. IMHO the status of the prefix could only affect its length. I don't know what are your desires w.r.t the time frame for the prefix, i.e., whether you are trying to get a permanent prefix or just an assignment that would be returned unless the IETF decides otherwise. => it doesn't matter, i.e., this should be part of the negociation. There also may be differences in whether the prefix is supposed to ever get out in IPv6 headers. In the HIP case it is not, i.e., it is supposed to appear only in HIP control packets in the network. => "not routable" means the prefix must never occur in an IPv6 header. In fact this is because the prefix is easy to recognize we can enforce this. IMHO those two issues may make a big difference that may also have affect to the length of the prefix that the IPv6 WG and the IETF are willing to issue. => IMHO we have first "to open the door". Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 31 06:07:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAjG-0006q7-MR; Sun, 31 Jul 2005 06:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAjF-0006q2-Is for hipsec@megatron.ietf.org; Sun, 31 Jul 2005 06:07:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14834 for ; Sun, 31 Jul 2005 06:07:30 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBFE-00042k-1e for hipsec@ietf.org; Sun, 31 Jul 2005 06:40:41 -0400 Received: from [10.0.1.2] (open-24-101.ietf63.ietf.org [86.255.24.101]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B246C1BAC4D; Sun, 31 Jul 2005 12:07:13 +0200 (CEST) Date: Sun, 31 Jul 2005 12:03:53 +0200 From: Martin Stiemerling To: Alejandro Parra Briones , hipsec@ietf.org Subject: =?ISO-8859-1?Q?Re:_[Hipsec]_=BFIs_there_any_linux_based_NAT/FW_HIP_a?= =?ISO-8859-1?Q?ware_version=3F?= Message-ID: <1C22E38D060B114185E5D832@753F3B888A9969457862729D> In-Reply-To: <42E4C5810000169E@mailserver1.itesm.mx> References: <42E4C5810000169E@mailserver1.itesm.mx> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Alejandro, If you are interested on HIP across NAT and firewall you might consider reading this draft too: This document is mainly discussed in the HIP research group. Martin --On Dienstag, 26. Juli 2005 15:01 Uhr -0600 Alejandro Parra Briones wrote: | Dear HIP comunity: | I am a HIP newbie. I am a full time professor at a University in | Mexico. I have been reading the hip drafts. I am interested in the middle | boxes problem. I wonder if you have already working any NAT/FW HIP aware | version. If not I could help to make a prototype of a FW xor a NAT. | | | Regards | Alejandro Parra Briones | Centro de Investigacion en Informatica | CETEC 6to. Piso Torre norte | | 83284012 | | | _______________________________________________ | Hipsec mailing list | Hipsec@lists.ietf.org | https://www1.ietf.org/mailman/listinfo/hipsec | _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 31 18:18:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzM8P-0005tl-VV; Sun, 31 Jul 2005 18:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzM8O-0005td-40 for hipsec@megatron.ietf.org; Sun, 31 Jul 2005 18:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22348 for ; Sun, 31 Jul 2005 18:18:13 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzMeS-0002yo-Ov for hipsec@ietf.org; Sun, 31 Jul 2005 18:51:30 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA01155 for ; Sun, 31 Jul 2005 17:17:55 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6VMHsv08382 for ; Sun, 31 Jul 2005 17:17:54 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 15:17:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Jul 2005 15:17:53 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D512A97@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: comments on the WGLC drafts Thread-Index: AcWWHbJIDW+ZZJYiQueV92Oh6jayJg== From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 31 Jul 2005 22:17:54.0034 (UTC) FILETIME=[B2594520:01C5961D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] comments on the WGLC drafts X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I read through them this weekend again and think they are in good shape to move forward. A few minor points below to add to the final "issues" list: Base draft ---------- Sections 2.2 and 2.3 are incomplete There is a missing reference for Sigma in the Abstract and section 1.2. It should be: Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO 2003: 400-425 Section 11-- I have some question as to how these references should be cited. Do we need normative and informative in an experimental spec? Also, what to do about dependencies on drafts that are not yet published and may lag these documents (e.g., BEET draft referenced in the ESP document)? Appendices A and B probably can be deleted at this time, or edited (perhaps combined into a combined informative appendix "Probabilities on certain HIP computations". At the very least, Appendix B reads like it was copied and pasted from an email message and should be edited. Appendix E will need revised once IANA considerations are settled. ESP draft --------- the last paragraph of 3.2 should point to appendix A is a Section 5.3.3 needed showing the typical third (UPDATE ACK) packet? in 6.1, step 3, it may be helpful to state that it is not just having proper IP addresses but also proper IP header format for the IP addresses in use (i.e., IPv4 or IPv6). section 6.2, step 4-- typically, IP headers are not passed to the application, so I suggest deleting this step, or else rewording if something else was intended section 7, suggest telling the reader that the "g" and "l" subscripts are defined in the base spec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec