From rgm@htt-consult.com Wed Sep 12 11:37:49 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60321F8523 for ; Wed, 12 Sep 2012 11:37:49 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOp98sRQY-mv for ; Wed, 12 Sep 2012 11:37:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1E221F851E for ; Wed, 12 Sep 2012 11:37:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8B55962AB3 for ; Wed, 12 Sep 2012 18:37:19 +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 jFwC1VMjqvP7 for ; Wed, 12 Sep 2012 14:36:58 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A56B362A6C for ; Wed, 12 Sep 2012 14:36:57 -0400 (EDT) Message-ID: <5050D644.9070308@htt-consult.com> Date: Wed, 12 Sep 2012 14:36:52 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 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 ESP cipher suites X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 18:37:49 -0000 We have tried to limit the suites supported in 5202 and have our own suite list, different from: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml In part this is good as many of those suites are old and should be just lost. But some are marginially important and it is hard to figure out which they are. To get to specifics we have AES-CCM and AES-GCM 8 & 16, we skip 12 for each. But what about ENCR_NULL_AUTH_AES_GMAC? We don't have a 'good' auth only beyond NULL-ENCRYPT with HMAC-SHA2 (there is no AES-CMAC cipher, as that would really not work). So marginally we need to add the GMAC cipher. Then I am in discussions with a few people to come out with a set of 'compressed' CCM and GCM ciphers that replace the cipher's IV with using ESP's ESN, saving 8 bytes on the 'wire' and in wireless situations this is really worth doing. And I really will need the AES-CCM-8 version of this for one application and AES-GCM-8 for another. One can argue that if the wireless developers are busy screaming about both the ESN and IV, they will opt for the 8-octet ICV. So what do we do? Do we exactly follow the ESP cipher suite list and be done with it? If it is available for ESP use it if you desire? Or do we maintain our own reduced list and after publishing add more through our expert(s) like IKEv2 does (that is Tero). As I look over the last paragraph I realize it is not so simple, as the ESP_TRANSFORM is both the encryption and authentication, whereas other users of ESP negotiate these separately. So we do need to go with option 2, our own list as we have, and add GMAC to the current list and be ready to add the compressed versions of CCM and GCM. From rgm@htt-consult.com Wed Sep 12 13:22:26 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5821F844B for ; Wed, 12 Sep 2012 13:22:26 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pbYNkU2bbXX for ; Wed, 12 Sep 2012 13:22:26 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id DB26621F8629 for ; Wed, 12 Sep 2012 13:22:25 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5BFB862A86 for ; Wed, 12 Sep 2012 20:22:00 +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 RSnTOren5h3T for ; Wed, 12 Sep 2012 16:21:50 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3E47D62AA0 for ; Wed, 12 Sep 2012 16:21:50 -0400 (EDT) Message-ID: <5050EEDD.1020507@htt-consult.com> Date: Wed, 12 Sep 2012 16:21:49 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 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 and UDP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 20:22:26 -0000 I really should know this, and if I dig a bit, I will find it I suspect, but are UDP apps (eg tftp) bound to IP addresses as TCP apps (via the TCB). Is there a UCB? I can't find my intro to TCP/IP by Stevens book.... Why I ask, you ask? I am assuming the same address mapping is occuring in UDP apps as in TCP apps. Just some musings at the end of the day. Like I said, I am having some random thoughts here.... From andrewmcgr@gmail.com Wed Sep 12 15:24:31 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5138221F8624 for ; Wed, 12 Sep 2012 15:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avMEUbyOIeue for ; Wed, 12 Sep 2012 15:24:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA4E221F861F for ; Wed, 12 Sep 2012 15:24:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2981223pbb.31 for ; Wed, 12 Sep 2012 15:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=rLDuUNVO98tkzJT4ZzRSctqVQlBMkqpDBmaesLOsMhM=; b=W1NWhy+Ncz9sB/fmcvy5nPlhrR/f/o8N1e/sihdACBmsm5LkbiFyPIdnHp+iiCFAQR ySkE3leFYDpDm/pkO13it5Gpq0p7B8nmgm/iGy8n4g76oT4ullBKRzkay4a3itWDszjB qq3A1AQoc6X2Zyy1vusHn8xhQDd/lVmAHS8zQJjmwc1B8bmhkZvj9KyLKC6tBR88cPW+ dTW4kNvf1IGIAHI+HBS1dSg2Tphu/0MCMJbXXWrMdgl4Pbq+Pe72AWkrsx/5NpHOWKBa FwOyUVx+fH7Bdq3kJ6wZWBGfzUVqh4ddncxGTaeoNTlk69Wu96Jg7Rnmvm/e3/ZeUpNw FazQ== Received: by 10.68.193.194 with SMTP id hq2mr1009364pbc.93.1347488670659; Wed, 12 Sep 2012 15:24:30 -0700 (PDT) Received: from ?IPv6:2406:e000:62e9:1:fd74:f641:b0de:3ff7? ([2406:e000:62e9:1:fd74:f641:b0de:3ff7]) by mx.google.com with ESMTPS id pi1sm7171662pbb.7.2012.09.12.15.24.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 15:24:27 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_55CFC601-6EA5-4A6E-98E5-614456F9F2CA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Andrew McGregor In-Reply-To: <5050EEDD.1020507@htt-consult.com> Date: Thu, 13 Sep 2012 10:24:18 +1200 Message-Id: References: <5050EEDD.1020507@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1486) Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP and UDP X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2012 22:24:31 -0000 --Apple-Mail=_55CFC601-6EA5-4A6E-98E5-614456F9F2CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The same address mapping has to be possible, yes. This isn't = necessarily done by socket information, as binding UDP sockets is = optional. But, in the kernel, after source address selection, all the = necessary information is available anyway. On 13/09/2012, at 8:21 AM, Robert Moskowitz wrote: > I really should know this, and if I dig a bit, I will find it I = suspect, but are UDP apps (eg tftp) bound to IP addresses as TCP apps = (via the TCB). Is there a UCB? I can't find my intro to TCP/IP by = Stevens book.... >=20 > Why I ask, you ask? >=20 > I am assuming the same address mapping is occuring in UDP apps as in = TCP apps. >=20 > Just some musings at the end of the day. Like I said, I am having = some random thoughts here.... >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --Apple-Mail=_55CFC601-6EA5-4A6E-98E5-614456F9F2CA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTIyMjI0MThaMCMGCSqGSIb3DQEJBDEWBBSIsbvB bJArMWuAxqz2LV8ruxSIDTCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAJPdMcCf2CjfWDndcFcWvovE12DMsRKxEk6KJDBbq9yz0PTDaX25uD8e MTPeXqL8dDUYeYzxW/EUkaFDtvpOifiOaYosmDTBT2vIKUM2t+7XDe1u3DiUeQizhCdb92REHHSI xIz2D7vouhf2hdNX6Jiup9lSBLqPNn07G4eZznY7hCep0POAGPleLBNMih6nDFLLbYOSKXI1/7SR LAusOueTYv6da/+qukAhQNKTr9SUxBxK4eB7KGIf4hy/4bz0rffvL33cd9hR2BpASMT1EXLqRxwR ZruZnL2zvfXxfFshiUxTeTCzO7ZYVASUK644/eEvuMwtjAD+6lhLFBzZy3AAAAAAAAA= --Apple-Mail=_55CFC601-6EA5-4A6E-98E5-614456F9F2CA-- From gonzalo.camarillo@ericsson.com Thu Sep 13 01:11:33 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC221F8532 for ; Thu, 13 Sep 2012 01:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaN3sjeEGLM8 for ; Thu, 13 Sep 2012 01:11:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B96421F8523 for ; Thu, 13 Sep 2012 01:11:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-d3-5051953198c1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.1C.11467.13591505; Thu, 13 Sep 2012 10:11:30 +0200 (CEST) Received: from [131.160.36.145] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Thu, 13 Sep 2012 10:11:30 +0200 Message-ID: <50519531.2010802@ericsson.com> Date: Thu, 13 Sep 2012 11:11:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvra7R1MAAg8YJLBZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpS9L9kLnrJUfGxtYG9g/MncxcjBISFgIrHvO3sXIyeQKSZx 4d56NhBbSOAUo8Tj29ldjFxA9hpGida+F6wgCV4BbYmP/1+BFbEIqEo871jKAmKzCVhIbLl1 H8wWFQiWOLdxGxtEvaDEyZlPwOIiApISPXch6oUFlCW6H1yAWiwp8WbyTbA4s4CexJSrLYwQ trzE9rdzmCEO0pZY/qyFZQIj/ywkY2chaZmFpGUBI/MqRuHcxMyc9HJDvdSizOTi4vw8veLU TYzAIDu45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKib 8kB0w6z7wbnZRVJ71Muv2V3iifttEs8Ur8G22Ofsbg0NPq0KLsOgsNyCtMVFc5le9rGkaCd9 cL09/SRD/GnHw9LPNYT3hxnVvjB7WK+fmVRZ4PiPyfhEk9NDmeWSfjw2v93aHnYcf2iR8Gzr q7I1SXMu3ra2Oekv2nHh5xcptT0vapwuK7EUZyQaajEXFScCAFooU8gAAgAA Subject: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 08:11:33 -0000 Folks, I would like to start the WGLCs on the following two drafts. These WGLCs will end on September 30th. https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ In addition to technical comments, please also let the list know whether you still care about these specifications. Given the low level of energy in the WG, one of the issues the IESG will evaluate will be whether there is still enough interest behind all these bis documents. Please, send your comments to this mailing list. Thanks, Gonzalo HIP WG co-chair From gonzalo.camarillo@ericsson.com Thu Sep 13 01:15:42 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6321F856F for ; Thu, 13 Sep 2012 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YfONN98v9Xz for ; Thu, 13 Sep 2012 01:15:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCF21F8532 for ; Thu, 13 Sep 2012 01:15:38 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-04-50519629375a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C2.F1.17130.92691505; Thu, 13 Sep 2012 10:15:38 +0200 (CEST) Received: from [131.160.36.145] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Thu, 13 Sep 2012 10:15:36 +0200 Message-ID: <50519627.8090209@ericsson.com> Date: Thu, 13 Sep 2012 11:15:35 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ari Keranen References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> In-Reply-To: <5012C05B.6080203@nomadiclab.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvra7WtMAAg7Z5HBZtb36xWUxdNJnZ 4svRacwWR3tbmBxYPHbOusvusWTJTyaPzkXRAcxRXDYpqTmZZalF+nYJXBlbpu9hL7jHV7H8 bRdjA+Nj7i5GDg4JAROJ7w/4uhg5gUwxiQv31rN1MXJxCAmcYpRoXfydEcJZwyix58ghFpAG XgFtiebJwiAmi4CqRE+7L0gvm4CFxJZb91lAbFGBYIlzG7exgdi8AoISJ2c+AYuLCOhIdG+7 ywQyklmgiVHiwMlj7CAJYQENietvfrBC7PrLKDFx/XSwbk4BPYm2F2eYIK6TlHgz+SbYJGag +JSrLYwQtrzE9rdzmEFsIaDblj9rYZnAKDQLyfJZSFpmIWlZwMi8ilE4NzEzJ73cXC+1KDO5 uDg/T684dRMjMLwPbvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTAePtFwjWXOpcybHGH5nwo/fow7fD4797mKkOi/7pVrp6248HUxi++jvd/u7c06/b/6 8mOt5BD343KiXxZNVpieERfwa1JO25uGK5nifOpTl4nGn9CrS+WeXD7/W+YMpjWb1Mr9bPuU 5c29Ek++83+66/Hzmr2q75e2/v14Lef61uTTz0649TxPVmIpzkg01GIuKk4EAEZXcdY9AgAA Cc: Julien Laganier , Julien Laganier , "hipsec@ietf.org" Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 08:15:42 -0000 Hi Julien, if you could respond to Ari's comments on the 5203bis draft below, that would be great. Also, note that the latest version of this draft has expired. Thanks, Gonzalo On 27/07/2012 7:22 PM, Ari Keranen wrote: > Hi Julien, > > On 7/6/12 3:37 AM, Julien Laganier wrote: >> - 5203bis (registration) can IMHO be republished as is as I haven't >> seen any issue with the original version. If people agree I could >> republish it and we could WGLC it... > > I posted some comments about 5203bis earlier this year but back then > there was no discussion regarding them. So, here goes again. > > Some of these have been discussed also earlier on this list (these > relate to requirements discovered with the native NAT traversal draft > [1]), but I'll have them all here for easier reference. > > Currently, the registrar has no way of indicating that it would > otherwise accept the registration, but it's currently running low on > resources. For this purpose, a failure type "Insufficient resources" > could be added to the "registration failure types". > > Registration using authentication with certificates could be part of the > registration RFC. Currently, only authentication with HI is defined, but > knowing all HIs beforehand is not practical in many cases. > > Text in section 3.2. of [1] could be used as a basis for this (just > replace "HIP' data relay" with "registrar"). Also, if this > authentication mode is added to the draft, failure type "Invalid > certificate" should be added for the failure case. > > Should we have these in the registration draft? > > > Cheers, > Ari > > [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From mkomu@cs.hut.fi Thu Sep 13 05:04:44 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB1621F8568 for ; Thu, 13 Sep 2012 05:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9szCpZ8u43nE for ; Thu, 13 Sep 2012 05:04:43 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6592321F855B for ; Thu, 13 Sep 2012 05:04:43 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id D7BFD3031E0 for ; Thu, 13 Sep 2012 15:04:41 +0300 (EEST) Message-ID: <5051CBD9.30205@cs.hut.fi> Date: Thu, 13 Sep 2012 15:04:41 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <50519531.2010802@ericsson.com> In-Reply-To: <50519531.2010802@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 12:04:44 -0000 Hi, On 09/13/2012 11:11 AM, Gonzalo Camarillo wrote: > Folks, > > I would like to start the WGLCs on the following two drafts. These WGLCs > will end on September 30th. > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ > > In addition to technical comments, please also let the list know whether > you still care about these specifications. Given the low level of energy > in the WG, one of the issues the IESG will evaluate will be whether > there is still enough interest behind all these bis documents. > > Please, send your comments to this mailing list. I do care and I should have now time to comment. From julien.ietf@gmail.com Thu Sep 13 08:41:48 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91521F860B for ; Thu, 13 Sep 2012 08:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPlPsDE1qrSH for ; Thu, 13 Sep 2012 08:41:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC221F8607 for ; Thu, 13 Sep 2012 08:41:47 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4138938pbb.31 for ; Thu, 13 Sep 2012 08:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mx1DYAqpgKQlnOK4eKgM51+I4oEGs7SPY2NRk/57JDQ=; b=o09i3MEdvMuo06O+bhTTBqRa76yHC9aCbpY66ONHfJsjN9ph5MxPRw66BlfBeQ9CUZ 6VL8CJKnH4XmRduQF73MBDN8lA0JaLVnoAbhoKmbmbwF7u6Zd2cRUqFu/vgEqKdX931I OSJH3X+WoxA6+1w1EVURiwpXo5YL3paPtQqNrb47nL3ecFy/tVjoAzni12QbKFCbKpSE zLfn257FyfwLiJOB7Xk1pdCNSySwbPGBRktvxG+/vojbZwgggGyUQPy+SSeTgY/6jM/U a0Eyouhte2pPhdRE1u6ZehA8njD9PircaexGTCTAzpfgMotjYgSFpDnjy3H0XpnOB4IO fe3g== MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr5112743pbc.164.1347550907315; Thu, 13 Sep 2012 08:41:47 -0700 (PDT) Received: by 10.68.12.130 with HTTP; Thu, 13 Sep 2012 08:41:46 -0700 (PDT) In-Reply-To: <5012C05B.6080203@nomadiclab.com> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> Date: Thu, 13 Sep 2012 08:41:46 -0700 Message-ID: From: Julien Laganier To: Ari Keranen Content-Type: text/plain; charset=ISO-8859-1 Cc: hipsec@ietf.org Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 15:41:48 -0000 Hi Ari, On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: > > On 7/6/12 3:37 AM, Julien Laganier wrote: >> >> - 5203bis (registration) can IMHO be republished as is as I haven't >> seen any issue with the original version. If people agree I could >> republish it and we could WGLC it... > > > I posted some comments about 5203bis earlier this year but back then there > was no discussion regarding them. So, here goes again. > > Some of these have been discussed also earlier on this list (these relate to > requirements discovered with the native NAT traversal draft [1]), but I'll > have them all here for easier reference. > > Currently, the registrar has no way of indicating that it would otherwise > accept the registration, but it's currently running low on resources. For > this purpose, a failure type "Insufficient resources" could be added to the > "registration failure types". > > Registration using authentication with certificates could be part of the > registration RFC. Currently, only authentication with HI is defined, but > knowing all HIs beforehand is not practical in many cases. > > Text in section 3.2. of [1] could be used as a basis for this (just replace > "HIP' data relay" with "registrar"). Also, if this authentication mode is > added to the draft, failure type "Invalid certificate" should be added for > the failure case. > > [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal > > Should we have these in the registration draft? These suggestions sound reasonable to me. --julien From mkomu@cs.hut.fi Fri Sep 14 01:18:39 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A521F8578 for ; Fri, 14 Sep 2012 01:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrzkSsfe2stq for ; Fri, 14 Sep 2012 01:18:38 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 26BED21F8550 for ; Fri, 14 Sep 2012 01:18:37 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 938043030C8 for ; Fri, 14 Sep 2012 11:18:36 +0300 (EEST) Message-ID: <5052E85C.5010109@cs.hut.fi> Date: Fri, 14 Sep 2012 11:18:36 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <50519531.2010802@ericsson.com> <5051CBD9.30205@cs.hut.fi> In-Reply-To: <5051CBD9.30205@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 08:18:39 -0000 Hi, On 09/13/2012 03:04 PM, Miika Komu wrote: > Hi, > > On 09/13/2012 11:11 AM, Gonzalo Camarillo wrote: >> Folks, >> >> I would like to start the WGLCs on the following two drafts. These WGLCs >> will end on September 30th. >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ >> >> In addition to technical comments, please also let the list know whether >> you still care about these specifications. Given the low level of energy >> in the WG, one of the issues the IESG will evaluate will be whether >> there is still enough interest behind all these bis documents. >> >> Please, send your comments to this mailing list. > > I do care and I should have now time to comment. besides me, there's also some other people who could help in the final push if we'd know more specifically what to do. Could somebody re-post what to comment or to check from the drafts? If we need more complete reviews, we could split the work if there's volunteers? From rgm@htt-consult.com Fri Sep 14 03:04:14 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91021F853D for ; Fri, 14 Sep 2012 03:04:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxQmq1ZyFR5E for ; Fri, 14 Sep 2012 03:04:13 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 83A1521F851E for ; Fri, 14 Sep 2012 03:04:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D1ED462A7E; Fri, 14 Sep 2012 10:03:51 +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 tVLoqZOPRco6; Fri, 14 Sep 2012 06:03:30 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3A75962A6E; Fri, 14 Sep 2012 06:03:30 -0400 (EDT) Message-ID: <505300F1.8080400@htt-consult.com> Date: Fri, 14 Sep 2012 06:03:29 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Miika Komu References: <50519531.2010802@ericsson.com> <5051CBD9.30205@cs.hut.fi> <5052E85C.5010109@cs.hut.fi> In-Reply-To: <5052E85C.5010109@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 10:04:14 -0000 On 09/14/2012 04:18 AM, Miika Komu wrote: > Hi, > > On 09/13/2012 03:04 PM, Miika Komu wrote: >> Hi, >> >> On 09/13/2012 11:11 AM, Gonzalo Camarillo wrote: >>> Folks, >>> >>> I would like to start the WGLCs on the following two drafts. These >>> WGLCs >>> will end on September 30th. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ >>> >>> In addition to technical comments, please also let the list know >>> whether >>> you still care about these specifications. Given the low level of >>> energy >>> in the WG, one of the issues the IESG will evaluate will be whether >>> there is still enough interest behind all these bis documents. >>> >>> Please, send your comments to this mailing list. >> >> I do care and I should have now time to comment. > > besides me, there's also some other people who could help in the final > push if we'd know more specifically what to do. Could somebody re-post > what to comment or to check from the drafts? > > If we need more complete reviews, we could split the work if there's > volunteers? Sec 11 of 5201-bis is a pretty good change section. Kudos to Tobias on that. I did not do as good of a job with sec 13 in 4423-bis. Of course this is what was changed and not what was left, but should have been changed. So look at the changed sections, to understand the changes, then the whole document to see if it flows. I did that too many times to go back and do it again. From heer@informatik.rwth-aachen.de Sun Sep 16 02:14:31 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621BD21F8452 for ; Sun, 16 Sep 2012 02:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x-wFT7izu0U for ; Sun, 16 Sep 2012 02:14:30 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id B400621F8450 for ; Sun, 16 Sep 2012 02:14:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) 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 <0MAF0041TR04SXB0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sun, 16 Sep 2012 11:14:28 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.80,429,1344204000"; d="scan'208";a="103802115" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Sun, 16 Sep 2012 11:14:28 +0200 Received: from [192.168.1.100] ([unknown] [95.114.144.102]) 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 <0MAF00M0WR03Y730@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sun, 16 Sep 2012 11:14:28 +0200 (CEST) Message-id: <50559873.8030509@cs.rwth-aachen.de> Date: Sun, 16 Sep 2012 11:14:27 +0200 From: "Dr. Tobias Heer" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: Miika Komu , hipsec@ietf.org References: <50519531.2010802@ericsson.com> <5051CBD9.30205@cs.hut.fi> <5052E85C.5010109@cs.hut.fi> In-reply-to: <5052E85C.5010109@cs.hut.fi> Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 09:14:31 -0000 Hello, Am 14.09.2012 10:18, schrieb Miika Komu: > Hi, > > On 09/13/2012 03:04 PM, Miika Komu wrote: >> Hi, >> >> On 09/13/2012 11:11 AM, Gonzalo Camarillo wrote: >>> Folks, >>> >>> I would like to start the WGLCs on the following two drafts. These >>> WGLCs >>> will end on September 30th. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ >>> >>> In addition to technical comments, please also let the list know >>> whether >>> you still care about these specifications. Given the low level of >>> energy >>> in the WG, one of the issues the IESG will evaluate will be whether >>> there is still enough interest behind all these bis documents. >>> >>> Please, send your comments to this mailing list. >> >> I do care and I should have now time to comment. > > besides me, there's also some other people who could help in the final > push if we'd know more specifically what to do. Could somebody re-post > what to comment or to check from the drafts? > I think it would be good to check the general big-picture and how all parts play together. When redesigning the BEX and changing the HIT, we were careful to still maintain the properties of HIP. However, I think it woulr be best to have a close look at the general protocol mechanics to make sure that all parts are still in place. For 5201-bis, we have had some extensive reviews during the writing phase about a year ago. These reviews were generally very positive and the improvements that we have made to the text seem to add clarity. Since then only detail changes have been made. So I am quite confident that the WGLC reviews will go well. > If we need more complete reviews, we could split the work if there's > volunteers? More and better reviews are always a good thing ;-) Tobias > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From gonzalo.camarillo@ericsson.com Tue Sep 18 00:36:52 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E7C21F861E for ; Tue, 18 Sep 2012 00:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L1FABeYnIyZ for ; Tue, 18 Sep 2012 00:36:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B96F721F8639 for ; Tue, 18 Sep 2012 00:36:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-a9-505824913fc2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C9.33.11467.19428505; Tue, 18 Sep 2012 09:36:49 +0200 (CEST) Received: from [131.160.36.73] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Tue, 18 Sep 2012 09:36:49 +0200 Message-ID: <50582491.5050701@ericsson.com> Date: Tue, 18 Sep 2012 10:36:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvre5ElYgAg3krTC2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG2NPxgL9jNXLNr9lr2B8SlTFyMnh4SAicTrlsksELaYxIV7 69m6GLk4hAROMUrsfLuLBcJZzSixeNURsA5eAW2JeR19YDaLgKpE78rTjCA2m4CFxJZb98Em iQoES5zbuI0Nol5Q4uTMJ2BxEQFJiZ67S8FsYQElicmNU1khNktKvJl8EyzOLKAnMeVqCyOE LS+x/e0cZhBbCGjv8mctLBMY+WchGTsLScssJC0LGJlXMQrnJmbmpJcb6qUWZSYXF+fn6RWn bmIEBtrBLb91dzCeOidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbL jRlWKxZcWnE4c51Fc+SZiAv/k+OSnlVEu//baHto2633+82WMqVnfdPer/Bg/ST7GXPWmnas yVtevCTya+i86ZKLjh4PmyrEVnRFqP3EaqsWpijhfxY189bv/n2qoXDmNl/Be/ur+Kb3ce76 d7w+bLrO/17fDfvuh096cWvC6khrEYn1jIvLlFiKMxINtZiLihMB0wQn8wICAAA= Subject: [Hipsec] Drafts for our milestones X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 07:36:52 -0000 Folks, as you know, our charter includes the list of our milestones: http://datatracker.ietf.org/wg/hip/charter/ As you can see, the drafts associated with many of the milestones are not currently in the IETF archives: http://datatracker.ietf.org/wg/hip/ If you are the editor of one of those missing drafts, please submit a new revision so that we have non-expired versions of all our drafts out there. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Tue Sep 18 00:53:31 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E395921F8491 for ; Tue, 18 Sep 2012 00:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqNwr9BURv6u for ; Tue, 18 Sep 2012 00:53:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 250DF21F847A for ; Tue, 18 Sep 2012 00:53:30 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-21-505828790716 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.A0.25676.97828505; Tue, 18 Sep 2012 09:53:29 +0200 (CEST) Received: from [131.160.36.73] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Tue, 18 Sep 2012 09:53:29 +0200 Message-ID: <50582878.7010405@ericsson.com> Date: Tue, 18 Sep 2012 10:53:28 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: HIP References: <50519531.2010802@ericsson.com> In-Reply-To: <50519531.2010802@ericsson.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VrdSIyLAYNokK4upiyYzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48r8qewFUzkq7hy5zNLAeJGti5GTQ0LARKLxxGEmCFtM4sK9 9UBxLg4hgVOMEi++bmcGSQgJrGaU+LysFMTmFdCW+DV3FVgDi4CqxOf70xhBbDYBC4ktt+6z gNiiAsES5zZuY4OoF5Q4OfMJWFxEQFKi5+5SMFtYwEDi1J/z7F2MHEDztSXmbw8DCXMK6Ej8 v3GZEeIeSYk3k2+ClTML6ElMudrCCGHLS2x/OwfqNG2J5c9aWCYwCs5Csm0WkpZZSFoWMDKv YhTOTczMSS830kstykwuLs7P0ytO3cQIDMqDW36r7mC8c07kEKM0B4uSOK/11j3+QgLpiSWp 2ampBalF8UWlOanFhxiZODilGhhzV9UHz7jVPEeLv4qjeU/guqJPRg4f5sx29JcsOOSu6ruZ ueTvx0j/m3HxnOsNr2wPmWcdXbjmaGVBn6j6pMZ7Pixt8k2dayftNYxef1Si4pQoe/43+6Dt lWdepNza6HpdupqpRXdTbarc+3ncc3YusTW+HHtf3u2d54Ofs17MDzvy3/ecdYUSS3FGoqEW c1FxIgD/NmZPGAIAAA== Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2012 07:53:32 -0000 Hi, in particular, please provide input on whether 4423-bis, which does not have normative language, should be (eventually) published as a PS or an Informational RFC. Cheers, Gonzalo On 13/09/2012 11:11 AM, Gonzalo Camarillo wrote: > Folks, > > I would like to start the WGLCs on the following two drafts. These WGLCs > will end on September 30th. > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ > > In addition to technical comments, please also let the list know whether > you still care about these specifications. Given the low level of energy > in the WG, one of the issues the IESG will evaluate will be whether > there is still enough interest behind all these bis documents. > > Please, send your comments to this mailing list. > > Thanks, > > Gonzalo > HIP WG co-chair > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From gurtov@cs.helsinki.fi Tue Sep 18 23:10:19 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8E221E8090 for ; Tue, 18 Sep 2012 23:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BeOQcxyBxLz for ; Tue, 18 Sep 2012 23:10:18 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DCC21E8087 for ; Tue, 18 Sep 2012 23:10:16 -0700 (PDT) Received: from [10.20.46.234] (gw1.panoulu.net [212.50.147.101]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 19 Sep 2012 09:10:15 +0300 id 0008C31F.505961C7.00003C6C Message-ID: <505961C7.4070202@cs.helsinki.fi> Date: Wed, 19 Sep 2012 09:10:15 +0300 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120607 Thunderbird/14.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <50519531.2010802@ericsson.com> In-Reply-To: <50519531.2010802@ericsson.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 06:10:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, My group has interest in these documents and can provide reviews if needed. Andrei On 13.9.2012 11:11, Gonzalo Camarillo wrote: > Folks, > > I would like to start the WGLCs on the following two drafts. These > WGLCs will end on September 30th. > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ > > In addition to technical comments, please also let the list know > whether you still care about these specifications. Given the low > level of energy in the WG, one of the issues the IESG will evaluate > will be whether there is still enough interest behind all these bis > documents. > > Please, send your comments to this mailing list. > > Thanks, > > Gonzalo HIP WG co-chair > _______________________________________________ Hipsec mailing > list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEUEARECAAYFAlBZYcYACgkQP7jp0uceFkS2wwCWJ4wcdgA1J6XZ95oOJE253qWa +gCeNk3M3FfLeXn1BuZWWoAL5BL1pkI= =k/yE -----END PGP SIGNATURE----- From mkomu@cs.hut.fi Wed Sep 19 00:51:39 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17FA21F8652 for ; Wed, 19 Sep 2012 00:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2owJUO4+Ujq for ; Wed, 19 Sep 2012 00:51:39 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D421F8650 for ; Wed, 19 Sep 2012 00:51:38 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 6FF513033B8 for ; Wed, 19 Sep 2012 10:51:37 +0300 (EEST) Message-ID: <50597989.2050205@cs.hut.fi> Date: Wed, 19 Sep 2012 10:51:37 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <50519531.2010802@ericsson.com> <50582878.7010405@ericsson.com> In-Reply-To: <50582878.7010405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 07:51:39 -0000 Hi, from the viewpoint of research, the different aspects of HIP seems to be covered quite well and the architecture has been adopted as a basis for a number of other research-oriented protocols. The research group is closing, so I don't think there will be many new variants (like the DEX and RFID-version of HIP) of the architecture. From the viewpoint of engineering, we have currently three well-known implementations (in addition to some early approaches and few java-based implementations) that we have successfully inteoperated earlier. Combining the three aspects, I'd lean slightly towards Proposed Standard but I guess the issue is subtle as RFC4423 does not have any normative language. On 09/18/2012 10:53 AM, Gonzalo Camarillo wrote: > Hi, > > in particular, please provide input on whether 4423-bis, which does not > have normative language, should be (eventually) published as a PS or an > Informational RFC. > > Cheers, > > Gonzalo > > On 13/09/2012 11:11 AM, Gonzalo Camarillo wrote: >> Folks, >> >> I would like to start the WGLCs on the following two drafts. These WGLCs >> will end on September 30th. >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ >> >> In addition to technical comments, please also let the list know whether >> you still care about these specifications. Given the low level of energy >> in the WG, one of the issues the IESG will evaluate will be whether >> there is still enough interest behind all these bis documents. >> >> Please, send your comments to this mailing list. >> >> Thanks, >> >> Gonzalo >> HIP WG co-chair >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From internet-drafts@ietf.org Wed Sep 19 14:54:49 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C19A21E80B4; Wed, 19 Sep 2012 14:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuNNpJH3Gbka; Wed, 19 Sep 2012 14:54:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFA321E8050; Wed, 19 Sep 2012 14:54:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919215448.32529.66238.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 14:54:48 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4843-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2012 21:54:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash I= dentifiers Version 2 (ORCHIDv2) Author(s) : Julien Laganier Francis Dupont Filename : draft-ietf-hip-rfc4843-bis-02.txt Pages : 14 Date : 2012-09-19 Abstract: This document specifies an updated Overlay Routable Cryptographich Hash Identifiers format that obsoletes the earlier format defined in [RFC4843]. 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. The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4843-bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ari.keranen@nomadiclab.com Thu Sep 20 06:58:52 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE0221F8779 for ; Thu, 20 Sep 2012 06:58:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgdSZPBXPCf3 for ; Thu, 20 Sep 2012 06:58:52 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id D183121F84AF for ; Thu, 20 Sep 2012 06:58:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 2C7BD4E6E4; Thu, 20 Sep 2012 16:58:49 +0300 (EEST) 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 w6UqVWj-QM1m; Thu, 20 Sep 2012 16:58:47 +0300 (EEST) Received: from tri59.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id A57894E679; Thu, 20 Sep 2012 16:58:47 +0300 (EEST) Message-ID: <505B2117.8010907@nomadiclab.com> Date: Thu, 20 Sep 2012 16:58:47 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Julien Laganier References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 13:58:52 -0000 Hi Julien, On 9/13/12 6:41 PM, Julien Laganier wrote: > Hi Ari, > > On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >> >> On 7/6/12 3:37 AM, Julien Laganier wrote: >>> >>> - 5203bis (registration) can IMHO be republished as is as I haven't >>> seen any issue with the original version. If people agree I could >>> republish it and we could WGLC it... >> >> >> I posted some comments about 5203bis earlier this year but back then there >> was no discussion regarding them. So, here goes again. >> >> Some of these have been discussed also earlier on this list (these relate to >> requirements discovered with the native NAT traversal draft [1]), but I'll >> have them all here for easier reference. >> >> Currently, the registrar has no way of indicating that it would otherwise >> accept the registration, but it's currently running low on resources. For >> this purpose, a failure type "Insufficient resources" could be added to the >> "registration failure types". >> >> Registration using authentication with certificates could be part of the >> registration RFC. Currently, only authentication with HI is defined, but >> knowing all HIs beforehand is not practical in many cases. >> >> Text in section 3.2. of [1] could be used as a basis for this (just replace >> "HIP' data relay" with "registrar"). Also, if this authentication mode is >> added to the draft, failure type "Invalid certificate" should be added for >> the failure case. >> >> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >> >> Should we have these in the registration draft? > > These suggestions sound reasonable to me. OK, great. If you add these to the registration draft, I can update the native NAT traversal draft accordingly. Cheers, Ari From gonzalo.camarillo@ericsson.com Thu Sep 20 08:00:48 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AE521F87EA for ; Thu, 20 Sep 2012 08:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94fDTqCPRtM9 for ; Thu, 20 Sep 2012 08:00:48 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C758021F877E for ; Thu, 20 Sep 2012 08:00:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-05-505b2f9e3059 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 08.61.11467.E9F2B505; Thu, 20 Sep 2012 17:00:46 +0200 (CEST) Received: from [131.160.126.223] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Thu, 20 Sep 2012 17:00:45 +0200 Message-ID: <505B2F9D.2040301@ericsson.com> Date: Thu, 20 Sep 2012 18:00:45 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrei Gurtov References: <50519531.2010802@ericsson.com> <505961C7.4070202@cs.helsinki.fi> In-Reply-To: <505961C7.4070202@cs.helsinki.fi> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre48/egAgxdtRhbNG08zW0xdNJnZ gclj7TULjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfzunc9c8JCr4umS7AbGKxxdjJwcEgImEqtX HGKFsMUkLtxbz9bFyMUhJHCKUeLP+U5mCGcto8SXQ3vYQKp4BbQlnq7oYwSxWQRUJbZtWgrW zSZgIbHl1n0WEFtUIFji3MZtUPWCEidnPgGLiwhoSky9t5YZxGYWUJdo7j3HBGILCxhInPpz nh3EFhLwldh74zNYL6eAnsS6dTNZIK6TlHgz+SYLRK+exJSrLYwQtrzE9rdzmCF6tSWWP2th mcAoNAvJ6llIWmYhaVnAyLyKUTg3MTMnvdxQL7UoM7m4OD9Przh1EyMwgA9u+a27g/HUOZFD jNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPr8YlvZH/C/9iPTlWnm+rce 5Sidca17G6dbsWi/+4T+1MeNWUukrPVjI4Uiz5bfe3A3mbdEObi7wDJ4D/8lro3KKs6zVoZa Oiy88Ji5MeTEGwdn1tcus5N3c6mzBfj3fq75d3y+ymIO6+fu0TdS0gT56wKZrK/OTrH2bFLZ f4O9fsHSCSv7lFiKMxINtZiLihMBqAtA5y4CAAA= Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 15:00:48 -0000 Hi Andrei if you can provide reviews, now it would be the perfect time to do it given that we have two of our drafts under WGLC and will be WGLCing more drafts in the near future. Thanks, Gonzalo On 19/09/2012 9:10 AM, Andrei Gurtov wrote: > Hi, > > My group has interest in these documents and can provide reviews > if needed. > > Andrei > > On 13.9.2012 11:11, Gonzalo Camarillo wrote: >> Folks, > >> I would like to start the WGLCs on the following two drafts. >> These WGLCs will end on September 30th. > >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ > >> In addition to technical comments, please also let the list know >> whether you still care about these specifications. Given the low >> level of energy in the WG, one of the issues the IESG will >> evaluate will be whether there is still enough interest behind >> all these bis documents. > >> Please, send your comments to this mailing list. > >> Thanks, > >> Gonzalo HIP WG co-chair >> _______________________________________________ Hipsec mailing >> list Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > > _______________________________________________ Hipsec mailing > list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec > > From internet-drafts@ietf.org Thu Sep 20 10:32:23 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD4F21F882C; Thu, 20 Sep 2012 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7zSTMqnWwWa; Thu, 20 Sep 2012 10:32:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8520521F87E9; Thu, 20 Sep 2012 10:32:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920173222.26468.35578.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 10:32:22 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4843-bis-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 17:32:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash I= dentifiers Version 2 (ORCHIDv2) Author(s) : Julien Laganier Francis Dupont Filename : draft-ietf-hip-rfc4843-bis-03.txt Pages : 13 Date : 2012-09-20 Abstract: This document specifies an updated Overlay Routable Cryptographich Hash Identifiers format that obsoletes the earlier format defined in [RFC4843]. 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. The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4843-bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From julien.ietf@gmail.com Thu Sep 20 16:49:58 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003E621E8050 for ; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji29-66u0Pyj for ; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF721E8047 for ; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3851317pbb.31 for ; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xlwd5yv8o6C31n4CZtSb++nGxhHcZT1MtiSqa2iU03k=; b=jXR4u8X/Mt/FpmfZsDD44REE+WzwbvyhoZs+sZAdhHyYqGozqyb+TzHXDDXVxz78nt asAOBvEKGWQIM80H8nvwEIdlVNhXyx6QiSHj85oQt6Gaq1obKfRaQ64CldZxCihVC+sH mxFwyN9zpjB1sZBYBbUEnXrH57UwBe5c+w6DyMEBOtZkYMFlxb5jsis0Ll75iYMjVCNM Pm6uFic4bKDLXEhBEjFJ+pNuLbEEhcW1//COzsXgZWlnTVPWYOiaHlUKHXorG3leWo91 p5LZY45BaiNjL+ymAPZt9lqyrjfDw1i3sihsySUjJYjqr7i631pSrGFrRPuz0sV7r20u 9/pQ== MIME-Version: 1.0 Received: by 10.66.76.3 with SMTP id g3mr9006291paw.25.1348184997332; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) Received: by 10.68.12.130 with HTTP; Thu, 20 Sep 2012 16:49:57 -0700 (PDT) In-Reply-To: <5012C05B.6080203@nomadiclab.com> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> Date: Thu, 20 Sep 2012 16:49:57 -0700 Message-ID: From: Julien Laganier To: Ari Keranen , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: hipsec@ietf.org Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 23:49:58 -0000 On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: > Hi Julien, > > > On 7/6/12 3:37 AM, Julien Laganier wrote: >> >> - 5203bis (registration) can IMHO be republished as is as I haven't >> seen any issue with the original version. If people agree I could >> republish it and we could WGLC it... > > > I posted some comments about 5203bis earlier this year but back then there > was no discussion regarding them. So, here goes again. > > Some of these have been discussed also earlier on this list (these relate to > requirements discovered with the native NAT traversal draft [1]), but I'll > have them all here for easier reference. > > Currently, the registrar has no way of indicating that it would otherwise > accept the registration, but it's currently running low on resources. For > this purpose, a failure type "Insufficient resources" could be added to the > "registration failure types". > > Registration using authentication with certificates could be part of the > registration RFC. Currently, only authentication with HI is defined, but > knowing all HIs beforehand is not practical in many cases. > > Text in section 3.2. of [1] could be used as a basis for this (just replace > "HIP' data relay" with "registrar"). Also, if this authentication mode is > added to the draft, failure type "Invalid certificate" should be added for > the failure case. > > Should we have these in the registration draft? > > [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal I was going to shamelessly copy/paste section 3.2 of [1] in the registration draft but I noticed that [1] actually has a normative dependency on RFC 6253 "Host Identity Protocol Certificates" which is Experimental. Thus adding the support for certificates to a standard track HIP registration would cause a so-called downref which could be problematic... Gonzalo - what is your take on this? --julien From gonzalo.camarillo@ericsson.com Fri Sep 21 01:11:49 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB421F86E3 for ; Fri, 21 Sep 2012 01:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUkVNHjOh00d for ; Fri, 21 Sep 2012 01:11:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9E21F8694 for ; Fri, 21 Sep 2012 01:11:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-71-505c214006ac Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EB.EC.11467.0412C505; Fri, 21 Sep 2012 10:11:44 +0200 (CEST) Received: from [131.160.36.124] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Fri, 21 Sep 2012 10:11:44 +0200 Message-ID: <505C213F.6050701@ericsson.com> Date: Fri, 21 Sep 2012 11:11:43 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Julien Laganier References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvra6DYkyAwcw9RhZtb36xWUxdNJnZ 4svRacwOzB47Z91l91iy5CeTR+ei6ADmKC6blNSczLLUIn27BK6MVz03WAv2Cle0b+5hbWC8 yd/FyMkhIWAiseLwNRYIW0ziwr31bF2MXBxCAqcYJV58+MkK4axhlOiesZC9i5GDg1dAW2LV 1gqQBhYBVYkHU3azgdhsAhYSW27dBxskKhAscW7jNrA4r4CgxMmZT8DiIkCtpyY1gNnMAiES dzfcZwKxhQU0JK6/+QG16xCTxIG+LkaQXZwCgRK7J5ZAHCcp8WbyTahePYkpV1sYIWx5ie1v 5zCD2EJA85c/a2GZwCg0C8nqWUhaZiFpWcDIvIpRODcxMye93FAvtSgzubg4P0+vOHUTIzCo D275rbuD8dQ5kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw2it4VZ0S aFO/63/7G4Nj0aqJ9/e2SWx95ZxfddNYxsjI9PHme8KFWs38TxbGit832cvf8K+gcs3EO7v8 9WdUJYuHvZtTV5HP+VzzrsmhFLm0h1O6Lf89OZepESro+jl9c3HuCr13HBv3WryXfDyrewfv RasVZioblVfpd9ZNYGNYkrW8f4KHEktxRqKhFnNRcSIAN7a+/zgCAAA= Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Sep 2012 08:11:50 -0000 Hi Julien, my take on this is that we need to produce a standards-track document specifying exactly that. This is what our charter says about it: https://datatracker.ietf.org/wg/hip/charter/ > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. Cheers, Gonzalo On 21/09/2012 2:49 AM, Julien Laganier wrote: > On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >> Hi Julien, >> >> >> On 7/6/12 3:37 AM, Julien Laganier wrote: >>> >>> - 5203bis (registration) can IMHO be republished as is as I haven't >>> seen any issue with the original version. If people agree I could >>> republish it and we could WGLC it... >> >> >> I posted some comments about 5203bis earlier this year but back then there >> was no discussion regarding them. So, here goes again. >> >> Some of these have been discussed also earlier on this list (these relate to >> requirements discovered with the native NAT traversal draft [1]), but I'll >> have them all here for easier reference. >> >> Currently, the registrar has no way of indicating that it would otherwise >> accept the registration, but it's currently running low on resources. For >> this purpose, a failure type "Insufficient resources" could be added to the >> "registration failure types". >> >> Registration using authentication with certificates could be part of the >> registration RFC. Currently, only authentication with HI is defined, but >> knowing all HIs beforehand is not practical in many cases. >> >> Text in section 3.2. of [1] could be used as a basis for this (just replace >> "HIP' data relay" with "registrar"). Also, if this authentication mode is >> added to the draft, failure type "Invalid certificate" should be added for >> the failure case. >> >> Should we have these in the registration draft? >> >> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal > > I was going to shamelessly copy/paste section 3.2 of [1] in the > registration draft but I noticed that [1] actually has a normative > dependency on RFC 6253 "Host Identity Protocol Certificates" which is > Experimental. Thus adding the support for certificates to a standard > track HIP registration would cause a so-called downref which could be > problematic... > > Gonzalo - what is your take on this? > > --julien > From internet-drafts@ietf.org Fri Sep 21 17:15:52 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439C521E80B7; Fri, 21 Sep 2012 17:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkw6H6HoWrVk; Fri, 21 Sep 2012 17:15:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F1A21E8049; Fri, 21 Sep 2012 17:15:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120922001551.10482.92285.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 17:15:51 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Sep 2012 00:15:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Identity Protocol (HIP) Registration Extension Author(s) : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5203-bis-02.txt Pages : 14 Date : 2012-09-21 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5203-bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From julien.ietf@gmail.com Fri Sep 21 17:34:58 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028D621F855E for ; Fri, 21 Sep 2012 17:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJOnCpVqbn8n for ; Fri, 21 Sep 2012 17:34:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFA21F8554 for ; Fri, 21 Sep 2012 17:34:57 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so6273858pbb.31 for ; Fri, 21 Sep 2012 17:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/d9ct8Nw1CO7kqjkkJ/lF24mFqjrwZphTHhCHNnDpCU=; b=oCDZ9fgfj/8bqUzzwsIFVyl7jWt5C5mdB8jdm6Mn9Ai1duHVzu/dnN2kkD/BSUqf2E +URQj8WfsxmB9YJNpZTwwcSgK9o8yLYCV9z4u2//XGH1a+5ilt/XJxEc2Ri9lfi2hkfb /pVXY6tjRNcjWS5bcJgn5b73a7sqzaNLsDgqFXGYb4Gkq+c0XLXk/0wxn6VyIcT4yOFe KHaE9Ci/7P+narr3aa/ByU8NY4WESm93CdHWQSFqddnGGXC3hK1PoJludjfC80MhTXs5 g6bUQ60c5hizqjEJV8Plk4AUyzo+RNFBpCdmJmYt7+++y8BMOteowFmvSOq1RUazjxtP mSPA== MIME-Version: 1.0 Received: by 10.68.192.7 with SMTP id hc7mr19744544pbc.6.1348274097143; Fri, 21 Sep 2012 17:34:57 -0700 (PDT) Received: by 10.68.12.130 with HTTP; Fri, 21 Sep 2012 17:34:57 -0700 (PDT) In-Reply-To: References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> Date: Fri, 21 Sep 2012 17:34:57 -0700 Message-ID: From: Julien Laganier To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Sep 2012 00:34:58 -0000 Folks, I've been thinking a bit more about the update of RFC5204 / Rendezvous Server support. See below: On Thu, Jul 5, 2012 at 5:37 PM, Julien Laganier wrote: > [...] > - 5204bis (rendezvous) needs one more subsection regarding relaying of > the UPDATE packet to support double jump of mobile nodes. As this > isn't really useful without the mobility support my proposal is to > tackle this one together with the 5206bis. I figured two things: 1- relaying an UPDATE packet is pointless in the absence of HIP mobility support on both endpoints. 2- support for rendezvous server is useful independently of support for HIP mobility. Taking both 1. and 2. into account, my conclusion is that it makes sense to keep the rendezvous server support self-contained in 5203bis, i.e., without a normative dependency to the mobility support in 5206bis, while 5206 would specify an extension to rendezvous mechanism for support of relaying UPDATE packets. Makes sense? --julien From internet-drafts@ietf.org Fri Sep 21 17:39:57 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD7F21E80BF; Fri, 21 Sep 2012 17:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2FmJxT883RC; Fri, 21 Sep 2012 17:39:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E8D21E8053; Fri, 21 Sep 2012 17:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120922003956.30169.55625.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 17:39:56 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5204-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Sep 2012 00:39:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Identity Protocol (HIP) Rendezvous Extension Author(s) : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5204-bis-02.txt Pages : 15 Date : 2012-09-21 Abstract: This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5204-bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 21 18:04:40 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B3321E80D9; Fri, 21 Sep 2012 18:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HSlt8revFHj; Fri, 21 Sep 2012 18:04:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321721E80BF; Fri, 21 Sep 2012 18:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120922010439.30164.14087.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 18:04:39 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5205-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Sep 2012 01:04:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Ex= tension Author(s) : Julien Laganier Filename : draft-ietf-hip-rfc5205-bis-02.txt Pages : 17 Date : 2012-09-21 Abstract: 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). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5205-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5205-bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rene.hummen@gmail.com Sun Sep 23 08:35:58 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2E21F84D9 for ; Sun, 23 Sep 2012 08:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32FIYc4UeqA8 for ; Sun, 23 Sep 2012 08:35:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18B3F21F84C4 for ; Sun, 23 Sep 2012 08:35:56 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so212764pbb.31 for ; Sun, 23 Sep 2012 08:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Yi2r8sISfivJzMk7ejXt6VcvkahctWuL3p7TqtNcsVo=; b=CaIUTIzgwzubDJ5T1FOhK3Nn+zuzdbD1EGA9xPeo+GxNlFtctsRvkRugQbpSX7i6ah Slau+faFsKFi01imygtao6hkErefkOOXhcee2MIq/1abl8aCPFvf8bXa675/zlvuom59 iByqyhkSy/niAdjHbyFkmxiJJ7vhD5BASwrnfyvktkOl7iQRVpE5RWv4y7uh1Esix347 /YqqKwp+beKE64Q1f8pt+Z22V/lhxkYacEy+Coaq42JJpnaFTMj0txMBEiyQsnQ4m630 H/1KFcjwaWIyeVL4fP6z+GCZiXVUhy0j6BHkrCV6UtlnnyTEeVlg3wgEerIo4GpCCM3e szsw== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr29994359pbc.97.1348414556648; Sun, 23 Sep 2012 08:35:56 -0700 (PDT) Sender: rene.hummen@gmail.com Received: by 10.68.57.102 with HTTP; Sun, 23 Sep 2012 08:35:56 -0700 (PDT) Date: Sun, 23 Sep 2012 17:35:56 +0200 X-Google-Sender-Auth: Ouk5djPSJ4ZCPyMvGMd5F5NOPUg Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Hummen?= To: HIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2012 15:42:36 -0000 Hi all, I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some technical as well as editorial issues that I consider worth discussing and fixing. Please note that especially the technical issues regarding the used packet space may not be considered problematic in case of everyday Internet connections. However, resource-constrained environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard payload limits. Here, a few bytes of additional packet size can determine whether packets need to be fragmented or not. Therefore, I think, we should also consider these scenarios in the basic HIP specification that is shared by all HIP variants. I structured my feedback into different topics highlight by ###. Technical issues: ------------------------ ### R1 Counter ### 4.1.4. HIP Replay Protection "The R1 counter SHOULD NOT roll over." No explanation is given what implementors should do when a roll over occurs. I suggest to add the following text: "If a roll over is detected, the associated HIs SHOULD be removed and new ones should be generated." Note, however, that such a change would also invalidate ACLs and HI-IP lookup information based on the original HIs. ### HIP Checksum ### 5.1.1. Checksum What is the reason for using the IP-based pseudo-headers here? If I am not overlooking something, non-HIP-aware NATs on the communication path effectively break the HIP checksum. I know that this is the way how TCP/IP pseudo-headers are defined. Still, I suggest to only checksum the HIP header and the HIP parameters to avoid problems in the future and to maintain layer separation. What happens if HIP is used in non-IP environments? ### Decreasing the per-packet overhead ### 4.1.2. Puzzle Exchange "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder can include some data in R1 that the Initiator MUST copy unmodified in the corresponding I2 packet." 5.2.4. PUZZLE "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 parameter." Especially in resource-constrained environments such as targeted by HIP DEX, each byte that needs to be transmitted is valuable (from a power perspective) and may lead to fragmentation at the lower layers. Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE parameter and to add +2 to the type number (resulting in 259) for the new PUZZLE type. If the Responder has to transfer state in an unsigned fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for this purpose. Furthermore, the opaque value does not seem to be necessary, as HIPL currently does not use it. 5.2.5. SOLUTION Here, I suggest removing 1 byte of reserved space and the 2 byte, echoed opaque value for the same reason presented above. The type number could be moved to 323 (SOLUTION + 2). If we need to modify the puzzle parameter for some reason in the future, I suggest to design a new parameter instead of using the reserved field. That is how new semantics are handled for any other parameter as well (see MAC_X). 5.2.3. R1_COUNTER "It SHOULD be included in the R1 (in which case, it is covered by the signature), and if present in the R1, it MUST be echoed (including the Reserved field verbatim) by the Initiator in the I2 packet." Similar to the SOLUTION parameter, I suggest removing the 4 bytes of reserved space from the R1 counter parameter and to add +2 to the type number (resulting in 131) for the new R1_COUNTER type. I understand that these changes break parameter compatibility with existing v1 implementations. However, I do not consider a new parameter layout problematic as the semantics won't change considerably allowing for code re-use in most cases. Editorial changes: ------------------------ 1.3. Memo Structure "Finally, Sections 7, 8, and 9 discuss policy, security, and IANA considerations, respectively." 8 and 9 lack internal references to the respective sections in the document. 4.1.7. HIP Downgrade Protection "In contrast to the first version of HIP [RFC5201],the version 2 of [...]" There is a space missing after the comma: "In contrast to the first version of HIP [RFC5201], the version 2 of [...]" ### HIP Header Length ### 5.1. Payload Format "The Header Length field contains the combined length of the HIP Header and HIP parameters in 8-byte units, excluding the first 8 bytes." 5.2.21. ECHO_REQUEST_UNSIGNED "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.2. R1 - the HIP Responder Packet "The signature is calculated over the whole HIP packet, after setting the Initiator's HIT, header checksum, as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any parameters that follow the signature, as described in Section 5.2.15." These three sections indicate the following problem with the HIP header length field: The sender generates the packet, sets the header length, and signs/MACs the packet. A middlebox afterwards adds an ECHO_REQUEST_UNSIGNED parameter to the packet. However, this invalidates the HIP header length information resulting in a broken packet. If the middlebox modifies the HIP header length value, it invalidates the signature/MAC. However, following the references to: 6.4.1. HMAC Calculation 6.4.2. Signature Calculation ... clarifies the issue I just described: "In the HIP header, the Header Length field value is calculated to the beginning of the [HIP_SIGNATURE | HIP_MAC] parameter." Hence, I suggest the following text in Section 5.3.2 in order to prevent misconceptions by implementors: "The signature is calculated over the HIP packet as described in Section 5.2.15." ### References ### 12. References References to HIP-related documents refer to old revisions (e.g., I-D.ietf-hip-cert). -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ From rgm@htt-consult.com Sun Sep 23 09:34:47 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183D21F84F2 for ; Sun, 23 Sep 2012 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vBTVtJtFTSb for ; Sun, 23 Sep 2012 09:34:46 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id C45C321F84A2 for ; Sun, 23 Sep 2012 09:34:45 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 19C3F62A79; Sun, 23 Sep 2012 16:34: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 ZkxhOIGuHI-s; Sun, 23 Sep 2012 12:34:04 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8F88E62A69; Sun, 23 Sep 2012 12:34:04 -0400 (EDT) Message-ID: <505F39F6.5000002@htt-consult.com> Date: Sun, 23 Sep 2012 12:33:58 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?UTF-8?B?UmVuw6kgSHVtbWVu?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: HIP WG Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2012 16:34:47 -0000 Great review, Rene! For KMP transport over 802.15.4 for 15.4 keying, please see: https://mentor.ieee.org/802.15/dcn/12/15-12-0458-02-0009-moving-kmp-forward.ppt At the meeting last week, we decided that we are done discussing the design and can write the spec. This will go into: https://mentor.ieee.org/802.15/dcn/12/15-12-0116-04-0009-p802-15-9-d001.doc Of course 15.9 has a LOT less overhead than 6lowpan for running HIP at IP layer. On 09/23/2012 11:35 AM, René Hummen wrote: > Hi all, > > I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some > technical as well as editorial issues that I consider worth discussing > and fixing. Please note that especially the technical issues regarding > the used packet space may not be considered problematic in case of > everyday Internet connections. However, resource-constrained > environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard > payload limits. Here, a few bytes of additional packet size can > determine whether packets need to be fragmented or not. Therefore, I > think, we should also consider these scenarios in the basic HIP > specification that is shared by all HIP variants. > > I structured my feedback into different topics highlight by ###. > > > Technical issues: > ------------------------ > > ### R1 Counter ### > > 4.1.4. HIP Replay Protection > "The R1 counter SHOULD NOT roll over." > > No explanation is given what implementors should do when a roll over > occurs. I suggest to add the following text: > > "If a roll over is detected, the associated HIs SHOULD be removed and > new ones should be generated." > > Note, however, that such a change would also invalidate ACLs and HI-IP > lookup information based on the original HIs. > > > ### HIP Checksum ### > > 5.1.1. Checksum > > What is the reason for using the IP-based pseudo-headers here? If I am > not overlooking something, non-HIP-aware NATs on the communication > path effectively break the HIP checksum. I know that this is the way > how TCP/IP pseudo-headers are defined. Still, I suggest to only > checksum the HIP header and the HIP parameters to avoid problems in > the future and to maintain layer separation. What happens if HIP is > used in non-IP environments? > > > ### Decreasing the per-packet overhead ### > > 4.1.2. Puzzle Exchange > "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an > ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an > ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder > can include some data in R1 that the Initiator MUST copy unmodified in > the corresponding I2 packet." > > 5.2.4. PUZZLE > "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 > parameter." > > Especially in resource-constrained environments such as targeted by > HIP DEX, each byte that needs to be transmitted is valuable (from a > power perspective) and may lead to fragmentation at the lower layers. > Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE > parameter and to add +2 to the type number (resulting in 259) for the > new PUZZLE type. If the Responder has to transfer state in an unsigned > fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for > this purpose. Furthermore, the opaque value does not seem to be > necessary, as HIPL currently does not use it. > > > 5.2.5. SOLUTION > > Here, I suggest removing 1 byte of reserved space and the 2 byte, > echoed opaque value for the same reason presented above. The type > number could be moved to 323 (SOLUTION + 2). If we need to modify the > puzzle parameter for some reason in the future, I suggest to design a > new parameter instead of using the reserved field. That is how new > semantics are handled for any other parameter as well (see MAC_X). > > > 5.2.3. R1_COUNTER > "It SHOULD be included in the R1 (in which case, it is covered by the > signature), and if present in the R1, it MUST be echoed (including the > Reserved field verbatim) by the Initiator in the I2 packet." > > Similar to the SOLUTION parameter, I suggest removing the 4 bytes of > reserved space from the R1 counter parameter and to add +2 to the type > number (resulting in 131) for the new R1_COUNTER type. > > > I understand that these changes break parameter compatibility with > existing v1 implementations. However, I do not consider a new > parameter layout problematic as the semantics won't change > considerably allowing for code re-use in most cases. > > > Editorial changes: > ------------------------ > > 1.3. Memo Structure > "Finally, Sections 7, 8, and 9 discuss policy, security, and IANA > considerations, respectively." > > 8 and 9 lack internal references to the respective sections in the document. > > > 4.1.7. HIP Downgrade Protection > "In contrast to the first version of HIP [RFC5201],the version 2 of [...]" > > There is a space missing after the comma: > "In contrast to the first version of HIP [RFC5201], the version 2 of [...]" > > > ### HIP Header Length ### > > 5.1. Payload Format > "The Header Length field contains the combined length of the HIP > Header and HIP parameters in 8-byte units, excluding the first 8 > bytes." > > 5.2.21. ECHO_REQUEST_UNSIGNED > "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.2. R1 - the HIP Responder Packet > "The signature is calculated over the whole HIP packet, after setting > the Initiator's HIT, header checksum, as well as the Opaque field and > the Random #I in the PUZZLE parameter temporarily to zero, and > excluding any parameters that follow the signature, as described in > Section 5.2.15." > > These three sections indicate the following problem with the HIP > header length field: > The sender generates the packet, sets the header length, and > signs/MACs the packet. A middlebox afterwards adds an > ECHO_REQUEST_UNSIGNED parameter to the packet. However, this > invalidates the HIP header length information resulting in a broken > packet. If the middlebox modifies the HIP header length value, it > invalidates the signature/MAC. > > However, following the references to: > 6.4.1. HMAC Calculation > 6.4.2. Signature Calculation > ... clarifies the issue I just described: > "In the HIP header, the Header Length field value is calculated to the > beginning of the [HIP_SIGNATURE | HIP_MAC] parameter." > > Hence, I suggest the following text in Section 5.3.2 in order to > prevent misconceptions by implementors: > "The signature is calculated over the HIP packet as described in > Section 5.2.15." > > > ### References ### > > 12. References > > References to HIP-related documents refer to old revisions (e.g., > I-D.ietf-hip-cert). > > > From thomas.r.henderson@boeing.com Sun Sep 23 16:25:34 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4621F851E for ; Sun, 23 Sep 2012 16:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he5+DcuekIvN for ; Sun, 23 Sep 2012 16:25:33 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 849B821F851C for ; Sun, 23 Sep 2012 16:25:33 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8NNPWQG000415 for ; Sun, 23 Sep 2012 18:25:32 -0500 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8NNPVdv000412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 23 Sep 2012 18:25:32 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Sun, 23 Sep 2012 16:25:19 -0700 From: "Henderson, Thomas R" To: "'Julien Laganier'" , "hipsec@ietf.org" Date: Sun, 23 Sep 2012 16:25:18 -0700 Thread-Topic: [Hipsec] Status of WG items Thread-Index: Ac2YWhivjNkk4eEYSaKZjEJRn5tpSgBiI7sg Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C032@XCH-NW-16V.nw.nos.boeing.com> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> In-Reply-To: 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 X-TM-AS-MML: No Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2012 23:25:34 -0000 > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Friday, September 21, 2012 5:35 PM > To: hipsec@ietf.org > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] Status of WG items >=20 > Folks, >=20 > I've been thinking a bit more about the update of RFC5204 / Rendezvous > Server support. See below: >=20 > On Thu, Jul 5, 2012 at 5:37 PM, Julien Laganier > wrote: > > [...] > > - 5204bis (rendezvous) needs one more subsection regarding relaying > of > > the UPDATE packet to support double jump of mobile nodes. As this > > isn't really useful without the mobility support my proposal is to > > tackle this one together with the 5206bis. >=20 > I figured two things: >=20 > 1- relaying an UPDATE packet is pointless in the absence of HIP > mobility support on both endpoints. >=20 > 2- support for rendezvous server is useful independently of support for > HIP mobility. >=20 > Taking both 1. and 2. into account, my conclusion is that it makes > sense to keep the rendezvous server support self-contained in 5203bis, > i.e., without a normative dependency to the mobility support in > 5206bis, while 5206 would specify an extension to rendezvous mechanism > for support of relaying UPDATE packets. >=20 > Makes sense? >=20 Julien, I would be fine with your proposal. - Tom From thomas.r.henderson@boeing.com Sun Sep 23 17:26:18 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC8521F855E for ; Sun, 23 Sep 2012 17:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztdUvBe3VZ3g for ; Sun, 23 Sep 2012 17:26:18 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0E83021F8555 for ; Sun, 23 Sep 2012 17:26:18 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8O0Q7or006534 for ; Sun, 23 Sep 2012 17:26:07 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8O0Q6ML006531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 23 Sep 2012 17:26:07 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 23 Sep 2012 17:26:04 -0700 From: "Henderson, Thomas R" To: =?iso-8859-1?Q?=27Ren=E9_Hummen=27?= , HIP WG Date: Sun, 23 Sep 2012 17:26:04 -0700 Thread-Topic: [Hipsec] WGLCs: 4423bis and 5201bis Thread-Index: Ac2ZogzQ6A1yE1WzTd+GaK+f8UxYwgAQ/lGQ Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C033@XCH-NW-16V.nw.nos.boeing.com> References: In-Reply-To: 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-TM-AS-MML: No Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 00:26:18 -0000 Rene, thanks for this review; responses inline below: > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Ren=E9 Hummen > Sent: Sunday, September 23, 2012 8:36 AM > To: HIP WG > Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis >=20 > Hi all, >=20 > I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some > technical as well as editorial issues that I consider worth discussing > and fixing. Please note that especially the technical issues regarding > the used packet space may not be considered problematic in case of > everyday Internet connections. However, resource-constrained > environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard > payload limits. Here, a few bytes of additional packet size can > determine whether packets need to be fragmented or not. Therefore, I > think, we should also consider these scenarios in the basic HIP > specification that is shared by all HIP variants. >=20 > I structured my feedback into different topics highlight by ###. >=20 >=20 > Technical issues: > ------------------------ >=20 > ### R1 Counter ### >=20 > 4.1.4. HIP Replay Protection > "The R1 counter SHOULD NOT roll over." >=20 > No explanation is given what implementors should do when a roll over > occurs. I suggest to add the following text: >=20 > "If a roll over is detected, the associated HIs SHOULD be removed and > new ones should be generated." >=20 > Note, however, that such a change would also invalidate ACLs and HI-IP > lookup information based on the original HIs. I might suggest instead to make the invalidation of HIs to be use case depe= ndent, and point out the issues. =20 "If a roll over is detected, the associated HIs may need to be replaced if = there is concern that such roll over may impact potential initiators; howev= er, such replacement would also invalidate any other state in the network t= hat associates the HI with other identifiers." >=20 >=20 > ### HIP Checksum ### >=20 > 5.1.1. Checksum >=20 > What is the reason for using the IP-based pseudo-headers here? If I am > not overlooking something, non-HIP-aware NATs on the communication path > effectively break the HIP checksum. I know that this is the way how > TCP/IP pseudo-headers are defined. Still, I suggest to only checksum > the HIP header and the HIP parameters to avoid problems in the future > and to maintain layer separation. What happens if HIP is used in non-IP > environments? I believe that this decision was taken to be able to leverage any possible = existing checksum implementations. I am neutral about changing this as sug= gested, but wouldn't object if others supported it for non-IP reasons. I m= ight suggest at least that a statement be added here that checksum computat= ion in non-IP environments is out of scope of this document. >=20 >=20 > ### Decreasing the per-packet overhead ### >=20 > 4.1.2. Puzzle Exchange > "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an > ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an ECHO_REQUEST_UNSIGNED > parameter (see Section 5.2.21), the Responder can include some data in > R1 that the Initiator MUST copy unmodified in the corresponding I2 > packet." >=20 > 5.2.4. PUZZLE > "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 > parameter." >=20 > Especially in resource-constrained environments such as targeted by HIP > DEX, each byte that needs to be transmitted is valuable (from a power > perspective) and may lead to fragmentation at the lower layers. > Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE > parameter and to add +2 to the type number (resulting in 259) for the > new PUZZLE type. If the Responder has to transfer state in an unsigned > fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for > this purpose. Furthermore, the opaque value does not seem to be > necessary, as HIPL currently does not use it. If I understand correctly, you're suggesting a new PUZZLE type that has opa= que data (type code 259) but to remove opaque from PUZZLE? =20 >=20 >=20 > 5.2.5. SOLUTION >=20 > Here, I suggest removing 1 byte of reserved space and the 2 byte, > echoed opaque value for the same reason presented above. The type > number could be moved to 323 (SOLUTION + 2). If we need to modify the > puzzle parameter for some reason in the future, I suggest to design a > new parameter instead of using the reserved field. That is how new > semantics are handled for any other parameter as well (see MAC_X). >=20 >=20 > 5.2.3. R1_COUNTER > "It SHOULD be included in the R1 (in which case, it is covered by the > signature), and if present in the R1, it MUST be echoed (including the > Reserved field verbatim) by the Initiator in the I2 packet." >=20 > Similar to the SOLUTION parameter, I suggest removing the 4 bytes of > reserved space from the R1 counter parameter and to add +2 to the type > number (resulting in 131) for the new R1_COUNTER type. >=20 >=20 > I understand that these changes break parameter compatibility with > existing v1 implementations. However, I do not consider a new parameter > layout problematic as the semantics won't change considerably allowing > for code re-use in most cases. I don't have a major problem with your proposals to shed some bytes or intr= oduce new parameters, but won't the overhead just come back in the form of = extra padding (see 5.2.1)? Do you need to revisit this padding requirement= to accomplish your goals? >=20 >=20 > Editorial changes: > ------------------------ >=20 > 1.3. Memo Structure > "Finally, Sections 7, 8, and 9 discuss policy, security, and IANA > considerations, respectively." >=20 > 8 and 9 lack internal references to the respective sections in the > document. >=20 >=20 > 4.1.7. HIP Downgrade Protection > "In contrast to the first version of HIP [RFC5201],the version 2 of > [...]" >=20 > There is a space missing after the comma: > "In contrast to the first version of HIP [RFC5201], the version 2 of > [...]" >=20 >=20 > ### HIP Header Length ### >=20 > 5.1. Payload Format > "The Header Length field contains the combined length of the HIP Header > and HIP parameters in 8-byte units, excluding the first 8 bytes." >=20 > 5.2.21. ECHO_REQUEST_UNSIGNED > "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." >=20 > 5.3.2. R1 - the HIP Responder Packet > "The signature is calculated over the whole HIP packet, after setting > the Initiator's HIT, header checksum, as well as the Opaque field and > the Random #I in the PUZZLE parameter temporarily to zero, and > excluding any parameters that follow the signature, as described in > Section 5.2.15." >=20 > These three sections indicate the following problem with the HIP header > length field: > The sender generates the packet, sets the header length, and signs/MACs > the packet. A middlebox afterwards adds an ECHO_REQUEST_UNSIGNED > parameter to the packet. However, this invalidates the HIP header > length information resulting in a broken packet. If the middlebox > modifies the HIP header length value, it invalidates the signature/MAC. >=20 > However, following the references to: > 6.4.1. HMAC Calculation > 6.4.2. Signature Calculation > ... clarifies the issue I just described: > "In the HIP header, the Header Length field value is calculated to the > beginning of the [HIP_SIGNATURE | HIP_MAC] parameter." >=20 > Hence, I suggest the following text in Section 5.3.2 in order to > prevent misconceptions by implementors: > "The signature is calculated over the HIP packet as described in > Section 5.2.15." >=20 >=20 > ### References ### >=20 > 12. References >=20 > References to HIP-related documents refer to old revisions (e.g., I- > D.ietf-hip-cert). >=20 Thanks for these editorial fixes. - Tom From mkomu@cs.hut.fi Sun Sep 23 17:32:07 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615B721F8501 for ; Sun, 23 Sep 2012 17:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm-KfabCBTt2 for ; Sun, 23 Sep 2012 17:32:07 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id B44A821F84F5 for ; Sun, 23 Sep 2012 17:32:06 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id F34B1304E59 for ; Mon, 24 Sep 2012 03:32:04 +0300 (EEST) Message-ID: <505FAA04.90304@cs.hut.fi> Date: Mon, 24 Sep 2012 08:32:04 +0800 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <758141CC3D829043A8C3164DD3D593EA2E4C38C032@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C032@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 00:32:07 -0000 Hi, On 09/24/2012 07:25 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Julien Laganier [mailto:julien.ietf@gmail.com] >> Sent: Friday, September 21, 2012 5:35 PM >> To: hipsec@ietf.org >> Cc: Henderson, Thomas R >> Subject: Re: [Hipsec] Status of WG items >> >> Folks, >> >> I've been thinking a bit more about the update of RFC5204 / Rendezvous >> Server support. See below: >> >> On Thu, Jul 5, 2012 at 5:37 PM, Julien Laganier >> wrote: >>> [...] >>> - 5204bis (rendezvous) needs one more subsection regarding relaying >> of >>> the UPDATE packet to support double jump of mobile nodes. As this >>> isn't really useful without the mobility support my proposal is to >>> tackle this one together with the 5206bis. >> >> I figured two things: >> >> 1- relaying an UPDATE packet is pointless in the absence of HIP >> mobility support on both endpoints. >> >> 2- support for rendezvous server is useful independently of support for >> HIP mobility. >> >> Taking both 1. and 2. into account, my conclusion is that it makes >> sense to keep the rendezvous server support self-contained in 5203bis, >> i.e., without a normative dependency to the mobility support in >> 5206bis, while 5206 would specify an extension to rendezvous mechanism >> for support of relaying UPDATE packets. >> >> Makes sense? >> > > Julien, I would be fine with your proposal. seems fine to me as well. From rene.hummen@comsys.rwth-aachen.de Thu Sep 20 12:12:08 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E9321E8088 for ; Thu, 20 Sep 2012 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgntUOvZ+QX0 for ; Thu, 20 Sep 2012 12:12:08 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 96D4B21E8084 for ; Thu, 20 Sep 2012 12:12:07 -0700 (PDT) MIME-version: 1.0 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) 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 <0MAN009QQXC5KEA0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 20 Sep 2012 21:12:05 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.80,455,1344204000"; d="p7s'?scan'208,217";a="104393972" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Thu, 20 Sep 2012 21:12:06 +0200 Received: from [192.168.2.11] ([unknown] [93.129.33.127]) 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 <0MAN00HQ7XC50240@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 20 Sep 2012 21:12:05 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-type: multipart/signed; boundary="Apple-Mail=_0CEA7C10-DF43-4085-A3D2-EFE09926DE4F"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 20 Sep 2012 21:12:04 +0200 In-reply-to: <50519531.2010802@ericsson.com> To: HIP WG References: <50519531.2010802@ericsson.com> Message-id: <8975C395-05DC-4798-9EEE-A58A76687093@comsys.rwth-aachen.de> X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sun, 23 Sep 2012 23:41:59 -0700 Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2012 20:33:02 -0000 --Apple-Mail=_0CEA7C10-DF43-4085-A3D2-EFE09926DE4F Content-Type: multipart/alternative; boundary="Apple-Mail=_402EF576-4D9A-4818-BA50-67C11B7F18B0" --Apple-Mail=_402EF576-4D9A-4818-BA50-67C11B7F18B0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, On 13.09.2012, at 10:11, Gonzalo Camarillo wrote: > Folks, > > I would like to start the WGLCs on the following two drafts. These WGLCs > will end on September 30th. > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ > > In addition to technical comments, please also let the list know whether > you still care about these specifications. Given the low level of energy > in the WG, one of the issues the IESG will evaluate will be whether > there is still enough interest behind all these bis documents. > > Please, send your comments to this mailing list. I'll have a look at the documents during this weekend. -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_402EF576-4D9A-4818-BA50-67C11B7F18B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks,

I would like to start the WGLCs on the = following two drafts. These WGLCs
will end on September = 30th.

http= s://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/
https://da= tatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/

In addition to = technical comments, please also let the list know whether
you still = care about these specifications. Given the low level of energy
in the = WG, one of the issues the IESG will evaluate will be whether
there is = still enough interest behind all these bis documents.

Please, = send your comments to this mailing = list.

I'll have a look at the = documents during this weekend.
http://www.com= sys.rwth-aachen.de/team/rene-hummen/

= --Apple-Mail=_402EF576-4D9A-4818-BA50-67C11B7F18B0-- --Apple-Mail=_0CEA7C10-DF43-4085-A3D2-EFE09926DE4F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MjAxOTEyMDVaMCMGCSqGSIb3DQEJBDEWBBSpvTJU+XLb hCd5r4suWgsBVo27bjB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQAfL/57+KNp EXxprBl9tPMSkjqH7qDoodXk8e7b5r0/onnByNogPgF5Cro0W/wLJ26FxgyOQGAZ9uIzRrxNOrNx 4isHWKp2s6NJ2u+iiqlw/97IM+sjY7LSoM7x5qKsaiXUxSwLeAGmv4C2KiQgp9Dyyiic1E93aO7B +nDxbHiLkH8/lDbHE0YTmT1vUQQiHN3cUViJJTYFHUug5GbuAuAlXJO4ERE0Soliepb+5HJQLkMc xhmv5x+MGvYGk/NWu3/nraX05reUFOHSvv6o2hnZlGdBUCs4udt/fG5PtZnWPk9JQG+1VGZ2Uwd7 iXAxfXRPLZatE8SElNXMY6MvF510AAAAAAAA --Apple-Mail=_0CEA7C10-DF43-4085-A3D2-EFE09926DE4F-- From julien.ietf@gmail.com Mon Sep 24 07:48:14 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6499221F84B2 for ; Mon, 24 Sep 2012 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksbqRhoimSIM for ; Mon, 24 Sep 2012 07:48:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3621F846D for ; Mon, 24 Sep 2012 07:48:13 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so1805441pbb.31 for ; Mon, 24 Sep 2012 07:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=q/AMW7xkLD94hGJ5HpmRJhZhsS0rslllkV5TWM7bkPU=; b=sUUMtN8AXuBeiwFf+e0/n+SVi6oFOLF59Sbw//qz/BBJ2DsMprVf9P09L8s1TTd2L5 lENU2+ZAeHn14rwjDk3GrjoOz3/49rib1Q7FpJwhFBRnA/gbyYfs4LbaTeLraTwk1x3y E+yBTqmg72wwMB1xfzOh0ClCjYUW8EwTK1cpdwfxIniGoOgBfjxSEt93Vet0Y0lbQ6CV aPenJoTQTwndJfZQXFl41QQszTzQJyFrHAoaEd/WsyhISkMnasW6hU399RjcJHydy4uF 3dXXy/dCg3dP7Ryb+/RFyPQvMiT9Go11KkH9f0FCnvIpFGzASEpCj+o0jV5QgguL8AM7 BWRg== MIME-Version: 1.0 Received: by 10.68.240.36 with SMTP id vx4mr37283515pbc.89.1348498088430; Mon, 24 Sep 2012 07:48:08 -0700 (PDT) Received: by 10.68.12.130 with HTTP; Mon, 24 Sep 2012 07:48:08 -0700 (PDT) In-Reply-To: References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> Date: Mon, 24 Sep 2012 07:48:08 -0700 Message-ID: From: Julien Laganier To: Gonzalo Camarillo , Ari Keranen , HIP Content-Type: text/plain; charset=ISO-8859-1 Subject: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2012 14:48:14 -0000 Hi Gonzalo, all, So if we include in the registration a dependency towards the standard tracks HIP certificates draft (that doesn't exist yet) we would be tying the two together such that the registration can't be published before the HIP certificate RFC is. An alternative would be to move ahead with the current registration draft without specific dependency on HIP certificates but leaving the door open for these to be used once they are defined in standard track; the current draft and RFC already have hooks for authentication means beyond HIT authentication: In particular, REG_FAILED with a failure type of zero indicates the service(s) type(s) that require further credentials for registration. If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to register again with the service after the HIP association has been established. The precise means of establishing and verifying credentials are beyond the scope of this document and are expected to be defined in other documents. Would that be an appropriate way forward? --julien On Fri, Sep 21, 2012 at 1:11 AM, Gonzalo Camarillo wrote: > Hi Julien, > > my take on this is that we need to produce a standards-track document > specifying exactly that. This is what our charter says about it: > > https://datatracker.ietf.org/wg/hip/charter/ > >> o Specify in a standards track RFC how to carry certificates in the >> base exchange. This was removed from the base HIP spec so that the >> mechanism is specified in a stand-alone spec. > > Cheers, > > Gonzalo > > On 21/09/2012 2:49 AM, Julien Laganier wrote: >> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >>> Hi Julien, >>> >>> >>> On 7/6/12 3:37 AM, Julien Laganier wrote: >>>> >>>> - 5203bis (registration) can IMHO be republished as is as I haven't >>>> seen any issue with the original version. If people agree I could >>>> republish it and we could WGLC it... >>> >>> >>> I posted some comments about 5203bis earlier this year but back then there >>> was no discussion regarding them. So, here goes again. >>> >>> Some of these have been discussed also earlier on this list (these relate to >>> requirements discovered with the native NAT traversal draft [1]), but I'll >>> have them all here for easier reference. >>> >>> Currently, the registrar has no way of indicating that it would otherwise >>> accept the registration, but it's currently running low on resources. For >>> this purpose, a failure type "Insufficient resources" could be added to the >>> "registration failure types". >>> >>> Registration using authentication with certificates could be part of the >>> registration RFC. Currently, only authentication with HI is defined, but >>> knowing all HIs beforehand is not practical in many cases. >>> >>> Text in section 3.2. of [1] could be used as a basis for this (just replace >>> "HIP' data relay" with "registrar"). Also, if this authentication mode is >>> added to the draft, failure type "Invalid certificate" should be added for >>> the failure case. >>> >>> Should we have these in the registration draft? >>> >>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >> >> I was going to shamelessly copy/paste section 3.2 of [1] in the >> registration draft but I noticed that [1] actually has a normative >> dependency on RFC 6253 "Host Identity Protocol Certificates" which is >> Experimental. Thus adding the support for certificates to a standard >> track HIP registration would cause a so-called downref which could be >> problematic... >> >> Gonzalo - what is your take on this? >> >> --julien >> > From gonzalo.camarillo@ericsson.com Tue Sep 25 00:26:15 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3F21F890F for ; Tue, 25 Sep 2012 00:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS90K9M9BdEi for ; Tue, 25 Sep 2012 00:26:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67D6D21F890C for ; Tue, 25 Sep 2012 00:26:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-92-50615c943613 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B9.5E.11467.49C51605; Tue, 25 Sep 2012 09:26:12 +0200 (CEST) Received: from [131.160.36.30] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Tue, 25 Sep 2012 09:26:12 +0200 Message-ID: <50615C93.6090300@ericsson.com> Date: Tue, 25 Sep 2012 10:26:11 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Julien Laganier References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre6UmMQAg33TVSza3vxis5i6aDKz xZej05gdmD12zrrL7rFkyU8mj85F0QHMUVw2Kak5mWWpRfp2CVwZi5f2sxW8UqiY/e0bYwPj fKkuRk4OCQETiY53DYwQtpjEhXvr2boYuTiEBE4xSlw4cp8VwlnNKLH4+jsmkCpeAW2JW3+v gNksAqoST3pPg9lsAhYSW27dZwGxRQWCJc5t3MYGUS8ocXLmE7C4CFDvqUkNYDazgLPEvr0/ 2UFsYQFdiUOn7zKD2EICb5glJn4UAbE5BQIlls6YwgxxnaTEm8k3oXr1JKZcbWGEsOUltr+d A9WrLbH8WQvLBEahWUhWz0LSMgtJywJG5lWMwrmJmTnp5YZ6qUWZycXF+Xl6xambGIFhfXDL b90djKfOiRxilOZgURLn5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMfvnzv1/XoRr C9vEc7YlXDDvzXCbtuqRl71Wu6ZXj+7L8vN7bPb7CLzsUeY63yH8TbpF/tfUM/73b8oW7Gya cZth67tfV34Ibtt2VdL/u4zChAfHG88/zJzHvueo/9I1cz3t07WeRNSd1OIS0JxUW3u2on/B Tf2DovPDpoffsdC10njEuHCqtxJLcUaioRZzUXEiAKXv24g5AgAA Cc: HIP Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2012 07:26:15 -0000 Hi, if we have the appropriate hooks in the main specs, we could do as you suggest. I would be interested in hearing more opinions, though. Cheers, Gonzalo On 24/09/2012 5:48 PM, Julien Laganier wrote: > Hi Gonzalo, all, > > So if we include in the registration a dependency towards the standard > tracks HIP certificates draft (that doesn't exist yet) we would be > tying the two together such that the registration can't be published > before the HIP certificate RFC is. > > An alternative would be to move ahead with the current registration > draft without specific dependency on HIP certificates but leaving the > door open for these to be used once they are defined in standard > track; the current draft and RFC already have hooks for authentication > means beyond HIT authentication: > > > In particular, > REG_FAILED with a failure type of zero indicates the service(s) > type(s) that require further credentials for registration. > > If the registrar requires further authorization and the requester has > additional credentials available, the requester SHOULD try to > register again with the service after the HIP association has been > established. The precise means of establishing and verifying > credentials are beyond the scope of this document and are expected to > be defined in other documents. > > Would that be an appropriate way forward? > > --julien > > On Fri, Sep 21, 2012 at 1:11 AM, Gonzalo Camarillo > wrote: >> Hi Julien, >> >> my take on this is that we need to produce a standards-track document >> specifying exactly that. This is what our charter says about it: >> >> https://datatracker.ietf.org/wg/hip/charter/ >> >>> o Specify in a standards track RFC how to carry certificates in the >>> base exchange. This was removed from the base HIP spec so that the >>> mechanism is specified in a stand-alone spec. >> >> Cheers, >> >> Gonzalo >> >> On 21/09/2012 2:49 AM, Julien Laganier wrote: >>> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >>>> Hi Julien, >>>> >>>> >>>> On 7/6/12 3:37 AM, Julien Laganier wrote: >>>>> >>>>> - 5203bis (registration) can IMHO be republished as is as I haven't >>>>> seen any issue with the original version. If people agree I could >>>>> republish it and we could WGLC it... >>>> >>>> >>>> I posted some comments about 5203bis earlier this year but back then there >>>> was no discussion regarding them. So, here goes again. >>>> >>>> Some of these have been discussed also earlier on this list (these relate to >>>> requirements discovered with the native NAT traversal draft [1]), but I'll >>>> have them all here for easier reference. >>>> >>>> Currently, the registrar has no way of indicating that it would otherwise >>>> accept the registration, but it's currently running low on resources. For >>>> this purpose, a failure type "Insufficient resources" could be added to the >>>> "registration failure types". >>>> >>>> Registration using authentication with certificates could be part of the >>>> registration RFC. Currently, only authentication with HI is defined, but >>>> knowing all HIs beforehand is not practical in many cases. >>>> >>>> Text in section 3.2. of [1] could be used as a basis for this (just replace >>>> "HIP' data relay" with "registrar"). Also, if this authentication mode is >>>> added to the draft, failure type "Invalid certificate" should be added for >>>> the failure case. >>>> >>>> Should we have these in the registration draft? >>>> >>>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >>> >>> I was going to shamelessly copy/paste section 3.2 of [1] in the >>> registration draft but I noticed that [1] actually has a normative >>> dependency on RFC 6253 "Host Identity Protocol Certificates" which is >>> Experimental. Thus adding the support for certificates to a standard >>> track HIP registration would cause a so-called downref which could be >>> problematic... >>> >>> Gonzalo - what is your take on this? >>> >>> --julien >>> >> > > From mattes@asguardnetworks.com Wed Sep 26 15:10:20 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7221F8587 for ; Wed, 26 Sep 2012 15:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdU1v1TEGKFk for ; Wed, 26 Sep 2012 15:10:20 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB31A21F853F for ; Wed, 26 Sep 2012 15:10:19 -0700 (PDT) Received: by padfb11 with SMTP id fb11so806275pad.31 for ; Wed, 26 Sep 2012 15:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=6HyrMrp873lxX89K28CLkvzkFjCTUqEYrE0JSe8ciqU=; b=AqKSJ9ZabmddO3y+jYKBx9kMN/HKcxoAEMgsRz/QsrsM8A37pXg19Oy3WohyCq08cX TMW0KdPL2vwY9i09Kh4ZdjCRKvtseiTQ+fctz7erZnzDZL9S0OiPrFU5GrwfrkKXQOes pltIeotQVJPuwBknTCmXrPiTgFolm80f097oT/p6Ul5wY6eoh5xZ6WudUfRECzCK/l8+ +YrJQPRX2a66Dy8X61vWRbjqV7I95haP/XE5ay7rhZNe0bEZHjG9SczJYO/5/a0ihGjX 16/tS8wXtp4Y9RrM23hM5V+buLRfpVSTyktEqDm94JB6i4ZcVlcFK+LEzSKunQByiXIf hoew== MIME-Version: 1.0 Received: by 10.68.241.232 with SMTP id wl8mr5963803pbc.112.1348697419338; Wed, 26 Sep 2012 15:10:19 -0700 (PDT) Received: by 10.68.237.225 with HTTP; Wed, 26 Sep 2012 15:10:19 -0700 (PDT) X-Originating-IP: [24.18.182.182] Date: Wed, 26 Sep 2012 15:10:19 -0700 Message-ID: From: David Mattes To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmfsAnwF3qYfj0Y36SMW/VhRUa9LUtzylu4OLBWSGpz0Zl9z0IOPQ+0IEk/aF+GwM6/TvsT Subject: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2012 22:12:47 -0000 Hi, I have read both 4423bis and 5201bis and think they are ready to publish. As a company developing network security products based on HIP, Asguard Networks is very excited to see HIP make the step towards published standard. Regards, David -- David Mattes Founder, Asguard Networks 425-213-4691 http://asguardnetworks.com From thomas.r.henderson@boeing.com Wed Sep 26 21:27:33 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E81021F864A for ; Wed, 26 Sep 2012 21:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELSlCyTPgIcU for ; Wed, 26 Sep 2012 21:27:32 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC821F8646 for ; Wed, 26 Sep 2012 21:27:31 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8R4RJax022228 for ; Wed, 26 Sep 2012 21:27:19 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8R4RI4L022225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 26 Sep 2012 21:27:18 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 26 Sep 2012 21:27:12 -0700 From: "Henderson, Thomas R" To: HIP WG Date: Wed, 26 Sep 2012 21:27:11 -0700 Thread-Topic: review of RFC4423-bis Thread-Index: Ac2b+tKxlyO0CHdLQAKcXvk7mpYJMAAFpwxQABV/t4A= Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C07D@XCH-NW-16V.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 X-TM-AS-MML: No Subject: [Hipsec] review of RFC4423-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 04:27:33 -0000 I had another read through of http://datatracker.ietf.org/doc/draft-ietf-hi= p-rfc4423-bis/ I think it is nearly ready to publish; the main substantive comments that I= have are: 1) Section 13 (Changes from RFC 4423) is incomplete as written; it should e= ither be completed or deleted 2) it would be nice to describe how host identifiers are intended to be rev= oked/replaced over time. However, the current text in Section 1 seems to b= e restrictive in this regard (more on this below). 3) it would be nice to go into a bit more detail of how HIP relates to mult= icast Regarding whether it should be published as Informational or PS RFC, I don'= t have a strong opinion. I guess I would lean towards Informational since = it is not normative specification, but I would yield to whatever is best cu= rrent practice in the IETF for documents such as these. - Tom Detailed comments below: Section 1 (Introduction) > There is exactly one Host Identifier for each Host Identity. This document does not talk about replacing Host Identifiers over time; sho= uld it? Also, couldn't multiple keys be associated with the same Identity = (computing stack)? I wonder whether this statement is too restrictive, esp= ecially since one can imagine times in which keys are replaced and two Host= Identifiers may be active at the same time. Section 2 (Terminology) > (Public key) Used as a publicly known identifier for cryptographic ident= ity authentication.=20 Does it need to be publicly known? See later "Unpublished Host Identifier"= definition. Suggest "(typically publicly known)" instead. Section 3 (Background) > IP numbers suggest "IP addresses" instead (many places in this section) Section 4 (Host Identity namespace) > As will be specified in the Host Identity Protocol Base EXchange (BEX) [R= FC5201-bis] specification Suggest instead: "As specified in the Host Identity Protocol [RFC5201-bis]= specification Section 4.1 (Host Identifiers) > The actual Host Identities are never directly used in any Internet pro= tocols. I believe that this should instead be Identifier (Identities are abstract). Section 4.2 (Host Identity Hash) > It is possible to for the two Hosts in the HIP exchange to use different = hashes. Suggest "It is possible for the two hosts..." Section 4.3 (Host Identity Tag) s/perfers/prefers Section 5 (New stack architecture) > As discussed above, the IP addresses can be seen to be a confounding of r= outing direction vectors and interface names. Is it routing direction vectors, or endpoint (or stack) names? Is "routing= direction vector" terminology used elsewhere; if so, suggest to add a refe= rence, if not, suggest to change to end-point names. Section 7 (HIP and ESP) > As adding a new naming layer allows one to potentially add a new forwardi= ng layer (see Section 9, below), it is very important that the HIP provides= mechanisms for middlebox authentication. Perhaps add reference to RFC 5207 here? s/consistant/consistent > It should be noted that there are already BITW implementations. Perhaps a clarification here: "It should be noted that there are already B= ITW implementations of HIP providing virtual private network (VPN) services= ." Section 10 (Multicast) > Since its inception, a few studies have looked at how HIP might affect= IP-layer or application-layer multicast. IMO, this section should be expanded with some more commentary about how HI= P applies to multicast. In particular, how amenable are multicast key mana= gement protocols and security associations to being able to leverage HIP? = Would HITs ever be put into source or destination address fields of multica= st datagrams? Section 13 (Changes from RFC 4423) This section is not yet completed. Either complete or delete. Section 14 (Security considerations) > There are more details on this process in the Host Identity Protocol unde= r development. Suggest to strike "under development" since the HIP protocol has now been d= eveloped. > There has been no attempt to develop a secure method to issue the HIT rev= ocation notice. This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to re= phrase. From internet-drafts@ietf.org Thu Sep 27 00:47:20 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43521F86A4; Thu, 27 Sep 2012 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vkEv4Q6ACH5; Thu, 27 Sep 2012 00:47:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122F721F849B; Thu, 27 Sep 2012 00:47:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120927074720.4774.40995.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2012 00:47:20 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5202-bis-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 07:47:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Using the Encapsulating Security Payload (ESP) Transport= Format with the Host Identity Protocol (HIP) Author(s) : Petri Jokela Robert Moskowitz Jan Melen Filename : draft-ietf-hip-rfc5202-bis-01.txt Pages : 36 Date : 2012-09-27 Abstract: This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5202-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5202-bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rgm@htt-consult.com Thu Sep 27 06:07:40 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577D321F8504 for ; Thu, 27 Sep 2012 06:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzTIk-AoprsN for ; Thu, 27 Sep 2012 06:07:39 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3F25A21F844F for ; Thu, 27 Sep 2012 06:07:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EFF9462A8C; Thu, 27 Sep 2012 13:07:10 +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 ezoPmm7rBHp2; Thu, 27 Sep 2012 09:06:51 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 9877162A66; Thu, 27 Sep 2012 09:06:50 -0400 (EDT) Message-ID: <50644F67.7060000@htt-consult.com> Date: Thu, 27 Sep 2012 09:06:47 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <758141CC3D829043A8C3164DD3D593EA2E4C38C07D@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C07D@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] review of RFC4423-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 13:07:40 -0000 Great review. Thank you. Just some quick notes (Hoiidays through Oct 11 and I only have a few work hours until then and I got kicked out of my office as it is also a guest room; working in my NOC). On 09/27/2012 12:27 AM, Henderson, Thomas R wrote: > I had another read through of http://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > > I think it is nearly ready to publish; the main substantive comments that I have are: > > 1) Section 13 (Changes from RFC 4423) is incomplete as written; it should either be completed or deleted What did I miss? :) Problem is I did it after changes and I am not good at remembering all I changed :( So if you can help me, great. If the concensus is to delete it, I gladly will. > > 2) it would be nice to describe how host identifiers are intended to be revoked/replaced over time. However, the current text in Section 1 seems to be restrictive in this regard (more on this below). Can add a few words here. It is almost an anything goes within a framework. A sensor will probably never get its HI revoked/replaced. Running out of counter is a good reason to r/r, or just on general principles. > > 3) it would be nice to go into a bit more detail of how HIP relates to multicast And I am NOT well versed on multicast and would need help here. Basically we can have HIs for multicast, but what do we have in a multicast KMP? I guess I should read the RFC again! > > Regarding whether it should be published as Informational or PS RFC, I don't have a strong opinion. I guess I would lean towards Informational since it is not normative specification, but I would yield to whatever is best current practice in the IETF for documents such as these. Same here. These sorts of RFCs have traditionally been informational. Don't know what the current IESG position is. > > - Tom > > Detailed comments below: > > > Section 1 (Introduction) > >> There is exactly one Host Identifier for each Host Identity. > This document does not talk about replacing Host Identifiers over time; should it? Also, couldn't multiple keys be associated with the same Identity (computing stack)? I wonder whether this statement is too restrictive, especially since one can imagine times in which keys are replaced and two Host Identifiers may be active at the same time. > > Section 2 (Terminology) > >> (Public key) Used as a publicly known identifier for cryptographic identity authentication. > Does it need to be publicly known? See later "Unpublished Host Identifier" definition. Suggest "(typically publicly known)" instead. > > Section 3 (Background) > >> IP numbers > suggest "IP addresses" instead (many places in this section) > > Section 4 (Host Identity namespace) > >> As will be specified in the Host Identity Protocol Base EXchange (BEX) [RFC5201-bis] specification > Suggest instead: "As specified in the Host Identity Protocol [RFC5201-bis] specification > > Section 4.1 (Host Identifiers) > >> The actual Host Identities are never directly used in any Internet protocols. > I believe that this should instead be Identifier (Identities are abstract). > > Section 4.2 (Host Identity Hash) > >> It is possible to for the two Hosts in the HIP exchange to use different hashes. > Suggest "It is possible for the two hosts..." > > Section 4.3 (Host Identity Tag) > > s/perfers/prefers > > Section 5 (New stack architecture) > >> As discussed above, the IP addresses can be seen to be a confounding of routing direction vectors and interface names. > Is it routing direction vectors, or endpoint (or stack) names? Is "routing direction vector" terminology used elsewhere; if so, suggest to add a reference, if not, suggest to change to end-point names. > > Section 7 (HIP and ESP) > >> As adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is very important that the HIP provides mechanisms for middlebox authentication. > Perhaps add reference to RFC 5207 here? > > s/consistant/consistent > >> It should be noted that there are already BITW implementations. > Perhaps a clarification here: "It should be noted that there are already BITW implementations of HIP providing virtual private network (VPN) services." > > Section 10 (Multicast) > >> Since its inception, a few studies have looked at how HIP might affect IP-layer or application-layer multicast. > IMO, this section should be expanded with some more commentary about how HIP applies to multicast. In particular, how amenable are multicast key management protocols and security associations to being able to leverage HIP? Would HITs ever be put into source or destination address fields of multicast datagrams? > > Section 13 (Changes from RFC 4423) > > This section is not yet completed. Either complete or delete. > > Section 14 (Security considerations) > >> There are more details on this process in the Host Identity Protocol under development. > Suggest to strike "under development" since the HIP protocol has now been developed. > >> There has been no attempt to develop a secure method to issue the HIT revocation notice. > This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to rephrase. > > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Thu Sep 27 12:08:52 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8A621F869E for ; Thu, 27 Sep 2012 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY0pjhPrcPhh for ; Thu, 27 Sep 2012 12:08:51 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 69F2821F8665 for ; Thu, 27 Sep 2012 12:08:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D87AC62A6B; Thu, 27 Sep 2012 19:08:29 +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 UKpq3fL8Ewsg; Thu, 27 Sep 2012 15:08:18 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id AED0962A62; Thu, 27 Sep 2012 15:08:18 -0400 (EDT) Message-ID: <5064A422.70408@htt-consult.com> Date: Thu, 27 Sep 2012 15:08:18 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?UTF-8?B?UmVuw6kgSHVtbWVu?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: HIP WG Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 19:08:52 -0000 On 09/23/2012 11:35 AM, René Hummen wrote: > Hi all, > > I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some > technical as well as editorial issues that I consider worth discussing > and fixing. Please note that especially the technical issues regarding > the used packet space may not be considered problematic in case of > everyday Internet connections. However, resource-constrained > environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard > payload limits. Here, a few bytes of additional packet size can > determine whether packets need to be fragmented or not. Therefore, I > think, we should also consider these scenarios in the basic HIP > specification that is shared by all HIP variants. > > I structured my feedback into different topics highlight by ###. > > > Technical issues: > ------------------------ > > ### R1 Counter ### > > 4.1.4. HIP Replay Protection > "The R1 counter SHOULD NOT roll over." > > No explanation is given what implementors should do when a roll over > occurs. I suggest to add the following text: > > "If a roll over is detected, the associated HIs SHOULD be removed and > new ones should be generated." > > Note, however, that such a change would also invalidate ACLs and HI-IP > lookup information based on the original HIs. Well it would take a lot of HIP packets to roll over, but I guess I can see it on a big server. So thought for implementing. I can see the recommended behaviour. > > > ### HIP Checksum ### > > 5.1.1. Checksum > > What is the reason for using the IP-based pseudo-headers here? If I am > not overlooking something, non-HIP-aware NATs on the communication > path effectively break the HIP checksum. I know that this is the way > how TCP/IP pseudo-headers are defined. Still, I suggest to only > checksum the HIP header and the HIP parameters to avoid problems in > the future and to maintain layer separation. What happens if HIP is > used in non-IP environments? Others can best comment on this. > > > ### Decreasing the per-packet overhead ### This is a great proposal, but we would have to net out the actual impact of these changes. First for BEX: Work with ECDSA p-256 HIs and ECDH p-256. Need to use (x,y) coordinate formats for both. What other parameters do we need to 'set' to get to actual packet size. Then give the packet size and see what we save. For DEX it is a bit simpler, but need to go through the same exercise. At this point I am reluctant to make a general change for BEX. Perhaps a specific variant of each of these for DEX (as I have already have had to make other changes). > > 4.1.2. Puzzle Exchange > "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an > ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an > ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder > can include some data in R1 that the Initiator MUST copy unmodified in > the corresponding I2 packet." > > 5.2.4. PUZZLE > "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 > parameter." > > Especially in resource-constrained environments such as targeted by > HIP DEX, each byte that needs to be transmitted is valuable (from a > power perspective) and may lead to fragmentation at the lower layers. > Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE > parameter and to add +2 to the type number (resulting in 259) for the > new PUZZLE type. If the Responder has to transfer state in an unsigned > fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for > this purpose. Furthermore, the opaque value does not seem to be > necessary, as HIPL currently does not use it. > > > 5.2.5. SOLUTION > > Here, I suggest removing 1 byte of reserved space and the 2 byte, > echoed opaque value for the same reason presented above. The type > number could be moved to 323 (SOLUTION + 2). If we need to modify the > puzzle parameter for some reason in the future, I suggest to design a > new parameter instead of using the reserved field. That is how new > semantics are handled for any other parameter as well (see MAC_X). > > > 5.2.3. R1_COUNTER > "It SHOULD be included in the R1 (in which case, it is covered by the > signature), and if present in the R1, it MUST be echoed (including the > Reserved field verbatim) by the Initiator in the I2 packet." > > Similar to the SOLUTION parameter, I suggest removing the 4 bytes of > reserved space from the R1 counter parameter and to add +2 to the type > number (resulting in 131) for the new R1_COUNTER type. > > > I understand that these changes break parameter compatibility with > existing v1 implementations. However, I do not consider a new > parameter layout problematic as the semantics won't change > considerably allowing for code re-use in most cases. > > > Editorial changes: > ------------------------ thanks for these, I will work with my co-authors on them. > > 1.3. Memo Structure > "Finally, Sections 7, 8, and 9 discuss policy, security, and IANA > considerations, respectively." > > 8 and 9 lack internal references to the respective sections in the document. > > > 4.1.7. HIP Downgrade Protection > "In contrast to the first version of HIP [RFC5201],the version 2 of [...]" > > There is a space missing after the comma: > "In contrast to the first version of HIP [RFC5201], the version 2 of [...]" > > > ### HIP Header Length ### > > 5.1. Payload Format > "The Header Length field contains the combined length of the HIP > Header and HIP parameters in 8-byte units, excluding the first 8 > bytes." > > 5.2.21. ECHO_REQUEST_UNSIGNED > "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.2. R1 - the HIP Responder Packet > "The signature is calculated over the whole HIP packet, after setting > the Initiator's HIT, header checksum, as well as the Opaque field and > the Random #I in the PUZZLE parameter temporarily to zero, and > excluding any parameters that follow the signature, as described in > Section 5.2.15." > > These three sections indicate the following problem with the HIP > header length field: > The sender generates the packet, sets the header length, and > signs/MACs the packet. A middlebox afterwards adds an > ECHO_REQUEST_UNSIGNED parameter to the packet. However, this > invalidates the HIP header length information resulting in a broken > packet. If the middlebox modifies the HIP header length value, it > invalidates the signature/MAC. > > However, following the references to: > 6.4.1. HMAC Calculation > 6.4.2. Signature Calculation > ... clarifies the issue I just described: > "In the HIP header, the Header Length field value is calculated to the > beginning of the [HIP_SIGNATURE | HIP_MAC] parameter." > > Hence, I suggest the following text in Section 5.3.2 in order to > prevent misconceptions by implementors: > "The signature is calculated over the HIP packet as described in > Section 5.2.15." Again thank you and will review with co-authors. > > > ### References ### > > 12. References > > References to HIP-related documents refer to old revisions (e.g., > I-D.ietf-hip-cert). oops. Thanks. will fix. (and there might be a -bis on that, we shall see). From rgm@htt-consult.com Fri Sep 28 08:35:31 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3A221F8613 for ; Fri, 28 Sep 2012 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCjBZe7hfONc for ; Fri, 28 Sep 2012 08:35:30 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7B721F8574 for ; Fri, 28 Sep 2012 08:35:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 54FE162A82; Fri, 28 Sep 2012 15:35:02 +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 xBFnDZossnQX; Fri, 28 Sep 2012 11:34:51 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 682B362A6B; Fri, 28 Sep 2012 11:34:51 -0400 (EDT) Message-ID: <5065C39A.4000303@htt-consult.com> Date: Fri, 28 Sep 2012 11:34:50 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <758141CC3D829043A8C3164DD3D593EA2E4C38C07D@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C07D@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] review of RFC4423-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 15:35:31 -0000 I will publish an ID today with all changes so far. Given my Holiday schedule through the 10th, I want to keep things current. Will take a bit to work through a couple of these recommendations, but here is most: On 09/27/2012 12:27 AM, Henderson, Thomas R wrote: > I had another read through of http://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > > I think it is nearly ready to publish; the main substantive comments that I have are: > > 1) Section 13 (Changes from RFC 4423) is incomplete as written; it should either be completed or deleted > > 2) it would be nice to describe how host identifiers are intended to be revoked/replaced over time. However, the current text in Section 1 seems to be restrictive in this regard (more on this below). > > 3) it would be nice to go into a bit more detail of how HIP relates to multicast > > Regarding whether it should be published as Informational or PS RFC, I don't have a strong opinion. I guess I would lean towards Informational since it is not normative specification, but I would yield to whatever is best current practice in the IETF for documents such as these. > > - Tom > > Detailed comments below: > > > Section 1 (Introduction) > >> There is exactly one Host Identifier for each Host Identity. > This document does not talk about replacing Host Identifiers over time; should it? Also, couldn't multiple keys be associated with the same Identity (computing stack)? I wonder whether this statement is too restrictive, especially since one can imagine times in which keys are replaced and two Host Identifiers may be active at the same time. Yes, this is 'old'. With all the key algorithms and hashs, there will be more than one. But I will have to think about the difference here being discussed between Identifier and Identity. I will add to this in the next couple weeks; what with my holiday schedule. > > Section 2 (Terminology) > >> (Public key) Used as a publicly known identifier for cryptographic identity authentication. > Does it need to be publicly known? See later "Unpublished Host Identifier" definition. Suggest "(typically publicly known)" instead. I have added the following to the Explanation: "Public is a relative term here, ranging from known to peers only to known to the World." > > Section 3 (Background) > >> IP numbers > suggest "IP addresses" instead (many places in this section) Made this change but specifically changed: "IP addresses are numbers that name networking interfaces" > > Section 4 (Host Identity namespace) > >> As will be specified in the Host Identity Protocol Base EXchange (BEX) [RFC5201-bis] specification > Suggest instead: "As specified in the Host Identity Protocol [RFC5201-bis] specification Thanks. Hard to catch all of these tense changes that were necessitated due to the original IETF environment. > > Section 4.1 (Host Identifiers) > >> The actual Host Identities are never directly used in any Internet protocols. > I believe that this should instead be Identifier (Identities are abstract). Changed. > > Section 4.2 (Host Identity Hash) > >> It is possible to for the two Hosts in the HIP exchange to use different hashes. > Suggest "It is possible for the two hosts..." Changed. > > Section 4.3 (Host Identity Tag) > > s/perfers/prefers Fixed. > > Section 5 (New stack architecture) > >> As discussed above, the IP addresses can be seen to be a confounding of routing direction vectors and interface names. > Is it routing direction vectors, or endpoint (or stack) names? Is "routing direction vector" terminology used elsewhere; if so, suggest to add a reference, if not, suggest to change to end-point names. "Routing direction vector" is right. This was highly debated back in the beginning. It is the part of IP addressing that is tied into the routing infrastructure. The people behind this distinct terminology have scattered to the winds. I can work out an expansion of this term. I will check with my routing colleagues. As for EIDs, it is not even Interface names. EIDs are higher stack things like HITs! > > Section 7 (HIP and ESP) > >> As adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is very important that the HIP provides mechanisms for middlebox authentication. > Perhaps add reference to RFC 5207 here? Or should it go in Section 9? > > s/consistant/consistent fixed. > >> It should be noted that there are already BITW implementations. > Perhaps a clarification here: "It should be noted that there are already BITW implementations of HIP providing virtual private network (VPN) services." Done. > > Section 10 (Multicast) > >> Since its inception, a few studies have looked at how HIP might affect IP-layer or application-layer multicast. > IMO, this section should be expanded with some more commentary about how HIP applies to multicast. In particular, how amenable are multicast key management protocols and security associations to being able to leverage HIP? Would HITs ever be put into source or destination address fields of multicast datagrams? Need help here from some multicast people... > > Section 13 (Changes from RFC 4423) > > This section is not yet completed. Either complete or delete. Got a decent diff tool? Otherwise I will drop it. > > Section 14 (Security considerations) > >> There are more details on this process in the Host Identity Protocol under development. > Suggest to strike "under development" since the HIP protocol has now been developed. Done. > >> There has been no attempt to develop a secure method to issue the HIT revocation notice. > This is no longer true due to draft-irtf-hiprg-revocation-05; suggest to rephrase. Yes, but what is the status of this? Will it hold up the RFC while we wait for it to come out as an RFC? I can same something like: "There has been research in developing a secure method to issue the HIT revocation notice." From internet-drafts@ietf.org Fri Sep 28 12:56:06 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338A121F8604; Fri, 28 Sep 2012 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAqmDuoepV6h; Fri, 28 Sep 2012 12:56:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9630F21F85DA; Fri, 28 Sep 2012 12:56:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928195605.27391.56416.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 12:56:05 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2012 19:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Host Identity Protocol Architecture Author(s) : Robert Moskowitz Filename : draft-ietf-hip-rfc4423-bis-05.txt Pages : 27 Date : 2012-09-28 Abstract: This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4423-bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gonzalo.camarillo@ericsson.com Sun Sep 30 00:24:32 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD321F853D for ; Sun, 30 Sep 2012 00:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u2noK3c7got for ; Sun, 30 Sep 2012 00:24:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE721F8528 for ; Sun, 30 Sep 2012 00:24:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-19-5067f3aec22e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.A8.25676.EA3F7605; Sun, 30 Sep 2012 09:24:30 +0200 (CEST) Received: from [131.160.126.221] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 30 Sep 2012 09:24:29 +0200 Message-ID: <5067F3AD.3030001@ericsson.com> Date: Sun, 30 Sep 2012 10:24:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre66z+kBBu9aRS2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDu3frIXXGCseHfqBGsD43zGLkZODgkBE4mmu2+gbDGJC/fW s3UxcnEICZxilDg95xIThLOWUaJ99W/WLkYODl4BbYmdbQUgDSwCqhIdN7+xgdhsAhYSW27d ZwGxRQWCJc5t3AYW5xUQlDg58wlYXERAUqLn7lIwWxio9/LOQ8wQiyUl3ky+CRZnFtCTmHK1 hRHClpfY/nYOWI0Q0Nrlz1pYJjDyz0IydhaSlllIWhYwMq9iFM5NzMxJLzfSSy3KTC4uzs/T K07dxAgMs4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GAX3cayqyJibKBbS7bagIPvKVtWgmsZnx+f0MXJLOd6LeK1x43kwf6D31jotpVS2Oo+2Hs0j 7pday769OHTIVcLxBGftfoGNUvuKXPel7j5T0VXZPqsw9LCRvNE7x6UfpbVqlTc7N+V0tj+L ddxu9Wdyvv+iAhXpWU+kV//tbKpad/Loa94/SizFGYmGWsxFxYkAjZRhZgECAAA= Subject: [Hipsec] No HIP WG session in Atlanta X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2012 07:24:32 -0000 Folks, as you know, we have been working under the assumption that we will not have a HIP WG session in Atlanta. So far, it seems WGLC comments can be handled on the mailing list. Cheers, Gonzalo