From david.black@emc.com Tue Mar 1 06:44:13 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0AE3A67E9; Tue, 1 Mar 2011 06:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.303 X-Spam-Level: X-Spam-Status: No, score=-105.303 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, FRT_ESTABLISH2=2.492, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v-UL6DEdySv; Tue, 1 Mar 2011 06:44:07 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 657213A67A4; Tue, 1 Mar 2011 06:44:07 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21Ej7LI002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2011 09:45:07 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 1 Mar 2011 09:44:59 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21EiOus005331; Tue, 1 Mar 2011 09:44:24 -0500 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 1 Mar 2011 09:44:23 -0500 From: To: Date: Tue, 1 Mar 2011 09:44:23 -0500 Thread-Topic: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05 Thread-Index: AcvXSSQWVLSkZuCtQpq/WI8KzEo1qwA1Udsw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C57C@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> <70848F08-3FA5-4BD0-8CCA-6987C6444C17@ericsson.com> In-Reply-To: <70848F08-3FA5-4BD0-8CCA-6987C6444C17@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 02 Mar 2011 01:24:35 -0800 Cc: hipsec@ietf.org, ops-dir@ietf.org, rdroms.ietf@gmail.com, david.black@emc.com, gonzalo.camarillo@ericsson.com Subject: Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 01 Mar 2011 14:44:13 -0000 Hi Ari, > If we explicitly prevent a policy that would not allow un-encrypted conne= ction re-establishing > UPDATEs, I think we have this fixed, and we would not need to use error m= essages for informing about > this. I would change the text in section 5 into (added the last sentence = and changed the second-to- > last one): >=20 > [...] If encryption was > previously used, hosts SHOULD send outside of the encrypted > connection only HIP messages that are used to re-establish the > encrypted connection. Especially, messages for which the policy is > to send them only encrypted (e.g., DATA messages using an encrypted > transport mode) MUST be sent only using the encrypted connection. > Note that a policy MUST NOT prevent sending un-encrypted UPDATE > messages used for re-establishing the encrypted connection, since > that would prevent recovering from failed encrypted connections. That proposed change looks good to me, as the immediately following sentenc= e in Section 5 points back to Section 3.2 for the re-negotiation, from whic= h the reader will proceed to Section 3.3 on handling the error that occurs = if the re-negotiation fails to propose an encrypted HIP transport. Please wait to hear from Ralph (AD) before submitting a revised draft, as a= n RFC Editor Note may suffice to make this change. Thanks, --David > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Monday, February 28, 2011 8:11 AM > To: Black, David > Cc: ops-dir@ietf.org; hipsec@ietf.org; rdroms.ietf@gmail.com; gonzalo.cam= arillo@ericsson.com > Subject: Re: [Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05 >=20 > Hi David, >=20 > Thanks for the review! >=20 > On Feb 25, 2011, at 9:07 PM, = wrote: > [...] > > Summary: This draft is basically ready for publication, but has nits th= at should be fixed before > publication. > [...] > > I have one recommendation for change - this draft is somewhat inconsist= ent about support for a HIP > node policy that requires use of an encrypted transport for HIP signaling= . Section 3.3 provides an > essential building block, the error signaling mechanism to indicate that = an encrypted transport is > required and none was proposed. On the other hand, Section 5 is unclear = with respect to this class of > policy in that it strongly recommends (SHOULD) fallback to a non-encrypte= d HIP connection but requires > (MUST) that "messages that are intended to be sent only encrypted" not be= sent unencrypted. If the > "messages that are intended to be sent only encrypted" are all HIP messag= es after the base exchange, > these two requirements appear to be in conflict. >=20 > That's a valid point. A policy that would prevent sending the re-establis= hing UPDATEs un-encrypted > after a failed encrypted connection would be unreasonable since then one = could never re-establish such > a connection or even close it properly. This is already explicit for the = receiving end (MUST accept > without encryption), but making it explicit also for the sender makes sen= se. >=20 > The first SHOULD refers to the fact that one may also do something else t= han re-establish the > connection (e.g., close it). >=20 > > I suggest adding a short explanation to Section 5 of what would be reas= onable vs. unreasonable > policy for "messages that are intended to be sent only encrypted", and ho= w to use the Section 3.3 > error report when a failed encrypted connection is recovered by attemptin= g to fall back to an > unencrypted connection when HIP node policy requires encryption of all si= gnaling after the base > exchange. >=20 >=20 > If we explicitly prevent a policy that would not allow un-encrypted conne= ction re-establisihing > UPDATEs, I think we have this fixed, and we would not need to use error m= essages for informing about > this. I would change the text in section 5 into (added the last sentence = and changed the second-to- > last one): >=20 > [...] If encryption was > previously used, hosts SHOULD send outside of the encrypted > connection only HIP messages that are used to re-establish the > encrypted connection. Especially, messages for which the policy is > to send them only encrypted (e.g., DATA messages using an encrypted > transport mode) MUST be sent only using the encrypted connection. > Note that a policy MUST NOT prevent sending un-encrypted UPDATE > messages used for re-establishing the encrypted connection, since > that would prevent recovering from failed encrypted connections. >=20 >=20 > Cheers, > Ari From ari.keranen@ericsson.com Tue Mar 1 07:42:29 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49613A6975; Tue, 1 Mar 2011 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5d7tqArgkNu; Tue, 1 Mar 2011 07:42:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5C5CF3A695A; Tue, 1 Mar 2011 07:42:28 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-e4-4d6d141f68ff Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 72.3E.09202.F141D6D4; Tue, 1 Mar 2011 16:43:27 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Tue, 1 Mar 2011 16:43:26 +0100 Received: from EV000C295089FF.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 56C4A2868; Tue, 1 Mar 2011 17:43:26 +0200 (EET) MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-95-711942887"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C57C@MX14A.corp.emc.com> Date: Tue, 1 Mar 2011 17:43:26 +0200 Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> <70848F08-3FA5-4BD0-8CCA-6987C6444C17@ericsson.com> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C57C@MX14A.corp.emc.com> To: david.black@emc.com X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 02 Mar 2011 01:24:35 -0800 Cc: "hipsec@ietf.org" , "ops-dir@ietf.org" , "rdroms.ietf@gmail.com" , Gonzalo Camarillo Subject: Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 01 Mar 2011 15:42:29 -0000 --Apple-Mail-95-711942887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, On Mar 1, 2011, at 4:44 PM, david.black@emc.com wrote: >> If we explicitly prevent a policy that would not allow un-encrypted = connection re-establishing >> UPDATEs, I think we have this fixed, and we would not need to use = error messages for informing about >> this. I would change the text in section 5 into (added the last = sentence and changed the second-to- >> last one): >>=20 >> [...] If encryption was >> previously used, hosts SHOULD send outside of the encrypted >> connection only HIP messages that are used to re-establish the >> encrypted connection. Especially, messages for which the policy is >> to send them only encrypted (e.g., DATA messages using an encrypted >> transport mode) MUST be sent only using the encrypted connection. >> Note that a policy MUST NOT prevent sending un-encrypted UPDATE >> messages used for re-establishing the encrypted connection, since >> that would prevent recovering from failed encrypted connections. >=20 > That proposed change looks good to me, as the immediately following = sentence in Section 5 points back to Section 3.2 for the re-negotiation, = from which the reader will proceed to Section 3.3 on handling the error = that occurs if the re-negotiation fails to propose an encrypted HIP = transport. Thanks! I'll use that text in the next revision. > Please wait to hear from Ralph (AD) before submitting a revised draft, = as an RFC Editor Note may suffice to make this change. OK, although there will be at least one more change due to Lars' review, = so it probably makes sense to submit a revised version after I've fixed = all the comments and discusses. Cheers, Ari --Apple-Mail-95-711942887 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM6TCCBCsw ggMToAMCAQICEQC9hDQ5ZjGu+Cn6udMwJoBBMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMDgwOTE5MTM1 OTAwWhcNMTEwOTE5MTM1ODU4WjBlMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMQXJpIEtl csOkbmVuMRAwDgYDVQQFEwdlYXJpa2VyMScwJQYJKoZIhvcNAQkBFhhhcmkua2VyYW5lbkBlcmlj c3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKjeyOGs+5NtHV4qZlJvjhrlFb7D lJKBsAd7D/Oul1Ok2Ne41Gc55HdD52M9tYuaGi0GPJBxzMc1YfVEip9T4HEwQqbq9qHHjmS8DZvr 7OJxtKQQT1hGFhrd+wNfA9J5yZZoSfDaTqA4EmWiQjIceqaozPLDAUTFz/t0vAkhICrHAgMBAAGj ggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNv bS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5j b20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhcmkua2VyYW5lbkBl cmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYjaHR0cDovL3d3 dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFPBNTCM2UrAPmOF02kMY6zDaIIGF MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG 9w0BAQUFAAOCAQEAeEFvRB0WTJBpsuiLvPTX+YjxfS1KM26phSXddRfN5WgHV1LhjDlHO0MdNifJ 7E+s5Cnqe//YURaDyLQxU/LoVMUz7DtCMtAPTwkSXYjeRsLF138PRi4+p25cuduizbfZxMqDvtgs PH6hkJw05fYOdm/ejfjzG0nd8a5BE9/srrqvzQj5w67Vx5aOkKlR0V/0iVVMIJD/w3/dFZPv1YlX E+ZXStP8oqdH+VgGOBMHhjDZFy43HXJYN3yfTseaKpk+q6QHY1rQfOZx/I1pQOMy5np7czxlzuTi IkyTNVHFHY49Z7L+aKn7tjLHZgLABafYnzkFAEbT4jRBysbboYEsMDCCBEUwggMtoAMCAQICEBPJ 6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3Jv dXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2MTAwNjEwMDA1 M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29u IE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYQd+Q1 HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLnfub9LBc7dQpR Hjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT39h79brHdRkd PBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXRlobv0Klu8lxG 5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2oFRQ6Px7/Gydp M/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQIMAYBAf8CAQAw RgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50cnVzdC50ZWxp YS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxvPVRlbGlhU29u ZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4GmKhqCMbY4g4 o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tPjhUvSuNs00Nh d0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz6Npztpo2JG7A EKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIKXrIVVvHTOYpb WA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXuiNuC7VKoob8mF O9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9lFWRzMIPMIIE bTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQ UlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDYxMDMx MjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBHcm91cDEmMCQG A1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdWPMLHDjzhw5Iz Dd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/jel59WsWYXKG g/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1ibp6LsBWDp56M Ppg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw/+paGEdqHPeS FYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFiMIIBXjAfBgNV HSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGoIxtjiDij2+Aa YvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEwMDAuBggrBgEF BQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAjAgEBMDAwLgYI KwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYDVR0fBGkwZzBl oGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5 L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYDVR0PAQH/BAQD AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm25PWf/XkWko41 TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJSgeJ0w+7Ymjv Chu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTPBH/1poLccsUx sKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+npjwPbedMPUZk DYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5GtDYPMYICFTCC AhECAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQTAxAhEAvYQ0OWYxrvgp+rnTMCaAQTAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAzMDExNTQzMjZaMCMGCSqGSIb3DQEJBDEW BBRKyzRo5nW6wYgbW5ySqu+6qi98yzBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNz c29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQC9hDQ5ZjGu+Cn6udMw JoBBMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAvYQ0OWYxrvgp+rnTMCaAQTANBgkqhkiG9w0BAQEF AASBgHpv49TgrcFXcdUUpLb/yjVrGxeN72/00W7IAGvroHqp3/nBYG7HAGe+m9u6liq5BcynRbPW FCd2SVRHdx2mgsbOdlOoAKMzic7vJ+fgh1DBcJV70ALN34qXWK1FKGb8YSa4I+jE+JCBRoLW+KQc nHgzTX0yA8HeYShgrKvmcsqXAAAAAAAA --Apple-Mail-95-711942887-- From rgm@htt-consult.com Wed Mar 2 10:35:58 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FDD3A6800 for ; Wed, 2 Mar 2011 10:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfqedaxClRhs for ; Wed, 2 Mar 2011 10:35:58 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id D0CD13A67FD for ; Wed, 2 Mar 2011 10:35:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A818A62860 for ; Wed, 2 Mar 2011 18:36:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emmmb2RRkNVc for ; Wed, 2 Mar 2011 13:36:18 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 62CAF62AAB for ; Wed, 2 Mar 2011 13:36:18 -0500 (EST) Message-ID: <4D6E8E22.9090307@htt-consult.com> Date: Wed, 02 Mar 2011 13:36:18 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP datatracker page problems X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 02 Mar 2011 18:35:58 -0000 The datatracker page does not have pointers to all of the -bis drafts. In particular, 5203-bis thru 5205-bis are not shown there. Can we get that fixed? From rgm@htt-consult.com Wed Mar 2 11:16:01 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E49F3A6800 for ; Wed, 2 Mar 2011 11:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kNI1uG7wiqj for ; Wed, 2 Mar 2011 11:16:00 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id C11F73A6831 for ; Wed, 2 Mar 2011 11:16:00 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id ACB4662A6C for ; Wed, 2 Mar 2011 19:16:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLe+MQWDcNf6 for ; Wed, 2 Mar 2011 14:16:16 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id E52F862A79 for ; Wed, 2 Mar 2011 14:16:15 -0500 (EST) Message-ID: <4D6E977F.3080206@htt-consult.com> Date: Wed, 02 Mar 2011 14:16:15 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4D6E8E22.9090307@htt-consult.com> In-Reply-To: <4D6E8E22.9090307@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIP datatracker page problems X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 02 Mar 2011 19:16:01 -0000 On 03/02/2011 01:36 PM, Robert Moskowitz wrote: > The datatracker page does not have pointers to all of the -bis drafts. > In particular, 5203-bis thru 5205-bis are not shown there. > > Can we get that fixed? Oh, I see that the drafts are expired and can be found linked at: http://tools.ietf.org/wg/hip/ From rgm@htt-consult.com Wed Mar 2 11:18:39 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29873A6848 for ; Wed, 2 Mar 2011 11:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eU6NQ9sE9Mc for ; Wed, 2 Mar 2011 11:18:38 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id CB6C73A6840 for ; Wed, 2 Mar 2011 11:18:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3A2DD62A79 for ; Wed, 2 Mar 2011 19:19:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l09VyoswALCJ for ; Wed, 2 Mar 2011 14:19:04 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 9C4BF62A6C for ; Wed, 2 Mar 2011 14:19:04 -0500 (EST) Message-ID: <4D6E9828.9030409@htt-consult.com> Date: Wed, 02 Mar 2011 14:19:04 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] IETF MARCH madness :) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 02 Mar 2011 19:18:39 -0000 It is time for everyone to put a serious set of eyes on the HIP -bis drafts. March 14th is the cutoff date for ID revision submissions; let's get some reviews going so that the authors have time to incorporate the 'easy' ones to get new documents posted. We need to get any issues together to cover at the meeting. Or better yet get them resolved before the meeting. To the authors: Some IDs are still referencing the initial RFCs and not the -bis drafts. Please update this before posting the next submission. From rgm@htt-consult.com Thu Mar 3 06:13:20 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E730B3A68B9 for ; Thu, 3 Mar 2011 06:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vssCwVtwNVD3 for ; Thu, 3 Mar 2011 06:13:20 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 278FC3A68AD for ; Thu, 3 Mar 2011 06:13:20 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 716706293D for ; Thu, 3 Mar 2011 14:13:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfx+marOR7wo for ; Thu, 3 Mar 2011 09:13:38 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 141F262A6D for ; Thu, 3 Mar 2011 09:13:38 -0500 (EST) Message-ID: <4D6FA211.3000107@htt-consult.com> Date: Thu, 03 Mar 2011 09:13:37 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] 5202-bis and IESG Note X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 03 Mar 2011 14:13:21 -0000 In 5202 bis, there is an IESG note that we MUST address in 5202-bis. I am asking everyone here to look at this note and, particularly those that have implemented 5202, to work out how to address this issue in 5202-bis. I have also reviewed the documents for the use of the word 'future'. We need some fix up in 5202-bis wrt this. I THINK all occurances of 'future' are ok in the other drafts. We particularly need to check for consistancy between the drafts. Wording used across multiple drafts needs to be consistant (separately, I copied LOTS of text from 5201-bis for HIP-DEX and now after lots of edits to 5201-bis, I need to edit the HIP-DEX draft). From rgm@htt-consult.com Mon Mar 7 05:28:08 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEC63A67AA for ; Mon, 7 Mar 2011 05:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAY3TvqEEtZ3 for ; Mon, 7 Mar 2011 05:28:05 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7FFBD3A6960 for ; Mon, 7 Mar 2011 05:28:05 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 31ABC62A45 for ; Mon, 7 Mar 2011 13:28:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7RbsHUzXKLv for ; Mon, 7 Mar 2011 08:28:37 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id BF59F62AB4 for ; Mon, 7 Mar 2011 08:28:37 -0500 (EST) Message-ID: <4D74DD85.9030309@htt-consult.com> Date: Mon, 07 Mar 2011 08:28:37 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Change a HIP Parameter, change its Type value? X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 07 Mar 2011 13:28:08 -0000 In 5201-bis we have slightly altered the format of the Host_ID TLV. It is still Type value 705. Is reving the HIP version number enough here, or should the value for Host_ID be changed as well? We changed the name of some TLVs, like HMAC to HIP_MAC and did not change the value. We generalized the definition, but basically there is no change in BEX in how these TLVs are handled. Any comments? From ari.keranen@nomadiclab.com Mon Mar 7 05:54:34 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8562F3A6955 for ; Mon, 7 Mar 2011 05:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6feLHu7WLw9 for ; Mon, 7 Mar 2011 05:54:33 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 9BA8E3A67AC for ; Mon, 7 Mar 2011 05:54:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 64B014E6DF for ; Mon, 7 Mar 2011 15:55:44 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXuGdovkfaAd for ; Mon, 7 Mar 2011 15:55:44 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id EE63C4E6DC for ; Mon, 7 Mar 2011 15:55:43 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> Date: Mon, 7 Mar 2011 15:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33EC3BC4-8A6B-4CFE-A91A-F6746BB12F05@nomadiclab.com> References: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 07 Mar 2011 13:54:34 -0000 Hi, I noticed that the IANA considerations section of the 5201-bis draft = refers to Obsoleted RFC2434. That should be fixed to refer to RFC5226 = instead (and then "IETF consensus" should be changed into "IETF = review"). Cheers, Ari= From Internet-Drafts@ietf.org Wed Mar 9 03:00:16 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944323A691D; Wed, 9 Mar 2011 03:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZQhNy7FJG4y; Wed, 9 Mar 2011 03:00:14 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517643A693D; Wed, 9 Mar 2011 03:00:13 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309110010.27535.43076.idtracker@localhost> Date: Wed, 09 Mar 2011 03:00:10 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-10.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 09 Mar 2011 11:00:16 -0000 --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 Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-10.txt Pages : 13 Date : 2011-03-09 The CERT parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-cert-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09025431.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Mar 9 03:30:15 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCD83A695E; Wed, 9 Mar 2011 03:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB2dilRHcovg; Wed, 9 Mar 2011 03:30:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B308C3A6936; Wed, 9 Mar 2011 03:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309113001.5304.80635.idtracker@localhost> Date: Wed, 09 Mar 2011 03:30:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 09 Mar 2011 11:30:16 -0000 --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 Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-11.txt Pages : 13 Date : 2011-03-09 The CERT parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. This document updates RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-cert-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09032157.I-D@ietf.org> --NextPart-- From rgm@htt-consult.com Wed Mar 9 11:53:07 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C533A6A87 for ; Wed, 9 Mar 2011 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv8qBthlH+td for ; Wed, 9 Mar 2011 11:53:06 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 256903A6967 for ; Wed, 9 Mar 2011 11:53:06 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8FEED62A6F for ; Wed, 9 Mar 2011 19:54:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UmKLT4sqPHw for ; Wed, 9 Mar 2011 14:53:41 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id D470462AC3 for ; Wed, 9 Mar 2011 14:53:36 -0500 (EST) Message-ID: <4D77DAC0.9050308@htt-consult.com> Date: Wed, 09 Mar 2011 14:53:36 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP on Android X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 09 Mar 2011 19:53:08 -0000 I see a few messages over in HIPL-DEV on efforts along this line, but.... I have been told that there are a number of challenges for a 'tunneling app' on the Android, as you need root permissions to set up things like virtual interfaces and change default routes. For example if you wanted to use TUN-TAP, it is supposedly NOT part of the kernel as shipped. Do we have any Android development people here? From jav@sics.se Wed Mar 9 23:36:53 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA1E3A67EF for ; Wed, 9 Mar 2011 23:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGG2aG5xxWcV for ; Wed, 9 Mar 2011 23:36:53 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 1C5983A67FA for ; Wed, 9 Mar 2011 23:36:53 -0800 (PST) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 5935A4037C; Thu, 10 Mar 2011 08:38:09 +0100 (CET) From: Javier Ubillos To: Robert Moskowitz In-Reply-To: <4D77DAC0.9050308@htt-consult.com> References: <4D77DAC0.9050308@htt-consult.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Mar 2011 08:38:09 +0100 Message-ID: <1299742689.2092.1.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP on Android X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 10 Mar 2011 07:36:54 -0000 On Wed, 2011-03-09 at 14:53 -0500, Robert Moskowitz wrote: > I see a few messages over in HIPL-DEV on efforts along this line, but.... > > I have been told that there are a number of challenges for a 'tunneling > app' on the Android, as you need root permissions to set up things like > virtual interfaces and change default routes. For example if you wanted > to use TUN-TAP, it is supposedly NOT part of the kernel as shipped. > > Do we have any Android development people here? > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec We have a port for name-based sockets for Android. Perhaps our experiences can be of some help. E-mail me and we'll see if what we have is of any value to you guys. // Javier From Internet-Drafts@ietf.org Thu Mar 10 00:45:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898453A6989; Thu, 10 Mar 2011 00:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmmZneYkbhu1; Thu, 10 Mar 2011 00:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5AA3A6968; Thu, 10 Mar 2011 00:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310084502.28825.4047.idtracker@localhost> Date: Thu, 10 Mar 2011 00:45:02 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 10 Mar 2011 08:45:03 -0000 --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 : Encrypted Signaling Transport Modes for the Host Identity Protocol Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-06.txt Pages : 13 Date : 2011-03-10 This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-over-hip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10003543.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Thu Mar 10 00:54:01 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714913A687F for ; Thu, 10 Mar 2011 00:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVjY2DsHlFiu for ; Thu, 10 Mar 2011 00:54:00 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7F26A3A67EF for ; Thu, 10 Mar 2011 00:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id F21144E6D7 for ; Thu, 10 Mar 2011 10:55:15 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y4F-Ul49d9y for ; Thu, 10 Mar 2011 10:55:15 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 36F6F4E6CF for ; Thu, 10 Mar 2011 10:55:15 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <20110310084502.28825.4047.idtracker@localhost> Date: Thu, 10 Mar 2011 10:55:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27EF34D8-5CD5-42AD-86F5-7708447BF79E@nomadiclab.com> References: <20110310084502.28825.4047.idtracker@localhost> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 10 Mar 2011 08:54:01 -0000 Hi all, FYI, this new revision contains just fixes to IESG and OPS-DIR review = comments. Cheers, Ari On Mar 10, 2011, at 10:45 AM, 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. >=20 >=20 > Title : Encrypted Signaling Transport Modes for the = Host Identity Protocol > Author(s) : A. Keranen > Filename : draft-ietf-hip-over-hip-06.txt > Pages : 13 > Date : 2011-03-10 >=20 > This document specifies two transport modes for Host Identity > Protocol (HIP) signaling messages that allow conveying them over > encrypted connections initiated with the Host Identity Protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-06.txt From thomas.r.henderson@boeing.com Fri Mar 11 15:20:09 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97523A6A33 for ; Fri, 11 Mar 2011 15:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBPfX+i3B8Un for ; Fri, 11 Mar 2011 15:20:08 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id F07FE3A6778 for ; Fri, 11 Mar 2011 15:20:07 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2BNLOtV014898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2011 15:21:24 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2BNLO2G011878; Fri, 11 Mar 2011 15:21:24 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2BNLOb4011873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Mar 2011 15:21:24 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 11 Mar 2011 15:21:23 -0800 From: "Henderson, Thomas R" To: HIP Date: Fri, 11 Mar 2011 15:21:23 -0800 Thread-Topic: review of tracker issues for RFC 5206-bis Thread-Index: AcvgQwmNAkXQCZb4ThqFqsGvjxVK6g== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AFBF@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christian Vogt , Jari Arkko Subject: [Hipsec] review of tracker issues for RFC 5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 11 Mar 2011 23:20:09 -0000 I would like to make an update of the RFC5206-bis draft by Monday's cutoff.= I will not make any technical changes between now and then so that there = is time for people to discuss any changes, but I would like to review the o= pen issues in this mail with a proposal for how to handle each of them. I = hope that, by the end of the Prague meeting, we could close most or all of = the mobility-related issues. For reference, the tracker issues are logged here: http://trac.tools.ietf.org/wg/hip/trac/report/1 If you would like to start a thread on any of these proposals, can you plea= se start one with a new subject line?=20 I will discuss the issues related to mobility in particular; multihoming ca= n be left for another time. Ticket2: inclusion of LOCATOR in R2 vs. R1 This is a proposal by Miika to shift the load balancing feature of the R1 L= OCATOR to DNS-based schemes. I am neutral to slightly against this proposa= l on the grounds that we try to avoid DNS reliance in HIP in general, and I= am not convinced it is a burden on implementations. I suggest no change, = but feel free to convince me otherwise. Ticket 4: make before break use case missing Ticket 5: cross-family handovers missing from RFC5206-bis Ticket 6: specify peer-locator exposure policies and sending from unannoun= ced locators Ticket 8: decouple locator announcement from SA creation I support adding text for these four cases and will try to come up with a s= pecific proposal for review on the list before adding to the published draf= t. So, this would be added for the subsequent draft version (the next one = past Monday's IETF-80 version). Ticket 10: LOCATOR/locator terminology in RFC 5206 I would like to suggest changing the name of this parameter to "LOCATOR-SET= " but I will wait for comments on this suggestion before implementing it. = This would also need to change in the RFC5770-bis. Tickete 11: review ESP_INFO/SPI issues in RFC5206 this is a request to clarify whether the mappings of SPI to interface or lo= cator are one-one or one-many. draft-melen-hip-nat-mm-00 recommended to av= oid assigning locators on different interfaces to a single SPI (this may be= more an issue for the multihoming draft). Ticket 12: should UPDATE be sent via rendezvous server? This requires coordination with RFC5204-bis but I support adding text to do= cument this. Ticket 13: SEQ/ACK handling with respect to UPDATE I do not really understand the concern so would like to request specific te= xt change proposal. Ticket 14: can actual IP addresses of UPDATEs be used as locators, even if= not in LOCATOR set? In principle, it seems like this should be permitted; I do not see a reason= why an implementation should be precluded from trying a locator found on t= he inbound IP packet, perhaps as a last resort. I would suggest to add a s= tatement along these lines. Ticket 15: suggestion for naming UPDATE packets I believe that the basic request here is to reduce the number of possible d= ifferent UPDATE scenarios, document them better, and modularize the separat= e concepts. I will have a look at this in the subsequent revision. ---- So, in summary, I propose to do the following - publish draft-ietf-hip-rfc5206-bis-02.txt by Monday, with updated referen= ces - work on a suggested -03 draft for possible publishing during IETF 80 week= or shortly thereafter, covering the above topics. Tom From heer@informatik.rwth-aachen.de Sun Mar 13 12:18:13 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3901D3A6A65 for ; Sun, 13 Mar 2011 12:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKEP6m13VrK4 for ; Sun, 13 Mar 2011 12:18:10 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id CBD663A6A18 for ; Sun, 13 Mar 2011 12:18:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LI000ETFGCICAI0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sun, 13 Mar 2011 20:19:30 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.62,311,1297033200"; d="scan'208";a="99850177" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sun, 13 Mar 2011 20:19:30 +0100 Received: from [192.168.3.4] ([unknown] [91.179.71.48]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LI000A48GB74N60@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sun, 13 Mar 2011 20:19:30 +0100 (CET) From: Tobias Heer In-reply-to: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> Date: Sun, 13 Mar 2011 20:19:30 +0100 Message-id: <0DF41C4B-5B59-4766-AE72-61D64C8EFA9F@cs.rwth-aachen.de> References: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> To: =?iso-8859-1?Q?Ari_Ker=E4nen?= X-Mailer: Apple Mail (2.1082) Cc: hipsec@ietf.org Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 13 Mar 2011 19:18:13 -0000 Hello Ari, ok, this took a while. Finally I am through. Most of your comments did not require second thoughts. On some I made more detailed comments. Please check if I always got your point or if I misunderstood something. Also. A BIG thank you for providing alternative text when appropriate. That did speed up addressing the comments quite much. Excellent work! Am 03.02.2011 um 18:47 schrieb Ari Keranen: > Hi, > > Here's comments, suggestions, and questions of the rest of the rfc5201-bis-04 document. > > BTW, don't be scared of the amount of comments; I just tried to do a thorough review and weed out all the remaining errors, ambiguities, and style issues -- even the smaller ones. > Thanks, I appreciate the tough review (even if it keeps me busy for a while). > > 5.1. Payload Forma > > | Next Header | Header Length |0| Packet Type | VER. | RES.|1|i > > s/ VER. /Version/ > (if fits there, so no need to abbreviate?) > Done. > > document does not describe processing for Next Header values other > than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. > Future documents MAY do so. > > s/do so/define behavior for also other values/ > Agreed. > > The Header Length field contains the length of the HIP Header and HIP > parameters in 8-byte units, excluding the first 8 bytes. > > s/the length/the combined length/ > Ok. > > The HIP Version is four bits. The current version is 2. > > s/Version is/Version field is/ > s/current version/version defined in this document/ > Ok. > > For example, in the case > that the forthcoming SHIM6 protocol happens to be compatible with > this specification > > Since SHIM6 is already an RFC, this text could be updated. > Right. This can be removed/adjusted. > > 5.1.2. HIP Controls > > The HIP Controls section conveys information about the structure of > > s/section/field/ > > > The following fields have been defined: > > s/fields/sub-fields/ Ok. > > > This control is set in packets R1 and/or > I2. The peer receiving an anonymous HI may choose to refuse it. > > How about using anonymous HIs with other packets? Say, NOTIFYs or UPDATEs? It doesn't make much sense because the anonymous HI is only important for end-hosts when they bootstrap a new HIP association. UPDATEs and NOTIFYs are not sent before BEX is complete. For middleboxes, things may be different because after an UPDATE a middlebox may suddenly be on the primary communication path between two HIP hosts that previously established a connection. However, middleboxes are only addressed to a minimal degree in BEX. The semantics and function of the HIT for middleboxes is undefined so far. If we start adding things for middleboxes here we might have to delve much deeper. Any opinion? > > > 5.1.3. HIP Fragmentation Support > > In IPv4 networks, HIP packets may encounter low MTUs along their > routed path. Since HIP does not provide a mechanism to use multiple > IP datagrams for a single HIP packet > > HIP over HIP does provide mechanism for this, so I'd change: > s/HIP does not/basic HIP, as defined in this document, does not/ (or something) Agreed. > > > HIP-aware NAT > devices MUST perform any IPv4 reassembly/fragmentation. > > Despite the warning in the next paragraph, this would potentially make all HIP-aware IPv4 NAT devices vulnerable for fragment-attacks. Could change the MUST into SHOULD? Also, could clarify that reassembly/fragmentation is a MUST/SHOULD for HIP packets, not for any random packet. It should definitely be a SHOULD. The box may or may not be useful without fragmentation support. BEX is not the document to decide that. I also agree that only HIP packets are to be considered. However, the distinction may be difficult if the fragments arrive out of order. How will the box figure out if the fragment is a HIP control packet or not if the HIP header is in another fragment? > > > it is strongly recommended that the separate document > specifying the certificate usage in the HIP Base Exchange defines the > usage of "Hash and URL" formats rather than including certificates in > exchanges. > > This already exists in the CERT draft, so this text could be removed/re-worded. The reference to fragmentation DoS attack is still useful though. > Alternative text: Certificate chains can cause the packet to be fragmented and fragmentation can open implementations to denial-of-service attacks [KAU03]. "Hash and URL" schemes as defined in [I-D.ietf-hip-cert] for HIP version 1 may be used to avoid fragmentation and mitigate resulting DoS attacks. The implications and security considerations for certficate chains and hash and url are discussed there. Hence, I see no reason to put a MUST or SHOULD here. > > 5.2. HIP Parameters > > The HIP Parameters are used to carry the public key associated with > the sender's HIT, together with related security and other > information. > > Considering the amount of different things carried in HIP Parameters today, this section could start with a more generic description of the use of the parameters ("and other information" sounds a bit understatement). Can't come up with the right words for now, but would be good to have something that would explain that Parameters are used to carry the security stuff, but are also one of the main ways for extending HIP. Let me try ;-) The HIP parameters carry information that is necessary for establishing and maintaining a HIP association. For example, the peer's public keys as well as the signaling for negotiating ciphers and payload handling are encapsulated in HIP parameters. Additional information, meaningful for end-hosts or middleboxes, may also be included in HIP parameters. The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior. In HIP packets, HIP parameters are ordered according to their numeric type number and encoded in TLV format. > > > | R1_COUNTER | 128 | 12 | System Boot Counter | > > The data description does not seem to match other descriptions of R1_COUNTER. > --> Puzzle generation counter > > | HIP_CIPHER | 579 | variable | HIP encryption | > | | | | algorithm | > > s/HIP encryption algorithm/List of HIP encryption algorithms/ > Ok. > > | ENCRYPTED | 641 | variable | Encrypted part of I2 | > | | | | packet | > > ENCRYPTED could be also in other packets than just I2, right? > Now, yes. Agreed. It used to be there for the HI of the Initiator. > > | CERT | 768 | variable | HI Certificate; used | > > Also this text regarding certificates should be updated. > Yep. The cert stuff has evaded me so far. It seems I have been focusing on crypto agility too much. > > | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | > | | | | back; under signature | > > s/echoed back/echoed back by request/ > Do you think this is necessary? To me it is obvious and pronounced in the rest of the text. > Also "covered by signature", or "signed" could be better than "under signature" (also in ECHO_REQ_SIGNED). > > > | 2048 - 4095 | Parameters related to HIP transport types | > > s/transport types/transport formats/ > (to be consistent with the later text) > > > 5.2.1. TLV Format > > The type-field value also describes the order of these > fields in the packet, except for type values from 2048 to 4095 which > are reserved for new transport forms. > > This is a bit strange exception. I wonder if it would make sense to make this consistent with the other ordered lists, i.e., have one parameter that lists the supported transport formats and then, depending on which format was chosen, the corresponding parameter(s) from this range are used (and others ignored). I recently sent this issue to the list and unless there are any objections, I'll add the following. I won't be able to get this done before the next version but it will be the first thing for the next revision. Option: Give all transforms different type numbers, keep the ordering and express preference in a list. Example HIP packet excerpt: +------+ +------+---------+ +------+-----+ +------+-----+ |Header| | 2050 | XYZ, ESP| | 2095 | ESP | | 2096 | XYZ | ... +------+ +----------------+ +------+-----+ +------+-----+ ^ | List----------+ > > Also: > s/order of these fields/order of these parameters/ > s/transport forms/transport formats/ > Done. > > If the parameter can exist multiple times in the packet, the > type value may be the same in consecutive parameters. > > This could rather be formatted as a normative requirement (and then it would be also implicit for the responder). Something like: > > If the parameter can exist multiple times in the packet, the > parameters with the same type MUST be consecutive in the packet. > Agreed and done. > > 5.2.2. Defining New Parameters > > Implementations operating in a mode > adhering to this specification MUST disable the sending of new > critical parameters. > > This sounds a bit strange. Should that be "MUST allow disabling"? > I think the original meaning was that you have to enable it by hand and it is disabled by default. This makes sense because otherwise standard compliant implementations will be incompatible by default. To make it clearer I changed the sentence to: Implementations operating in a mode adhering to this specification MUST disable the sending of new critical parameters by default. > > 5.2.3. R1_COUNTER > > The sender is supposed to increment this counter > periodically. > > s/is supposed to increment/increments/ or "SHOULD increment" > SHOULD is fine here. Done. > > 5.2.6. DIFFIE_HELLMAN > > The 160-bit ECP > group can be used when lower security is enough (e.g., web surfing) > and when the equipment is not powerful enough (e.g., some PDAs). > > Should mention which Group ID the 160-bit ECP is (I'd assume 10, but it's not explicit). > I rephrased the sentence to mention the group name explicitly. This should clarify it. A HIP implementation MUST implement Group ID 3. The 160-bit SECP160R1 group can be used when lower security is enough ... > Also, some general recommendation on the order of proposed group IDs would be helpful so that implementations don't end up (unnecessarily) proposing the weakest groups by default. > Hmmm.. I think the words of caution above should avoid that. Otherwise, I could write something like: In general stronger groups SHOULD be preferred. Should we explicit state the order here? Stronger groups are of course more costly and need more space in the packets. So I wouldn't want to propose group 9 as default. > > 5.2.7. HIP_CIPHER > > Cipher ID defines the cipher algorithm to be used for > encrypting parts of the HIP packet > > Is HIP_CIPHER used anywhere else except in the ENCRYPTED parameter? If not, the explanation above could say that explicitly. That is, for example, > s/parts of the HIP packet/the contents of the ENCRYPTED parameter/ > Nope it is nowhere else (at least in this document). However other documents might use it for something else. But well, these documents will define it more explicitly anyway. Agreed, changed. > > NULL-ENCRYPTION is included > for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via > the UI. > > There may be no UI for the implementation, so could say "by the user" instead of "via the UI". > There is (almost) always a UI, right? Maybe its no GUI, maybe its not even a command line tool... but any interface that allows the user to interact is a UI, right. Changing it to "by the user" implies the existence of some UI as well. > > 5.2.8. HOST_ID > > DI-type type of the following Domain Identifier field > Domain Identifier the identifier of the sender > > The actual content of these fields is not clear from the text. Could at least move the DI-types table closer to the figure. Also, "DI Length" could simply say "length (in octets) of the Domain Identifier field"; the FQDN and NAI part just confuses here. > I moved it closer and adjusted the order of the field explanations to match the order of the fields in the parameter. I hope things are clearer now. I also changed the DI field length descriptions according to your suggestion. > > If there is no Domain Identifier, i.e., the DI-type field is zero, > the DI Length field is set to zero as well. > > Should there be some normative text on when to have the domain identifier? It is zero if the HIT does not belong to any domain, I guess. I am not fully aware of the reasons that led to the inclusion of the NAI and FQDN here. From my perspective it is some nice-to-have information that adds some weak hierarchy to the HOST_ID (weak because it is not a input for the actual HI or HIT. Maybe someone can shed some light? (I will post this as separate mail on the list so that it is not lost in the bulk of the comments and replies here). > > > 5.2.10. DH_GROUP_LIST > > The information in the > DH_GROUP_LIST allows the Responder to select the DH group preferred > by itself and the Initiator. > > s/and the Initiator/and supported by the Initiator/ > Good catch! I am impressed with the scrutiny you applied. Thanks! > > 5.2.13. HIP_SIGNATURE > > The signature algorithms are defined in Section 5.2.8. > > The algorithm identifier field side for HOST_ID (Section 5.2.8) is 16 bits whereas here it is 8 bits. Something wrong here? Woops. That's still a remnant of 5201 (no bis). It should be changed, of course. It won't bloat the signature to use a 16 bit field. On the other hand, we're limited in the numbers of algorithms anyway so 256 seems kind of okay. Well, I'll go for the 16 bit field in HIP_SIGNATURE if no one produces valid reasons not to do this. This has to be carefully documented in the changelog - otherwise implementers will struggle with this hidden change quite a lot. > > Could also reference to exact table with the algorithms since section 5.2.8 has 4 different tables. I added a introductory sentence to the table in 5.2.8. I hope this does the trick. > > > Sections 5.2.15 and 5.2.16 (SEQ and ACK) > > Figures, and their Length descriptions are not consistent although, AFAIK, the format of the parameters is identical. > > Woops. There is something fishy here. The figure for SEQ is wrong. SEQ should ONLY contain ONE update ID. Not more. ACK can acknowledge several update IDs, though. I'll change it. This seems like a editing error when the acknowledgment of several updates was added. The editor changed the wrong figure. I am surprised that no one noticed this so far. I'll change it. The figures are now correct. The description was updated. > 5.2.16. ACK > > The Length field identifies the number of > peer Update IDs that are present in the parameter. > > This is a bit misleading. Could say something like "number of peer Update IDs can be inferred from the length by dividing it by 4" > > One could and should. Thanks. > 5.2.17. ENCRYPTED > > Encrypted The data is encrypted using an encryption algorithm > data as defined in the HIP_CIPHER parameter. > > s/an encryption algorithm as defined in/the encryption algorithm defined by/ > > Done. > 5.2.18. NOTIFICATION > > Padding any Padding, if necessary, to make the parameter a > multiple of 8 bytes. > > This is the first parameter to explicitly define padding after the figure (not consistent). Also, base text says that padding MUST be zero, but here it says "anything will do". Would suggest removing this altogether. > > Good catch. Thanks. > Notification information can be error messages specifying why an SA > > First occurrence of SA. Expand, and maybe add a reference too. > I think this refers to the HIP security association, not IPsec. In that regard, the text is blurry (I'll change that) but does not require a reference. The new text is: Notification information can be error messages specifying why an HIP Security Association could not be established. It can also be status data that a HIP implementation wishes to communicate with a peer process. The table below lists the Notification messages and their corresponding values. > > Overall, this section is fairly inconsistent with the use of different ways to refer to "Notify Message Type", some suggestions for change: > > The table below lists the Notification messages and their > corresponding values. > > s/Notification messages/Notify Message Types/ > suggestion: The table below lists the notification messages and their Notification Message Types. > Types in the range 0-16383 are intended for reporting errors and in > > s/Types/Notify Message Types/ > Ack. > An > implementation that receives a NOTIFY packet with a NOTIFICATION > error parameter in response to a request packet > > s/NOTIFICATION error parameter/(something)/ > An implementation that receives a NOTIFY packet with a Notify Message Type that indicates an error in response to a request packet ... is this appropriate for (something)? > Notify payloads with status types MUST be ignored if not recognized. > > s/Notify payloads with status types/Notification Data in NOTIFICATION parameters with status Notify Message Types/ > Ack. Thanks for providing alternative text. Saves me some cycles :-) > NOTIFICATION PARAMETER - ERROR TYPES Value > > s/NOTIFICATION PARAMETER - ERROR TYPES/Notify Message Types - Errors/ > (or why not in all-caps, if that looks better) > > NOTIFY MESSAGES - STATUS TYPES Value > > s/NOTIFY MESSAGES - STATUS TYPES/Notify Message Types - Status/ > I guess that's a matter of taste - but I like your suggestion - changed. > > UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 > > Sent if the parameter type has the "critical" bit set and the > parameter type is not recognized. Notification Data contains the > two-octet parameter type. > > What if there are multiple unsupported critical parameter types? Should send multiple NOTIFICATIONs of this Message Type or would it be better to concatenate the types? There may be several notify parameters in one HIP packet in that case. I spelled it out explicitly in the introduction: HIP packets MAY contain multiple notify parameters if several problems exist or several independent pieces of information must be transmitted. > > > INVALID_SYNTAX 7 > > Indicates that the HIP message received was invalid because some > type, length, or value was out of range or because the request > was rejected for policy reasons. > > Rejecting message with "invalid syntax" code due to policy reasons sounds strange. Isn't the type "BLOCKED_BY_POLICY" for that purpose? Could change that policy text to: "[...] or the message was otherwise malformed". > Agreed. Makes sense. > 5.2.19. ECHO_REQUEST_SIGNED > > A HIP > packet can contain only one ECHO_REQUEST_SIGNED or > ECHO_REQUEST_UNSIGNED parameter. > > > s/can/MUST/ ? > That is complete bull. There MAY be one SIGNED but there MAY be several UNSIGNED. I'll change it. > > 5.2.20. ECHO_REQUEST_UNSIGNED > > HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. > It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters > in HIP packets passing by. > > This seems to contradict with the previous section (see above). Yepp. Changed it. > > The sender has to create the Opaque field > so that it can later identify and remove the corresponding > ECHO_RESPONSE_UNSIGNED parameter. > > Does this apply also to middleboxes, i.e., is "sender" the sender of the packet or sender of the parameter? > The creator of the parameter. I'll state this more clearly. The creator of the ECHO_REQUEST_UNSIGNED (end-host or middlebox) has to create the Opaque field so that it can later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED parameter. > > 5.3.1. I1 - the HIP Initiator Packet > > IP ( HIP ( DH_GROUP_LIST ) ) > > This is not strictly consistent with the notation definition "X(y) indicates that y is a parameter of X" (HIP stuff is not really a parameter of IP packet). I'm not entirely sure how to fix this though (or if it even needs to be fixed). > > I think it ti rather clear here. if it were IP(HIP) I could imagine that someone might be confused. All other forms of braces are used up anyway ([{}]) > The Initiator receives the Responder's HIT either from a DNS lookup > of the Responder's FQDN, > > Add here a reference to 5205-bis. > Ack. > > 5.3.2. R1 - the HIP Responder Packet > > The Initiator's HIT MUST match the one received in the I1 packet. > > ...if the R1 is sent due to I1. > The Initiator's HIT MUST match the one received in the I1 packet if the R1 is a response to an I1. > > Re-using Diffie-Hellman public keys opens up the potential security > risk of more than one Initiator ending up with the same keying > > s/public keys/public values/ ? > (same in next paragraph) > kk > > If a future version of this protocol is considered, we strongly > recommend that these issues be studied again. > > Has anyone looked into this? > I thought about it for a while but did not come up with any good conclusion. > > The signature is calculated over the whole HIP envelope > > "HIP envelope" is not defined anywhere (but used many times after this occurrence too). Perhaps add it to the definitions part. > > We can substitute it with HIP packet. That is more technical and more precise. > 5.3.3. I2 - the Second HIP Initiator Packet > > The HITs used MUST match the ones used previously. > > This is ambiguous. Should that be "used in R1" or are there also other possibilities? > > Nope. Changed. (Damn... Man, this review is sooo much work. I am not even close to the end. Thanks for doing this in such great detail!) > > The HIP_CIPHER contains the single encryption transform selected by > the Initiator, that it uses to encrypt the ENCRYPTED parameter. > > s/the ENCRYPTED parameter/ENCRYPTED parameters/ > (The ENCRYPTED parameter is optional here, but may be sent later, right?) > Ack. > > 5.3.5. UPDATE - the HIP Update Packet > > An UPDATE that does not contain a SEQ parameter is > simply an acknowledgment of a previous UPDATE and itself MUST NOT be > acknowledged by a separate ACK. The text above seems shaky in itself. The update should nonetheless contain an ACK because otherwise it is not clear which SEQ it acknowledges. I'll change that. > > What about UPDATE without ACK nor SEQ? Unreliable UPDATE or a protocol error? > I changed the text to: The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST acknowledge the the UPDATE. An UPDATE that does not contain a SEQ but only an ACK parameter is simply an acknowledgment of a previous UPDATE and itself MUST NOT be acknowledged by a separate ACK. UPDATE packets without SEQ parameters do not require an acknowledgment and do not require processing in relative order to other UPDATE packets. Satisfied? > > 5.3.7. CLOSE - the HIP Association Closing Packet > > The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate > both the HIP_MAC and the signature if it has state for a HIP > association, > > The ECHO_RESPONSE_SIGNED is only in the CLOSE_ACK. I assume this is not just a typo, since there's not much to validate in the request, right? Also, could be more explicit about who the state is with. > You are right about this. This paragraph must be moved to close ACK. Done. > 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet > > The receiver peer MUST validate both the HMAC and the signature. > > ...and the contents of the ECHO_RESPONSE? > > This is related to the comment above. There is text on the ECHO_RESPONSE now. > 5.4.1. Invalid Version > > pointing to the VER./RES. byte in the HIP header. > > If you change the "VER." field (as suggested in the beginning of this mail), remember to change it also here. > Done. Thanks for pointing this out. > > 6.1. Processing Outgoing Application Data > > The exact format and method for transferring the data from the source > > s/the data/the user data/ > (this does not apply to HIP packets) > Eagle-eye Ari. > > 6.4.1. HMAC Calculation > > 6. Set Checksum and Header Length field in the HIP header to > original values. > > This could be just an implementation issue, but unless the signatures and MACs are also restored, the length and checksum are invalid after this step. Is this step even needed? > Well.. this is a hint for the implementors so that they don't deal with a corrupted packet. I guess its fine. > > 6.5. HIP KEYMAT Generation > > > HIP-gl encryption key for HOST_g's outgoing HIP packets > HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets > > It's a bit confusing to use the same "key name" twice (same for -lg). I assume "outgoing HIP packets" means the ENCRYPTED parameter? If so, could say it explicitly. Changed it to make ENCRYPTED more obvious but I am not sure what you mean by "same key name twice"... can you explain? > > HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP > packets > > Why HOST_l's key is not used if either Initiator or Responder may end up being the HOST_l? > I fully agree. > > 6.7. Processing Incoming I1 Packets > > 2. If the Responder is in ESTABLISHED state, the Responder MAY > respond to this with an R1 packet, prepare to drop existing SAs, > > Should prepare to drop only the SAs one has with the I1's sender? > New text: If the Responder is in ESTABLISHED state, the Responder MAY respond to this with an R1 packet, prepare to drop an existing HIP security association with the peer, and stay at ESTABLISHED state. > > Other than that, selecting the HIT is a > local policy matter. > > Shouldn't the Responder use the same as HIT the Initiator used for it? This would otherwise break section 6.8 step 3. Actually that is stated two sentences before the clause you cited: If the received Responder's HIT in the I1 is NULL, the Responder selects a HIT with a the same HIT Suite as the Initiator's HIT. If this HIT Suite is not supported by the Responder, it SHOULD select a REQUIRED HIT Suite from , which is currently RSA/DSA/SHA-1. Other than that, selecting the HIT is a local policy matter. The "Other than that, selecting the HIT is a local policy matter" is for the case if several HITs (same suite) are possible. > > > 6.8. Processing Incoming R1 Packets > > > 7. The system MUST check that the DH Group ID in the DH parameter > > s/DH parameter/DIFFIE_HELLMAN parameter/ > (twice in this step) kk. > > > 6.9. Processing Incoming I2 Packets > > > Hellman key, decrypting the Initiator's Host Identity, verifying the > > s/decrypting/possibly decrypting/ > (if it's not within ENCRYPTED parameter; also in step 11) > okay. > > 7. If the system's state machine is in any other state than R2- > SENT, the system SHOULD check that the echoed R1 generation > counter in the I2 packet is within the acceptable range. > > ...if the counter is included > Done. > > 6.10. Processing of Incoming R2 Packets > > If an R2 packet is received in state I2-SENT, it SHOULD be processed. > > When would it be appropriate to *not* process the R2 in I2-SENT state? This looks like a MUST to me. > To me, too. > > 2. The system MUST verify that the HITs in use correspond to the > HITs that were received in the R1 packet. > > "..that caused the transition to the I1-SENT state" > i.e., not just any R1 > > Details, details, details. But these matter :-) I'll gladly change it. > 6.14. Processing CLOSE Packets > > The HIP association is not discarded before the host moves from the > UNASSOCIATED state. > > s/from/to/? Woops. Okay. > > > 6.15. Processing CLOSE_ACK Packets > > A host can map CLOSE messages to CLOSE_ACK messages by using > the included ECHO_RESPONSE_SIGNED in response to the sent > ECHO_REQUEST_SIGNED in the CLOSE_ACK. > > s/using/matching/ > And the end of the sentence seems to be incorrect anyway (REQ is not in ACK). Could rephrase the whole sentence. > New text: A host can map CLOSE messages to CLOSE_ACK messages by using the included ECHO_RESPONSE_SIGNED that was sent in the CLOSE_ACK packet in response to the ECHO_REQUEST_SIGNED in the CLOSE packet. > > The CLOSE_ACK contains the HIP_MAC and the SIGNATURE for > > s/and the SIGNATURE/and SIGNATURE parameters/ > Done. > > 7. HIP Policies > > Initiators may use a different HI for different Responders to provide > basic privacy. Such implementations SHOULD keep state for mapping > Initiator's HIT to Responder's HIT. This access control list (ACL) > SHOULD also include preferred transform and local lifetimes. > > This sounds a bit ambiguous. Why is the mapping needed? What are the lifetimes? Why store the preferred transform? > Okay... The text was blurry and weird. I have some equally blurry but clearer alternative here. Blurry because this is really local policy, not HIP. Initiators may use a different HI for different Responders to provide basic privacy. Whether such private HITs are used repeatedly with the same Responder and how long these HITs are used is decided by local policy and depends on the privacy requirements of the Initiator. > > The value of K used in the HIP R1 packet can also vary by policy. K > should never be greater than 20, but for trusted partners it could be > as low as 0. > > s/should never/SHOULD NOT/ > Also, why 20? Some rough number on "how much is 20" could be helpful. How about, say, 10 years from now, is 20 that big still then or should we comment something on adjusting the maximum value in the future? Or will it be HIP v3 by then? :) I would remove the text on 20 altogether. The 20 makes assumptions on the capabilities of the clients and the attacker, which we should not do. The 20 is just an unjustified magic number. The new text says: The value of K used in the HIP R1 must be chosen with care. Too high numbers of K will exclude clients with weak CPUs beause these devices cannot solve the puzzle within reasonable time. K should only be raised if a Responder is under high load attack, i.e., it cannot process all incoming HIP handshakes any more. If a responder is not under high load, K SHOULD be 0. > > > 10. IANA Considerations > > This document also creates a set of new namespaces. These are > described below. > > Do we create new namespaces for v2 or should we re-use the existing ones? > We create new ones because the parameter ranges and the parameter definitions change. So I guess no textual change is needed here. > > HIP Version > > At least this namespace we shouldn't redefine (but e.g., HIP Suite we should). > Agreed. Changed the text. > > Group ID > > New values either from the reserved or unassigned > space are assigned through IETF Consensus. > What are these spaces? Is "0" the "reserved space"? Same with CIPHER_ID. > Removed the reserved space. Also changed IETF Consensus to IETF Review. > > Notify Message Type values 1-10 are used for informing about > errors in packet structures, values 11-20 for informing about > problems in parameters [...] > > This text could be more helpful in the NOTIFICATION section. > Agreed. > > That's all for now. More nits coming off-lists. > Thank you so much for this detailed review. I am really impressed. Tobias > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From samu.varjonen@hiit.fi Sun Mar 13 18:43:43 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A813A6AB7 for ; Sun, 13 Mar 2011 18:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8nHNrwlxXPH for ; Sun, 13 Mar 2011 18:43:43 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D55933A6AAC for ; Sun, 13 Mar 2011 18:43:42 -0700 (PDT) Received: from [192.168.0.10] (cs181123051.pp.htv.fi [82.181.123.51]) by argo.otaverkko.fi (Postfix) with ESMTP id 243DF25EDDC for ; Mon, 14 Mar 2011 03:45:04 +0200 (EET) Message-ID: <4D7D730F.5050800@hiit.fi> Date: Mon, 14 Mar 2011 03:44:47 +0200 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] rfc5201-bis-04 internationalized domain names X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 01:43:44 -0000 Hi, Draft-ietf-hip-rfc5201-bis includes the following text in section 5.2.8. "The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. The format for the NAI is defined in [RFC4282]" From these references the RFC4282 supports internationalized usernames and internationalization of the realm portion. RFC1035 defines the domain names as sequences of ASCII only labels. I propose the addition of the support for internationalized domain names for HOST_ID. This would mean the following modification to the draft-ietf-hip-rfc5201-bis section 5.2.8. " The format for the FQDN is defined in [RFC1035] Section 3.1. Internationalized Domain Names (IDNs) MAY be included in the Domain Identifier (DI). Conforming implementations MUST convert IDNs to the ASCII compatible Encoding (ACE) format as specified in Section 4 of [RFC3490] before storage to the DI. When comparing the FQDNs for equality, conforming implementations MUST perform a case-insensitive exact match on the entire FQDN. Conforming implementations should convert IDNs to Unicode before display by performing the conversion operation specified in Section 4 of [RFC3490]. The non-conforming implementations may identify IDNs by checking the inclusion of the IDN ACE label additional characters "xn--" in any capitalization. All implementations MUST allow for increased space requirements for IDNs in the DI. The format and internationalization for NAI is defined in [RFC4282]. " Comments and a sanity check would be appreciated. BR, Samu Varjonen From heer@informatik.rwth-aachen.de Mon Mar 14 00:58:41 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BF53A6AFC for ; Mon, 14 Mar 2011 00:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW3BbFCnRP2F for ; Mon, 14 Mar 2011 00:58:40 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id E14283A6AC3 for ; Mon, 14 Mar 2011 00:58:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LI100G13FK2LS20@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 14 Mar 2011 09:00:02 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.62,314,1297033200"; d="scan'208";a="50638344" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Mon, 14 Mar 2011 09:00:02 +0100 Received: from [192.168.3.4] ([unknown] [91.179.12.246]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LI100EWLFK2QY10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 14 Mar 2011 09:00:02 +0100 (CET) From: Tobias Heer Date: Mon, 14 Mar 2011 08:59:57 +0100 Message-id: <190A2117-D9F3-4C00-8C84-286A352BA30E@cs.rwth-aachen.de> To: hipsec@ietf.org X-Pgp-Agent: GPGMail 1.3.2 X-Mailer: Apple Mail (2.1082) Subject: [Hipsec] New version of RFC5201-bis (05) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 07:58:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone! Here is a new version of RFC5201-bis (draft-ietf-hip-rfc5201-bis-05). http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-05 A praise to former and future reviewers - --------------------------------------- There are quite many changes thanks to the detailed reviews of Miika Komu, Jeff Ahrenholz, and Ari Keranen. I have received an enormous amount of good, detailed, and valid feedback on issues that are new in the bis document and even more comments on issues that we inherited from RFC5201. I would like to express my gratitude and respect for these three guys. They have done a great job. *APPLAUSE* Again, I'd like to encourage people to review the document. I am especially interested in the opinion of a) implementers and b) people who defined extensions for HIP. It would be good to see if your HIP extensions still work with the new changes or if something fundamentally breaks your extension . I've gone over the security considerations section again. Some text in there seemed to have accumulated over the time while RFC5201 was still in the making and did not seem fully fitting today. I also changed the proposed defense mechanism for I2 flooding attacks. I would be happy if someone could go over it thoroughly with a second pair of eyes. Changes that are tricky to spot: - ------------------------------- In this version are some things that are incompatible to RFC5201 but are difficult to spot. These are mostly redefinitions of already existing parameters. I'll highlight these changes here: a) The HOST_ID format has changed to accommodate ECC HIs. This leads to a different parameter format. b) The SEQ and ACK descriptions have changed. There was a bug in the figures. This leads to a different parameter format if the figure was chosen as basis for the implementation. c) There may be several NOTIFY parameters per packet. This was not forbidden before but is explicitly allowed now. This change was made to allow signaling for multiple problems in a HIP control packet. d) The document now says the puzzle K SHOULD be 0 if the Responder is not under high load. Please make sure that HIP implementations set the K to 0 if they have no good reason to raise the value. Higher values of K will only slow down HIP, burn CPU cycles and energy, and serve no purpose if there is no overload condition. e) The HIP_SIGNATURE Algorithm field is now 16 bits long (it was 8 bits long before). Now the field is better aligned with the HOST_ID algorithm field. These changes are also mentioned in the Changelog section. Full change log: - ---------------- See the changelog below: 11.1. Changes from draft-ietf-hip-rfc5201-bis-04 o Moved this list farther to the back. o Clarifications of the Security Considerations section. One DoS defense mechanism was changed to be more effective and less prone to misuse. o Minor clarifications of the state machine. o Clarified text on HIP puzzle. o Added names and references for figures. o Extended the definitions section. o Added a reference to the HIP Version 1 certificate document. o Added Initiator, Responder, HIP association, and signed data to the definitions section. o Changed parameter figure for PUZZLE and SOLUTION to use RHASH_len/8 instead of n-byte. o Replaced occurrences of SHOULD not with SHOULD NOT. o Changed text to reflect the fact that several ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and several ECHO_RESPONSE parameters may be present in an I2. o Added text on verifying the ECHO_RESPONSE_SIGNED parameter in CLOSE_ACK. o Changed wording from HMAC to HIP_MAC in Section 5.3.8. o Reflected fact that the UPDATE packet MAY include zero or more ACKs. o Added BEX to Definitions section. o Changed HIP_SIGNATURE algorithm field from 8 bit to 16 bit to achieve alignment with the HOST_ID parameters. o Fixed the wrong figures of the SEQ and ACK parameters. SEQ always contains ONE update ID. ACK may acknowledge SEVERAL update IDs. o Added wording that several NOTIFY parameters may be present in a HIP packet. o Changed wording for the ECHO_RESPONSE_SIGNED parameter. Also lifted the restriction that only one ECHO_RESPONSE_UNSIGNED parameter MUST be present in each HIP control packet. This did contradict the definition of the ECHO_RESPONSE_UNSIGNED parameter. o Changed IETF Consensus to IETF Review in IANA section. o Aligned use of I, J, and K. Now I is #I, J is #J and K is #K throughout the document. o Updated references. o Editorial changes. - -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk19ywEACgkQf4eSaa7spb86XwCdFuBZICHktgVg6NmijiW8PQoU fqIAnjNgww7Kt4DCpXCnF5Nk7ByIRgtu =JR47 -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Mon Mar 14 01:00:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD763A6B7A; Mon, 14 Mar 2011 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEUxqzXBaZix; Mon, 14 Mar 2011 01:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E073A6B0F; Mon, 14 Mar 2011 01:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314080001.29769.5344.idtracker@localhost> Date: Mon, 14 Mar 2011 01:00:01 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5201-bis-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 08:00:02 -0000 --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 Version 2 (HIPv2) Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-rfc5201-bis-05.txt Pages : 121 Date : 2011-03-14 This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc5201-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14004918.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 04:30:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D67E3A6CB4; Mon, 14 Mar 2011 04:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgSgYQz5U2Or; Mon, 14 Mar 2011 04:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA993A6C7F; Mon, 14 Mar 2011 04:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314113002.6216.91869.idtracker@localhost> Date: Mon, 14 Mar 2011 04:30:02 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 11:30:03 -0000 --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 Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-12.txt Pages : 14 Date : 2011-03-14 The CERT parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. This document updates RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-cert-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14042110.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 12:45:05 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59683A6E82; Mon, 14 Mar 2011 12:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65uwAaEAdMbM; Mon, 14 Mar 2011 12:45:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DB73A6EA0; Mon, 14 Mar 2011 12:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314194502.5173.32422.idtracker@localhost> Date: Mon, 14 Mar 2011 12:45:02 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc4843-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 19:45:06 -0000 --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 : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) Author(s) : J. Laganier, F. Dupont Filename : draft-ietf-hip-rfc4843-bis-01.txt Pages : 13 Date : 2011-03-14 This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4843-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc4843-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14124500.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 13:00:04 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BC93A6E81; Mon, 14 Mar 2011 13:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swFNBIxUZJKj; Mon, 14 Mar 2011 13:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B3C3A6B22; Mon, 14 Mar 2011 13:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314200001.13055.23292.idtracker@localhost> Date: Mon, 14 Mar 2011 13:00:01 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5203-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 20:00:04 -0000 --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) Registration Extension Author(s) : J. Laganier, et al. Filename : draft-ietf-hip-rfc5203-bis-01.txt Pages : 13 Date : 2011-03-14 This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5203-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc5203-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14124508.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 13:00:05 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82143A6B22; Mon, 14 Mar 2011 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvDNmvlmzlkV; Mon, 14 Mar 2011 13:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA763A6B57; Mon, 14 Mar 2011 13:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314200002.13055.91861.idtracker@localhost> Date: Mon, 14 Mar 2011 13:00:02 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5204-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 20:00:05 -0000 --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-rfc5204-bis-01.txt Pages : 15 Date : 2011-03-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-rfc5204-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc5204-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14124516.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 13:00:06 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6FC3A6B22; Mon, 14 Mar 2011 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jumTVVIi0jeX; Mon, 14 Mar 2011 13:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C7E3A6B71; Mon, 14 Mar 2011 13:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314200002.13055.12130.idtracker@localhost> Date: Mon, 14 Mar 2011 13:00:02 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5205-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 20:00:06 -0000 --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) Extension Author(s) : J. Laganier Filename : draft-ietf-hip-rfc5205-bis-01.txt Pages : 17 Date : 2011-03-14 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 (RVSs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5205-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc5205-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14124523.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 16:15:06 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962193A6F9B; Mon, 14 Mar 2011 16:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObCJYTTp3Dej; Mon, 14 Mar 2011 16:15:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED90D3A6FB1; Mon, 14 Mar 2011 16:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314231501.3499.65636.idtracker@localhost> Date: Mon, 14 Mar 2011 16:15:01 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5206-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 14 Mar 2011 23:15:06 -0000 --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 Mobility with the Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-rfc5206-bis-02.txt Pages : 33 Date : 2011-03-14 This document defines mobility 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 out of scope for this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5206-bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-hip-rfc5206-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14161331.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Wed Mar 16 05:12:08 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E263A67ED for ; Wed, 16 Mar 2011 05:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+wgwI4BCSOT for ; Wed, 16 Mar 2011 05:12:07 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id C8FA93A67EB for ; Wed, 16 Mar 2011 05:12:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 494AA4E6D8 for ; Wed, 16 Mar 2011 14:13:31 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahV9cbw8Ts-9 for ; Wed, 16 Mar 2011 14:13:30 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id C60B94E662 for ; Wed, 16 Mar 2011 14:13:30 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: Date: Wed, 16 Mar 2011 14:13:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 16 Mar 2011 12:12:08 -0000 One more review comment that originally ended up in the nits but = probably deserves wider consideration: 5.3.3. I2 - the Second HIP Initiator Packet The Initiator MAY include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet. Why is this only MAY? Wouldn't it make sense to have this as MUST (or at = least SHOULD) if the Responder added the R1_COUNTER? Cheers, Ari= From heer@informatik.rwth-aachen.de Wed Mar 16 05:46:57 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66193A67FA for ; Wed, 16 Mar 2011 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOt0sXgkmLoi for ; Wed, 16 Mar 2011 05:46:56 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 837A23A68AD for ; Wed, 16 Mar 2011 05:46:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LI5009GVI8M9ZF0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 16 Mar 2011 13:48:22 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.63,194,1299452400"; d="scan'208";a="100533640" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 16 Mar 2011 13:48:22 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LI5009PII8MYA20@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 16 Mar 2011 13:48:22 +0100 (CET) From: Tobias Heer In-reply-to: Date: Wed, 16 Mar 2011 13:48:21 +0100 Message-id: References: To: Ari Keranen X-Mailer: Apple Mail (2.1082) Cc: HIP Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 16 Mar 2011 12:46:57 -0000 Hello, Am 16.03.2011 um 13:13 schrieb Ari Keranen: > One more review comment that originally ended up in the nits but probably deserves wider consideration: > > > 5.3.3. I2 - the Second HIP Initiator Packet > > The Initiator MAY include an unmodified copy of the R1_COUNTER > parameter received in the corresponding R1 packet into the I2 packet. > > > Why is this only MAY? Wouldn't it make sense to have this as MUST (or at least SHOULD) if the Responder added the R1_COUNTER? > I am not sure why this was chosen as a MAY. From my perspective, the R1_COUNTER echo mechanism only makes sense if it is a MUST. If it is a MAY, the Receiver has to implement another mechanism anyway for the case that the Initiator does not send the I1. If there were no echo mechanism for the counter, the Responder could still use the opaque fields in the ECHO_REQUEST and the PUZZLE to index different puzzle generations. Hence, I would be fine with removing the echoing of the counter altogether or making it a MUST. I agree that the MAY makes little sense. A question for the implementors: How do the different implementations handle the indexing of puzzle generations? What do the implementations do when the R1 counter is missing in the I2? In the R1, the counter is useful for the Initiator to tell older from newer I1s. Hence, the counter in the R1 makes sense. BR, Tobias > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF From gonzalo.camarillo@ericsson.com Tue Mar 22 01:32:24 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61AB3A67AF for ; Tue, 22 Mar 2011 01:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DuVtFsF7WaA for ; Tue, 22 Mar 2011 01:32:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1E3153A67AA for ; Tue, 22 Mar 2011 01:32:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-e4-4d885eefac13 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.97.21265.FEE588D4; Tue, 22 Mar 2011 09:33:52 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Mar 2011 09:33:51 +0100 Received: from [131.160.126.142] (rvi2-126-142.lmf.ericsson.se [131.160.126.142]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 71C16234B for ; Tue, 22 Mar 2011 10:33:51 +0200 (EET) Message-ID: <4D885EEF.1030906@ericsson.com> Date: Tue, 22 Mar 2011 10:33:51 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Draft agenda X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 22 Mar 2011 08:32:24 -0000 Folks, here you have the draft agenda for our upcoming meeting: http://www.ietf.org/proceedings/80/agenda/hip.html If you intended to request time to present a draft but failed to do so, please let me know as soon as possible. Cheers, Gonzalo From iesg-secretary@ietf.org Mon Mar 21 14:12:29 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820853A68D1; Mon, 21 Mar 2011 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmL72wH1ghg9; Mon, 21 Mar 2011 14:12:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B4628C17C; Mon, 21 Mar 2011 14:12:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110321211228.14509.43990.idtracker@localhost> Date: Mon, 21 Mar 2011 14:12:28 -0700 X-Mailman-Approved-At: Wed, 23 Mar 2011 04:49:14 -0700 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Host Identity Protocol Certificates' to Experimental RFC (draft-ietf-hip-cert-12.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 21 Mar 2011 21:12:29 -0000 The IESG has approved the following document: - 'Host Identity Protocol Certificates' (draft-ietf-hip-cert-12.txt) as an Experimental RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-hip-cert/ Technical Summary The CERT parameter is a container for X.509.v3 certificates and Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. Working Group Summary The consensus behind this draft was solid. Document Quality A few of the existing HIP implementations intend to include this functionality. Personnel Gonzalo Camarillo is the document shepherd. Ralph Droms is the responsible AD. From iesg-secretary@ietf.org Mon Mar 28 09:41:09 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A19E28C104; Mon, 28 Mar 2011 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftzIVfYyBEZA; Mon, 28 Mar 2011 09:41:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244C928C10D; Mon, 28 Mar 2011 09:41:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328164108.1987.72498.idtracker@localhost> Date: Mon, 28 Mar 2011 09:41:08 -0700 X-Mailman-Approved-At: Mon, 28 Mar 2011 23:48:21 -0700 Cc: hip mailing list , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Encrypted Signaling Transport Modes for the Host Identity Protocol' to Experimental RFC (draft-ietf-hip-over-hip-06.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 28 Mar 2011 16:41:09 -0000 The IESG has approved the following document: - 'Encrypted Signaling Transport Modes for the Host Identity Protocol' (draft-ietf-hip-over-hip-06.txt) as an Experimental RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-hip-over-hip/ Technical Summary This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. Working Group Summary The consensus behind this draft was solid. Document Quality Implementations of HIP-based overlays will intend to include this functionality. Personnel Gonzalo Camarillo is the document shepherd. Ralph Droms is the responsible AD. From thomas.r.henderson@boeing.com Thu Mar 31 10:41:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7213A6A33 for ; Thu, 31 Mar 2011 10:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c01B3HBmxjlg for ; Thu, 31 Mar 2011 10:41:02 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 1B26C3A69FC for ; Thu, 31 Mar 2011 10:41:02 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2VHgf5l018213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Mar 2011 10:42:41 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2VHgeLr008480 for ; Thu, 31 Mar 2011 10:42:40 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2VHgeCF008471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 31 Mar 2011 10:42:40 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 31 Mar 2011 10:42:40 -0700 From: "Henderson, Thomas R" To: HIP Date: Thu, 31 Mar 2011 10:42:39 -0700 Thread-Topic: flow bindings for locators Thread-Index: AcvvywdKo5u6DpO3SVyIJuw38HquLA== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B0BF@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] flow bindings for locators X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 31 Mar 2011 17:41:03 -0000 I forgot to mention an additional issue to consider for rfc5206-bis, but I = just added a tracker item: http://trac.tools.ietf.org/wg/hip/trac/ticket/23 The issue to consider is from recently published draft-cao-hiprg-flow-mobil= ity-00; whether to consider to rework our LOCATOR parameter so that it is e= xtensible for flow bindings defined in RFC6089. Although flow bindings are a multihoming issue, the LOCATOR definition is p= art of 5206bis. Comments on this idea? - Tom From rgm@htt-consult.com Thu Mar 31 12:36:19 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A225C3A6BAB for ; Thu, 31 Mar 2011 12:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUj8n2F7HdW6 for ; Thu, 31 Mar 2011 12:36:18 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6295F3A6B94 for ; Thu, 31 Mar 2011 12:36:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4D35262AB0 for ; Thu, 31 Mar 2011 19:37:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf-eI2rydsxR for ; Thu, 31 Mar 2011 15:37:11 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [87.213.50.130]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F045D62A78 for ; Thu, 31 Mar 2011 15:37:10 -0400 (EDT) Message-ID: <4D94D7E4.5010701@htt-consult.com> Date: Thu, 31 Mar 2011 21:37:08 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 31 Mar 2011 19:36:19 -0000 WHAT is the prefix used in HIPv1 (RFC 5201)? RFC 4843 states: Prefix : A constant 28-bit-long bitstring value (2001:10::/28). But 4843-bis states: IANA allocated a temporary non-routable 28-bit prefix from the IPv6 address space. By default, the prefix will be returned to IANA in 2014, continued use requiring IETF consensus. As per [RFC4773], the 28-bit prefix was drawn out of the IANA Special Purpose Address Block, namely 2001:0000::/23, in support of the experimental usage described in this document. IANA has updated the IPv6 Special Purpose Address Registry. There is NOTHING in the IANA registry about any assignment. But as I plowed through the iana assignment information, I found: http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml [9] 3FFE:831F::/32 was used for Teredo in some old but widely distributed networking stacks. This usage is deprecated in favour of 2001::/32, which was allocated for the purpose in [RFC4380] And sure enough in 4380: 2.6. Global Teredo IPv6 Service Prefix An IPv6 addressing prefix whose value is 2001:0000:/32. From this I MIGHT infer that Teredo is stepping within HIP's ORCHID allocation! Obviously this needs some clarification (at least for me!) AND IANA needs to put in the registry what HIPv1 is using, and then make sure that the HIPv2 prefix is publicized. From samu.varjonen@hiit.fi Thu Mar 31 21:23:12 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539B23A6BE0 for ; Thu, 31 Mar 2011 21:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-eeaUbePlvH for ; Thu, 31 Mar 2011 21:23:11 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D0BFD3A6965 for ; Thu, 31 Mar 2011 21:23:10 -0700 (PDT) Received: from [192.168.0.10] (cs181123051.pp.htv.fi [82.181.123.51]) by argo.otaverkko.fi (Postfix) with ESMTP id 1D5DD25ED56; Fri, 1 Apr 2011 07:24:49 +0300 (EEST) Message-ID: <4D95538C.30303@hiit.fi> Date: Fri, 01 Apr 2011 07:24:44 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Robert Moskowitz References: <4D94D7E4.5010701@htt-consult.com> In-Reply-To: <4D94D7E4.5010701@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Need to clarify HIT prefix X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 01 Apr 2011 04:23:12 -0000 31.3.2011 22:37, Robert Moskowitz kirjoitti: > WHAT is the prefix used in HIPv1 (RFC 5201)? > > RFC 4843 states: > > Prefix : A constant 28-bit-long bitstring value > (2001:10::/28). > > > But 4843-bis states: > > IANA allocated a temporary non-routable 28-bit prefix from the IPv6 > address space. By default, the prefix will be returned to IANA in > 2014, continued use requiring IETF consensus. As per [RFC4773], the > 28-bit prefix was drawn out of the IANA Special Purpose Address > Block, namely 2001:0000::/23, in support of the experimental usage > described in this document. IANA has updated the IPv6 Special > Purpose Address Registry. > > There is NOTHING in the IANA registry about any assignment. But as I > plowed through the iana assignment information, I found: > > http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml > > > [9] 3FFE:831F::/32 was used for Teredo in some old but widely > distributed networking stacks. This usage is deprecated in favour of > 2001::/32, > which was allocated for the purpose in [RFC4380] > > And sure enough in 4380: > > 2.6. Global Teredo IPv6 Service Prefix > > An IPv6 addressing prefix whose value is 2001:0000:/32. > > From this I MIGHT infer that Teredo is stepping within HIP's ORCHID > allocation! > There is something similar going on with RFC 3849. The Nit-checker complained the following: " == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. " > Obviously this needs some clarification (at least for me!) > > AND > > IANA needs to put in the registry what HIPv1 is using, and then make > sure that the HIPv2 prefix is publicized. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec