From hipsec-bounces@lists.ietf.org Tue Aug 15 05:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCupK-0003bK-Jn; Tue, 15 Aug 2006 05:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCupI-0003bF-IX for hipsec@ietf.org; Tue, 15 Aug 2006 05:03:08 -0400 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 1GCupH-0004Zp-2A for hipsec@ietf.org; Tue, 15 Aug 2006 05:03:08 -0400 Received: from [217.152.227.131] (hippy.infrahip.net [217.152.227.131]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 15 Aug 2006 12:03:04 +0300 id 0007C879.44E18DC8.00002A6D Message-ID: <44E18DC5.8060400@cs.helsinki.fi> Date: Tue, 15 Aug 2006 12:03:01 +0300 From: Andrei Gurtov User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-dns-06.txt References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: hipsec-bounces@lists.ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the next revision it would be good to update DNSSEC refs to RFC4033-RFC4035. How about simultaneous query of A and HIP RR? It might be useful to save some RTTs, but it doesn't seem explicitly described. What about storing multiple HIs per a host? Is it done using several HIP RRs? Some typos in the draft using HIT in APIS of the HPIHI record 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 (HIP) Domain Name System (DNS) Extensions > Author(s) : P. Nikander, J. Laganier > Filename : draft-ietf-hip-dns-06.txt > Pages : 21 > Date : 2006-2-27 > > This document specifies a new resource record (RR) for the Domain > Name System (DNS), and how to use it with the Host Identity Protocol > (HIP.) This RR allows 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 Names of its rendezvous servers (RVS.) > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-06.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-06.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-06.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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4Y0SP7jp0uceFkQRAt0sAJ40ptC+/BXmUp91EJsA1V0xasOHUQCg0v8c HKd1BYvnwmAbJn2W0Qlm8OA= =sCl2 -----END PGP SIGNATURE----- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 18 10:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5S7-0007kr-EI; Fri, 18 Aug 2006 10:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5S5-0007km-V5 for hipsec@ietf.org; Fri, 18 Aug 2006 10:36:01 -0400 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 1GE5S1-0002hE-A1 for hipsec@ietf.org; Fri, 18 Aug 2006 10:36:01 -0400 Received: from [217.152.227.130] (hipserver.infrahip.net [217.152.227.130]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 18 Aug 2006 17:35:55 +0300 id 0007C758.44E5D04B.00002387 Message-ID: <44E5D045.4040003@cs.helsinki.fi> Date: Fri, 18 Aug 2006 17:35:49 +0300 From: Andrei Gurtov User-Agent: Thunderbird 1.5.0.4 (X11/20060614) Mime-Version: 1.0 To: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-05.txt References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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="===============1104207684==" 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. --===============1104207684== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_courier-9095-1155911755-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-9095-1155911755-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I would like to ask if VIA parameter is mandatory or not. Currently the draft seems not clear on this, the first paragraph tells that responder may include addresses, while second tells it must do so 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. When a responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVS's. 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 (HIP) Rendezvous Extension > Author(s) : J. Laganier, L. Eggert > Filename : draft-ietf-hip-rvs-05.txt > Pages : 15 > Date : 2006-6-7 > > 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-05.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-05.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-05.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 > -- Andrei Gurtov gurtov@hiit.fi http://www.hiit.fi/andrei.gurtov Adjunct Professor, TKK PhD, Senior Research Scientist Helsinki Institute for Information Technology (HIIT) High Tech Center, Helsinki, Finland --=_courier-9095-1155911755-0001-2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJozCC AywwggKVoAMCAQICEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMjE4MTU1MVoX DTA3MDMyMjE4MTU1MVowfzEPMA0GA1UEBBMGR3VydG92MQ8wDQYDVQQqEwZBbmRyZWkxFjAU BgNVBAMTDUFuZHJlaSBHdXJ0b3YxJDAiBgkqhkiG9w0BCQEWFWd1cnRvdkBjcy5oZWxzaW5r aS5maTEdMBsGCSqGSIb3DQEJARYOZ3VydG92QGhpaXQuZmkwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDG8ApEd2xo6tY7eJLBpxUkYp4w0Gk94HlTGd4axDvJUtasnb5oCmn2 Kor1kmYMf+j9neL8hOPO5CUxpsM9gW2a05djUwiRv6clH4WNSSOyZ5JEv6h7uqwiYA4ILZ2e jnJjZrHOIVXX7Dy/3TCitmmTI9/I/wtSqbbkXyYxHBcyA9JT8wyxI7kpTwg10aSaaYDKf7hW 6pvkVVG+7fl8b1kvy8LC4jk0xfAt8OVXuI9Vdg0nH1hos2bTXHNA47ONbDrFvSWQGSCZnqYK OEcg8tmS7TZBTmhEHgkzZDKr4ZqAUPyYEvj0i+x345T0OjhkjW4EZlknyAIdRZhIE4avbJvZ AgMBAAGjQjBAMDAGA1UdEQQpMCeBFWd1cnRvdkBjcy5oZWxzaW5raS5maYEOZ3VydG92QGhp aXQuZmkwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCKrp4lDsaSRnlawg0/7+na HN/8y9bGorkWzCp2us64WEpgM+b83jwGkcjiR59N6gOAHq0olbpoXp1x5EEoW5aMIRycO49G uXesyibDnFzHrhJAlSmyQ/biAmaT1UuGw97wTVurxpTnO7LOKcjzqLS/9d5pRjUoYwGJnt0y bnvkpTCCAywwggKVoAMCAQICEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEEBQAwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMjE4 MTU1MVoXDTA3MDMyMjE4MTU1MVowfzEPMA0GA1UEBBMGR3VydG92MQ8wDQYDVQQqEwZBbmRy ZWkxFjAUBgNVBAMTDUFuZHJlaSBHdXJ0b3YxJDAiBgkqhkiG9w0BCQEWFWd1cnRvdkBjcy5o ZWxzaW5raS5maTEdMBsGCSqGSIb3DQEJARYOZ3VydG92QGhpaXQuZmkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDG8ApEd2xo6tY7eJLBpxUkYp4w0Gk94HlTGd4axDvJUtas nb5oCmn2Kor1kmYMf+j9neL8hOPO5CUxpsM9gW2a05djUwiRv6clH4WNSSOyZ5JEv6h7uqwi YA4ILZ2ejnJjZrHOIVXX7Dy/3TCitmmTI9/I/wtSqbbkXyYxHBcyA9JT8wyxI7kpTwg10aSa aYDKf7hW6pvkVVG+7fl8b1kvy8LC4jk0xfAt8OVXuI9Vdg0nH1hos2bTXHNA47ONbDrFvSWQ GSCZnqYKOEcg8tmS7TZBTmhEHgkzZDKr4ZqAUPyYEvj0i+x345T0OjhkjW4EZlknyAIdRZhI E4avbJvZAgMBAAGjQjBAMDAGA1UdEQQpMCeBFWd1cnRvdkBjcy5oZWxzaW5raS5maYEOZ3Vy dG92QGhpaXQuZmkwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCKrp4lDsaSRnla wg0/7+naHN/8y9bGorkWzCp2us64WEpgM+b83jwGkcjiR59N6gOAHq0olbpoXp1x5EEoW5aM IRycO49GuXesyibDnFzHrhJAlSmyQ/biAmaT1UuGw97wTVurxpTnO7LOKcjzqLS/9d5pRjUo YwGJnt0ybnvkpTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0 dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdCYaCCkzbYT1lgCG Ob4tpzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjA4MTgxNDM1NDlaMCMGCSqGSIb3DQEJBDEWBBRVPtoamxFjrisg9BRBZ49C pf9mGzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHQmGggpM22E 9ZYAhjm+LacwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEHQmGggpM22E9ZYAhjm+LacwDQYJKoZIhvcNAQEBBQAE ggEAZg3szJ7Sr5/RFgfzKAICAm/fRr/8BrbUoa6eFRNiiWNmFo//HyVSSgo2+bnMEFFfQr98 +AA5+qvdNnSNfQ7XYatbDSffqvIa+ppMdO4Fo26xAwHK50+vimoXC59X0OGLX/OWKuYypCu5 YoPvjupBus62CJboQICYNN7Dw9+irhkQfEtVbw0T0HAwbkuatkY6kvwpQteXjy2Kdg6GBiSG 12KNGVxK2tTAEPr1z7giuRbqBsDSKAKyu3emB1+kNg19lbC6cd1TiEcaao8258aWtecS8D03 fZL6z3QoZmkKUtFCqou7vNwiPOKO9yf4jsxpQfZwOeJ577qLnztnotpB8QAAAAAAAA== --=_courier-9095-1155911755-0001-2-- --===============1104207684== 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 --===============1104207684==-- From hipsec-bounces@lists.ietf.org Tue Aug 22 04:16:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRQq-0004kZ-9h; Tue, 22 Aug 2006 04:16:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFRQo-0004iV-Ef for hipsec@ietf.org; Tue, 22 Aug 2006 04:16:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFRQn-00047X-7Z for hipsec@ietf.org; Tue, 22 Aug 2006 04:16:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Aug 2006 01:16:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,154,1154934000"; d="scan'208"; a="37358708:sNHT4384217008" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7M8GFZr007701; Tue, 22 Aug 2006 04:16:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7M8GEuI002297; Tue, 22 Aug 2006 04:16:15 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 04:16:14 -0400 Received: from [192.168.1.101] ([10.82.217.85]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 04:16:13 -0400 Message-ID: <44EABD76.50100@cisco.com> Date: Tue, 22 Aug 2006 10:16:54 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: hip-chairs@tools.ietf.org, hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2006 08:16:14.0156 (UTC) FILETIME=[3BF0A8C0:01C6C5C3] DKIM-Signature: a=rsa-sha1; q=dns; l=415; t=1156234575; x=1157098575; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:draft-ietf-hip-esp-03 |To:hip-chairs@tools.ietf.org,=20hipsec@ietf.org; X=v=3Dcisco.com=3B=20h=3D9RcNBJ+2TKEcW3F8JtcYzmJz0z0=3D; b=Ez2iM6zjLTAnfO5RJNiWiTcVMl8cAzXuEgucm6BolimrqQVbhX0GFLal0I5J10tIkCjhRySc 1IyqsAcgxCy3Md/AYjM598mNn2v3vM4eO26JatpeWSjXrGUmJApaZ7n8; Authentication-Results: rtp-dkim-1.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Hipsec] draft-ietf-hip-esp-03 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: , Errors-To: hipsec-bounces@lists.ietf.org The Security Area has asked for the following: An explicit section describing why the semantics of HIP ESP differ from IPsec ESP,and explaining how a node can run both IPsec and HIP. If a node cannot run HIP and IPsec at the same time in all configurations of HIP, you are likely to see significant pushback. Such a section sounds reasonable. Also, is the latter true or false? Thanks, - Mark _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 24 02:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8ot-0000a7-3Q; Thu, 24 Aug 2006 02:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8or-0000a2-EW for hipsec@ietf.org; Thu, 24 Aug 2006 02:36:01 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG8oo-0004LR-2J for hipsec@ietf.org; Thu, 24 Aug 2006 02:36:01 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7O6ZZfc015579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Aug 2006 23:35:35 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7O6ZuKs028016 for ; Wed, 23 Aug 2006 23:35:57 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7O6ZuLl028008; Wed, 23 Aug 2006 23:35:56 -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.1830); Wed, 23 Aug 2006 23:35:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-ietf-hip-esp-03 Date: Wed, 23 Aug 2006 23:35:55 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44EABD76.50100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-esp-03 Thread-Index: AcbFw4Bn1Smars+ATD2qHKZdJhM12gBgPvzw From: "Henderson, Thomas R" To: "Mark Townsley" X-OriginalArrivalTime: 24 Aug 2006 06:35:56.0491 (UTC) FILETIME=[8DF559B0:01C6C747] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: hipsec-bounces@lists.ietf.org OK, I'll bite...=20 > -----Original Message----- > From: Mark Townsley [mailto:townsley@cisco.com]=20 > Sent: Tuesday, August 22, 2006 1:17 AM > To: hip-chairs@tools.ietf.org; hipsec@ietf.org > Subject: [Hipsec] draft-ietf-hip-esp-03 >=20 >=20 > The Security Area has asked for the following: >=20 > An explicit section describing why the semantics of HIP ESP differ=20 > from IPsec ESP,and explaining how a node can run both IPsec and HIP. =20 > If a node cannot run HIP and IPsec at the same time in all=20 > configurations of HIP, you are likely to see significant pushback. >=20 > Such a section sounds reasonable. Also, is the latter true or false? - How the semantics of HIP ESP differ from those of IPsec ESP: See Section 5 of: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt - Why the semantics of HIP ESP differ from those of IPsec ESP: See Section 3 of: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt - Can a node run both IPsec and HIP at the same time? If one defines IPsec as including the proposed BEET mode, then the answer is "yes," HIP can run with a proposed extension of IPsec ESP; moreover, the only mode of HIP presently defined is one that *requires* such ESP. =20 If one defines IPsec as all modes of RFCs 430*, then strictly speaking, I think the answer is "no," for the following reasons (there may be more): i) existing transport mode has issues due to the use of IP addresses and not HITs in the upper-layer checksum ii) tunnel mode may have issues in supporting BITW implementations? That is, I understand from recent shim6 discussions that one cannot just implement IPsec native in the stack; one must also be able to implement the same SAD/SPD in BITW gateways. Since HITs are not routable (unlike shim6 ULIDs), it would seem to me to be difficult to do so in practice. (By the way, no one has formally proposed using HIP with existing tunnel mode, other than in some WG discussions I've participated in). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 24 03:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9z4-00016k-3D; Thu, 24 Aug 2006 03:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9z3-00016f-Ai for hipsec@ietf.org; Thu, 24 Aug 2006 03:50:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG9z1-0006BB-RI for hipsec@ietf.org; Thu, 24 Aug 2006 03:50:37 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA73D212C61; Thu, 24 Aug 2006 10:50:23 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id A922D212C3F; Thu, 24 Aug 2006 10:50:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@lists.ietf.org Subject: Re: [Hipsec] draft-ietf-hip-esp-03 Date: Thu, 24 Aug 2006 11:03:23 +0300 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@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: <200608241103.23967.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Tom, Mark, and others On Thursday 24 August 2006 09:35, Henderson, Thomas R wrote: > > If one defines IPsec as all modes of RFCs 430*, then strictly speaking, > I think the answer is "no," for the following reasons (there may be > more): > i) existing transport mode has issues due to the use of IP addresses and > not HITs in the upper-layer checksum The upper-layer checksum is indeed calculated with HITs, but I don't see what is the problem with the checksum. On inbound packet: The implementation has to keep track of the SPIs used for HIP connections and apply the upper-layer checksum verification method using HITs proposed in: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-03.txt section 3.2 paragraph 2. On outbound packet: A strict binding between the socket, SP and SA is needed so that the packet which checksum was calculated using HITs will end up to the SA created by HIP. If then IKE or any other keying protocol creates a SA in the host with same end points the upper-layer checksum verification is then done using IP addresses. The SPI value will be anyway different in different SAs. > ii) tunnel mode may have issues in supporting BITW implementations? > That is, I understand from recent shim6 discussions that one cannot just > implement IPsec native in the stack; one must also be able to implement > the same SAD/SPD in BITW gateways. Since HITs are not routable (unlike > shim6 ULIDs), it would seem to me to be difficult to do so in practice. > (By the way, no one has formally proposed using HIP with existing tunnel > mode, other than in some WG discussions I've participated in). Tunnel mode should work fine with HIP as long as you create the tunnel end-to-end which is basically the way BEET works. The policies created by HIP using tunnel mode would inner-addresses with prefix length of 128 bits which would mean that the packet received through the tunnel is destined to local host. In BEET you basically have a "tunnel" that is end-to-end (BEET just doesn't send the inner header on the wire). The HIP protocol is not able create a end-to-network tunnels as it is a end-to-end keying protocol. Using tunnel mode is pretty straight forward but you'll end up having the overhead of the IPv6 header (Our first linux implementation of HIP used tunnel mode instead of BEET mode). Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 24 03:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGA1B-0001K6-LW; Thu, 24 Aug 2006 03:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGA1A-0001Jv-Cx for hipsec@ietf.org; Thu, 24 Aug 2006 03:52:48 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGA18-0006dg-L0 for hipsec@ietf.org; Thu, 24 Aug 2006 03:52:48 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id TAA23118; Thu, 24 Aug 2006 19:52:29 +1200 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] draft-ietf-hip-esp-03 Date: Thu, 24 Aug 2006 19:53:38 +1200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: hipsec-bounces@lists.ietf.org On 24/08/2006, at 6:35 PM, Henderson, Thomas R wrote: > > - Can a node run both IPsec and HIP at the same time? > If one defines IPsec as including the proposed BEET mode, then the > answer is "yes," HIP can run with a proposed extension of IPsec ESP; > moreover, the only mode of HIP presently defined is one that > *requires* > such ESP. > > If one defines IPsec as all modes of RFCs 430*, then strictly > speaking, > I think the answer is "no," for the following reasons (there may be > more): > i) existing transport mode has issues due to the use of IP > addresses and > not HITs in the upper-layer checksum > ii) tunnel mode may have issues in supporting BITW implementations? > That is, I understand from recent shim6 discussions that one cannot > just > implement IPsec native in the stack; one must also be able to > implement > the same SAD/SPD in BITW gateways. Since HITs are not routable > (unlike > shim6 ULIDs), it would seem to me to be difficult to do so in > practice. > (By the way, no one has formally proposed using HIP with existing > tunnel > mode, other than in some WG discussions I've participated in). > But isn't it the case that a node can perfectly well run HIP and IPsec at the same time on different SPIs in any combination of modes? In other words, mere support of HIP should have no effect on IPsec support. There is little logical problem with running tunnel-mode between two HIP nodes using HIP as the keying/initialisation protocol, however this was somewhat contrary to the initial goals of HIP. Nevertheless, it should not be difficult. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 24 06:22:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGCL1-0001bT-S7; Thu, 24 Aug 2006 06:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGCL0-0001bE-UC for hipsec@lists.ietf.org; Thu, 24 Aug 2006 06:21:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGA5K-0007Wr-9a for hipsec@lists.ietf.org; Thu, 24 Aug 2006 03:57:06 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG9yy-0003HV-Bs for hipsec@lists.ietf.org; Thu, 24 Aug 2006 03:50:34 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA73D212C61; Thu, 24 Aug 2006 10:50:23 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id A922D212C3F; Thu, 24 Aug 2006 10:50:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@lists.ietf.org Subject: Re: [Hipsec] draft-ietf-hip-esp-03 Date: Thu, 24 Aug 2006 11:03:23 +0300 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F5D4@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: <200608241103.23967.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Tom, Mark, and others On Thursday 24 August 2006 09:35, Henderson, Thomas R wrote: > > If one defines IPsec as all modes of RFCs 430*, then strictly speaking, > I think the answer is "no," for the following reasons (there may be > more): > i) existing transport mode has issues due to the use of IP addresses and > not HITs in the upper-layer checksum The upper-layer checksum is indeed calculated with HITs, but I don't see what is the problem with the checksum. On inbound packet: The implementation has to keep track of the SPIs used for HIP connections and apply the upper-layer checksum verification method using HITs proposed in: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-03.txt section 3.2 paragraph 2. On outbound packet: A strict binding between the socket, SP and SA is needed so that the packet which checksum was calculated using HITs will end up to the SA created by HIP. If then IKE or any other keying protocol creates a SA in the host with same end points the upper-layer checksum verification is then done using IP addresses. The SPI value will be anyway different in different SAs. > ii) tunnel mode may have issues in supporting BITW implementations? > That is, I understand from recent shim6 discussions that one cannot just > implement IPsec native in the stack; one must also be able to implement > the same SAD/SPD in BITW gateways. Since HITs are not routable (unlike > shim6 ULIDs), it would seem to me to be difficult to do so in practice. > (By the way, no one has formally proposed using HIP with existing tunnel > mode, other than in some WG discussions I've participated in). Tunnel mode should work fine with HIP as long as you create the tunnel end-to-end which is basically the way BEET works. The policies created by HIP using tunnel mode would inner-addresses with prefix length of 128 bits which would mean that the packet received through the tunnel is destined to local host. In BEET you basically have a "tunnel" that is end-to-end (BEET just doesn't send the inner header on the wire). The HIP protocol is not able create a end-to-network tunnels as it is a end-to-end keying protocol. Using tunnel mode is pretty straight forward but you'll end up having the overhead of the IPv6 header (Our first linux implementation of HIP used tunnel mode instead of BEET mode). Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 25 03:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWLO-00013f-HN; Fri, 25 Aug 2006 03:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWLM-00012M-R0 for hipsec@ietf.org; Fri, 25 Aug 2006 03:43:08 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGWLL-000283-C6 for hipsec@ietf.org; Fri, 25 Aug 2006 03:43:08 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 38987212C61; Fri, 25 Aug 2006 10:17:54 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BB72D212C3F; Fri, 25 Aug 2006 10:17:53 +0300 (EEST) Message-ID: <44EEA3D5.3080505@nomadiclab.com> Date: Fri, 25 Aug 2006 10:16:37 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Mark Townsley , hipsec@ietf.org Subject: Re: [Hipsec] draft-ietf-hip-esp-03 References: <44EABD76.50100@cisco.com> In-Reply-To: <44EABD76.50100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: jan.melen@nomadiclab.com, hip-chairs@tools.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: , Errors-To: hipsec-bounces@lists.ietf.org Mark Townsley wrote: > > The Security Area has asked for the following: > > An explicit section describing why the semantics of HIP ESP differ from > IPsec ESP,and explaining how a node can run both IPsec and HIP. If a > node cannot run HIP and IPsec at the same time in all configurations of > HIP, you are likely to see significant pushback. > > Such a section sounds reasonable. Also, is the latter true or false? > > Thanks, > > - Mark Hi, we discussed with Jan about this and he wrote a proposal for a new subsection describing what has to be considered when HIP is used together with other keying protocols. This limits implementation possibilities, but I hope it is not too restrictive to be written on the specification. BR, Petri 3.4 IPsec and HIP ESP implementation considerations When HIP is run on a node where a standards compliant IPsec is used, some issues have to be considered. The HIP implementation must be able to co-exist with other IPsec keying protocols. When the HIP implementation selects the SPI value, it may lead to a collision if not implemented properly. To avoid the possibility for a collision, the HIP implementation MUST request SPI values from the IPsec (e.g. using PFKey interface). For outbound traffic the HIP has to make a strict binding between the application socket, Security Policy (SP), and Security Association (SA) used by HIP. Data originating from a socket that should be processed as described in this document should have a SP that is bound to the socket. The SP then MUST be bound to the matching SA and non-HIP packets will not be processed by this SA. Data originating from a socket that is not using HIP, MUST NOT have checksum recalculated as described in Section 3.2 paragraph 2 and data MUST NOT be passed to the SP or SA created by the HIP. Incoming data packets using a SA that is not negotiated by HIP, MUST NOT be processed as described in Section 3.2 paragraph 2. The SPI will identify the correct SA for packet decryption and MUST be used to identify that the packet has an upper-layer checksum that is calculated in HIP way. The socket that uses HIP SHOULD NOT be able to receive any data that has not come through the SA that was created by HIP. /petri -- Petri Jokela e-mail: petri.jokela@nomadiclab.com Research Scientist phone: +358 9 299 2413 Ericsson Research, NomadicLab mobile: +358 44 299 2413 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 25 10:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGci2-00013m-Ih; Fri, 25 Aug 2006 10:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGchz-0000tN-Vl for hipsec@ietf.org; Fri, 25 Aug 2006 10:30:55 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGchw-0005WN-Me for hipsec@ietf.org; Fri, 25 Aug 2006 10:30:55 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7PEUi7Q000809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Aug 2006 07:30:50 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7PEUhoF002220 for ; Fri, 25 Aug 2006 07:30:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7PEUaQb001740; Fri, 25 Aug 2006 07:30:41 -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.1830); Fri, 25 Aug 2006 07:30:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-ietf-hip-esp-03 Date: Fri, 25 Aug 2006 07:30:40 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F5DA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-esp-03 Thread-Index: AcbHUkzxGIAdeKabQNuJEKyWglOYdAA/8Gzg From: "Henderson, Thomas R" To: "Andrew McGregor" X-OriginalArrivalTime: 25 Aug 2006 14:30:40.0726 (UTC) FILETIME=[0A4C6F60:01C6C853] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Andrew McGregor [mailto:andrew@indranet.co.nz]=20 > Sent: Thursday, August 24, 2006 12:54 AM > To: Henderson, Thomas R > Cc: Mark Townsley; hipsec@ietf.org > Subject: Re: [Hipsec] draft-ietf-hip-esp-03 >=20 > But isn't it the case that a node can perfectly well run HIP and =20 > IPsec at the same time on different SPIs in any combination of =20 > modes? In other words, mere support of HIP should have no effect on =20 > IPsec support. >=20 Yes, I misread the second part of the question as asking whether HIP qualified as IPsec. I agree with you. mea culpa, Tom=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 30 12:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISel-00057y-Fb; Wed, 30 Aug 2006 12:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISej-00057m-6z for hipsec@ietf.org; Wed, 30 Aug 2006 12:11:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISeg-00022i-T8 for hipsec@ietf.org; Wed, 30 Aug 2006 12:11:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Aug 2006 09:11:05 -0700 X-IronPort-AV: i="4.08,189,1154934000"; d="scan'208"; a="39012368:sNHT2910494686" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7UGB4ZI025064; Wed, 30 Aug 2006 12:11:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7UGB4uI027291; Wed, 30 Aug 2006 12:11:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 12:11:03 -0400 Received: from [192.168.1.101] ([10.82.240.127]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 12:11:03 -0400 Message-ID: <44F5B894.6090108@cisco.com> Date: Wed, 30 Aug 2006 18:11:00 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Petri Jokela Subject: Re: [Hipsec] draft-ietf-hip-esp-03 References: <44EABD76.50100@cisco.com> <44EEA3D5.3080505@nomadiclab.com> In-Reply-To: <44EEA3D5.3080505@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2006 16:11:03.0888 (UTC) FILETIME=[E472C500:01C6CC4E] DKIM-Signature: a=rsa-sha1; q=dns; l=2937; t=1156954264; x=1157818264; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20[Hipsec]=20draft-ietf-hip-esp-03 |To:Petri=20Jokela=20; X=v=3Dcisco.com=3B=20h=3DgvNP2JDOPH4thR3gNhR9opRwsWQ=3D; b=nBSp743sSoI1BVgv1IKqZzd/WfZlHvepDCrNB+5G53hH6rVEDtS7b+u0nJsatWWWdPiG+/kp z+HWdKtWeeK1sPIa3IRITLXDQd7gI2q9hM4FAPYCDSXZYMLkEFEjqosk; Authentication-Results: rtp-dkim-2.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: hipsec@ietf.org, Russ Housley , Sam Hartman , hip-chairs@tools.ietf.org, jan.melen@nomadiclab.com 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: , Errors-To: hipsec-bounces@lists.ietf.org It sounds like this addresses the concern in terms of "truth in advertising" here, and I am very glad to see this as it is certainly important. I wonder if the IPsec community will have architectural issues with SPIs being attached to specific processing above the IP stack (depending, I suppose, on where you consider HIP, IP, and IPsec in relation to one another). I remember somewhat similar cases in the past causing serious heartburn within the IPsec community. cc'ing Sam and Russ for their opinion. - Mark Petri Jokela wrote: > Mark Townsley wrote: >> >> The Security Area has asked for the following: >> >> An explicit section describing why the semantics of HIP ESP differ >> from IPsec ESP,and explaining how a node can run both IPsec and HIP. >> If a node cannot run HIP and IPsec at the same time in all >> configurations of HIP, you are likely to see significant pushback. >> >> Such a section sounds reasonable. Also, is the latter true or false? >> >> Thanks, >> >> - Mark > > Hi, > > we discussed with Jan about this and he wrote a proposal for a new > subsection describing what has to be considered when HIP is used > together with other keying protocols. This limits implementation > possibilities, but I hope it > is not too restrictive to be written on the specification. > > BR, Petri > > > 3.4 IPsec and HIP ESP implementation considerations > > When HIP is run on a node where a standards compliant IPsec is used, > some issues have to be considered. > > The HIP implementation must be able to co-exist with other IPsec keying > protocols. When the HIP implementation selects the SPI value, it may > lead to a collision if not implemented properly. To avoid the > possibility for a collision, the HIP implementation MUST request SPI > values from the IPsec (e.g. using PFKey interface). > > For outbound traffic the HIP has to make a strict binding between the > application socket, Security Policy (SP), and Security Association (SA) > used by HIP. Data originating from a socket that should be processed as > described in this document should have a SP that is bound to the socket. > The SP then MUST be bound to the matching SA and non-HIP packets will > not be processed by this SA. Data originating from a socket that is not > using HIP, MUST NOT have checksum recalculated as described in Section > 3.2 paragraph 2 and data MUST NOT be passed to the SP or SA created by > the HIP. > > Incoming data packets using a SA that is not negotiated by HIP, MUST NOT > be processed as described in Section 3.2 paragraph 2. The SPI will > identify the correct SA for packet decryption and MUST be used to > identify that the packet has an upper-layer checksum that is calculated > in HIP way. The socket that uses HIP SHOULD NOT be able to receive any > data that has not come through the SA that was created by HIP. > > /petri > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 30 15:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVj2-0003UC-Bl; Wed, 30 Aug 2006 15:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVj1-0003U7-4z for hipsec@ietf.org; Wed, 30 Aug 2006 15:27:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIViz-0005Au-T6 for hipsec@ietf.org; Wed, 30 Aug 2006 15:27:47 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Aug 2006 12:27:45 -0700 X-IronPort-AV: i="4.08,189,1154934000"; d="scan'208"; a="39063364:sNHT32745612" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7UJRjpW032669; Wed, 30 Aug 2006 15:27:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7UJRidM018875; Wed, 30 Aug 2006 15:27:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 15:27:44 -0400 Received: from [192.168.1.101] ([10.82.240.127]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 15:27:44 -0400 Message-ID: <44F5E6AD.3000209@cisco.com> Date: Wed, 30 Aug 2006 21:27:41 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [Hipsec] draft-ietf-hip-esp-03 References: <44EABD76.50100@cisco.com> <44EEA3D5.3080505@nomadiclab.com> <44F5B894.6090108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2006 19:27:44.0360 (UTC) FILETIME=[5E13E680:01C6CC6A] DKIM-Signature: a=rsa-sha1; q=dns; l=1172; t=1156966065; x=1157830065; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20[Hipsec]=20draft-ietf-hip-esp-03 |To:Sam=20Hartman=20; X=v=3Dcisco.com=3B=20h=3DgvNP2JDOPH4thR3gNhR9opRwsWQ=3D; b=WqlWOIKfcw2TtA+f18Ncse2m8rgfaCF7F+3YImuuJ7E2++JaJ2tyCM4h0SWlrCX12D+U4Yfs vBzp4fb8jHaZSFAO3LWXePV8YnATdrxjEvkfJZV4bhBbtyHqyHuz67+9; Authentication-Results: rtp-dkim-1.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: hipsec@ietf.org, Russ Housley , hip-chairs@tools.ietf.org, jan.melen@nomadiclab.com 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: , Errors-To: hipsec-bounces@lists.ietf.org Thanks, Sam. Could you facilitate a secdir review? - Mark Sam Hartman wrote: >>>>>> "Mark" == Mark Townsley writes: >>>>>> > > Mark> It sounds like this addresses the concern in terms of "truth > Mark> in advertising" here, and I am very glad to see this as it > Mark> is certainly important. I wonder if the IPsec community will > Mark> have architectural issues with SPIs being attached to > Mark> specific processing above the IP stack (depending, I > Mark> suppose, on where you consider HIP, IP, and IPsec in > Mark> relation to one another). I remember somewhat similar cases > Mark> in the past causing serious heartburn within the IPsec > Mark> community. > > I actually saw a copy of the new section 3.4 before it was posted to > the list (or at the same time). I think the best thing to do at this > point is to run it by the IPsec community either by asking for secdir > reviews or by sending to the old ipsec list. > > I actually suspect you get more comments of the form "you said things > the wrong way," than "you did things that must not be done. > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 30 16:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWGh-0006uH-1M; Wed, 30 Aug 2006 16:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWGf-0006u6-EW for hipsec@ietf.org; Wed, 30 Aug 2006 16:02:33 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWGe-0001Oh-34 for hipsec@ietf.org; Wed, 30 Aug 2006 16:02:33 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7UK2QqY006507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Aug 2006 13:02:27 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7UK2P6c009012 for ; Wed, 30 Aug 2006 13:02:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7UK2Mqm008918; Wed, 30 Aug 2006 13:02: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.1830); Wed, 30 Aug 2006 13:02:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-ietf-hip-esp-03 Date: Wed, 30 Aug 2006 13:02:23 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F616@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <44EEA3D5.3080505@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-esp-03 Thread-Index: AcbIGmMSka0xY2OZTAGJsEuQ/Mx/jgEUxZSQ From: "Henderson, Thomas R" To: "Petri Jokela" , "Mark Townsley" , X-OriginalArrivalTime: 30 Aug 2006 20:02:23.0859 (UTC) FILETIME=[358E4430:01C6CC6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: jan.melen@nomadiclab.com, hip-chairs@tools.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: , Errors-To: hipsec-bounces@lists.ietf.org I have a few comments on this proposed text. > 3.4 IPsec and HIP ESP implementation considerations >=20 > When HIP is run on a node where a standards compliant IPsec is used, > some issues have to be considered. >=20 > The HIP implementation must be able to co-exist with other=20 > IPsec keying > protocols. When the HIP implementation selects the SPI value, it may > lead to a collision if not implemented properly. To avoid the > possibility for a collision, the HIP implementation MUST request SPI > values from the IPsec (e.g. using PFKey interface). I would prefer to say "MUST ensure that the SPI values used for HIP SAs are not used for IPsec or other SAs, and vice versa." -- less implementation dependent description.=20 >=20 > For outbound traffic the HIP has to make a strict binding between the > application socket, Security Policy (SP), and Security=20 > Association (SA) > used by HIP. Data originating from a socket that should be=20 > processed as > described in this document should have a SP that is bound to=20 > the socket. I think that the issue of binding a HIP SA to a socket is a separate implementation/architectural issue that also exists in the realm of IPsec (the channel binding discussion in BTNS WG). The above text conflicts with section 9 of the BEET draft (and also our experience) that says that you can reuse an existing IPsec implementation (without socket bindings) to implement HIP. I think that it suffices to say that for outbound traffic, the SPD or (coordinated) SPDs if there are two (one for HIP, one for IPsec) must ensure that packets intended for HIP processing are given a HIP-enabled SA and that packets intended for IPsec processing are given an IPsec-enabled SA. > The SP then MUST be bound to the matching SA and non-HIP packets will > not be processed by this SA. Data originating from a socket=20 > that is not > using HIP, MUST NOT have checksum recalculated as described in Section > 3.2 paragraph 2 and data MUST NOT be passed to the SP or SA created by > the HIP. >=20 > Incoming data packets using a SA that is not negotiated by=20 > HIP, MUST NOT > be processed as described in Section 3.2 paragraph 2. The SPI will > identify the correct SA for packet decryption and MUST be used to > identify that the packet has an upper-layer checksum that is=20 > calculated > in HIP way. The socket that uses HIP SHOULD NOT be able to receive any > data that has not come through the SA that was created by HIP. >=20 I don't think the last sentence adds anything. Regards, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec