From gonzalo.camarillo@ericsson.com Tue Jan 5 17:45:07 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1473A693E for ; Tue, 5 Jan 2010 17:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv7VIxYcwwr6 for ; Tue, 5 Jan 2010 17:45:07 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B6E553A6923 for ; Tue, 5 Jan 2010 17:45:06 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-32-4b43eb1f8d80 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BB.9F.04178.F1BE34B4; Wed, 6 Jan 2010 02:45:03 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 02:45:03 +0100 Received: from [159.107.48.142] ([159.107.48.142]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 02:45:03 +0100 Message-ID: <4B43EB1F.7030506@ericsson.com> Date: Wed, 06 Jan 2010 03:45:03 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jan 2010 01:45:03.0651 (UTC) FILETIME=[DDC38F30:01CA8E71] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] TEST X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 01:45:07 -0000 Please, ignore. Gonzalo From rgm@htt-consult.com Tue Jan 5 20:08:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226E23A6867 for ; Tue, 5 Jan 2010 20:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UPPERCASE_50_75=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FQgV1GeyA6c for ; Tue, 5 Jan 2010 20:08:50 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 69AE63A63EB for ; Tue, 5 Jan 2010 20:08:50 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C638D68A8B for ; Wed, 6 Jan 2010 05:06:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RepoieKDKAEr for ; Wed, 6 Jan 2010 00:05:53 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 335A968B23 for ; Wed, 6 Jan 2010 00:05:53 -0500 (EST) Message-ID: <4B440CA5.3010209@htt-consult.com> Date: Tue, 05 Jan 2010 23:08:05 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 04:08:51 -0000 Proposed new list for HIP_TRANSFORM: Suite ID Value RESERVED 0 AES-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) DEPRECATED 3 BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], [RFC2404]) NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) DEPRECATED 6 NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) AES-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) AES-CCM-8 9 [RFC4309] AES-CCM-12 10 [RFC4309] AES-CCM-16 11 [RFC4309] AES-GCM with a 8 octet ICV 12 [RFC4106] AES-GCM with a 12 octet ICV 13 [RFC4106] AES-GCM with a 16 octet ICV 14 [RFC4106] From thomas.r.henderson@boeing.com Wed Jan 6 07:12:01 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1BF3A659B for ; Wed, 6 Jan 2010 07:12:01 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3CN9I6UdrCy for ; Wed, 6 Jan 2010 07:12:00 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 561513A63C9 for ; Wed, 6 Jan 2010 07:12:00 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o06FBrhA002685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 07:11:53 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o06FBrJs012874; Wed, 6 Jan 2010 07:11:53 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o06FBq0x012869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Jan 2010 07:11:52 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 6 Jan 2010 07:11:52 -0800 From: "Henderson, Thomas R" To: HIP Date: Wed, 6 Jan 2010 07:11:51 -0800 Thread-Topic: RFC5206-bis and next steps Thread-Index: AcqNDHZvlfcxsbr8Qf+DZFnd40hcLgARMyuwAGRLn4A= Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A02@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Pekka Nikander' , 'Christian Vogt' , 'Jari Arkko' Subject: [Hipsec] RFC5206-bis and next steps X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:12:01 -0000 Similar to what was started for RFC 4423 and 5201, I posted a new version o= f RFC 5206 as draft-henderson-hip-rfc5206-bis-00. Presently it is the same= as RFC 5206. I intend to use the trac issue tracker once I can access it. http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt Since RFC5206 was written, we've had a number of developments: 1) NAT traversal draft (soon to be RFC): http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09 2) mobility management aspects of NAT traversal: http://tools.ietf.org/html/draft-melen-hip-nat-mm-00 3) There has been work from a couple of implementation teams on cross-famil= y handovers (which were largely out of scope of RFC 5206; briefly mentioned= in Section 3.2.7) 4) shim6 has published RFC 5334 that does failure detection and locator pai= r exploration for shim6 contexts, but also has applicability to HIP. 5) Mobile router draft http://tools.ietf.org/html/draft-melen-hip-mr-02 My first question is how to scope the RFC5206 revision to take into account= this additional work. On one hand, Gonzalo has previously requested that,= while we can rewrite/reorganize the RFC to improve clarity, we should avoi= d adding functionality. On the other, it seems to me to be hard to ignore = this additional progress when revising RFC5206bis, because I think we would= like to avoid asking the future implementor to guess how one set of mechan= isms (for traditional mobility management) interact with another (when NAT = traversal is in use). My recommendation would be to make RFC5206bis be NAT-aware and cross-family= capable, but leave out the mobile router work (keep the scope to be end-to= -end mechanisms). I think we should somehow reconcile the similar but slig= htly different approaches to determining working locator pairs that can be = found in RFC5206, ICE, and RFC5534. My second question is about use cases and document organization. Use cases= are very important to document so that people understand how these mechani= sms work, but there are quite a few possibilities (permutations) such as wh= ether rekeying is simultaneously occurring or not, in what order the events= occur, whether NAT traversal occurs or not (moving into and from a NATted = environment), how mobility events are detected or triggered, etc. If we ke= ep all of the use cases together with the normative material in the documen= t, the document may get quite large. Another option to having a single document is to keep RFC5206bis focused on= normative material that is necessary to interoperate (e.g. messages, requi= red elements of procedure) and keep in parallel a second informative "use c= ases" document that can also discuss how platform-specific or implementatio= n-specific policies impact the operation of the protocol. If we went down = this path, we could take Section 3 from RFC5206 as well as the use cases in= draft-melen-hip-nat-mm-00 and put them in a new hip-mm-use-cases document.= If this approach were to work out, it would mean that the WG would prepar= e two documents to replace RFC5206, one normative and one informative. I w= ould be inclined to at least try this approach. Any comments or feedback on these choices? - Tom From rgm@htt-consult.com Wed Jan 6 07:16:21 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548413A68C7 for ; Wed, 6 Jan 2010 07:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXa5sBc2+VZB for ; Wed, 6 Jan 2010 07:16:20 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 30E873A67D9 for ; Wed, 6 Jan 2010 07:16:20 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AC3D968B8D for ; Wed, 6 Jan 2010 16:13:54 +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 NPFVden7FK1T for ; Wed, 6 Jan 2010 11:13:46 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F127D68B21 for ; Wed, 6 Jan 2010 11:13:45 -0500 (EST) Message-ID: <4B44A92F.9080305@htt-consult.com> Date: Wed, 06 Jan 2010 10:15:59 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:16:21 -0000 Proposed new list for DIFFIE_HELLMAN: Group Value Source Reserved 0 384-bit group 1 OAKLEY well-known group 1 2 Appendex E 1536-bit MODP group 3 RFC3526 3072-bit MODP group 4 RFC3526 6144-bit MODP group 5 RFC3526 8192-bit MODP group 6 RFC3526 1024-bit MODP Group with 160-bit Prime Order Subgroup 7 RFC5114 2048-bit MODP Group with 224-bit Prime Order Subgroup 8 RFC5114 2048-bit MODP Group with 256-bit Prime Order Subgroup 9 RFC5114 192-bit Random ECP Group 10 RFC5114 224-bit Random ECP Group 11 RFC5114 256-bit Random ECP Group 12 RFC5114 384-bit Random ECP Group 13 RFC5114 521-bit Random ECP Group 14 RFC5114 Currently Groups 1 and 3 are MUST implement. How does Group 1 compare to 13? Can we drop 1 and Appendix D and just make 13 and 3 MUST? Should 7 replace 3 for the MUST? Note that 12-14 were first defined in 4753, which is referenced in 5114, so I just want to keep all the ECP's together... From rgm@htt-consult.com Wed Jan 6 07:44:58 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DECE3A6830 for ; Wed, 6 Jan 2010 07:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmPd7pxynjBp for ; Wed, 6 Jan 2010 07:44:57 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 57D2E3A67AE for ; Wed, 6 Jan 2010 07:44:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B120F68B8C for ; Wed, 6 Jan 2010 16:42:33 +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 H4obegUoEU2p for ; Wed, 6 Jan 2010 11:42:25 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0E49468B85 for ; Wed, 6 Jan 2010 11:42:25 -0500 (EST) Message-ID: <4B44AFEB.5000806@htt-consult.com> Date: Wed, 06 Jan 2010 10:44:43 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Proposed new HASH Parameter X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:44:58 -0000 A new HIP Parameter: HASH is proposed. This is the HI Hash, or HIH. The values are: Hash Value Reserved 0 SHA-1 1 SHA-2 2 2 will be MANDITORY to implement and 1 is SHOULD. Once NIST comes out with a new hash, we will add it to the list. The revised BEX that Tobias, with Miika's and my help is working on, will include this parameter and address the downgrade attacks that are introduced by HIH. Tobias did a quick and dirty test with openssl speed on his machine during normal operation shows the following: The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 16335.80k 41030.10k 76838.89k 96992.97k 107657.16k sha1 21577.09k 66409.19k 157907.49k 235312.60k 27521 8.50k Speed drops to 75-30% However, he assumes that it is still sufficiently fast. Code size shouldn't be an issue since the main difference between SHA-1 and SHA-256 lies in the number of rounds. However, since the lookup table for the inversion step is a bit larger but not dramaticaly. =========================================== From miika.komu@hiit.fi Wed Jan 6 09:05:58 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417133A6915 for ; Wed, 6 Jan 2010 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TURwe6Lfi6dq for ; Wed, 6 Jan 2010 09:05:57 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 58EB73A690B for ; Wed, 6 Jan 2010 09:05:56 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id A53C625ED15; Wed, 6 Jan 2010 19:05:54 +0200 (EET) Message-ID: <4B44C35E.8090200@hiit.fi> Date: Wed, 06 Jan 2010 19:07:42 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B440CA5.3010209@htt-consult.com> In-Reply-To: <4B440CA5.3010209@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:05:58 -0000 Robert Moskowitz wrote: Hi, > Proposed new list for HIP_TRANSFORM: > > Suite ID Value > > RESERVED 0 > AES-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) > 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) > DEPRECATED 3 > BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], [RFC2404]) > NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) > DEPRECATED 6 > NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) > AES-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) > AES-CCM-8 9 [RFC4309] > AES-CCM-12 10 [RFC4309] > AES-CCM-16 11 [RFC4309] > AES-GCM with a 8 octet ICV 12 [RFC4106] > AES-GCM with a 12 octet ICV 13 [RFC4106] > AES-GCM with a 16 octet ICV 14 [RFC4106] seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? From rgm@htt-consult.com Wed Jan 6 09:36:47 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C837928C134 for ; Wed, 6 Jan 2010 09:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhHApqz8nBUt for ; Wed, 6 Jan 2010 09:36:47 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id F063728C0F4 for ; Wed, 6 Jan 2010 09:36:46 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3287068B7C; Wed, 6 Jan 2010 18:34:26 +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 GNdQ1O7VB-kd; Wed, 6 Jan 2010 13:34:17 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1D48868B83; Wed, 6 Jan 2010 13:34:08 -0500 (EST) Message-ID: <4B44CA15.2070905@htt-consult.com> Date: Wed, 06 Jan 2010 12:36:21 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> In-Reply-To: <4B44C35E.8090200@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:36:47 -0000 On 01/06/2010 12:07 PM, Miika Komu wrote: > Robert Moskowitz wrote: > > Hi, > >> Proposed new list for HIP_TRANSFORM: >> >> Suite ID Value >> >> RESERVED 0 >> AES-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) >> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) >> DEPRECATED 3 >> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], [RFC2404]) >> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) >> DEPRECATED 6 >> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) >> AES-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) >> AES-CCM-8 9 [RFC4309] >> AES-CCM-12 10 [RFC4309] >> AES-CCM-16 11 [RFC4309] >> AES-GCM with a 8 octet ICV 12 [RFC4106] >> AES-GCM with a 12 octet ICV 13 [RFC4106] >> AES-GCM with a 16 octet ICV 14 [RFC4106] > > seems fine with me. Should the "natural" key size be reflected in some > of the algorithms descriptions? I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. From christian.vogt@ericsson.com Wed Jan 6 09:58:30 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538773A67F6 for ; Wed, 6 Jan 2010 09:58:30 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRinomQfxoc0 for ; Wed, 6 Jan 2010 09:58:29 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5E35A3A6452 for ; Wed, 6 Jan 2010 09:58:29 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o06HxBpi026062; Wed, 6 Jan 2010 12:00:05 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 6 Jan 2010 12:51:40 -0500 From: Christian Vogt To: "Henderson, Thomas R" Date: Wed, 6 Jan 2010 12:51:37 -0500 Thread-Topic: [Hipsec] RFC5206-bis and next steps Thread-Index: AcqO+OX7QqZQxRW0Qtq68/ZSJxOUvQ== Message-ID: <02F67919-2745-435A-8C5A-0FF54582CDE0@ericsson.com> References: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A02@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A02@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pekka Nikander , HIP , Jari, Arkko Subject: Re: [Hipsec] RFC5206-bis and next steps X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:58:30 -0000 Tom - I agree that NAT traversal support as well as support for handovers =20 across address families would be useful to add to the document. I =20 don't see either of this as new functionality, but rather as a =20 robustness improvement. In regards of your suggestion to move use cases into a separate =20 document: Why not? It makes sense in particular because the use case =20 description is quite comprehensive. - Christian On Jan 6, 2010, at 7:11, Henderson, Thomas R wrote: > Similar to what was started for RFC 4423 and 5201, I posted a new =20 > version of RFC 5206 as draft-henderson-hip-rfc5206-bis-00. =20 > Presently it is the same as RFC 5206. I intend to use the trac =20 > issue tracker once I can access it. > http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt > > Since RFC5206 was written, we've had a number of developments: > > 1) NAT traversal draft (soon to be RFC): > http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09 > > 2) mobility management aspects of NAT traversal: > http://tools.ietf.org/html/draft-melen-hip-nat-mm-00 > > 3) There has been work from a couple of implementation teams on =20 > cross-family handovers (which were largely out of scope of RFC 5206; =20 > briefly mentioned in Section 3.2.7) > > 4) shim6 has published RFC 5334 that does failure detection and =20 > locator pair exploration for shim6 contexts, but also has =20 > applicability to HIP. > > 5) Mobile router draft > http://tools.ietf.org/html/draft-melen-hip-mr-02 > > My first question is how to scope the RFC5206 revision to take into =20 > account this additional work. On one hand, Gonzalo has previously =20 > requested that, while we can rewrite/reorganize the RFC to improve =20 > clarity, we should avoid adding functionality. On the other, it =20 > seems to me to be hard to ignore this additional progress when =20 > revising RFC5206bis, because I think we would like to avoid asking =20 > the future implementor to guess how one set of mechanisms (for =20 > traditional mobility management) interact with another (when NAT =20 > traversal is in use). > > My recommendation would be to make RFC5206bis be NAT-aware and cross-=20 > family capable, but leave out the mobile router work (keep the scope =20 > to be end-to-end mechanisms). I think we should somehow reconcile =20 > the similar but slightly different approaches to determining working =20 > locator pairs that can be found in RFC5206, ICE, and RFC5534. > > My second question is about use cases and document organization. =20 > Use cases are very important to document so that people understand =20 > how these mechanisms work, but there are quite a few possibilities =20 > (permutations) such as whether rekeying is simultaneously occurring =20 > or not, in what order the events occur, whether NAT traversal occurs =20 > or not (moving into and from a NATted environment), how mobility =20 > events are detected or triggered, etc. If we keep all of the use =20 > cases together with the normative material in the document, the =20 > document may get quite large. > > Another option to having a single document is to keep RFC5206bis =20 > focused on normative material that is necessary to interoperate =20 > (e.g. messages, required elements of procedure) and keep in parallel =20 > a second informative "use cases" document that can also discuss how =20 > platform-specific or implementation-specific policies impact the =20 > operation of the protocol. If we went down this path, we could take =20 > Section 3 from RFC5206 as well as the use cases in draft-melen-hip-=20 > nat-mm-00 and put them in a new hip-mm-use-cases document. If this =20 > approach were to work out, it would mean that the WG would prepare =20 > two documents to replace RFC5206, one normative and one =20 > informative. I would be inclined to at least try this approach. > > Any comments or feedback on these choices? > > - Tom From miika.komu@hiit.fi Wed Jan 6 10:00:13 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241DD3A682B for ; Wed, 6 Jan 2010 10:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydhto8VpIYHg for ; Wed, 6 Jan 2010 10:00:12 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 4FBF13A6452 for ; Wed, 6 Jan 2010 10:00:12 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id B6FC525ED15; Wed, 6 Jan 2010 20:00:10 +0200 (EET) Message-ID: <4B44D016.7050102@hiit.fi> Date: Wed, 06 Jan 2010 20:01:58 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> In-Reply-To: <4B44CA15.2070905@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:00:13 -0000 Robert Moskowitz wrote: Hi, > On 01/06/2010 12:07 PM, Miika Komu wrote: >> Robert Moskowitz wrote: >> >> Hi, >> >>> Proposed new list for HIP_TRANSFORM: >>> >>> Suite ID Value >>> >>> RESERVED 0 >>> AES-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) >>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) >>> DEPRECATED 3 >>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], [RFC2404]) >>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) >>> DEPRECATED 6 >>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) >>> AES-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) >>> AES-CCM-8 9 [RFC4309] >>> AES-CCM-12 10 [RFC4309] >>> AES-CCM-16 11 [RFC4309] >>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>> AES-GCM with a 16 octet ICV 14 [RFC4106] >> >> seems fine with me. Should the "natural" key size be reflected in some >> of the algorithms descriptions? > > I am not sure what you are alluding to here. Key sizes for AES-based > transforms start at 128 and go up. If you are asking about those > 8/12/16 sizes in CCM and GCM, that applies to the auth size. do we have to negotiate AES key size? From rgm@htt-consult.com Wed Jan 6 10:19:27 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389033A6941 for ; Wed, 6 Jan 2010 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5ARcdF4vW7n for ; Wed, 6 Jan 2010 10:19:26 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 3B6223A693F for ; Wed, 6 Jan 2010 10:19:26 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4494668A8E; Wed, 6 Jan 2010 19:16:56 +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 eSbD8JEs1qEK; Wed, 6 Jan 2010 14:16:47 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7E57B68B55; Wed, 6 Jan 2010 14:16:47 -0500 (EST) Message-ID: <4B44D414.4080501@htt-consult.com> Date: Wed, 06 Jan 2010 13:19:00 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> In-Reply-To: <4B44D016.7050102@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:19:27 -0000 On 01/06/2010 01:01 PM, Miika Komu wrote: > Robert Moskowitz wrote: > > Hi, > >> On 01/06/2010 12:07 PM, Miika Komu wrote: >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>>> Proposed new list for HIP_TRANSFORM: >>>> >>>> Suite ID Value >>>> >>>> RESERVED 0 >>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>> [RFC2404]) >>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>> [RFC2404]) >>>> DEPRECATED 3 >>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>> [RFC2404]) >>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>> [RFC2404]) >>>> DEPRECATED 6 >>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>> [RFC4868]) >>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>> [RFC4868]) >>>> AES-CCM-8 9 [RFC4309] >>>> AES-CCM-12 10 [RFC4309] >>>> AES-CCM-16 11 [RFC4309] >>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>> >>> seems fine with me. Should the "natural" key size be reflected in >>> some of the algorithms descriptions? >> >> I am not sure what you are alluding to here. Key sizes for AES-based >> transforms start at 128 and go up. If you are asking about those >> 8/12/16 sizes in CCM and GCM, that applies to the auth size. > > do we have to negotiate AES key size? OOPS. Good catch. We want to make sure we have Suite B support... Trying to dig around, how is it handled elsewhere, an ISAKMP keysize TLV for IKE and ESP? I have some thoughts for a simple way here... From miika.komu@hiit.fi Wed Jan 6 13:37:32 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BA13A681B for ; Wed, 6 Jan 2010 13:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX4KBhE0gr3m for ; Wed, 6 Jan 2010 13:37:31 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 3BE153A659B for ; Wed, 6 Jan 2010 13:37:30 -0800 (PST) Received: from ip104.infrahip.net (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 3E15825ED15; Wed, 6 Jan 2010 23:37:28 +0200 (EET) Message-ID: <4B450297.1070708@hiit.fi> Date: Wed, 06 Jan 2010 22:37:27 +0100 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> In-Reply-To: <4B44D414.4080501@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:37:32 -0000 Robert Moskowitz wrote: Hi, > On 01/06/2010 01:01 PM, Miika Komu wrote: >> Robert Moskowitz wrote: >> >> Hi, >> >>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>> Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>>> Proposed new list for HIP_TRANSFORM: >>>>> >>>>> Suite ID Value >>>>> >>>>> RESERVED 0 >>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>>> [RFC2404]) >>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>>> [RFC2404]) >>>>> DEPRECATED 3 >>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>>> [RFC2404]) >>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>>> [RFC2404]) >>>>> DEPRECATED 6 >>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>>> [RFC4868]) >>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>>> [RFC4868]) >>>>> AES-CCM-8 9 [RFC4309] >>>>> AES-CCM-12 10 [RFC4309] >>>>> AES-CCM-16 11 [RFC4309] >>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>> >>>> seems fine with me. Should the "natural" key size be reflected in >>>> some of the algorithms descriptions? >>> >>> I am not sure what you are alluding to here. Key sizes for AES-based >>> transforms start at 128 and go up. If you are asking about those >>> 8/12/16 sizes in CCM and GCM, that applies to the auth size. >> >> do we have to negotiate AES key size? > > OOPS. Good catch. We want to make sure we have Suite B support... > > Trying to dig around, how is it handled elsewhere, an ISAKMP keysize TLV > for IKE and ESP? > > I have some thoughts for a simple way here... either we fix the key size in the suite id or we negotiate it as max(key-size-in-r1, key-size-in-i2). From rgm@htt-consult.com Wed Jan 6 13:51:15 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7113A68C7 for ; Wed, 6 Jan 2010 13:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyA1BY+vSbhA for ; Wed, 6 Jan 2010 13:51:14 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 1AC803A68D6 for ; Wed, 6 Jan 2010 13:51:14 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9DB8468B93; Wed, 6 Jan 2010 22:48: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 G-ATaAsnjn-R; Wed, 6 Jan 2010 17:48:20 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id D875168B96; Wed, 6 Jan 2010 17:48:18 -0500 (EST) Message-ID: <4B4505A8.4010009@htt-consult.com> Date: Wed, 06 Jan 2010 16:50:32 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> In-Reply-To: <4B450297.1070708@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:51:15 -0000 On 01/06/2010 04:37 PM, Miika Komu wrote: > Robert Moskowitz wrote: > > Hi, > >> On 01/06/2010 01:01 PM, Miika Komu wrote: >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>> Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>>> Proposed new list for HIP_TRANSFORM: >>>>>> >>>>>> Suite ID Value >>>>>> >>>>>> RESERVED 0 >>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>>>> [RFC2404]) >>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>>>> [RFC2404]) >>>>>> DEPRECATED 3 >>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>>>> [RFC2404]) >>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>>>> [RFC2404]) >>>>>> DEPRECATED 6 >>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>>>> [RFC4868]) >>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>>>> [RFC4868]) >>>>>> AES-CCM-8 9 [RFC4309] >>>>>> AES-CCM-12 10 [RFC4309] >>>>>> AES-CCM-16 11 [RFC4309] >>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>> >>>>> seems fine with me. Should the "natural" key size be reflected in >>>>> some of the algorithms descriptions? >>>> >>>> I am not sure what you are alluding to here. Key sizes for >>>> AES-based transforms start at 128 and go up. If you are asking >>>> about those 8/12/16 sizes in CCM and GCM, that applies to the auth >>>> size. >>> >>> do we have to negotiate AES key size? >> >> OOPS. Good catch. We want to make sure we have Suite B support... >> >> Trying to dig around, how is it handled elsewhere, an ISAKMP keysize >> TLV for IKE and ESP? >> >> I have some thoughts for a simple way here... > > either we fix the key size in the suite id or we negotiate it as > max(key-size-in-r1, key-size-in-i2). So we either add a KEYSIZE parameter or change the HIP_TRANSFORM parameter to include a key size. Any why the max of the two? Rather the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. Thus the agreed keysize is 192, not 256. From miika.komu@hiit.fi Wed Jan 6 13:52:37 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB473A67F6 for ; Wed, 6 Jan 2010 13:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wAnU8-SoWUQ for ; Wed, 6 Jan 2010 13:52:35 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 2C6AD3A6767 for ; Wed, 6 Jan 2010 13:52:32 -0800 (PST) Received: from ip104.infrahip.net (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 842D525ED18; Wed, 6 Jan 2010 23:52:30 +0200 (EET) Message-ID: <4B45061D.8000201@hiit.fi> Date: Wed, 06 Jan 2010 22:52:29 +0100 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> <4B4505A8.4010009@htt-consult.com> In-Reply-To: <4B4505A8.4010009@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 21:52:37 -0000 Robert Moskowitz wrote: Hi, > On 01/06/2010 04:37 PM, Miika Komu wrote: >> Robert Moskowitz wrote: >> >> Hi, >> >>> On 01/06/2010 01:01 PM, Miika Komu wrote: >>>> Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>>> Robert Moskowitz wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>>> Proposed new list for HIP_TRANSFORM: >>>>>>> >>>>>>> Suite ID Value >>>>>>> >>>>>>> RESERVED 0 >>>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>>>>> [RFC2404]) >>>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>>>>> [RFC2404]) >>>>>>> DEPRECATED 3 >>>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>>>>> [RFC2404]) >>>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>>>>> [RFC2404]) >>>>>>> DEPRECATED 6 >>>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>>>>> [RFC4868]) >>>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>>>>> [RFC4868]) >>>>>>> AES-CCM-8 9 [RFC4309] >>>>>>> AES-CCM-12 10 [RFC4309] >>>>>>> AES-CCM-16 11 [RFC4309] >>>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>> >>>>>> seems fine with me. Should the "natural" key size be reflected in >>>>>> some of the algorithms descriptions? >>>>> >>>>> I am not sure what you are alluding to here. Key sizes for >>>>> AES-based transforms start at 128 and go up. If you are asking >>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the auth >>>>> size. >>>> >>>> do we have to negotiate AES key size? >>> >>> OOPS. Good catch. We want to make sure we have Suite B support... >>> >>> Trying to dig around, how is it handled elsewhere, an ISAKMP keysize >>> TLV for IKE and ESP? >>> >>> I have some thoughts for a simple way here... >> >> either we fix the key size in the suite id or we negotiate it as >> max(key-size-in-r1, key-size-in-i2). > > So we either add a KEYSIZE parameter or change the HIP_TRANSFORM > parameter to include a key size. Any why the max of the two? Rather > the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. > Thus the agreed keysize is 192, not 256. it could be also "initiator chooses". From rgm@htt-consult.com Wed Jan 6 14:31:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325413A683D for ; Wed, 6 Jan 2010 14:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwDmoqNQw0uZ for ; Wed, 6 Jan 2010 14:31:02 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id D05DA3A6405 for ; Wed, 6 Jan 2010 14:31:01 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5387E68B21; Wed, 6 Jan 2010 23:28:38 +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 pl9gphE28OQN; Wed, 6 Jan 2010 18:28:29 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 522AD68B91; Wed, 6 Jan 2010 18:28:29 -0500 (EST) Message-ID: <4B450F18.3020103@htt-consult.com> Date: Wed, 06 Jan 2010 17:30:48 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> <4B4505A8.4010009@htt-consult.com> <4B45061D.8000201@hiit.fi> In-Reply-To: <4B45061D.8000201@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 22:31:03 -0000 On 01/06/2010 04:52 PM, Miika Komu wrote: > Robert Moskowitz wrote: > > Hi, > >> On 01/06/2010 04:37 PM, Miika Komu wrote: >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>>> On 01/06/2010 01:01 PM, Miika Komu wrote: >>>>> Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>>>> Robert Moskowitz wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> Proposed new list for HIP_TRANSFORM: >>>>>>>> >>>>>>>> Suite ID Value >>>>>>>> >>>>>>>> RESERVED 0 >>>>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>>>>>> [RFC2404]) >>>>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>>>>>> [RFC2404]) >>>>>>>> DEPRECATED 3 >>>>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>>>>>> [RFC2404]) >>>>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>>>>>> [RFC2404]) >>>>>>>> DEPRECATED 6 >>>>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>>>>>> [RFC4868]) >>>>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>>>>>> [RFC4868]) >>>>>>>> AES-CCM-8 9 [RFC4309] >>>>>>>> AES-CCM-12 10 [RFC4309] >>>>>>>> AES-CCM-16 11 [RFC4309] >>>>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>>> >>>>>>> seems fine with me. Should the "natural" key size be reflected >>>>>>> in some of the algorithms descriptions? >>>>>> >>>>>> I am not sure what you are alluding to here. Key sizes for >>>>>> AES-based transforms start at 128 and go up. If you are asking >>>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the >>>>>> auth size. >>>>> >>>>> do we have to negotiate AES key size? >>>> >>>> OOPS. Good catch. We want to make sure we have Suite B support... >>>> >>>> Trying to dig around, how is it handled elsewhere, an ISAKMP >>>> keysize TLV for IKE and ESP? >>>> >>>> I have some thoughts for a simple way here... >>> >>> either we fix the key size in the suite id or we negotiate it as >>> max(key-size-in-r1, key-size-in-i2). >> >> So we either add a KEYSIZE parameter or change the HIP_TRANSFORM >> parameter to include a key size. Any why the max of the two? Rather >> the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. >> Thus the agreed keysize is 192, not 256. > > it could be also "initiator chooses". that makes the R1 key sizes being the offer, and I2 being the selection. I don't have a problem with that. Now is there any changes to any of the transforms based on the keysize? I hope not! From paul@marvell.com Wed Jan 6 17:37:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980D528C14F for ; Wed, 6 Jan 2010 17:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNEPMUYQ+Nlv for ; Wed, 6 Jan 2010 17:37:05 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id C151028C0FD for ; Wed, 6 Jan 2010 17:37:05 -0800 (PST) X-ASG-Debug-ID: 1262828224-7e6f014a0000-ZNEVin X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id 1FDA7D0C25; Wed, 6 Jan 2010 17:37:04 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id lPWWE5bZHuMurVsG; Wed, 06 Jan 2010 17:37:04 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id EAD6A82AC3; Wed, 6 Jan 2010 17:37:03 -0800 (PST) Received: from sc-owa02.marvell.com ([10.93.76.22]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 17:37:03 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 6 Jan 2010 17:37:03 -0800 From: Paul Lambert To: Robert Moskowitz , "miika.komu@hiit.fi" Date: Wed, 6 Jan 2010 17:37:02 -0800 X-ASG-Orig-Subj: RE: [Hipsec] Proposed new list for HIP_TRANSFORM Thread-Topic: [Hipsec] Proposed new list for HIP_TRANSFORM Thread-Index: AcqPH+9pHE56m4mzSLCKc+/FGcb7RQAGa7KQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013CA5A4AA5@SC-VEXCH2.marvell.com> References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> <4B4505A8.4010009@htt-consult.com> <4B45061D.8000201@hiit.fi> <4B450F18.3020103@htt-consult.com> In-Reply-To: <4B450F18.3020103@htt-consult.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-OriginalArrivalTime: 07 Jan 2010 01:37:03.0783 (UTC) FILETIME=[EA274370:01CA8F39] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1262828224 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 01:37:06 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf > Of Robert Moskowitz > Sent: Wednesday, January 06, 2010 2:31 PM > To: miika.komu@hiit.fi > Cc: HIP > Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM >=20 > On 01/06/2010 04:52 PM, Miika Komu wrote: > > Robert Moskowitz wrote: > > > > Hi, > > > >> On 01/06/2010 04:37 PM, Miika Komu wrote: > >>> Robert Moskowitz wrote: > >>> > >>> Hi, > >>> > >>>> On 01/06/2010 01:01 PM, Miika Komu wrote: > >>>>> Robert Moskowitz wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: > >>>>>>> Robert Moskowitz wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>>> Proposed new list for HIP_TRANSFORM: > >>>>>>>> > >>>>>>>> Suite ID Value > >>>>>>>> > >>>>>>>> RESERVED 0 > >>>>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], > >>>>>>>> [RFC2404]) > >>>>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], > >>>>>>>> [RFC2404]) > >>>>>>>> DEPRECATED 3 > >>>>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], > >>>>>>>> [RFC2404]) > >>>>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], > >>>>>>>> [RFC2404]) > >>>>>>>> DEPRECATED 6 > >>>>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], > >>>>>>>> [RFC4868]) > >>>>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], > >>>>>>>> [RFC4868]) > >>>>>>>> AES-CCM-8 9 [RFC4309] > >>>>>>>> AES-CCM-12 10 [RFC4309] > >>>>>>>> AES-CCM-16 11 [RFC4309] > >>>>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] > >>>>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] > >>>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] > >>>>>>> > >>>>>>> seems fine with me. Should the "natural" key size be reflected > >>>>>>> in some of the algorithms descriptions? > >>>>>> > >>>>>> I am not sure what you are alluding to here. Key sizes for > >>>>>> AES-based transforms start at 128 and go up. If you are asking > >>>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the > >>>>>> auth size. > >>>>> > >>>>> do we have to negotiate AES key size? > >>>> > >>>> OOPS. Good catch. We want to make sure we have Suite B support... > >>>> > >>>> Trying to dig around, how is it handled elsewhere, an ISAKMP > >>>> keysize TLV for IKE and ESP? > >>>> > >>>> I have some thoughts for a simple way here... > >>> > >>> either we fix the key size in the suite id or we negotiate it as > >>> max(key-size-in-r1, key-size-in-i2). > >> > >> So we either add a KEYSIZE parameter or change the HIP_TRANSFORM > >> parameter to include a key size. Any why the max of the two? Rather > >> the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. > >> Thus the agreed keysize is 192, not 256. > > > > it could be also "initiator chooses". >=20 > that makes the R1 key sizes being the offer, and I2 being the > selection. I don't have a problem with that. >=20 > Now is there any changes to any of the transforms based on the keysize? > I hope not! The encryption key size should be part of the transform name ..... Also ... why so many algorithms? Choices for similar algorithms are not ne= cessary a good idea. GCm is a little tricky and the max instantiations var= y based on the ICV size ... Paul >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Wed Jan 6 18:22:49 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA9A3A67B6 for ; Wed, 6 Jan 2010 18:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3PgvdJY-0BC for ; Wed, 6 Jan 2010 18:22:48 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6B9BB3A657C for ; Wed, 6 Jan 2010 18:22:48 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3E98B68B23; Thu, 7 Jan 2010 03:20:27 +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 EFyJ4Hkb2BMc; Wed, 6 Jan 2010 22:20:18 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1CD1A68B21; Wed, 6 Jan 2010 22:20:18 -0500 (EST) Message-ID: <4B454568.3090304@htt-consult.com> Date: Wed, 06 Jan 2010 21:22:32 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Paul Lambert References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> <4B4505A8.4010009@htt-consult.com> <4B45061D.8000201@hiit.fi> <4B450F18.3020103@htt-consult.com> <7BAC95F5A7E67643AAFB2C31BEE662D013CA5A4AA5@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013CA5A4AA5@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 02:22:49 -0000 On 01/06/2010 08:37 PM, Paul Lambert wrote: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf >> Of Robert Moskowitz >> Sent: Wednesday, January 06, 2010 2:31 PM >> To: miika.komu@hiit.fi >> Cc: HIP >> Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM >> >> On 01/06/2010 04:52 PM, Miika Komu wrote: >> >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>> >>>> On 01/06/2010 04:37 PM, Miika Komu wrote: >>>> >>>>> Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>>> On 01/06/2010 01:01 PM, Miika Komu wrote: >>>>>> >>>>>>> Robert Moskowitz wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>>>>> >>>>>>>>> Robert Moskowitz wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>>> Proposed new list for HIP_TRANSFORM: >>>>>>>>>> >>>>>>>>>> Suite ID Value >>>>>>>>>> >>>>>>>>>> RESERVED 0 >>>>>>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], >>>>>>>>>> [RFC2404]) >>>>>>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], >>>>>>>>>> [RFC2404]) >>>>>>>>>> DEPRECATED 3 >>>>>>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], >>>>>>>>>> [RFC2404]) >>>>>>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], >>>>>>>>>> [RFC2404]) >>>>>>>>>> DEPRECATED 6 >>>>>>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], >>>>>>>>>> [RFC4868]) >>>>>>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], >>>>>>>>>> [RFC4868]) >>>>>>>>>> AES-CCM-8 9 [RFC4309] >>>>>>>>>> AES-CCM-12 10 [RFC4309] >>>>>>>>>> AES-CCM-16 11 [RFC4309] >>>>>>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>>>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>>>>>> >>>>>>>>> seems fine with me. Should the "natural" key size be reflected >>>>>>>>> in some of the algorithms descriptions? >>>>>>>>> >>>>>>>> I am not sure what you are alluding to here. Key sizes for >>>>>>>> AES-based transforms start at 128 and go up. If you are asking >>>>>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the >>>>>>>> auth size. >>>>>>>> >>>>>>> do we have to negotiate AES key size? >>>>>>> >>>>>> OOPS. Good catch. We want to make sure we have Suite B support... >>>>>> >>>>>> Trying to dig around, how is it handled elsewhere, an ISAKMP >>>>>> keysize TLV for IKE and ESP? >>>>>> >>>>>> I have some thoughts for a simple way here... >>>>>> >>>>> either we fix the key size in the suite id or we negotiate it as >>>>> max(key-size-in-r1, key-size-in-i2). >>>>> >>>> So we either add a KEYSIZE parameter or change the HIP_TRANSFORM >>>> parameter to include a key size. Any why the max of the two? Rather >>>> the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. >>>> Thus the agreed keysize is 192, not 256. >>>> >>> it could be also "initiator chooses". >>> >> that makes the R1 key sizes being the offer, and I2 being the >> selection. I don't have a problem with that. >> >> Now is there any changes to any of the transforms based on the keysize? >> I hope not! >> > > The encryption key size should be part of the transform name ..... > Can you please expand on this? Why is it better to have a different transform for each allowed key size? > Also ... why so many algorithms? So that someone with more knowledge about the various algorithms can pipe up and advise us! Also depending on underlying MACsec, one algorithm might be perferred over another. CCM is in 802.11, 15, and 16. GCM is in 802.1AE for 802.3 usage. A device with a particular MAC may perfer that algorithm. > Choices for similar algorithms are not necessary a good idea. GCm is a little tricky and the max instantiations vary based on the ICV size ... > So only devices that have it already for the MAC might be using it? I would like to see only one CCM and one GCM, but I don't know what has actually been fielded for say 15.4 or .3ah. I went for a more 'complete' list for starters. From paul@marvell.com Wed Jan 6 19:08:38 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CA13A6976 for ; Wed, 6 Jan 2010 19:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0UC81Bk1bTC for ; Wed, 6 Jan 2010 19:08:37 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id 8D38A3A67AD for ; Wed, 6 Jan 2010 19:08:37 -0800 (PST) X-ASG-Debug-ID: 1262833715-37a301dd0000-ZNEVin X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id B6226D3CE2; Wed, 6 Jan 2010 19:08:35 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id 9k6ABgfC8ylglBVr; Wed, 06 Jan 2010 19:08:35 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id A02F382A9F; Wed, 6 Jan 2010 19:08:35 -0800 (PST) Received: from sc-owa02.marvell.com ([10.93.76.22]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 19:08:35 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 6 Jan 2010 19:08:35 -0800 From: Paul Lambert To: Robert Moskowitz Date: Wed, 6 Jan 2010 19:08:34 -0800 X-ASG-Orig-Subj: RE: [Hipsec] Proposed new list for HIP_TRANSFORM Thread-Topic: [Hipsec] Proposed new list for HIP_TRANSFORM Thread-Index: AcqPQE7wsz5ZaXQ8RhKJt+CVPT/x+gABCKvw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013CA5A4AEC@SC-VEXCH2.marvell.com> References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <4B44D414.4080501@htt-consult.com> <4B450297.1070708@hiit.fi> <4B4505A8.4010009@htt-consult.com> <4B45061D.8000201@hiit.fi> <4B450F18.3020103@htt-consult.com> <7BAC95F5A7E67643AAFB2C31BEE662D013CA5A4AA5@SC-VEXCH2.marvell.com> <4B454568.3090304@htt-consult.com> In-Reply-To: <4B454568.3090304@htt-consult.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-OriginalArrivalTime: 07 Jan 2010 03:08:35.0494 (UTC) FILETIME=[B377DC60:01CA8F46] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1262833715 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 03:08:38 -0000 =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > Sent: Wednesday, January 06, 2010 6:23 PM > To: Paul Lambert > Cc: miika.komu@hiit.fi; HIP > Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM >=20 > On 01/06/2010 08:37 PM, Paul Lambert wrote: > > > > > >> -----Original Message----- > >> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf > >> Of Robert Moskowitz > >> Sent: Wednesday, January 06, 2010 2:31 PM > >> To: miika.komu@hiit.fi > >> Cc: HIP > >> Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM > >> > >> On 01/06/2010 04:52 PM, Miika Komu wrote: > >> > >>> Robert Moskowitz wrote: > >>> > >>> Hi, > >>> > >>> > >>>> On 01/06/2010 04:37 PM, Miika Komu wrote: > >>>> > >>>>> Robert Moskowitz wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>>> On 01/06/2010 01:01 PM, Miika Komu wrote: > >>>>>> > >>>>>>> Robert Moskowitz wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> > >>>>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: > >>>>>>>> > >>>>>>>>> Robert Moskowitz wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Proposed new list for HIP_TRANSFORM: > >>>>>>>>>> > >>>>>>>>>> Suite ID Value > >>>>>>>>>> > >>>>>>>>>> RESERVED 0 > >>>>>>>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], > >>>>>>>>>> [RFC2404]) > >>>>>>>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], > >>>>>>>>>> [RFC2404]) > >>>>>>>>>> DEPRECATED 3 > >>>>>>>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], > >>>>>>>>>> [RFC2404]) > >>>>>>>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], > >>>>>>>>>> [RFC2404]) > >>>>>>>>>> DEPRECATED 6 > >>>>>>>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], > >>>>>>>>>> [RFC4868]) > >>>>>>>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], > >>>>>>>>>> [RFC4868]) > >>>>>>>>>> AES-CCM-8 9 [RFC4309] > >>>>>>>>>> AES-CCM-12 10 [RFC4309] > >>>>>>>>>> AES-CCM-16 11 [RFC4309] > >>>>>>>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] > >>>>>>>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] > >>>>>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] > >>>>>>>>>> > >>>>>>>>> seems fine with me. Should the "natural" key size be reflected > >>>>>>>>> in some of the algorithms descriptions? > >>>>>>>>> > >>>>>>>> I am not sure what you are alluding to here. Key sizes for > >>>>>>>> AES-based transforms start at 128 and go up. If you are asking > >>>>>>>> about those 8/12/16 sizes in CCM and GCM, that applies to the > >>>>>>>> auth size. > >>>>>>>> > >>>>>>> do we have to negotiate AES key size? > >>>>>>> > >>>>>> OOPS. Good catch. We want to make sure we have Suite B support..= . > >>>>>> > >>>>>> Trying to dig around, how is it handled elsewhere, an ISAKMP > >>>>>> keysize TLV for IKE and ESP? > >>>>>> > >>>>>> I have some thoughts for a simple way here... > >>>>>> > >>>>> either we fix the key size in the suite id or we negotiate it as > >>>>> max(key-size-in-r1, key-size-in-i2). > >>>>> > >>>> So we either add a KEYSIZE parameter or change the HIP_TRANSFORM > >>>> parameter to include a key size. Any why the max of the two? Rathe= r > >>>> the max in common. Say R1 has 128, 192, 256 and I2 has 128 and 192. > >>>> Thus the agreed keysize is 192, not 256. > >>>> > >>> it could be also "initiator chooses". > >>> > >> that makes the R1 key sizes being the offer, and I2 being the > >> selection. I don't have a problem with that. > >> > >> Now is there any changes to any of the transforms based on the keysize= ? > >> I hope not! > >> > > > > The encryption key size should be part of the transform name ..... > > >=20 > Can you please expand on this? Why is it better to have a different > transform for each allowed key size? The set of selected parameters for a "cryptographic transformation" may inc= lude: encryption algorithm, encryption algorithm key size, integrity algori= thm, integrity key size, ICV size, padding approach, and potentiall other p= arameters (e.g. M and L value in CCM). The usage considerations for a tran= sform vary considerably based on these choices. For example the ICV length= in GCM has subtle implications on rekey counters. It's really much better= to have less knobs on the configuration and more clearly define the few mo= des that will actually be used. Otherwise, you get significant complexity = in implementations attempt to test and validate the combinations. =20 So each named cipher suite should fully define one transform including the = key sizes. >=20 > > Also ... why so many algorithms? >=20 > So that someone with more knowledge about the various algorithms can > pipe up and advise us! >=20 > Also depending on underlying MACsec, one algorithm might be perferred > over another. CCM is in 802.11, 15, and 16. GCM is in 802.1AE for > 802.3 usage. A device with a particular MAC may perfer that algorithm. >=20 > > Choices for similar algorithms are not necessary a good idea. GCm i= s > a little tricky and the max instantiations vary based on the ICV size ... > > >=20 > So only devices that have it already for the MAC might be using it? I > would like to see only one CCM and one GCM, but I don't know what has > actually been fielded for say 15.4 or .3ah. >=20 > I went for a more 'complete' list for starters. >=20 One version of GCM matching 802.1ae and one CCM matching IPsec (and .11) wo= uld be reasonable. Dump 3DES and Blowfish. Replace HMAC SHAx with CMAC. Better to have just a few algorithms than to attempt and collect every know= n combination. If successful ... interested parties can add more later. Paul From andrew@indranet.co.nz Wed Jan 6 19:22:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A7B3A67AD for ; Wed, 6 Jan 2010 19:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjtSiYruIecm for ; Wed, 6 Jan 2010 19:22:15 -0800 (PST) Received: from mail.indranet.co.nz (unknown [203.97.93.68]) by core3.amsl.com (Postfix) with ESMTP id 04A593A657C for ; Wed, 6 Jan 2010 19:22:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.indranet.co.nz (Postfix) with ESMTP id 27C871256A9D; Thu, 7 Jan 2010 16:22:13 +1300 (NZDT) X-Virus-Scanned: amavisd-new at indranet.co.nz Received: from mail.indranet.co.nz ([127.0.0.1]) by localhost (XServe-2.acheron.indranet.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ycOaWUeDT5l; Thu, 7 Jan 2010 16:22:12 +1300 (NZDT) Received: from [192.168.1.100] (121-72-134-43.dsl.telstraclear.net [121.72.134.43]) by mail.indranet.co.nz (Postfix) with ESMTP id 1F5E71256A84; Thu, 7 Jan 2010 16:22:12 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Andrew McGregor In-Reply-To: <4B44D016.7050102@hiit.fi> Date: Thu, 7 Jan 2010 16:22:10 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> To: miika.komu@hiit.fi X-Mailer: Apple Mail (2.1077) Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 03:22:16 -0000 On 07/01/2010, at 7:01 AM, Miika Komu wrote: > Robert Moskowitz wrote: >=20 > Hi, >=20 >> On 01/06/2010 12:07 PM, Miika Komu wrote: >>> Robert Moskowitz wrote: >>>=20 >>> Hi, >>>=20 >>>> Proposed new list for HIP_TRANSFORM: >>>>=20 >>>> Suite ID Value >>>>=20 >>>> RESERVED 0 >>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], = [RFC2404]) >>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], = [RFC2404]) >>>> DEPRECATED 3 >>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], = [RFC2404]) >>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], = [RFC2404]) >>>> DEPRECATED 6 >>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], = [RFC4868]) >>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], = [RFC4868]) >>>> AES-CCM-8 9 [RFC4309] >>>> AES-CCM-12 10 [RFC4309] >>>> AES-CCM-16 11 [RFC4309] >>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>=20 >>> seems fine with me. Should the "natural" key size be reflected in = some of the algorithms descriptions? >> I am not sure what you are alluding to here. Key sizes for AES-based = transforms start at 128 and go up. If you are asking about those = 8/12/16 sizes in CCM and GCM, that applies to the auth size. >=20 > do we have to negotiate AES key size? No! We need more suite IDs for the key sizes we're going to use. The whole point of using suites in the first place was, once you have = the suite you know everything you need to know about the crypto setup... = you can literally just use the suite-id as an index into a table of all = the numbers. Andrew= From rgm@htt-consult.com Wed Jan 6 19:27:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36AD28C0FD for ; Wed, 6 Jan 2010 19:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDDmyKI0Mf6h for ; Wed, 6 Jan 2010 19:27:19 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id E789028C131 for ; Wed, 6 Jan 2010 19:27:18 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 40A7D68B84; Thu, 7 Jan 2010 04:24:54 +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 BMO7gJlxoXzX; Wed, 6 Jan 2010 23:24:45 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5F20B68B86; Wed, 6 Jan 2010 23:24:45 -0500 (EST) Message-ID: <4B455483.4070404@htt-consult.com> Date: Wed, 06 Jan 2010 22:26:59 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Andrew McGregor References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 03:27:20 -0000 On 01/06/2010 10:22 PM, Andrew McGregor wrote: > On 07/01/2010, at 7:01 AM, Miika Komu wrote: > > >> Robert Moskowitz wrote: >> >> Hi, >> >> >>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>> >>>> Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>> >>>>> Proposed new list for HIP_TRANSFORM: >>>>> >>>>> Suite ID Value >>>>> >>>>> RESERVED 0 >>>>> AES-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) >>>>> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) >>>>> DEPRECATED 3 >>>>> BLOWFISH-CBC with HMAC-SHA1 4 ([RFC2451], [RFC2404]) >>>>> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) >>>>> DEPRECATED 6 >>>>> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) >>>>> AES-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) >>>>> AES-CCM-8 9 [RFC4309] >>>>> AES-CCM-12 10 [RFC4309] >>>>> AES-CCM-16 11 [RFC4309] >>>>> AES-GCM with a 8 octet ICV 12 [RFC4106] >>>>> AES-GCM with a 12 octet ICV 13 [RFC4106] >>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>> >>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? >>>> >>> I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. >>> >> do we have to negotiate AES key size? >> > No! We need more suite IDs for the key sizes we're going to use. > I thank Paul and Andrew for jumping in and giving some good feedback. So 128 and 256? Skip 192? > The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers. > > Andrew > From miika.komu@hiit.fi Wed Jan 6 22:50:44 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FE93A67A4 for ; Wed, 6 Jan 2010 22:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSph1fxGgWim for ; Wed, 6 Jan 2010 22:50:43 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D441F3A677D for ; Wed, 6 Jan 2010 22:50:42 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 7CB1525ED15; Thu, 7 Jan 2010 08:20:58 +0200 (EET) Message-ID: <4B457DB9.2060305@hiit.fi> Date: Thu, 07 Jan 2010 08:22:49 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A02@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A02@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Pekka Nikander' , HIP , 'Christian Vogt' , 'Jari Arkko' Subject: Re: [Hipsec] RFC5206-bis and next steps X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 06:50:44 -0000 Henderson, Thomas R wrote: Hi, > Similar to what was started for RFC 4423 and 5201, I posted a new > version of RFC 5206 as draft-henderson-hip-rfc5206-bis-00. Presently > it is the same as RFC 5206. I intend to use the trac issue tracker > once I can access it. > http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt > > Since RFC5206 was written, we've had a number of developments: > > 1) NAT traversal draft (soon to be RFC): > http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09 > > 2) mobility management aspects of NAT traversal: > http://tools.ietf.org/html/draft-melen-hip-nat-mm-00 > > 3) There has been work from a couple of implementation teams on > cross-family handovers (which were largely out of scope of RFC 5206; > briefly mentioned in Section 3.2.7) > > 4) shim6 has published RFC 5334 that does failure detection and > locator pair exploration for shim6 contexts, but also has > applicability to HIP. > > 5) Mobile router draft > http://tools.ietf.org/html/draft-melen-hip-mr-02 > > My first question is how to scope the RFC5206 revision to take into > account this additional work. On one hand, Gonzalo has previously > requested that, while we can rewrite/reorganize the RFC to improve > clarity, we should avoid adding functionality. On the other, it > seems to me to be hard to ignore this additional progress when > revising RFC5206bis, because I think we would like to avoid asking > the future implementor to guess how one set of mechanisms (for > traditional mobility management) interact with another (when NAT > traversal is in use). > > My recommendation would be to make RFC5206bis be NAT-aware and > cross-family capable, but leave out the mobile router work (keep the > scope to be end-to-end mechanisms). I think we should somehow > reconcile the similar but slightly different approaches to > determining working locator pairs that can be found in RFC5206, ICE, > and RFC5534. I would suggest including crossfamily work and double jump descriptions, and perhaps the SHIM6 work because those have been verified by implementation work and/or sold specifications. On the other hand, we don't have stable specs or even implementation work on ICE-based mobility. Also, the mobility signaling will be quite different because it includes the ICE protocol. > My second question is about use cases and document organization. Use > cases are very important to document so that people understand how > these mechanisms work, but there are quite a few possibilities > (permutations) such as whether rekeying is simultaneously occurring > or not, in what order the events occur, whether NAT traversal occurs > or not (moving into and from a NATted environment), how mobility > events are detected or triggered, etc. If we keep all of the use > cases together with the normative material in the document, the > document may get quite large. This is not a strong opinion, but I would suggest leaving ICE-based NAT traversal out and continuing it's parallel development as a separate draft. On the other hand, this is a rather strong opinion :) If we include ICE-based mobility in the RFC5206, we should include it also in the RFC5201. I have also some other comments on the ICE work that affect this, but I'll start a separate thread on this. > Another option to having a single document is to keep RFC5206bis > focused on normative material that is necessary to interoperate (e.g. > messages, required elements of procedure) and keep in parallel a > second informative "use cases" document that can also discuss how > platform-specific or implementation-specific policies impact the > operation of the protocol. If we went down this path, we could take > Section 3 from RFC5206 as well as the use cases in > draft-melen-hip-nat-mm-00 and put them in a new hip-mm-use-cases > document. If this approach were to work out, it would mean that the > WG would prepare two documents to replace RFC5206, one normative and > one informative. I would be inclined to at least try this approach. > > Any comments or feedback on these choices? Seems ok to me but how do you think this split is this going to improve the readability of the specification? Currently the learning curve is pretty steep. From miika.komu@hiit.fi Wed Jan 6 23:20:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7073F3A635F for ; Wed, 6 Jan 2010 23:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo1SLZcK+6P0 for ; Wed, 6 Jan 2010 23:20:42 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id C282B3A6983 for ; Wed, 6 Jan 2010 23:20:41 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 0F07925ED1A; Thu, 7 Jan 2010 09:20:40 +0200 (EET) Message-ID: <4B458BB7.8090000@hiit.fi> Date: Thu, 07 Jan 2010 09:22:31 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:20:50 -0000 Hi, Baris Boyvat has implemented an experimental fault-tolerance extension for the HIP base exchange and UPDATE in the HIPL implementation. He will document it in his master thesis during this year, but I would like to start discussion of the topic already now. At the protocol level, the extension allows sending multiple I1 or UPDATE-with-locator packets sequentially. The idea is to scan through all possible source and destination IP pairs at the HIP layer to improve the chances for successful initial contact (I1) and to re-establish contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. We have playfully called the extension as "shotgun" mode in the implementation :) The obvious difference to ICE is that the shotgun mode works at the HIP protocol layer. A non-obvious difference is that the approach supports also fault-tolerance for a single relay/rendezvous (Responder's RVS has crashed) and it can make use of multiple relay/rendezvous servers for better redundancy. At the moment, neither of these are possible direcly with the ICE-NAT extensions. I actually believe the shotgun approach can be applied even with the ICE-NAT extensions to improve fault-tolerance. The shotgun approach seems useful to improve fault-tolerance with an without (single or multiple) rendezvous/relay middleboxes, but there is also another use case for this. The Initiator (or Mobile Node) can learn multiple mappings for the peer, some of which may have connectivity and some not. It is also possible that a malign user intentionally sends invalid mappings for a well-known service in a multiuser system (this case also requires some rate control for mappings per user). In such scenarios, it is useful to try multiple peer addresses sequentially instead of just single one. Minimally, the approach requires few considerations in an implementation: i) Allow sending of multiple I1 and UPDATE-with-locator packets in a rate-controlled fashion ii) Filter redundant incoming packets. Case (ii) could be implemented as filtering of I1 packets or filtering of R1 packets. We chose filtering of redundant R1 packets in the implementation and it required a small change in the state machine. For the UPDATE filtering, filtering based on sequence numbers was sufficient. I would like the WG feedback on whether we could include this approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). P.S. Maybe Baris has something to add or to explain some details better. From andrew@indranet.co.nz Wed Jan 6 23:24:08 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59C63A67A4 for ; Wed, 6 Jan 2010 23:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbDP9Aaf5JXa for ; Wed, 6 Jan 2010 23:24:07 -0800 (PST) Received: from mail.indranet.co.nz (unknown [203.97.93.68]) by core3.amsl.com (Postfix) with ESMTP id B470A3A635F for ; Wed, 6 Jan 2010 23:24:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.indranet.co.nz (Postfix) with ESMTP id 75CFF1258076; Thu, 7 Jan 2010 20:24:03 +1300 (NZDT) X-Virus-Scanned: amavisd-new at indranet.co.nz Received: from mail.indranet.co.nz ([127.0.0.1]) by localhost (XServe-2.acheron.indranet.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 860iFmDt9CT2; Thu, 7 Jan 2010 20:24:02 +1300 (NZDT) Received: from [192.168.1.100] (121-72-134-43.dsl.telstraclear.net [121.72.134.43]) by mail.indranet.co.nz (Postfix) with ESMTP id 25810125806C; Thu, 7 Jan 2010 20:24:02 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Andrew McGregor In-Reply-To: <4B458BB7.8090000@hiit.fi> Date: Thu, 7 Jan 2010 20:23:59 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <5C90FDBC-A581-4948-AA89-FE13BB16E843@indranet.co.nz> References: <4B458BB7.8090000@hiit.fi> To: miika.komu@hiit.fi X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: Re: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:24:08 -0000 It sounds like a perfectly reasonable idea at first glance; it should = work well. And then I started thinking about congestion control and fast start, and = realised that this will need specified carefully if we still believe = that protocols starting very slowly is desirable to deal with = low-bandwidth and congested situations. That's likely to spark a = debate, unfortunately. Andrew On 07/01/2010, at 8:22 PM, Miika Komu wrote: > Hi, >=20 > Baris Boyvat has implemented an experimental fault-tolerance extension = for the HIP base exchange and UPDATE in the HIPL implementation. He will = document it in his master thesis during this year, but I would like to = start discussion of the topic already now. >=20 > At the protocol level, the extension allows sending multiple I1 or = UPDATE-with-locator packets sequentially. The idea is to scan through = all possible source and destination IP pairs at the HIP layer to improve = the chances for successful initial contact (I1) and to re-establish = contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. = We have playfully called the extension as "shotgun" mode in the = implementation :) >=20 > The obvious difference to ICE is that the shotgun mode works at the = HIP protocol layer. A non-obvious difference is that the approach = supports also fault-tolerance for a single relay/rendezvous (Responder's = RVS has crashed) and it can make use of multiple relay/rendezvous = servers for better redundancy. At the moment, neither of these are = possible direcly with the ICE-NAT extensions. I actually believe the = shotgun approach can be applied even with the ICE-NAT extensions to = improve fault-tolerance. >=20 > The shotgun approach seems useful to improve fault-tolerance with an = without (single or multiple) rendezvous/relay middleboxes, but there is = also another use case for this. The Initiator (or Mobile Node) can learn = multiple mappings for the peer, some of which may have connectivity and = some not. It is also possible that a malign user intentionally sends = invalid mappings for a well-known service in a multiuser system (this = case also requires some rate control for mappings per user). In such = scenarios, it is useful to try multiple peer addresses sequentially = instead of just single one. >=20 > Minimally, the approach requires few considerations in an = implementation: >=20 > i) Allow sending of multiple I1 and UPDATE-with-locator packets in a = rate-controlled fashion > ii) Filter redundant incoming packets. >=20 > Case (ii) could be implemented as filtering of I1 packets or filtering = of R1 packets. We chose filtering of redundant R1 packets in the = implementation and it required a small change in the state machine. For = the UPDATE filtering, filtering based on sequence numbers was = sufficient. >=20 > I would like the WG feedback on whether we could include this approach = in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). >=20 > P.S. Maybe Baris has something to add or to explain some details = better. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >=20 From heer@informatik.rwth-aachen.de Thu Jan 7 02:51:37 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424C13A6811 for ; Thu, 7 Jan 2010 02:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYO5ZFc-UzxF for ; Thu, 7 Jan 2010 02:51:36 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 00C763A680A for ; Thu, 7 Jan 2010 02:51:35 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KVV00140I5WU540@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 11:51:32 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,234,1262559600"; d="scan'208";a="40013709" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 07 Jan 2010 11:51:32 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KVV00CF1I5WXV10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 11:51:32 +0100 (CET) From: Tobias Heer In-reply-to: <4B458BB7.8090000@hiit.fi> Date: Thu, 07 Jan 2010 12:51:32 +0100 Message-id: <8651FB5B-E07F-4EDC-8A8D-434C44AE8E05@cs.rwth-aachen.de> References: <4B458BB7.8090000@hiit.fi> To: miika.komu@hiit.fi X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: Re: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 10:51:37 -0000 Hi, Am 07.01.2010 um 08:22 schrieb Miika Komu: > Hi, > > Baris Boyvat has implemented an experimental fault-tolerance extension for the HIP base exchange and UPDATE in the HIPL implementation. He will document it in his master thesis during this year, but I would like to start discussion of the topic already now. > Great. I think this extension is really worth some deeper investigation. In our own tests with HIP(L) we found that timing and aggressiveness regarding retransmissions and opportunistic double transmissions can greatly improve the performance. > At the protocol level, the extension allows sending multiple I1 or UPDATE-with-locator packets sequentially. The idea is to scan through all possible source and destination IP pairs at the HIP layer to improve the chances for successful initial contact (I1) and to re-establish contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. We have playfully called the extension as "shotgun" mode in the implementation :) > > The obvious difference to ICE is that the shotgun mode works at the HIP protocol layer. A non-obvious difference is that the approach supports also fault-tolerance for a single relay/rendezvous (Responder's RVS has crashed) and it can make use of multiple relay/rendezvous servers for better redundancy. At the moment, neither of these are possible direcly with the ICE-NAT extensions. I actually believe the shotgun approach can be applied even with the ICE-NAT extensions to improve fault-tolerance. > > The shotgun approach seems useful to improve fault-tolerance with an without (single or multiple) rendezvous/relay middleboxes, but there is also another use case for this. The Initiator (or Mobile Node) can learn multiple mappings for the peer, some of which may have connectivity and some not. It is also possible that a malign user intentionally sends invalid mappings for a well-known service in a multiuser system (this case also requires some rate control for mappings per user). In such scenarios, it is useful to try multiple peer addresses sequentially instead of just single one. > > Minimally, the approach requires few considerations in an implementation: > > i) Allow sending of multiple I1 and UPDATE-with-locator packets in a rate-controlled fashion > ii) Filter redundant incoming packets. > > Case (ii) could be implemented as filtering of I1 packets or filtering of R1 packets. We chose filtering of redundant R1 packets in the implementation and it required a small change in the state machine. For the UPDATE filtering, filtering based on sequence numbers was sufficient. > > I would like the WG feedback on whether we could include this approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). I would like to see this as a separate document that solely focuses on fault-tolerance and performance I think the shotgun extension is a first step to a comprehensive document. My two reasons for this are: a) I think solving the problem goes beyond the scope of the base documents because this problem domain offers more possible solutions than the shotgun mode. A separate document could discuss use cases and solutions in more depth than it can be done in the base documents. b) Measures for improving fault tolerance may be quite specific to a scenario and may require to make some assumptions that cannot be made in the general case. Some more thoughts on fault tolerance: As far as I understood, the shotgun extension only works with multiple interfaces. What about optimizations for single-homed hosts? As far as I understood, the shotgun mode will make the mobile devices switch interfaces quite aggressively. What happens if the primary interface (e.g. WiFi) is temporarily down (because of a recent L2/L3 handover). The shotgun mode will determine that the secondary interface (e.g., GPRS) is working and will switch to the secondary interface? Do we need a mechanism to switch back as soon as the primary interface is available again? Variable timeouts and increased redundancy depending on the current situation (e.g., high packet loss -> more redundancy) might be an option, too. Thanks for the work you already did in this problem domain. Tobias > > P.S. Maybe Baris has something to add or to explain some details better. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Thu Jan 7 02:58:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD773A681D for ; Thu, 7 Jan 2010 02:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQqFRKT0FpD0 for ; Thu, 7 Jan 2010 02:58:05 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 6EF7D3A67B2 for ; Thu, 7 Jan 2010 02:58:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KVV005OTIGQV810@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 11:58:02 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,234,1262559600"; d="scan'208";a="21617656" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 07 Jan 2010 11:58:02 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KVV00CJ4IGQXV10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 11:58:02 +0100 (CET) From: Tobias Heer In-reply-to: Date: Thu, 07 Jan 2010 12:58:02 +0100 Message-id: <7DD22BB2-22FE-4EF9-B6BD-9BD2ED3333CB@cs.rwth-aachen.de> References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 10:58:06 -0000 Am 07.01.2010 um 04:22 schrieb Andrew McGregor: > > On 07/01/2010, at 7:01 AM, Miika Komu wrote: > >> Robert Moskowitz wrote: >> >> Hi, >> >>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>> Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>>> Proposed new list for HIP_TRANSFORM: >>>>> >>>>> Suite ID Value >>>>> >>>>> RESERVED 0 >>>>> ... >>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>> >>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? >>> I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. >> >> do we have to negotiate AES key size? > > No! We need more suite IDs for the key sizes we're going to use. > > The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers. > I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ? Tobias > Andrew > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Thu Jan 7 05:00:08 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425A328C11D for ; Thu, 7 Jan 2010 05:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uReR8s9l3-hg for ; Thu, 7 Jan 2010 05:00:07 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 3523F28C171 for ; Thu, 7 Jan 2010 05:00:06 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2F5D368B99; Thu, 7 Jan 2010 13:57:42 +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 s9XiGhkG7dW1; Thu, 7 Jan 2010 08:57:33 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5B25668B4A; Thu, 7 Jan 2010 08:57:33 -0500 (EST) Message-ID: <4B45DAC9.1090303@htt-consult.com> Date: Thu, 07 Jan 2010 07:59:53 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Tobias Heer References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <7DD22BB2-22FE-4EF9-B6BD-9BD2ED3333CB@cs.rwth-aachen.de> In-Reply-To: <7DD22BB2-22FE-4EF9-B6BD-9BD2ED3333CB@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 13:00:08 -0000 On 01/07/2010 06:58 AM, Tobias Heer wrote: > Am 07.01.2010 um 04:22 schrieb Andrew McGregor: > > >> On 07/01/2010, at 7:01 AM, Miika Komu wrote: >> >> >>> Robert Moskowitz wrote: >>> >>> Hi, >>> >>> >>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>> >>>>> Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>>> Proposed new list for HIP_TRANSFORM: >>>>>> >>>>>> Suite ID Value >>>>>> >>>>>> RESERVED 0 >>>>>> >>>>>> > ... > > >>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>> >>>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? >>>>> >>>> I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. >>>> >>> do we have to negotiate AES key size? >>> >> No! We need more suite IDs for the key sizes we're going to use. >> >> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers. >> >> > I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ? The HIP control packet MAC algorithm is still HMAC, and it will use the HIH as the underlying hash. There are HIP_TRANSFORMS that do not have a separate MAC, like CCM. From what I have read on the CFRG list, HMAC is sound and given all the things we do with it, it is OK to just use it where it makes sense. Now maybe I have been reading too much on too little sleep and have a few things twisted, but I don't think so. I will try and work up a new HIP_TRANSFORM list today, but I will be challenged to find the information on which size ICV to use for CCM and GCM. From oleg.ponomarev@hiit.fi Thu Jan 7 05:19:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEB73A6847 for ; Thu, 7 Jan 2010 05:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loV2CE+VUkLD for ; Thu, 7 Jan 2010 05:19:49 -0800 (PST) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 9566A3A6810 for ; Thu, 7 Jan 2010 05:19:47 -0800 (PST) Received: from [2001:708:140:220:21e:4fff:fe92:4522] ([IPv6:2001:708:140:220:21e:4fff:fe92:4522]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id o07DIcMq023669; Thu, 7 Jan 2010 15:18:39 +0200 Date: Thu, 7 Jan 2010 15:18:37 +0200 (EET) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer To: Robert Moskowitz In-Reply-To: <4B44A92F.9080305@htt-consult.com> Message-ID: References: <4B44A92F.9080305@htt-consult.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) X-GPG-FINGRPRINT: E94D 632A 70E4 3F92 9A7E B04E 20BF FC6B 983B CA5E X-GPG-PUBLIC_KEY: http://ponomarev.ru/oleg.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: HIP Subject: Re: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 13:19:51 -0000 Hi! On Wed, 6 Jan 2010, Robert Moskowitz wrote: > Proposed new list for DIFFIE_HELLMAN: > > 384-bit group 1 > 192-bit Random ECP Group 10 RFC5114 > 224-bit Random ECP Group 11 RFC5114 > 256-bit Random ECP Group 12 RFC5114 > 384-bit Random ECP Group 13 RFC5114 > 521-bit Random ECP Group 14 RFC5114 > How does Group 1 compare to 13? ECDH-384 is equivalent to DH-7680 > Can we drop 1 and Appendix D and just make 13 and 3 MUST? I think 13 is too long for a MUST. ECC-224 (~RSA2048) should be good enough until 2030 according to NIST recommendations. ECDH384 takes more than triple time of ECDH224. -- Regards, Oleg. From heer@informatik.rwth-aachen.de Thu Jan 7 07:04:12 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1F93A67F3 for ; Thu, 7 Jan 2010 07:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exIkpJRQLbsZ for ; Thu, 7 Jan 2010 07:04:11 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 326683A67B0 for ; Thu, 7 Jan 2010 07:04:10 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KVV005MTTUW8R80@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 16:04:08 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,235,1262559600"; d="scan'208";a="21637686" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 07 Jan 2010 16:04:08 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KVV00CF5TUWXV50@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 16:04:08 +0100 (CET) From: Tobias Heer In-reply-to: <4B45DAC9.1090303@htt-consult.com> Date: Thu, 07 Jan 2010 16:04:06 +0100 Message-id: <5460FD61-6C49-4211-8760-1AD3C5A6DC7F@cs.rwth-aachen.de> References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <7DD22BB2-22FE-4EF9-B6BD-9BD2ED3333CB@cs.rwth-aachen.de> <4B45DAC9.1090303@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:04:12 -0000 Am 07.01.2010 um 13:59 schrieb Robert Moskowitz: > On 01/07/2010 06:58 AM, Tobias Heer wrote: >> Am 07.01.2010 um 04:22 schrieb Andrew McGregor: >> >> >>> On 07/01/2010, at 7:01 AM, Miika Komu wrote: >>> >>> >>>> Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>> >>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>> >>>>>> Robert Moskowitz wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> Proposed new list for HIP_TRANSFORM: >>>>>>> >>>>>>> Suite ID Value >>>>>>> >>>>>>> RESERVED 0 >>>>>>> >>>>>>> >> ... >> >> >>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>>> >>>>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? >>>>>> >>>>> I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. >>>>> >>>> do we have to negotiate AES key size? >>>> >>> No! We need more suite IDs for the key sizes we're going to use. >>> >>> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers. >>> >>> >> I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ? > > The HIP control packet MAC algorithm is still HMAC, and it will use the HIH as the underlying hash. There are HIP_TRANSFORMS that do not have a separate MAC, like CCM. > Is it really wise to use the HIH instead of the ESP transform to determine the HIP control packet HMAC hash algorithm? In my opinion, the MAC algorithm from the ESP transform has more in common with the control packet HMAC than the HIH. The HIH is for generating an identity tag and the two other MACs are for integrity protection of packets. Of course, both algorithms need to be supported by both hosts but I can imagine that hosts might want to use stronger and more costly hash functions for generating their identity than they would use for integrity protection. In this regard, the security requirements for control channel hash algorithm are more similar to the ESP HMAC. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From miika.komu@hiit.fi Thu Jan 7 07:14:04 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535363A6847 for ; Thu, 7 Jan 2010 07:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RS8DODbgaVX for ; Thu, 7 Jan 2010 07:14:02 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 471F63A6838 for ; Thu, 7 Jan 2010 07:14:02 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 5261B25ED1A; Thu, 7 Jan 2010 17:13:59 +0200 (EET) Message-ID: <4B45FAA7.9030609@hiit.fi> Date: Thu, 07 Jan 2010 17:15:51 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Tobias Heer References: <4B458BB7.8090000@hiit.fi> <8651FB5B-E07F-4EDC-8A8D-434C44AE8E05@cs.rwth-aachen.de> In-Reply-To: <8651FB5B-E07F-4EDC-8A8D-434C44AE8E05@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:14:04 -0000 Tobias Heer wrote: Hi, > Hi, > > Am 07.01.2010 um 08:22 schrieb Miika Komu: > >> Hi, >> >> Baris Boyvat has implemented an experimental fault-tolerance >> extension for the HIP base exchange and UPDATE in the HIPL >> implementation. He will document it in his master thesis during >> this year, but I would like to start discussion of the topic >> already now. >> > Great. I think this extension is really worth some deeper > investigation. In our own tests with HIP(L) we found that timing and > aggressiveness regarding retransmissions and opportunistic double > transmissions can greatly improve the performance. > >> At the protocol level, the extension allows sending multiple I1 or >> UPDATE-with-locator packets sequentially. The idea is to scan >> through all possible source and destination IP pairs at the HIP >> layer to improve the chances for successful initial contact (I1) >> and to re-establish contact (UPDATE-with-locator) in way similar to >> the NAT-ICE extensions. We have playfully called the extension as >> "shotgun" mode in the implementation :) >> >> The obvious difference to ICE is that the shotgun mode works at the >> HIP protocol layer. A non-obvious difference is that the approach >> supports also fault-tolerance for a single relay/rendezvous >> (Responder's RVS has crashed) and it can make use of multiple >> relay/rendezvous servers for better redundancy. At the moment, >> neither of these are possible direcly with the ICE-NAT extensions. >> I actually believe the shotgun approach can be applied even with >> the ICE-NAT extensions to improve fault-tolerance. >> >> The shotgun approach seems useful to improve fault-tolerance with >> an without (single or multiple) rendezvous/relay middleboxes, but >> there is also another use case for this. The Initiator (or Mobile >> Node) can learn multiple mappings for the peer, some of which may >> have connectivity and some not. It is also possible that a malign >> user intentionally sends invalid mappings for a well-known service >> in a multiuser system (this case also requires some rate control >> for mappings per user). In such scenarios, it is useful to try >> multiple peer addresses sequentially instead of just single one. >> >> Minimally, the approach requires few considerations in an >> implementation: >> >> i) Allow sending of multiple I1 and UPDATE-with-locator packets in >> a rate-controlled fashion ii) Filter redundant incoming packets. >> >> Case (ii) could be implemented as filtering of I1 packets or >> filtering of R1 packets. We chose filtering of redundant R1 packets >> in the implementation and it required a small change in the state >> machine. For the UPDATE filtering, filtering based on sequence >> numbers was sufficient. >> >> I would like the WG feedback on whether we could include this >> approach in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). > > I would like to see this as a separate document that solely focuses > on fault-tolerance and performance I think the shotgun extension is a > first step to a comprehensive document. My two reasons for this are: > a) I think solving the problem goes beyond the scope of the base > documents because this problem domain offers more possible solutions > than the shotgun mode. A separate document could discuss use cases > and solutions in more depth than it can be done in the base > documents. b) Measures for improving fault tolerance may be quite > specific to a scenario and may require to make some assumptions that > cannot be made in the general case. Well, I am just a bit skeptic that this will be never taken into use if the state machine filtering part are not part of RFC5201-bis and RFC5206-bis. > Some more thoughts on fault tolerance: > > As far as I understood, the shotgun extension only works with > multiple interfaces. What about optimizations for single-homed hosts? the shotgun mode does not "care" about interfaces. It pairs up addresses, not interfaces. So if you've got two addresses on a single interface machine and peer has got one, two redundant packets will be sent. > As far as I understood, the shotgun mode will make the mobile devices > switch interfaces quite aggressively. What happens if the primary > interface (e.g. WiFi) is temporarily down (because of a recent L2/L3 > handover). The shotgun mode will determine that the secondary > interface (e.g., GPRS) is working and will switch to the secondary > interface? Do we need a mechanism to switch back as soon as the > primary interface is available again? This is a matter of the UPDATE policy and has nothing to do with the shotgun extension we're proposing. The shotgun mode just means that you send all I1 and UPDATE-with-locator through all known source IP and destination IP combinations. So the shotgun mode is quite dumb and simple. But perhaps I just misunderstood you. I haven't really thought about optimizing the shotgun - probably there's room for making it more clever. > Variable timeouts and increased redundancy depending on the current > situation (e.g., high packet loss -> more redundancy) might be an > option, too. > > Thanks for the work you already did in this problem domain. You're welcome. From rgm@htt-consult.com Thu Jan 7 09:13:08 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FECC3A67FA for ; Thu, 7 Jan 2010 09:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsDOs47S4o1x for ; Thu, 7 Jan 2010 09:12:59 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 52EBC3A6887 for ; Thu, 7 Jan 2010 09:12:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id CB6EC68B49; Thu, 7 Jan 2010 18:10:30 +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 e7MLcsp1Gdhv; Thu, 7 Jan 2010 13:10:22 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 208F668B89; Thu, 7 Jan 2010 13:10:22 -0500 (EST) Message-ID: <4B461605.9090008@htt-consult.com> Date: Thu, 07 Jan 2010 12:12:37 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Oleg Ponomarev References: <4B44A92F.9080305@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:13:08 -0000 On 01/07/2010 08:18 AM, Oleg Ponomarev wrote: > Hi! On Wed, 6 Jan 2010, Robert Moskowitz wrote: > >> Proposed new list for DIFFIE_HELLMAN: >> >> 384-bit group 1 >> 192-bit Random ECP Group 10 >> RFC5114 >> 224-bit Random ECP Group 11 >> RFC5114 >> 256-bit Random ECP Group 12 >> RFC5114 >> 384-bit Random ECP Group 13 >> RFC5114 >> 521-bit Random ECP Group 14 >> RFC5114 > >> How does Group 1 compare to 13? > > ECDH-384 is equivalent to DH-7680 OK. I see, and I read Appendix D of 5201 and looked some more at 5114. Given the 192 ECP group, is there any value in keeping our cheap, breakable 384 DH? > >> Can we drop 1 and Appendix D and just make 13 and 3 MUST? > > I think 13 is too long for a MUST. ECC-224 (~RSA2048) should be good > enough until 2030 according to NIST recommendations. ECDH384 takes > more than triple time of ECDH224. > So what would be the MUST implement? 3 and 12? And any hums on dropping 1? From miika.komu@hiit.fi Thu Jan 7 09:46:12 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A693A68D8 for ; Thu, 7 Jan 2010 09:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wiuLc9dc9ND for ; Thu, 7 Jan 2010 09:46:11 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 643E03A68BC for ; Thu, 7 Jan 2010 09:46:11 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id EDAFF25ED1A; Thu, 7 Jan 2010 19:46:08 +0200 (EET) Message-ID: <4B461E52.4020109@hiit.fi> Date: Thu, 07 Jan 2010 19:48:02 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Robert Moskowitz References: <4B44A92F.9080305@htt-consult.com> <4B461605.9090008@htt-consult.com> In-Reply-To: <4B461605.9090008@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:46:12 -0000 Robert Moskowitz wrote: Hi, > On 01/07/2010 08:18 AM, Oleg Ponomarev wrote: >> Hi! On Wed, 6 Jan 2010, Robert Moskowitz wrote: >> >>> Proposed new list for DIFFIE_HELLMAN: >>> >>> 384-bit group 1 >>> 192-bit Random ECP Group 10 >>> RFC5114 >>> 224-bit Random ECP Group 11 >>> RFC5114 >>> 256-bit Random ECP Group 12 >>> RFC5114 >>> 384-bit Random ECP Group 13 >>> RFC5114 >>> 521-bit Random ECP Group 14 >>> RFC5114 >> >>> How does Group 1 compare to 13? >> >> ECDH-384 is equivalent to DH-7680 > > OK. I see, and I read Appendix D of 5201 and looked some more at 5114. > Given the 192 ECP group, is there any value in keeping our cheap, > breakable 384 DH? >> >>> Can we drop 1 and Appendix D and just make 13 and 3 MUST? >> >> I think 13 is too long for a MUST. ECC-224 (~RSA2048) should be good >> enough until 2030 according to NIST recommendations. ECDH384 takes >> more than triple time of ECDH224. >> > > So what would be the MUST implement? 3 and 12? > > And any hums on dropping 1? I recall that 1 was there for low-end devices. From heer@informatik.rwth-aachen.de Thu Jan 7 09:55:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE40D3A68F8 for ; Thu, 7 Jan 2010 09:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dVyxPyCaiib for ; Thu, 7 Jan 2010 09:55:02 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id C1BC73A681E for ; Thu, 7 Jan 2010 09:55:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KVW003OM1ROC7B0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 18:55:00 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,236,1262559600"; d="scan'208";a="40076134" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 07 Jan 2010 18:55:01 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KVW00CU51ROXV70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 07 Jan 2010 18:55:00 +0100 (CET) From: Tobias Heer In-reply-to: <4B461E52.4020109@hiit.fi> Date: Thu, 07 Jan 2010 18:54:58 +0100 Message-id: References: <4B44A92F.9080305@htt-consult.com> <4B461605.9090008@htt-consult.com> <4B461E52.4020109@hiit.fi> To: miika.komu@hiit.fi X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: Re: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:55:03 -0000 Am 07.01.2010 um 18:48 schrieb Miika Komu: > Robert Moskowitz wrote: > > Hi, > >> On 01/07/2010 08:18 AM, Oleg Ponomarev wrote: >>> Hi! On Wed, 6 Jan 2010, Robert Moskowitz wrote: >>> >>>> Proposed new list for DIFFIE_HELLMAN: >>>> >>>> 384-bit group 1 >>>> 192-bit Random ECP Group 10 RFC5114 >>>> 224-bit Random ECP Group 11 RFC5114 >>>> 256-bit Random ECP Group 12 RFC5114 >>>> 384-bit Random ECP Group 13 RFC5114 >>>> 521-bit Random ECP Group 14 RFC5114 >>> >>>> How does Group 1 compare to 13? >>> >>> ECDH-384 is equivalent to DH-7680 >> OK. I see, and I read Appendix D of 5201 and looked some more at 5114. Given the 192 ECP group, is there any value in keeping our cheap, breakable 384 DH? >>> >>>> Can we drop 1 and Appendix D and just make 13 and 3 MUST? >>> >>> I think 13 is too long for a MUST. ECC-224 (~RSA2048) should be good enough until 2030 according to NIST recommendations. ECDH384 takes more than triple time of ECDH224. >>> >> So what would be the MUST implement? 3 and 12? >> And any hums on dropping 1? > > I recall that 1 was there for low-end devices. Low-end devices should be able to handle elliptic curve crypto. I agree with dropping 1 if there are no IPR problems for 12 or 13 (whatever becomes the next MUST). Tobias > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From oleg.ponomarev@hiit.fi Fri Jan 8 07:38:46 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4633A67B0 for ; Fri, 8 Jan 2010 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZplPWd6oyp4 for ; Fri, 8 Jan 2010 07:38:45 -0800 (PST) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 3349B3A67EA for ; Fri, 8 Jan 2010 07:38:44 -0800 (PST) Received: from [2001:708:140:220:21e:4fff:fe92:4522] ([IPv6:2001:708:140:220:21e:4fff:fe92:4522]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id o08FbYGj025581; Fri, 8 Jan 2010 17:37:36 +0200 Date: Fri, 8 Jan 2010 17:37:33 +0200 (EET) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer To: Robert Moskowitz In-Reply-To: <4B461605.9090008@htt-consult.com> Message-ID: References: <4B44A92F.9080305@htt-consult.com> <4B461605.9090008@htt-consult.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) X-GPG-FINGRPRINT: E94D 632A 70E4 3F92 9A7E B04E 20BF FC6B 983B CA5E X-GPG-PUBLIC_KEY: http://ponomarev.ru/oleg.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: HIP Subject: Re: [Hipsec] Proposed new list for DIFFIE_HELLMAN X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 15:38:46 -0000 Hi! On Thu, 7 Jan 2010, Robert Moskowitz wrote: >>> Proposed new list for DIFFIE_HELLMAN: >>> >>> Reserved 0 >>> 384-bit group 1 >>> OAKLEY well-known group 1 2 Appendex E >>> 1536-bit MODP group 3 RFC3526 >>> 3072-bit MODP group 4 RFC3526 >>> 6144-bit MODP group 5 RFC3526 >>> 8192-bit MODP group 6 RFC3526 >>> 1024-bit MODP Group with 160-bit Prime Order Subgroup 7 RFC5114 >>> 2048-bit MODP Group with 224-bit Prime Order Subgroup 8 RFC5114 >>> 2048-bit MODP Group with 256-bit Prime Order Subgroup 9 RFC5114 >>> 192-bit Random ECP Group 10 RFC5114 >>> 224-bit Random ECP Group 11 RFC5114 >>> 256-bit Random ECP Group 12 RFC5114 >>> 384-bit Random ECP Group 13 RFC5114 >>> 521-bit Random ECP Group 14 RFC5114 BTW, I would suggest to add 2048-bit and 4096-bit MODP Groups from RFC3526 > So what would be the MUST implement? 3 and 12? MUST implement 3 and 9, SHOULD 11 and MAY the rest, IMHO. -- Regards, Oleg. From heer@informatik.rwth-aachen.de Fri Jan 8 12:16:10 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EC03A6835 for ; Fri, 8 Jan 2010 12:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SbQqwRFjFDO for ; Fri, 8 Jan 2010 12:16:07 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 2469D3A6816 for ; Fri, 8 Jan 2010 12:16:06 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KVY000QG2YR7I30@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 08 Jan 2010 21:16:03 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,243,1262559600"; d="scan'208";a="21720702" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 08 Jan 2010 21:16:04 +0100 Received: from [192.168.3.237] ([unknown] [80.200.154.182]) 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 <0KVY007NI2YREX70@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 08 Jan 2010 21:16:03 +0100 (CET) From: Tobias Heer Date: Fri, 08 Jan 2010 21:16:02 +0100 Message-id: References: <5460FD61-6C49-4211-8760-1AD3C5A6DC7F@cs.rwth-aachen.de> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: hip WG Subject: [Hipsec] Fwd: Proposed new list for HIP_TRANSFORM X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 20:16:10 -0000 Anfang der weitergeleiteten E-Mail: > Von: Tobias Heer > Datum: 7. Januar 2010 16:04:06 MEZ > An: Robert Moskowitz > Kopie: hip WG > Betreff: Re: [Hipsec] Proposed new list for HIP_TRANSFORM > > > Am 07.01.2010 um 13:59 schrieb Robert Moskowitz: > >> On 01/07/2010 06:58 AM, Tobias Heer wrote: >>> Am 07.01.2010 um 04:22 schrieb Andrew McGregor: >>> >>> >>>> On 07/01/2010, at 7:01 AM, Miika Komu wrote: >>>> >>>> >>>>> Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>>> On 01/06/2010 12:07 PM, Miika Komu wrote: >>>>>> >>>>>>> Robert Moskowitz wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>>> Proposed new list for HIP_TRANSFORM: >>>>>>>> >>>>>>>> Suite ID Value >>>>>>>> >>>>>>>> RESERVED 0 >>>>>>>> >>>>>>>> >>> ... >>> >>> >>>>>>>> AES-GCM with a 16 octet ICV 14 [RFC4106] >>>>>>>> >>>>>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions? >>>>>>> >>>>>> I am not sure what you are alluding to here. Key sizes for AES-based transforms start at 128 and go up. If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size. >>>>>> >>>>> do we have to negotiate AES key size? >>>>> >>>> No! We need more suite IDs for the key sizes we're going to use. >>>> >>>> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers. >>>> >>>> >>> I agree. I think we should also tie the MAC Algorithm for the HIP control packets to the transform to avoid a separate negotiation. Or can you imagine a case in which the ESP MAC algorithm and the HIP control channel MAC algorithm should differ? >> >> The HIP control packet MAC algorithm is still HMAC, and it will use the HIH as the underlying hash. There are HIP_TRANSFORMS that do not have a separate MAC, like CCM. >> > > Is it really wise to use the HIH instead of the ESP transform to determine the HIP control packet HMAC hash algorithm? In my opinion, the MAC algorithm from the ESP transform has more in common with the control packet HMAC than the HIH. The HIH is for generating an identity tag and the two other MACs are for integrity protection of packets. Of course, both algorithms need to be supported by both hosts but I can imagine that hosts might want to use stronger and more costly hash functions for generating their identity than they would use for integrity protection. In this regard, the security requirements for control channel hash algorithm are more similar to the ESP HMAC. > I see your point that some transforms don't use a hash function that can be used in an HMAC. If we want to use HMAC for the control channel whose HIH should we use? Initiator or responder? Is it an option to use the same MAC (be it CCM, GCM, HMAC, ...) for the data and control channel? Tobias > > > > -- > > Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From miika.komu@hiit.fi Mon Jan 11 08:52:13 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4413A68D2 for ; Mon, 11 Jan 2010 08:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_20=-0.74, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7Darb+uW-LF for ; Mon, 11 Jan 2010 08:52:12 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 2804C3A6783 for ; Mon, 11 Jan 2010 08:52:12 -0800 (PST) Received: from ip104.infrahip.net (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id 27A0325ED0E for ; Mon, 11 Jan 2010 18:52:09 +0200 (EET) Message-ID: <4B4B5738.9030803@hiit.fi> Date: Mon, 11 Jan 2010 17:52:08 +0100 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] ORCHID RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 16:52:13 -0000 Hi, I assume that the ORCHID RFC will be updated also in addition to the other RFC. I have already a small suggestion. If the prefix changes, it would be nice to get a prefix multiple of eight bits. The current /28 prefix is more prone to developer errors. From thomas.r.henderson@boeing.com Mon Jan 11 09:05:44 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A603A6898 for ; Mon, 11 Jan 2010 09:05:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYKz2v6Gu2Ev for ; Mon, 11 Jan 2010 09:05:44 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1266D3A67F4 for ; Mon, 11 Jan 2010 09:05:44 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0BH5ZgE020879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jan 2010 09:05:39 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0BH5YL1001905 for ; Mon, 11 Jan 2010 09:05:34 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0BH5YLk001891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 11 Jan 2010 09:05:34 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 11 Jan 2010 09:05:34 -0800 From: "Henderson, Thomas R" To: hip WG Date: Mon, 11 Jan 2010 09:05:33 -0800 Thread-Topic: [Hipsec] ORCHID RFC Thread-Index: AcqS3nntrg33w3zPQ/iasmHFmnQT1wAALZsA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A45@XCH-NW-10V.nw.nos.boeing.com> References: <4B4B5738.9030803@hiit.fi> In-Reply-To: <4B4B5738.9030803@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] ORCHID RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 17:05:44 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Miika Komu > Sent: Monday, January 11, 2010 8:52 AM > To: hip WG > Subject: [Hipsec] ORCHID RFC > > Hi, > > I assume that the ORCHID RFC will be updated also in addition to the > other RFC. I have already a small suggestion. If the prefix > changes, it > would be nice to get a prefix multiple of eight bits. The current /28 > prefix is more prone to developer errors. I did not participate in the previous ORCHID discussions with IANA, but som= e questions have arisen during the review cycle of draft-ietf-hip-native-ap= i. 1) what is the process for possibly renewing ORCHID? 2) is 100 bits of hash considered to be enough for the 2nd preimage attack = resistance, or should future ORCHIDs have more hash bits? Was the reason = for setting an expiration date due to concerns that 100 bits was not enough= hash? (I don't recall this being the case but it seems that others may ha= ve this recollection) Thanks, Tom From rgm@htt-consult.com Tue Jan 12 08:01:24 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0944C3A69FB for ; Tue, 12 Jan 2010 08:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSDS8dltQCfM for ; Tue, 12 Jan 2010 08:01:22 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 8DDED3A6953 for ; Tue, 12 Jan 2010 08:01:22 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E49AC68BAC for ; Tue, 12 Jan 2010 16:58:52 +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 htj-Ypr4uQmP for ; Tue, 12 Jan 2010 11:58:43 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id BC23568B91 for ; Tue, 12 Jan 2010 11:58:42 -0500 (EST) Message-ID: <4B4C9C1F.7050309@htt-consult.com> Date: Tue, 12 Jan 2010 07:58:23 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: multipart/alternative; boundary="------------080905010401020704050305" Subject: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 16:01:24 -0000 This is a multi-part message in MIME format. --------------080905010401020704050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tobias and I have been working away on 5201-bis and of course one new thing is the HIH parameter that needs a number... -------- Original Message -------- Subject: Fwd: HIP parameters critical flag Date: Tue, 12 Jan 2010 11:49:51 +0100 From: Tobias Heer To: Robert Moskowitz Hello Bob, > Am 11.01.2010 um 21:54 schrieb Robert Moskowitz: > >> So for defining the new HIH parmeter, I am looking at 5.2.1 and it talks about the critical flag. Oops, of course HIH is critical. So I search for critical in the other parameters and NONE mention being critical. >> >> What am I missing here??? >> > > the C bit is the lowest order bit of the parameter number. All parameters with odd numbers (e.g. Puzzle, Solution, DH ...) are critical. We are going to clearify this in 5201-bis and explicitly state what is a critical parameter. >> Also what is the type value for HIH to get it in the 'right' place in the parameters? >> > The HIH definitely needs to be in the signed part of the packet. I would consider it a parameter that is related to the BEX. The appropriate parameter range would be 0-1023. We probably need to check the HIP extensions to find a free number in this range. I'll do this tomorrow. > I looked at the parameter numbers and I would suggest number 715 because is located behind 705/Host_ID and it is therefore close to it in the actual HIP control packet. I checked the following things for all active HIP drafts and documents that are accessible from the HIP WG status page: * There is no mentioning of the parameter number 715 * The next parameter higher than 705/HOST_ID is 768/Cert (RFC5201 and draft-ietf-hip-cert-02.txt) - there won't be any parameter between HOST_ID and HIH - there is sufficient space between HIH and Cert to introduce new parameters I checked the following files: rfc4423.txt rfc5201.txt rfc5202.txt rfc5203.txt rfc5204.txt rfc5205.txt rfc5206.txt rfc5338.txt draft-ietf-hip-bone-03.txt draft-ietf-hip-cert-02.txt draft-ietf-hip-hiccups-00.txt draft-ietf-hip-nat-traversal-09.txt draft-ietf-hip-native-api-11.txt Any more to check? HIP RG documents? ================================================================= And Miika proposes: I would say that it should be before the ESP_INFO parameter. 63? http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml ==================================================================== So a hum is requested: 715? 63? Other? --------------080905010401020704050305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tobias and I have been working away on 5201-bis and of course one new thing is the HIH parameter that needs a number...

-------- Original Message --------
Subject: Fwd: HIP parameters critical flag
Date: Tue, 12 Jan 2010 11:49:51 +0100
From: Tobias Heer <tobias.heer@gmx.de>
To: Robert Moskowitz <rgm@htt-consult.com> 


Hello Bob, 

> Am 11.01.2010 um 21:54 schrieb Robert Moskowitz:
> 
>> So for defining the new HIH parmeter, I am looking at 5.2.1 and it talks about the critical flag.  Oops, of course HIH is critical.  So I search for critical in the other parameters and NONE mention being critical.
>> 
>> What am I missing here???
>> 
> 
> the C bit is the lowest order bit of the parameter number. All parameters with odd numbers (e.g. Puzzle, Solution, DH ...) are critical. 

We are going to clearify this in 5201-bis and explicitly state what is a critical parameter.
 
>> Also what is the type value for HIH to get it in the 'right' place in the parameters?
>> 
> The HIH definitely needs to be in the signed part of the packet. I would consider it a parameter that is related to the BEX. The appropriate parameter range would be 0-1023. We probably need to check the HIP extensions to find a free number in this range. I'll do this tomorrow.
> 

I looked at the parameter numbers and I would suggest number 715 because is located behind 705/Host_ID and it is therefore close to it in the actual HIP control packet. 

I checked the following things for all active HIP drafts and documents that are accessible from the HIP WG status page:
* There is no mentioning of the parameter number 715
* The next parameter higher than 705/HOST_ID is 768/Cert (RFC5201 and draft-ietf-hip-cert-02.txt)
  - there won't be any parameter between HOST_ID and HIH
  - there is sufficient space between HIH and Cert to introduce new parameters

I checked the following files:

rfc4423.txt
rfc5201.txt
rfc5202.txt
rfc5203.txt
rfc5204.txt
rfc5205.txt
rfc5206.txt
rfc5338.txt
draft-ietf-hip-bone-03.txt
draft-ietf-hip-cert-02.txt
draft-ietf-hip-hiccups-00.txt
draft-ietf-hip-nat-traversal-09.txt
draft-ietf-hip-native-api-11.txt

Any more to check? HIP RG documents?


=================================================================

And Miika proposes:

I would say that it should be before the ESP_INFO parameter. 63?



http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml


====================================================================

So a hum is requested:

715?
63?

Other?
--------------080905010401020704050305-- From heer@informatik.rwth-aachen.de Tue Jan 12 08:35:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DAE28C0F3 for ; Tue, 12 Jan 2010 08:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAH-XAaaWRqJ for ; Tue, 12 Jan 2010 08:35:49 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id AEC033A677D for ; Tue, 12 Jan 2010 08:35:49 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW500DGL7FL8AD0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 17:35:45 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,262,1262559600"; d="scan'208";a="21935403" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 12 Jan 2010 17:35:45 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW50038U7FL7I70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 17:35:45 +0100 (CET) From: Tobias Heer In-reply-to: <4B4C9C1F.7050309@htt-consult.com> Date: Tue, 12 Jan 2010 17:35:46 +0100 Message-id: References: <4B4C9C1F.7050309@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 16:35:51 -0000 Since I suggested it, it makes sense to vote for it: 715 Tobias Am 12.01.2010 um 16:58 schrieb Robert Moskowitz: > Tobias and I have been working away on 5201-bis and of course one new thing is the HIH parameter that needs a number... > > -------- Original Message -------- > Subject: Fwd: HIP parameters critical flag > Date: Tue, 12 Jan 2010 11:49:51 +0100 > From: Tobias Heer > To: Robert Moskowitz > > > > Hello Bob, > >> Am 11.01.2010 um 21:54 schrieb Robert Moskowitz: >> >>> So for defining the new HIH parmeter, I am looking at 5.2.1 and it talks about the critical flag. Oops, of course HIH is critical. So I search for critical in the other parameters and NONE mention being critical. >>> >>> What am I missing here??? >>> >> >> the C bit is the lowest order bit of the parameter number. All parameters with odd numbers (e.g. Puzzle, Solution, DH ...) are critical. > > We are going to clearify this in 5201-bis and explicitly state what is a critical parameter. > >>> Also what is the type value for HIH to get it in the 'right' place in the parameters? >>> >> The HIH definitely needs to be in the signed part of the packet. I would consider it a parameter that is related to the BEX. The appropriate parameter range would be 0-1023. We probably need to check the HIP extensions to find a free number in this range. I'll do this tomorrow. >> > > I looked at the parameter numbers and I would suggest number 715 because is located behind 705/Host_ID and it is therefore close to it in the actual HIP control packet. > > I checked the following things for all active HIP drafts and documents that are accessible from the HIP WG status page: > * There is no mentioning of the parameter number 715 > * The next parameter higher than 705/HOST_ID is 768/Cert (RFC5201 and draft-ietf-hip-cert-02.txt) > - there won't be any parameter between HOST_ID and HIH > - there is sufficient space between HIH and Cert to introduce new parameters > > I checked the following files: > > rfc4423.txt > rfc5201.txt > rfc5202.txt > rfc5203.txt > rfc5204.txt > rfc5205.txt > rfc5206.txt > rfc5338.txt > draft-ietf-hip-bone-03.txt > draft-ietf-hip-cert-02.txt > draft-ietf-hip-hiccups-00.txt > draft-ietf-hip-nat-traversal-09.txt > draft-ietf-hip-native-api-11.txt > > Any more to check? HIP RG documents? > > > ================================================================= > > And Miika proposes: > > I would say that it should be before the ESP_INFO parameter. 63? > > > > http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml > > > ==================================================================== > > So a hum is requested: > > 715? > 63? > > Other? > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Tue Jan 12 09:17:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450323A6A5A for ; Tue, 12 Jan 2010 09:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VD9ZEcaeBc0 for ; Tue, 12 Jan 2010 09:17:50 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id F18513A659B for ; Tue, 12 Jan 2010 09:17:49 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW5007TO9DMO1H0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 18:17:46 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,262,1262559600"; d="scan'208";a="40623381" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 12 Jan 2010 18:17:46 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW5003VS9DL7I70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 18:17:46 +0100 (CET) From: Tobias Heer In-reply-to: <4B4C9C1F.7050309@htt-consult.com> Date: Tue, 12 Jan 2010 18:17:46 +0100 Message-id: References: <4B4C9C1F.7050309@htt-consult.com> To: hip WG X-Mailer: Apple Mail (2.1077) Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:17:51 -0000 Hi, Just one clarification: The suggestion that the HIH and the HI should be close in the packet comes from the fact that the HIH only makes sense in packets that contain the HI (e.g., to check the HI-HIT relation). Therefore, they are closely related and it might be useful to keep both together. Tobias > > I looked at the parameter numbers and I would suggest number 715 because is located behind 705/Host_ID and it is therefore close to it in the actual HIP control packet. > > I checked the following things for all active HIP drafts and documents that are accessible from the HIP WG status page: > * There is no mentioning of the parameter number 715 > * The next parameter higher than 705/HOST_ID is 768/Cert (RFC5201 and draft-ietf-hip-cert-02.txt) > - there won't be any parameter between HOST_ID and HIH > - there is sufficient space between HIH and Cert to introduce new parameters > > I checked the following files: > > rfc4423.txt > rfc5201.txt > rfc5202.txt > rfc5203.txt > rfc5204.txt > rfc5205.txt > rfc5206.txt > rfc5338.txt > draft-ietf-hip-bone-03.txt > draft-ietf-hip-cert-02.txt > draft-ietf-hip-hiccups-00.txt > draft-ietf-hip-nat-traversal-09.txt > draft-ietf-hip-native-api-11.txt > > Any more to check? HIP RG documents? > > > ================================================================= > > And Miika proposes: > > I would say that it should be before the ESP_INFO parameter. 63? > > > > http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml > > > ==================================================================== > > So a hum is requested: > > 715? > 63? > > Other? > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From jeffrey.m.ahrenholz@boeing.com Tue Jan 12 09:25:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129163A67AB for ; Tue, 12 Jan 2010 09:25:41 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzghM98+o8np for ; Tue, 12 Jan 2010 09:25:39 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7206B3A6A9D for ; Tue, 12 Jan 2010 09:25:05 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CHOkqK007482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 09:24:52 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CHOkQM029914; Tue, 12 Jan 2010 11:24:46 -0600 (CST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CHOkYA029898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 11:24:46 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 12 Jan 2010 09:24:46 -0800 From: "Ahrenholz, Jeffrey M" To: "'Tobias Heer'" , Robert Moskowitz Date: Tue, 12 Jan 2010 09:24:44 -0800 Thread-Topic: [Hipsec] HIP parameters critical flag Thread-Index: AcqTpWRMoZbonWNwSC6wV/e19TgxxQABOfPg Message-ID: References: <4B4C9C1F.7050309@htt-consult.com> 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 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:25:41 -0000 > Since I suggested it, it makes sense to vote for it: >=20 > 715 >=20 > Tobias Are you going to include the HIH parameter inside the ENCRYPTED TLV (in the= I2 packet)? If so, it keeping HIH next to HOST_ID with the value 715 makes sense to me.= Otherwise 63 would work.=20 Have you considered extending the HOST_ID TLV by one field to include HIH (= rather than using a separate parameter)? (for example the HI hi_hdr already indicates the RSA/DSA key type, the HIP_= SIGNATURE contains SIG algorithm, etc.) -Jeff >=20 >=20 > Am 12.01.2010 um 16:58 schrieb Robert Moskowitz: >=20 > > Tobias and I have been working away on 5201-bis and of=20 > course one new thing is the HIH parameter that needs a number... > >=20 > > -------- Original Message -------- > > Subject: Fwd: HIP parameters critical flag > > Date: Tue, 12 Jan 2010 11:49:51 +0100 > > From: Tobias Heer > > To: Robert Moskowitz > >=20 > >=20 > >=20 > > Hello Bob, > >=20 > >> Am 11.01.2010 um 21:54 schrieb Robert Moskowitz: > >>=20 > >>> So for defining the new HIH parmeter, I am looking at=20 > 5.2.1 and it talks about the critical flag. Oops, of course=20 > HIH is critical. So I search for critical in the other=20 > parameters and NONE mention being critical. > >>>=20 > >>> What am I missing here??? > >>>=20 > >>=20 > >> the C bit is the lowest order bit of the parameter number.=20 > All parameters with odd numbers (e.g. Puzzle, Solution, DH=20 > ...) are critical. > >=20 > > We are going to clearify this in 5201-bis and explicitly=20 > state what is a critical parameter. > >=20 > >>> Also what is the type value for HIH to get it in the=20 > 'right' place in the parameters? > >>>=20 > >> The HIH definitely needs to be in the signed part of the=20 > packet. I would consider it a parameter that is related to=20 > the BEX. The appropriate parameter range would be 0-1023. We=20 > probably need to check the HIP extensions to find a free=20 > number in this range. I'll do this tomorrow. > >>=20 > >=20 > > I looked at the parameter numbers and I would suggest=20 > number 715 because is located behind 705/Host_ID and it is=20 > therefore close to it in the actual HIP control packet. > >=20 > > I checked the following things for all active HIP drafts=20 > and documents that are accessible from the HIP WG status page: > > * There is no mentioning of the parameter number 715 > > * The next parameter higher than 705/HOST_ID is 768/Cert=20 > (RFC5201 and draft-ietf-hip-cert-02.txt) > > - there won't be any parameter between HOST_ID and HIH > > - there is sufficient space between HIH and Cert to=20 > introduce new parameters > >=20 > > I checked the following files: > >=20 > > rfc4423.txt > > rfc5201.txt > > rfc5202.txt > > rfc5203.txt > > rfc5204.txt > > rfc5205.txt > > rfc5206.txt > > rfc5338.txt > > draft-ietf-hip-bone-03.txt > > draft-ietf-hip-cert-02.txt > > draft-ietf-hip-hiccups-00.txt > > draft-ietf-hip-nat-traversal-09.txt > > draft-ietf-hip-native-api-11.txt > >=20 > > Any more to check? HIP RG documents? > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > And Miika proposes: > >=20 > > I would say that it should be before the ESP_INFO parameter. 63? > >=20 > >=20 > >=20 > > http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > So a hum is requested: > >=20 > > 715? > > 63? > >=20 > > Other? > >=20 > >=20 > >=20 > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec >=20 >=20 >=20 >=20 > -- =20 >=20 > Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group=20 > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > = From rgm@htt-consult.com Tue Jan 12 10:00:34 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63223A6808 for ; Tue, 12 Jan 2010 10:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hkzESPvBAgZ for ; Tue, 12 Jan 2010 10:00:33 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 69DD13A67FD for ; Tue, 12 Jan 2010 10:00:33 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A371868B97; Tue, 12 Jan 2010 18:57:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmUMjmToAugz; Tue, 12 Jan 2010 13:57:47 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DB9D968B41; Tue, 12 Jan 2010 13:57:46 -0500 (EST) Message-ID: <4B4CB807.5090707@htt-consult.com> Date: Tue, 12 Jan 2010 09:57:27 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4B4C9C1F.7050309@htt-consult.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] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:00:35 -0000 On 01/12/2010 09:24 AM, Ahrenholz, Jeffrey M wrote: >> Since I suggested it, it makes sense to vote for it: >> >> 715 >> >> Tobias >> > Are you going to include the HIH parameter inside the ENCRYPTED TLV (in the I2 packet)? > If so, it keeping HIH next to HOST_ID with the value 715 makes sense to me. Otherwise 63 would work. > > Have you considered extending the HOST_ID TLV by one field to include HIH (rather than using a separate parameter)? > (for example the HI hi_hdr already indicates the RSA/DSA key type, the HIP_SIGNATURE contains SIG algorithm, etc.) > I envision multiple HIH per HI. With a possible ranking of HIH for the HI. > -Jeff > > >> >> Am 12.01.2010 um 16:58 schrieb Robert Moskowitz: >> >> >>> Tobias and I have been working away on 5201-bis and of >>> >> course one new thing is the HIH parameter that needs a number... >> >>> -------- Original Message -------- >>> Subject: Fwd: HIP parameters critical flag >>> Date: Tue, 12 Jan 2010 11:49:51 +0100 >>> From: Tobias Heer >>> To: Robert Moskowitz >>> >>> >>> >>> Hello Bob, >>> >>> >>>> Am 11.01.2010 um 21:54 schrieb Robert Moskowitz: >>>> >>>> >>>>> So for defining the new HIH parmeter, I am looking at >>>>> >> 5.2.1 and it talks about the critical flag. Oops, of course >> HIH is critical. So I search for critical in the other >> parameters and NONE mention being critical. >> >>>>> What am I missing here??? >>>>> >>>>> >>>> the C bit is the lowest order bit of the parameter number. >>>> >> All parameters with odd numbers (e.g. Puzzle, Solution, DH >> ...) are critical. >> >>> We are going to clearify this in 5201-bis and explicitly >>> >> state what is a critical parameter. >> >>> >>>>> Also what is the type value for HIH to get it in the >>>>> >> 'right' place in the parameters? >> >>>>> >>>> The HIH definitely needs to be in the signed part of the >>>> >> packet. I would consider it a parameter that is related to >> the BEX. The appropriate parameter range would be 0-1023. We >> probably need to check the HIP extensions to find a free >> number in this range. I'll do this tomorrow. >> >>>> >>> I looked at the parameter numbers and I would suggest >>> >> number 715 because is located behind 705/Host_ID and it is >> therefore close to it in the actual HIP control packet. >> >>> I checked the following things for all active HIP drafts >>> >> and documents that are accessible from the HIP WG status page: >> >>> * There is no mentioning of the parameter number 715 >>> * The next parameter higher than 705/HOST_ID is 768/Cert >>> >> (RFC5201 and draft-ietf-hip-cert-02.txt) >> >>> - there won't be any parameter between HOST_ID and HIH >>> - there is sufficient space between HIH and Cert to >>> >> introduce new parameters >> >>> I checked the following files: >>> >>> rfc4423.txt >>> rfc5201.txt >>> rfc5202.txt >>> rfc5203.txt >>> rfc5204.txt >>> rfc5205.txt >>> rfc5206.txt >>> rfc5338.txt >>> draft-ietf-hip-bone-03.txt >>> draft-ietf-hip-cert-02.txt >>> draft-ietf-hip-hiccups-00.txt >>> draft-ietf-hip-nat-traversal-09.txt >>> draft-ietf-hip-native-api-11.txt >>> >>> Any more to check? HIP RG documents? >>> >>> >>> ================================================================= >>> >>> And Miika proposes: >>> >>> I would say that it should be before the ESP_INFO parameter. 63? >>> >>> >>> >>> http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml >>> >>> >>> ==================================================================== >>> >>> So a hum is requested: >>> >>> 715? >>> 63? >>> >>> Other? >>> >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> >> >> >> -- >> >> Dipl.-Inform. Tobias Heer, Ph.D. Student >> Distributed Systems Group >> RWTH Aachen University, Germany >> tel: +49 241 80 207 76 >> web: http://ds.cs.rwth-aachen.de/members/heer >> >> >> >> >> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> From jeffrey.m.ahrenholz@boeing.com Tue Jan 12 10:27:17 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5988028C119 for ; Tue, 12 Jan 2010 10:27:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzrFrX8jLTkQ for ; Tue, 12 Jan 2010 10:27:16 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id B3DA628C106 for ; Tue, 12 Jan 2010 10:27:16 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CIR26Y016218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 10:27:04 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CIR1HV001310; Tue, 12 Jan 2010 12:27:01 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CIR13b001295 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 12:27:01 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 12 Jan 2010 10:27:01 -0800 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" Date: Tue, 12 Jan 2010 10:27:00 -0800 Thread-Topic: [Hipsec] HIP parameters critical flag Thread-Index: AcqTsoZnxlx1fcdaQ0O4n0mnPe8wkwAAW2xg Message-ID: References: <4B4C9C1F.7050309@htt-consult.com> <4B4CB807.5090707@htt-consult.com> In-Reply-To: <4B4CB807.5090707@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:27:17 -0000 > > Have you considered extending the HOST_ID TLV by one field=20 > to include HIH (rather than using a separate parameter)? > > (for example the HI hi_hdr already indicates the RSA/DSA=20 > key type, the HIP_SIGNATURE contains SIG algorithm, etc.) > > =20 >=20 > I envision multiple HIH per HI. With a possible ranking of=20 > HIH for the HI. It seems hard to rank or negotiate the HIH since the HITs chosen in the HIP= header are already derived using a particular HIH. If you chose a differen= t HIH then you would start a new association using different HITs? Maybe I = don't fully understand HIH yet... -Jeff= From rgm@htt-consult.com Tue Jan 12 10:48:38 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FCF3A6A08 for ; Tue, 12 Jan 2010 10:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aua9BB81GvLG for ; Tue, 12 Jan 2010 10:48:37 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 89E4F3A67E7 for ; Tue, 12 Jan 2010 10:48:37 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5964268B9E; Tue, 12 Jan 2010 19:46:07 +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 Vri0dwkRkNXv; Tue, 12 Jan 2010 14:45:58 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id E0E4A68B93; Tue, 12 Jan 2010 14:45:57 -0500 (EST) Message-ID: <4B4CC351.9010804@htt-consult.com> Date: Tue, 12 Jan 2010 10:45:37 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4B4C9C1F.7050309@htt-consult.com> <4B4CB807.5090707@htt-consult.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] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:48:38 -0000 On 01/12/2010 10:27 AM, Ahrenholz, Jeffrey M wrote: > >>> Have you considered extending the HOST_ID TLV by one field >>> >> to include HIH (rather than using a separate parameter)? >> >>> (for example the HI hi_hdr already indicates the RSA/DSA >>> >> key type, the HIP_SIGNATURE contains SIG algorithm, etc.) >> >>> >>> >> I envision multiple HIH per HI. With a possible ranking of >> HIH for the HI. >> > It seems hard to rank or negotiate the HIH since the HITs chosen in the HIP header are already derived using a particular HIH. If you chose a different HIH then you would start a new association using different HITs? Maybe I don't fully understand HIH yet... > We are both correct :) The way that Tobias and I are working out the changes to BEX to support HIH, I1 will have a HIT based on I's perfered HIH, but listing the HIHs I supports. R1 would either just go with that or respond with R's perfered HIH. In the later case, I would restart BEX with just one HIH, either what is in R1 or guessing it is the victim of a downgrade attack what I suspects is the right HIH to use. Tobias, do you think it would be good to share your revised BEX exchange here? From jeffrey.m.ahrenholz@boeing.com Tue Jan 12 11:51:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFAF3A683B for ; Tue, 12 Jan 2010 11:51:19 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnVa65A3mHhF for ; Tue, 12 Jan 2010 11:51:18 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 8F6603A686A for ; Tue, 12 Jan 2010 11:51:18 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CJp2wJ026095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 13:51:02 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CJp2ng000970; Tue, 12 Jan 2010 13:51:02 -0600 (CST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CJp1Gv000951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 13:51:01 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 12 Jan 2010 11:51:01 -0800 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" Date: Tue, 12 Jan 2010 11:51:00 -0800 Thread-Topic: [Hipsec] HIP parameters critical flag Thread-Index: AcqTt9xRjdUgwuaSQH2crUXcxDj4bAABp36Q Message-ID: References: <4B4C9C1F.7050309@htt-consult.com> <4B4CB807.5090707@htt-consult.com> <4B4CC351.9010804@htt-consult.com> In-Reply-To: <4B4CC351.9010804@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 19:51:19 -0000 > HIH, I1 will have a HIT based on I's perfered HIH, but=20 > listing the HIHs=20 > I supports. R1 would either just go with that or respond with R's=20 > perfered HIH. In the later case, I would restart BEX with=20 > just one HIH,=20 > either what is in R1 or guessing it is the victim of a=20 > downgrade attack what I suspects is the right HIH to use. thanks, that clears it up a bit =20 > Tobias, do you think it would be good to share your revised=20 > BEX exchange here? I overlooked this previous message which Miika pointed out to me: http://www.ietf.org/mail-archive/web/hipsec/current/msg02770.html > Are you going to include the HIH parameter inside the=20 > ENCRYPTED TLV (in the I2 packet)? > If so, it keeping HIH next to HOST_ID with the value 715=20 > makes sense to me. Otherwise 63 would work.=20 Again, I'd say make the value 715 if you plan to include it in ENCRYPTED, o= therwise you may want to leave that value open for future parameters to be = included in ENCRYPTED. -Jeff= From jeffrey.m.ahrenholz@boeing.com Tue Jan 12 11:56:46 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883AE3A68DF for ; Tue, 12 Jan 2010 11:56:46 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw4RMnjSG8+R for ; Tue, 12 Jan 2010 11:56:45 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id BC7203A68AE for ; Tue, 12 Jan 2010 11:56:45 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CJubRA010231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 11:56:40 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CJubG8010181; Tue, 12 Jan 2010 13:56:37 -0600 (CST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CJuaGq010169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 13:56:36 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 12 Jan 2010 11:56:36 -0800 From: "Ahrenholz, Jeffrey M" To: "Ahrenholz, Jeffrey M" , "'Robert Moskowitz'" Date: Tue, 12 Jan 2010 11:56:35 -0800 Thread-Topic: [Hipsec] HIP parameters critical flag Thread-Index: AcqTt9xRjdUgwuaSQH2crUXcxDj4bAABp36QAACREvA= Message-ID: References: <4B4C9C1F.7050309@htt-consult.com><4B4CB807.5090707@htt-consult.com><4B4CC351.9010804@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-6.000.1038-17126.005 x-tm-as-result: No--45.487900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 19:56:46 -0000 > Again, I'd say make the value 715 if you plan to include it=20 > in ENCRYPTED, otherwise you may want to leave that value open=20 > for future parameters to be included in ENCRYPTED. looking more carefully at that previous message, I guess there is no ENCRYP= TED in the I1 packet that will include this info: "I1 packet has to be modified to include the hash, public keys and diffie-hellman algorithms supported by the Initiator in a new "algo" parameter. The parameter should indicate which hash and public key algorithm the Initiator used to generate its HIT." -Jeff= From rgm@htt-consult.com Tue Jan 12 12:06:59 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7E93A6929 for ; Tue, 12 Jan 2010 12:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVOdUW9KBAYy for ; Tue, 12 Jan 2010 12:06:58 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 96A833A6918 for ; Tue, 12 Jan 2010 12:06:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9B90C68B91; Tue, 12 Jan 2010 21:04:23 +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 SqXjY54TuEIc; Tue, 12 Jan 2010 16:04:14 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 64B8B68B8D; Tue, 12 Jan 2010 16:04:14 -0500 (EST) Message-ID: <4B4CD64A.9030102@htt-consult.com> Date: Tue, 12 Jan 2010 12:06:34 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4B4C9C1F.7050309@htt-consult.com><4B4CB807.5090707@htt-consult.com><4B4CC351.9010804@htt-consult.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] HIP parameters critical flag X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 20:06:59 -0000 oops on that last transmit. I "blame" it on a new install with a new version of Thunderbird.... Right... On 01/12/2010 11:56 AM, Ahrenholz, Jeffrey M wrote: >> Again, I'd say make the value 715 if you plan to include it >> in ENCRYPTED, otherwise you may want to leave that value open >> for future parameters to be included in ENCRYPTED. >> > looking more carefully at that previous message, I guess there is no ENCRYPTED in the I1 packet that will include this info: > > "I1 packet has to be modified to include the hash, public keys and > diffie-hellman algorithms supported by the Initiator in a new "algo" > parameter. The parameter should indicate which hash and public key > algorithm the Initiator used to generate its HIT." > And thus a new downgrade attack that we need to mitigate. And Tobias figured it out better than I did, so he gets to present it! From thomas.r.henderson@boeing.com Tue Jan 12 12:35:57 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DEBA3A686A for ; Tue, 12 Jan 2010 12:35:57 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3jYxvAYvb5x for ; Tue, 12 Jan 2010 12:35:56 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 9BD843A68C1 for ; Tue, 12 Jan 2010 12:35:56 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CKZnip003668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 12:35:50 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CKZnK4013464; Tue, 12 Jan 2010 12:35:49 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CKZnid013459 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 12:35:49 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 12 Jan 2010 12:35:49 -0800 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" , "hipsec@ietf.org" Date: Tue, 12 Jan 2010 12:35:48 -0800 Thread-Topic: [Hipsec] Changing HIP BEX to support crypto agility Thread-Index: Acp4eE52m1krt+5tTCSEfen/7Sr6/gbS7avg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> References: <4B1F0D12.2070104@htt-consult.com> In-Reply-To: <4B1F0D12.2070104@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 20:35:57 -0000 > 2.) We have several hash algos for HITs now and it cannot be assumed > that every host supports every algo. > HI bindings > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A host may now have a number of HIs (several signature > algorithms). This > results in the question how to bind these HIs together. Until now we > have only discussed a DNS-(sec)-based binding but other bindings are > also possible (certificates, etc). However, the question of > signature-algo compatibility remains. If the signature > algorithm of the > certificate is not understood, the binding is useless. In general, it > would probably make sense to not use crypto agility as a > "comfort tool" > that enables to use of any arbitrary combination of > algorithms but as a > tool that enables to increase the security of the system whenever the > currently used algorithms are threatened. Otherwise we will > end up with > hosts that have a large number of HIs and even more HITs. > Hmm, I am wondering what are the implications of this on the users and high= er layer protocols. What identifiers are the sockets bound to if the HITs = may later change (note: opportunistic mode has this problem already)? Wha= t name(s) do applications use to refer to the peer host? This seems to be = heading us more towards a cert-based architecture above HIP to manage bindi= ngs between the stable names (such as FQDN) and the various HIP names. No= t that I think that such a move is bad, but perhaps we need to be more expl= icit in sketching out the implications. - Tom From heer@informatik.rwth-aachen.de Tue Jan 12 13:24:52 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1C93A68A0 for ; Tue, 12 Jan 2010 13:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbh5rEyXdFpK for ; Tue, 12 Jan 2010 13:24:51 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 0E20A3A6895 for ; Tue, 12 Jan 2010 13:24:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW500KUVKTBOB40@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 22:24:47 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,264,1262559600"; d="scan'208";a="40645874" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 12 Jan 2010 22:24:47 +0100 Received: from [192.168.3.237] ([unknown] [87.65.8.186]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW5009MVKTAA500@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 22:24:47 +0100 (CET) From: Tobias Heer In-reply-to: Date: Tue, 12 Jan 2010 22:24:47 +0100 Message-id: References: <4B4C9C1F.7050309@htt-consult.com> <"AC120305-F2D2-428D-BFCB-CB12A 4114598"@cs.rwth-aachen.de> <4B4CB807.5090707@htt-consult.com> <"FD98F9C3CBABA74E 89B5D4B5DE0263B937813030CA"@XCH-NW-12V.nw.nos.boeing.com> <4B4CC351.9010804@htt-consult.com> To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org" Subject: [Hipsec] HI Parameter (was: HIP parameters critical flag) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 21:24:52 -0000 Hi Jeff, Am 12.01.2010 um 20:56 schrieb Ahrenholz, Jeffrey M: >> Again, I'd say make the value 715 if you plan to include it >> in ENCRYPTED, otherwise you may want to leave that value open >> for future parameters to be included in ENCRYPTED. > > looking more carefully at that previous message, I guess there is no ENCRYPTED in the I1 packet that will include this info: > > "I1 packet has to be modified to include the hash, public keys and > diffie-hellman algorithms supported by the Initiator in a new "algo" > parameter. The parameter should indicate which hash and public key > algorithm the Initiator used to generate its HIT." > > -Jeff > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec The purpose of the HIH parameter is to convey which hash function was used to generate the HIT used by a host. It is needed to verify the relation between HI and HIT because multiple algorithms. As far as I can see, there are four options to transfer the information: a) as part of the HIT - this option takes bits from the HIT that could otherwise be used for cryptographic purposes. It raised serious concerns about security and extendability. b) as part of the HIP header (close to the HIT itself) - this would make sense from a conceptual point but the information is only needed when verifying the HI/HIT relationship. Putting it into every packet would be overkill. c) as part of the HI parameter - this would make sense from a usage point of view but conceptually, the HIH is not part of the HI. Mixing these two might confuse people. Depending on the HIT in the HIP header, different HIs would be used. d) as extra parameter - this provides a distinction between HOST_ID and HIH. However, the space requirements for an own TLV are slightly higher than for options a, b, and c. I agree that c) and d) are valid and (in my opinion) good options. In which packets do we need the HIH parameter? In my opinion, we need the parameter in all packets that may trigger a verification of the HI-HIT relationship. This means R1 and I2 during the BEX. In general every packet that contains a HI should probably have a HIH parameter. However, I am not sure if there are any extension for which this rule of thumb fails. The list that Bob mentions is not necessarily a collections of HIH parameters. The HIH contains an index to the hash function used, the list contains several indexes. The list could be a separate parameter to avoid confusion and context-sensitive interpretation of the HIH. I will include some thoughts about crypto agility for the HIH below. The following text contains some thoughts for a BEX in which the Initiator does not know the HIHs supported by the Responder before the BEX: The Initiator initiates the BEX with an I1 packet. The Initiator picks source HIT and HIH based on local policies. The Responder responds to the I1 with an ordinary R1 with the exception that the R1 contains a list of supported HIH hash functions in the signed part of the R1. When receiving the R1, the Initiator verifies the signature in the R1 packet. If the signature is valid, it looks at the list of HIHs. If the previously selected initiator source HIT is amongst the supported HIHs, the Initiator continues with an I2 packet. If not it may restart the BEX with an I1 and a different source HIT. An attacker could try to launch a downgrade attack here but this will not be successful. I will explain the attack anyway. The attacker could store a old R1 message containing a HIH list with weak algorithms and replay it to the initiator even if the Responder upgrades its algorithms to stronger ones. The initiator would restart its BEX after receiving this replayed R1 - using the weaker algorithms. It sends a new I1 with a weaker HIT. So far the attack seems to be working. The next step is where it fails. The Responder will send an R1 message as response to the weaker source HI in the I1. This fresh R1 contains the HIH list (with the stronger algorithms) in the signed part of the packet, thereby revealing the attack. Moreover, the R1 counters will not match (huge gaps). This can even be noticed by security middleboxes. If the Attacker would decide to continue replaying the old R1 to the new (downgraded I1), the initiator would send a I2 with an invalid R1 counter and a wrong HMAC because the DH public key in the replayed R1 are not valid any more. -> No successful downgrade due to the list in the R1. I hope this gives enough context to understand my perception of the HIH parameter and the need for the HIH list. Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Tue Jan 12 13:40:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E233A68EA for ; Tue, 12 Jan 2010 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd2x3-5Q9KlQ for ; Tue, 12 Jan 2010 13:40:02 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 617473A68B7 for ; Tue, 12 Jan 2010 13:40:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW500C2TLIMZZH0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 22:39:58 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,264,1262559600"; d="scan'208";a="40647240" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 12 Jan 2010 22:40:00 +0100 Received: from [192.168.3.237] ([unknown] [87.65.8.186]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW5009U1LILA500@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 12 Jan 2010 22:39:58 +0100 (CET) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> Date: Tue, 12 Jan 2010 22:39:58 +0100 Message-id: <3CE3C99E-6635-4F78-94E1-E1582C35F533@cs.rwth-aachen.de> References: <4B1F0D12.2070104@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> To: "hipsec@ietf.org WG" X-Mailer: Apple Mail (2.1077) Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 21:40:03 -0000 Hi Tom, Am 12.01.2010 um 21:35 schrieb Henderson, Thomas R: >> 2.) We have several hash algos for HITs now and it cannot be assumed >> that every host supports every algo. > > > >> HI bindings >> =================== >> A host may now have a number of HIs (several signature >> algorithms). This >> results in the question how to bind these HIs together. Until now we >> have only discussed a DNS-(sec)-based binding but other bindings are >> also possible (certificates, etc). However, the question of >> signature-algo compatibility remains. If the signature >> algorithm of the >> certificate is not understood, the binding is useless. In general, it >> would probably make sense to not use crypto agility as a >> "comfort tool" >> that enables to use of any arbitrary combination of >> algorithms but as a >> tool that enables to increase the security of the system whenever the >> currently used algorithms are threatened. Otherwise we will >> end up with >> hosts that have a large number of HIs and even more HITs. >> > > Hmm, I am wondering what are the implications of this on the users and higher layer protocols. What identifiers are the sockets bound to if the HITs may later change (note: opportunistic mode has this problem already)? We had a long discussion in Helsinki about changing HITs during a BEX or during an established HIP association. The general opinion was that this is a) complicated and b) would break application-layer bindings (as you noticed in your question). We discussed two possible solutions in the e-mail you are referring to. Solution 2 (resolver selects algorithms) seemed to be the more practical one. The idea was to only present destination HITs to the application for which the resolver verified that the Initiator can use these (because it supports the HIH used for generating the HIT). That way, the application would open a socket with a proper destination HIT and there would not be a need for changing it on the fly. Of course, the resolver must be supplied with the information which HIH was used for generating a certain HIT. This information could also come from the DNS. Tobias > What name(s) do applications use to refer to the peer host? This seems to be heading us more towards a cert-based architecture above HIP to manage bindings between the stable names (such as FQDN) and the various HIP names. Not that I think that such a move is bad, but perhaps we need to be more explicit in sketching out the implications. > > - Tom > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From thomas.r.henderson@boeing.com Tue Jan 12 14:40:37 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064D73A6878 for ; Tue, 12 Jan 2010 14:40:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdEdR+2oxblT for ; Tue, 12 Jan 2010 14:40:36 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 041513A68B2 for ; Tue, 12 Jan 2010 14:40:35 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CMeQ0B017840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2010 14:40:28 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CMeQB6024387; Tue, 12 Jan 2010 16:40:26 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CMePoQ024366 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 16:40:26 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 12 Jan 2010 14:40:25 -0800 From: "Henderson, Thomas R" To: "'Tobias Heer'" , "hipsec@ietf.org WG" Date: Tue, 12 Jan 2010 14:40:24 -0800 Thread-Topic: [Hipsec] Changing HIP BEX to support crypto agility Thread-Index: AcqT0FMSeHbiy9kUQl2QKtn2F7A7OgAAz28g Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> References: <4B1F0D12.2070104@htt-consult.com><7CC566635CFE364D87DC5803D4712A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> <3CE3C99E-6635-4F78-94E1-E1582C35F533@cs.rwth-aachen.de> In-Reply-To: <3CE3C99E-6635-4F78-94E1-E1582C35F533@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 22:40:37 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Tuesday, January 12, 2010 1:40 PM > To: hipsec@ietf.org WG > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility > > > > > Hmm, I am wondering what are the implications of this on > the users and higher layer protocols. What identifiers are > the sockets bound to if the HITs may later change (note: > opportunistic mode has this problem already)? > > We had a long discussion in Helsinki about changing HITs > during a BEX or during an established HIP association. The > general opinion was that this is a) complicated and b) would > break application-layer bindings (as you noticed in your > question). We discussed two possible solutions in the e-mail > you are referring to. Solution 2 (resolver selects > algorithms) seemed to be the more practical one. The idea was > to only present destination HITs to the application for which > the resolver verified that the Initiator can use these > (because it supports the HIH used for generating the HIT). > That way, the application would open a socket with a proper > destination HIT and there would not be a need for changing it > on the fly. Of course, the resolver must be supplied with the > information which HIH was used for generating a certain HIT. > This information could also come from the DNS. Hi Tobias, Thanks for the quick reply. My main point is that we should be clear about where the architecture is headed. In this case, the recommended solution relies on DNS(sec) (and the security of the client resolver) to manage this situation. How will it work in the absence of DNS? (I recall people going to the mike in meetings past, pleading that we do not bake in a DNS dependency to HIP.) - Tom From rgm@htt-consult.com Tue Jan 12 15:15:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BF73A6916 for ; Tue, 12 Jan 2010 15:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKehccRjHRrn for ; Tue, 12 Jan 2010 15:15:22 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7F3D43A67EA for ; Tue, 12 Jan 2010 15:15:13 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 99CCB68BB1; Wed, 13 Jan 2010 00:12:43 +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 VEztFynIbWEH; Tue, 12 Jan 2010 19:12:34 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DDADC68B22; Tue, 12 Jan 2010 19:12:33 -0500 (EST) Message-ID: <4B4D01C9.3030607@htt-consult.com> Date: Tue, 12 Jan 2010 15:12:09 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B1F0D12.2070104@htt-consult.com><7CC566635CFE364D87DC5803D4712A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> <3CE3C99E-6635-4F78-94E1-E1582C35F533@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 23:15:23 -0000 On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >> Sent: Tuesday, January 12, 2010 1:40 PM >> To: hipsec@ietf.org WG >> Cc: Henderson, Thomas R >> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility >> >> >>> Hmm, I am wondering what are the implications of this on >>> >> the users and higher layer protocols. What identifiers are >> the sockets bound to if the HITs may later change (note: >> opportunistic mode has this problem already)? >> >> We had a long discussion in Helsinki about changing HITs >> during a BEX or during an established HIP association. The >> general opinion was that this is a) complicated and b) would >> break application-layer bindings (as you noticed in your >> question). We discussed two possible solutions in the e-mail >> you are referring to. Solution 2 (resolver selects >> algorithms) seemed to be the more practical one. The idea was >> to only present destination HITs to the application for which >> the resolver verified that the Initiator can use these >> (because it supports the HIH used for generating the HIT). >> That way, the application would open a socket with a proper >> destination HIT and there would not be a need for changing it >> on the fly. Of course, the resolver must be supplied with the >> information which HIH was used for generating a certain HIT. >> This information could also come from the DNS. >> > Hi Tobias, > Thanks for the quick reply. My main point is that we should be > clear about where the architecture is headed. In this case, the > recommended solution relies on DNS(sec) (and the security of the > client resolver) to manage this situation. How will it work in > the absence of DNS? (I recall people going to the mike in > meetings past, pleading that we do not bake in a DNS dependency > to HIP.) Whatever mechanism you use to get a HIT, you also have to get the HIH. If the base information is the HI from which you derive a HIT, there must be a list of HIHs (min size = 1) in perfered order to use. In opertunistic mode I would have to provide a list of HIHs it can handle so that R can send a usable R1 to it. From thomas.r.henderson@boeing.com Tue Jan 12 15:36:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1F23A68CB for ; Tue, 12 Jan 2010 15:36:35 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNGnFkT-DDsj for ; Tue, 12 Jan 2010 15:36:34 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id CBE9D3A68B6 for ; Tue, 12 Jan 2010 15:36:34 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0CNaN8G011915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 15:36:25 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0CNaNjx002338; Tue, 12 Jan 2010 15:36:23 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0CNaMdA002326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jan 2010 15:36:23 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Tue, 12 Jan 2010 15:36:22 -0800 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Tue, 12 Jan 2010 15:36:21 -0800 Thread-Topic: [Hipsec] Changing HIP BEX to support crypto agility Thread-Index: AcqT3RbegYpB2S62Q/GZZfNHEMF2AwAAVFyQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> References: <4B1F0D12.2070104@htt-consult.com><7CC566635CFE364D87DC5803D4712 A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> <3CE3C99E-6635-4F78-94E1-E1582C 35F533@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> <4B4D01C9.3030607@htt-consult.com> In-Reply-To: <4B4D01C9.3030607@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 23:36:35 -0000 > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > Sent: Tuesday, January 12, 2010 3:12 PM > To: Henderson, Thomas R > Cc: 'Tobias Heer'; hipsec@ietf.org WG > Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility > > On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: > > > > > >> -----Original Message----- > >> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > >> Sent: Tuesday, January 12, 2010 1:40 PM > >> To: hipsec@ietf.org WG > >> Cc: Henderson, Thomas R > >> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility > >> > >> > >>> Hmm, I am wondering what are the implications of this on > >>> > >> the users and higher layer protocols. What identifiers are > >> the sockets bound to if the HITs may later change (note: > >> opportunistic mode has this problem already)? > >> > >> We had a long discussion in Helsinki about changing HITs > >> during a BEX or during an established HIP association. The > >> general opinion was that this is a) complicated and b) would > >> break application-layer bindings (as you noticed in your > >> question). We discussed two possible solutions in the e-mail > >> you are referring to. Solution 2 (resolver selects > >> algorithms) seemed to be the more practical one. The idea was > >> to only present destination HITs to the application for which > >> the resolver verified that the Initiator can use these > >> (because it supports the HIH used for generating the HIT). > >> That way, the application would open a socket with a proper > >> destination HIT and there would not be a need for changing it > >> on the fly. Of course, the resolver must be supplied with the > >> information which HIH was used for generating a certain HIT. > >> This information could also come from the DNS. > >> > > Hi Tobias, > > Thanks for the quick reply. My main point is that we should be > > clear about where the architecture is headed. In this case, the > > recommended solution relies on DNS(sec) (and the security of the > > client resolver) to manage this situation. How will it work in > > the absence of DNS? (I recall people going to the mike in > > meetings past, pleading that we do not bake in a DNS dependency > > to HIP.) > > Whatever mechanism you use to get a HIT, you also have to get > the HIH. > If the base information is the HI from which you derive a HIT, there > must be a list of HIHs (min size =3D 1) in perfered order to use. > An implication seems to be that the fact that a HIT is 128 bits long is less interesting since you also need the HIH. Should this be considered in future ORCHIDs (to somehow encode the HIH within the 128 bits)? - Tom From rgm@htt-consult.com Tue Jan 12 16:00:46 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66A83A68E0 for ; Tue, 12 Jan 2010 16:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW7pcmehBBKA for ; Tue, 12 Jan 2010 16:00:45 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9D97E3A68CB for ; Tue, 12 Jan 2010 16:00:45 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AA9CB68BB1; Wed, 13 Jan 2010 00:58:15 +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 psoh-i4O4Ja3; Tue, 12 Jan 2010 19:58:06 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.43]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 9D6B268B93; Tue, 12 Jan 2010 19:58:05 -0500 (EST) Message-ID: <4B4D0C7E.7010106@htt-consult.com> Date: Tue, 12 Jan 2010 15:57:50 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B1F0D12.2070104@htt-consult.com><7CC566635CFE364D87DC5803D4712 A6C4C1CAF1A61@XCH-NW-10V.nw.nos.boeing.com> <3CE3C99E-6635-4F78-94E1-E1582C 35F533@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> <4B4D01C9.3030607@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 00:00:46 -0000 On 01/12/2010 03:36 PM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Robert Moskowitz [mailto:rgm@htt-consult.com] >> Sent: Tuesday, January 12, 2010 3:12 PM >> To: Henderson, Thomas R >> Cc: 'Tobias Heer'; hipsec@ietf.org WG >> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility >> >> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] >>>> Sent: Tuesday, January 12, 2010 1:40 PM >>>> To: hipsec@ietf.org WG >>>> Cc: Henderson, Thomas R >>>> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility >>>> >>>> >>>> >>>>> Hmm, I am wondering what are the implications of this on >>>>> >>>>> >>>> the users and higher layer protocols. What identifiers are >>>> the sockets bound to if the HITs may later change (note: >>>> opportunistic mode has this problem already)? >>>> >>>> We had a long discussion in Helsinki about changing HITs >>>> during a BEX or during an established HIP association. The >>>> general opinion was that this is a) complicated and b) would >>>> break application-layer bindings (as you noticed in your >>>> question). We discussed two possible solutions in the e-mail >>>> you are referring to. Solution 2 (resolver selects >>>> algorithms) seemed to be the more practical one. The idea was >>>> to only present destination HITs to the application for which >>>> the resolver verified that the Initiator can use these >>>> (because it supports the HIH used for generating the HIT). >>>> That way, the application would open a socket with a proper >>>> destination HIT and there would not be a need for changing it >>>> on the fly. Of course, the resolver must be supplied with the >>>> information which HIH was used for generating a certain HIT. >>>> This information could also come from the DNS. >>>> >>>> >>> Hi Tobias, >>> Thanks for the quick reply. My main point is that we should be >>> clear about where the architecture is headed. In this case, the >>> recommended solution relies on DNS(sec) (and the security of the >>> client resolver) to manage this situation. How will it work in >>> the absence of DNS? (I recall people going to the mike in >>> meetings past, pleading that we do not bake in a DNS dependency >>> to HIP.) >>> >> Whatever mechanism you use to get a HIT, you also have to get >> the HIH. >> If the base information is the HI from which you derive a HIT, there >> must be a list of HIHs (min size = 1) in perfered order to use. >> >> > An implication seems to be that the fact that a HIT is 128 bits long > is less interesting since you also need the HIH. Should this > be considered in future ORCHIDs (to somehow encode the HIH within > the 128 bits)? We have beaten this thought around and have no real conclusion. So far we are leaving it out to not shrink the collision space more than it is already. I may still need to include a HIH list in I1, as the HIT it 'discovered' might not be what R perfers to use given the HIHs supported by I? This is another area that Tobias, Miika, and I have discussed: Can I and R use different HIHs for their respective HITs. Should be allowed. Given an intersection of I(HIH) and R(HIH) does I or R select a common HIH? Of course so far we only have two HIHs: SHA1 and SHA2. I am seeing the recommendation of SHA-384 to be used with AES 256 in RFC 4869, but I am still plowing through this, and this only impacts the HIP and ESP transforms not the has to use on a HI. Better to leave HIH to SHA1 and SHA2 until the completion of the hash competition, IMHO. From heer@informatik.rwth-aachen.de Wed Jan 13 00:46:18 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959583A6A6A for ; Wed, 13 Jan 2010 00:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGghj4M9esSK for ; Wed, 13 Jan 2010 00:46:17 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 7881F3A6A66 for ; Wed, 13 Jan 2010 00:46:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW6007IVGD18UB0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 13 Jan 2010 09:46:13 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,267,1262559600"; d="scan'208";a="21975971" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 13 Jan 2010 09:46:13 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW6009GLGD1A570@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 13 Jan 2010 09:46:13 +0100 (CET) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> Date: Wed, 13 Jan 2010 09:46:14 +0100 Message-id: <1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> References: <4B1F0D12.2070104@htt-consult.com> <"7CC566635CFE364D87DC5803D4712 A6C4C1CAF1A61"@XCH-NW-10V.nw.nos.boeing.com> <"3CE3C99E-6635-4F78-94E1-E1582C 35F533"@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> <4B4D01C9.3030607@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> To: "hipsec@ietf.org WG" X-Mailer: Apple Mail (2.1077) Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 08:46:18 -0000 Am 13.01.2010 um 00:36 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: Robert Moskowitz [mailto:rgm@htt-consult.com] [...] >> Whatever mechanism you use to get a HIT, you also have to get >> the HIH. >> If the base information is the HI from which you derive a HIT, there >> must be a list of HIHs (min size = 1) in perfered order to use. >> > >> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: > An implication seems to be that the fact that a HIT is 128 bits long > is less interesting since you also need the HIH. Should this > be considered in future ORCHIDs (to somehow encode the HIH within > the 128 bits)? > > - Tom I still think that having a IPv6 compatible HIT is useful because a longer HIT is difficult to use in the stack. For legacy-style applications (which work quite nicely with HIP right now), a larger HIT would lead to another mapping. Moreover, the HIH is only needed within HIP (and the resolver). It is not needed by the application and will probably not be exposed to it. In my opinion, we could keep the application interface as it is now, even with the HIH. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Wed Jan 13 01:36:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B20B3A6827 for ; Wed, 13 Jan 2010 01:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xnvacTGAFRm for ; Wed, 13 Jan 2010 01:36:05 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 724F03A6817 for ; Wed, 13 Jan 2010 01:36:05 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 45F4068B84; Wed, 13 Jan 2010 10:33:34 +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 GCObGDKMqoAO; Wed, 13 Jan 2010 05:33:25 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.10]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DAFC768B26; Wed, 13 Jan 2010 05:33:24 -0500 (EST) Message-ID: <4B4D93F5.1000909@htt-consult.com> Date: Wed, 13 Jan 2010 01:35:49 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Tobias Heer References: <4B1F0D12.2070104@htt-consult.com> <"7CC566635CFE364D87DC5803D4712 A6C4C1CAF1A61"@XCH-NW-10V.nw.nos.boeing.com> <"3CE3C99E-6635-4F78-94E1-E1582C 35F533"@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@XCH-NW-10V.nw.nos.boeing.com> <4B4D01C9.3030607@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com> <1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> In-Reply-To: <1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 09:36:06 -0000 On 01/13/2010 12:46 AM, Tobias Heer wrote: > Am 13.01.2010 um 00:36 schrieb Henderson, Thomas R: > > >> >> >>> -----Original Message----- >>> From: Robert Moskowitz [mailto:rgm@htt-consult.com] >>> > [...] > > >>> Whatever mechanism you use to get a HIT, you also have to get >>> the HIH. >>> If the base information is the HI from which you derive a HIT, there >>> must be a list of HIHs (min size = 1) in perfered order to use. >>> >>> >> >>> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: >>> >> An implication seems to be that the fact that a HIT is 128 bits long >> is less interesting since you also need the HIH. Should this >> be considered in future ORCHIDs (to somehow encode the HIH within >> the 128 bits)? >> >> - Tom >> > I still think that having a IPv6 compatible HIT is useful because a longer HIT is difficult to use in the stack. For legacy-style applications (which work quite nicely with HIP right now), a larger HIT would lead to another mapping. > Moreover, the HIH is only needed within HIP (and the resolver). It is not needed by the application and will probably not be exposed to it. In my opinion, we could keep the application interface as it is now, even with the HIH. > > I think Tom was thinking about a different context for each HIH. Or a couple bits out of the 128 allocated as the HIH value. With the first option, I don't think you can back derive the HIH from the HIT, so nothing really gained. With the second option you increase the collision risk. But others might have a different take on this item... From root@core3.amsl.com Wed Jan 13 08:15:02 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 13B0B3A67D4; Wed, 13 Jan 2010 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100113161502.13B0B3A67D4@core3.amsl.com> Date: Wed, 13 Jan 2010 08:15:02 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-api-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Basic Socket Interface Extensions for Host Identity Protocol (HIP) Author(s) : M. Komu, T. Henderson Filename : draft-ietf-hip-native-api-12.txt Pages : 19 Date : 2010-01-13 This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-native-api-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-13080430.I-D@ietf.org> --NextPart-- From thomas.r.henderson@boeing.com Wed Jan 13 08:46:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495973A687F for ; Wed, 13 Jan 2010 08:46:06 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LayRWds9GBTx for ; Wed, 13 Jan 2010 08:46:05 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 47ED23A680B for ; Wed, 13 Jan 2010 08:46:05 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0DGjp9c010752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2010 10:45:57 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0DGjpfX020643; Wed, 13 Jan 2010 10:45:51 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0DGjpAp020592 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jan 2010 10:45:51 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 13 Jan 2010 08:45:50 -0800 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" , Tobias Heer Date: Wed, 13 Jan 2010 08:45:50 -0800 Thread-Topic: [Hipsec] Changing HIP BEX to support crypto agility Thread-Index: AcqUM9VZTEZv8pS2QpmOTuayEbV4vQAN4NXQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A70@XCH-NW-10V.nw.nos.boeing.com> References: <4B1F0D12.2070104@htt-consult.com><"7CC566635CFE364D87DC5803D471 2 A6C4C1CAF1A61"@XCH-NW-10V.nw.nos.boeing.com> <"3CE3C99E-6635-4F78-94E1-E1 582C35F533"@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A65@ XCH-NW-10V.nw.nos.boeing.com> <4B4D01C9.3030607@htt-consult.com> <7CC566635 CFE364D87DC5803D4712A6C4C1CAF1A6B@XCH-NW-10V.nw.nos.boeing.com><1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> <4B4D93F5.1000909@htt-consult.com> In-Reply-To: <4B4D93F5.1000909@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:46:06 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: Wednesday, January 13, 2010 1:36 AM > To: Tobias Heer > Cc: hipsec@ietf.org WG > Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility > > On 01/13/2010 12:46 AM, Tobias Heer wrote: > > Am 13.01.2010 um 00:36 schrieb Henderson, Thomas R: > > > > > >> > >> > >>> -----Original Message----- > >>> From: Robert Moskowitz [mailto:rgm@htt-consult.com] > >>> > > [...] > > > > > >>> Whatever mechanism you use to get a HIT, you also have to get > >>> the HIH. > >>> If the base information is the HI from which you derive a > HIT, there > >>> must be a list of HIHs (min size =3D 1) in perfered order to use. > >>> > >>> > >> > >>> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: > >>> > >> An implication seems to be that the fact that a HIT is 128 > bits long > >> is less interesting since you also need the HIH. Should this > >> be considered in future ORCHIDs (to somehow encode the HIH within > >> the 128 bits)? > >> > >> - Tom > >> > > I still think that having a IPv6 compatible HIT is useful > because a longer HIT is difficult to use in the stack. For > legacy-style applications (which work quite nicely with HIP > right now), a larger HIT would lead to another mapping. > > Moreover, the HIH is only needed within HIP (and the > resolver). It is not needed by the application and will > probably not be exposed to it. In my opinion, we could keep > the application interface as it is now, even with the HIH. > > > > > > I think Tom was thinking about a different context for each > HIH. Or a > couple bits out of the 128 allocated as the HIH value. Yes. > > With the first option, I don't think you can back derive the HIH from > the HIT, so nothing really gained. > > With the second option you increase the collision risk. The issue I was thinking about is that if it becomes commonplace to just use HITs as names in lots of places because it is 128-bits long, it seems to be odd that you will not be able to know the hash used to construct the HIT just by inspecting the HIT. And if the day comes when a hash is deprecated, how do you know whether the HIT you have of a peer system should be deprecated? I suppose that you can try to run the base exchange with them to learn the HIH. But it may be that people just start to store the HIH with the HIT explicitly. I had a separate question on the list recently about the process for renewing ORCHID and whether changes need to be made. I don't know how /28 was arrived at, and whether e.g. 4 bits of the prefix space could be reclaimed to encode HIH, or whether more bits are needed for hash output. Tom From heer@informatik.rwth-aachen.de Wed Jan 13 11:25:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DF83A69E0 for ; Wed, 13 Jan 2010 11:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HamMgnaU0kt6 for ; Wed, 13 Jan 2010 11:25:34 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 2E4CA3A69A3 for ; Wed, 13 Jan 2010 11:25:34 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KW7000VO9YHWMC0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 13 Jan 2010 20:25:29 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,269,1262559600"; d="scan'208";a="40789962" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 13 Jan 2010 20:25:29 +0100 Received: from [192.168.3.237] ([unknown] [87.65.4.145]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KW700DU79XDSR80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 13 Jan 2010 20:25:29 +0100 (CET) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A70@XCH-NW-10V.nw.nos.boeing.com> Date: Wed, 13 Jan 2010 20:25:30 +0100 Message-id: <42FEAEA1-EE3F-49FE-AF50-99D36B579105@cs.rwth-aachen.de> References: <4B1F0D12.2070104@htt-consult.com> <"7CC566635CFE364D87DC5803D471 2 A6C4C1CAF1A61"@XCH-NW-10V.nw.nos.boeing.com> <"3CE3C99E-6635-4F78-94E1-E1 582C35F533"@cs.rwth-aachen.de> <4B4D01C9.3030607@htt-consult.com> <"7CC566635 CFE364D87DC5803D4712A6C4C1CAF1A6B"@XCH-NW-10V.nw.nos.boeing.com> <1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> <4B4D93F5.1000909@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A70@XCH-NW-10V.nw.nos.boeing.com> To: "hipsec@ietf.org WG" X-Mailer: Apple Mail (2.1077) Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:25:35 -0000 Hello Tom, Am 13.01.2010 um 17:45 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Robert Moskowitz >> Sent: Wednesday, January 13, 2010 1:36 AM >> To: Tobias Heer >> Cc: hipsec@ietf.org WG >> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility >> >> On 01/13/2010 12:46 AM, Tobias Heer wrote: >>> Am 13.01.2010 um 00:36 schrieb Henderson, Thomas R: >>> >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Robert Moskowitz [mailto:rgm@htt-consult.com] >>>>> >>> [...] >>> >>> >>>>> Whatever mechanism you use to get a HIT, you also have to get >>>>> the HIH. >>>>> If the base information is the HI from which you derive a >> HIT, there >>>>> must be a list of HIHs (min size = 1) in perfered order to use. >>>>> >>>>> >>>> >>>>> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: >>>>> >>>> An implication seems to be that the fact that a HIT is 128 >> bits long >>>> is less interesting since you also need the HIH. Should this >>>> be considered in future ORCHIDs (to somehow encode the HIH within >>>> the 128 bits)? >>>> >>>> - Tom >>>> >>> I still think that having a IPv6 compatible HIT is useful >> because a longer HIT is difficult to use in the stack. For >> legacy-style applications (which work quite nicely with HIP >> right now), a larger HIT would lead to another mapping. >>> Moreover, the HIH is only needed within HIP (and the >> resolver). It is not needed by the application and will >> probably not be exposed to it. In my opinion, we could keep >> the application interface as it is now, even with the HIH. >>> >>> >> >> I think Tom was thinking about a different context for each >> HIH. Or a >> couple bits out of the 128 allocated as the HIH value. > > Yes. > >> >> With the first option, I don't think you can back derive the HIH from >> the HIT, so nothing really gained. >> >> With the second option you increase the collision risk. > > The issue I was thinking about is that if it becomes commonplace to > just use HITs as names in lots of places because it is 128-bits long, > it seems to be odd that you will not be able to know the hash used > to construct the HIT just by inspecting the HIT. And if the day > comes when a hash is deprecated, how do you know whether the > HIT you have of a peer system should be deprecated? I suppose that > you can try to run the base exchange with them to learn the HIH. > But it may be that people just start to store the HIH with the HIT > explicitly. > > I had a separate question on the list recently about the process > for renewing ORCHID and whether changes need to be made. I don't > know how /28 was arrived at, and whether e.g. 4 bits of the prefix > space could be reclaimed to encode HIH, or whether more bits are > needed for hash output. > I think one could work with four additional bits. This means that 16 different hash functions could be encoded at the same time. Of course we have to use crypto agility carefully then (i.e., we only introduce new HIH algorithms when the previous becomes insufficient). With 16 possible hash functions, this should give us plenty of time to completely phase out HIH #0 before #15 becomes insecure. If we look at the life-cycle of popular hash functions (MD5, SHA-1) 16 replacements represent a huge time frame. We could start over with #0 when #15 becomes insecure. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Wed Jan 13 12:32:59 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7993A67FC for ; Wed, 13 Jan 2010 12:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWT0ZtHLYa4K for ; Wed, 13 Jan 2010 12:32:58 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 3793A3A6880 for ; Wed, 13 Jan 2010 12:32:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1C4E168BDE; Wed, 13 Jan 2010 21:30:25 +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 o0DEIb3CLIzn; Wed, 13 Jan 2010 16:30:15 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [12.105.251.10]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 10E7E68BA1; Wed, 13 Jan 2010 16:30:14 -0500 (EST) Message-ID: <4B4E2DE7.4030705@htt-consult.com> Date: Wed, 13 Jan 2010 12:32:39 -0800 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Tobias Heer References: <4B1F0D12.2070104@htt-consult.com> <"7CC566635CFE364D87DC5803D471 2 A6C4C1CAF1A61"@XCH-NW-10V.nw.nos.boeing.com> <"3CE3C99E-6635-4F78-94E1-E1 582C35F533"@cs.rwth-aachen.de> <4B4D01C9.3030607@htt-consult.com> <"7CC566635 CFE364D87DC5803D4712A6C4C1CAF1A6B"@XCH-NW-10V.nw.nos.boeing.com> <1D3BB6D8-A956-4259-8283-66064A10A49A@cs.rwth-aachen.de> <4B4D93F5.1000909@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4C1CAF1A70@XCH-NW-10V.nw.nos.boeing.com> <42FEAEA1-EE3F-49FE-AF50-99D36B579105@cs.rwth-aachen.de> In-Reply-To: <42FEAEA1-EE3F-49FE-AF50-99D36B579105@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:32:59 -0000 On 01/13/2010 11:25 AM, Tobias Heer wrote: > Hello Tom, > > Am 13.01.2010 um 17:45 schrieb Henderson, Thomas R: > > >> >> >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org >>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Robert Moskowitz >>> Sent: Wednesday, January 13, 2010 1:36 AM >>> To: Tobias Heer >>> Cc: hipsec@ietf.org WG >>> Subject: Re: [Hipsec] Changing HIP BEX to support crypto agility >>> >>> On 01/13/2010 12:46 AM, Tobias Heer wrote: >>> >>>> Am 13.01.2010 um 00:36 schrieb Henderson, Thomas R: >>>> >>>> >>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Moskowitz [mailto:rgm@htt-consult.com] >>>>>> >>>>>> >>>> [...] >>>> >>>> >>>> >>>>>> Whatever mechanism you use to get a HIT, you also have to get >>>>>> the HIH. >>>>>> If the base information is the HI from which you derive a >>>>>> >>> HIT, there >>> >>>>>> must be a list of HIHs (min size = 1) in perfered order to use. >>>>>> >>>>>> >>>>>> >>>>> >>>>>> On 01/12/2010 02:40 PM, Henderson, Thomas R wrote: >>>>>> >>>>>> >>>>> An implication seems to be that the fact that a HIT is 128 >>>>> >>> bits long >>> >>>>> is less interesting since you also need the HIH. Should this >>>>> be considered in future ORCHIDs (to somehow encode the HIH within >>>>> the 128 bits)? >>>>> >>>>> - Tom >>>>> >>>>> >>>> I still think that having a IPv6 compatible HIT is useful >>>> >>> because a longer HIT is difficult to use in the stack. For >>> legacy-style applications (which work quite nicely with HIP >>> right now), a larger HIT would lead to another mapping. >>> >>>> Moreover, the HIH is only needed within HIP (and the >>>> >>> resolver). It is not needed by the application and will >>> probably not be exposed to it. In my opinion, we could keep >>> the application interface as it is now, even with the HIH. >>> >>>> >>>> >>> I think Tom was thinking about a different context for each >>> HIH. Or a >>> couple bits out of the 128 allocated as the HIH value. >>> >> Yes. >> >> >>> With the first option, I don't think you can back derive the HIH from >>> the HIT, so nothing really gained. >>> >>> With the second option you increase the collision risk. >>> >> The issue I was thinking about is that if it becomes commonplace to >> just use HITs as names in lots of places because it is 128-bits long, >> it seems to be odd that you will not be able to know the hash used >> to construct the HIT just by inspecting the HIT. And if the day >> comes when a hash is deprecated, how do you know whether the >> HIT you have of a peer system should be deprecated? I suppose that >> you can try to run the base exchange with them to learn the HIH. >> But it may be that people just start to store the HIH with the HIT >> explicitly. >> >> I had a separate question on the list recently about the process >> for renewing ORCHID and whether changes need to be made. I don't >> know how /28 was arrived at, and whether e.g. 4 bits of the prefix >> space could be reclaimed to encode HIH, or whether more bits are >> needed for hash output. >> >> > I think one could work with four additional bits. This means that 16 different hash functions could be encoded at the same time. > Of course we have to use crypto agility carefully then (i.e., we only introduce new HIH algorithms when the previous becomes insufficient). With 16 possible hash functions, this should give us plenty of time to completely phase out HIH #0 before #15 becomes insecure. If we look at the life-cycle of popular hash functions (MD5, SHA-1) 16 replacements represent a huge time frame. We could start over with #0 when #15 becomes insecure. > Right now I see two for HIH, though there are 3 for transforms. For HIH, there is SHA-1 and SHA-2. But for transforms and KEYMAT according to RFC 4869, we need to add SHA-384 for Suite-B. And considering 4869 is authored by NSA, I guess we will be adding SHA-384. But I don't see us needing it for HIT generation. And this gets me to a struggle I am having right now that I am getting close to posting here about the hash used within BEX operations as opposed to the hash used in HIT generation... From julienl@qualcomm.com Wed Jan 20 09:04:15 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFF13A68DF for ; Wed, 20 Jan 2010 09:04:15 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj-txRAb30cj for ; Wed, 20 Jan 2010 09:04:14 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3B7BD3A6837 for ; Wed, 20 Jan 2010 09:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264007050; x=1295543050; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"miika.komu@hiit.fi"=20,=20hip =20WG=20|Date:=20Wed,=2020=20Jan=202010 =2009:02:48=20-0800|Subject:=20RE:=20[Hipsec]=20ORCHID=20 RFC|Thread-Topic:=20[Hipsec]=20ORCHID=20RFC|Thread-Index: =20AcqS3mzctj08l4arQJaXyB4sgdm1EAHE5g/g|Message-ID:=20|References:=20<4B4B5738.9030803@hiit.fi> |In-Reply-To:=20<4B4B5738.9030803@hiit.fi> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=FtnBsMttZp/FJkYXpRnjcR+0evA9TbZhoSfs5T10uW4=; b=WW1X5yIuIR10apaUBiJ1Tn3Fij+cw49b1aB1rYU2DFC6cZZgI/lUFf6h +3eUWedRA7jNx74noPYGyFKVeMpc2QAc8P5UIKhMIzEJ9w+oGNmittg5t gzTWeMU+pcp0gHhB07VoqW1PsBlRSsGYJqMXUk1yD0Fpuh6G+zR13HKDp Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32382531" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 20 Jan 2010 09:04:08 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0KH47H3027802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Jan 2010 09:04:08 -0800 X-IronPort-AV: E=Sophos;i="4.49,310,1262592000"; d="scan'208";a="33504460" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jan 2010 09:03:30 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Jan 2010 09:02:49 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 20 Jan 2010 09:02:49 -0800 From: "Laganier, Julien" To: "miika.komu@hiit.fi" , hip WG Date: Wed, 20 Jan 2010 09:02:48 -0800 Thread-Topic: [Hipsec] ORCHID RFC Thread-Index: AcqS3mzctj08l4arQJaXyB4sgdm1EAHE5g/g Message-ID: References: <4B4B5738.9030803@hiit.fi> In-Reply-To: <4B4B5738.9030803@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] ORCHID RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:04:15 -0000 Hi, I do not think we can get a prefix shorter than /28. I do not think we shou= ld design protocols for an hypothetic developer who can't handle masking on= non-byte-boundaries. --julien =20 Miika Komu >=20 > Hi, >=20 > I assume that the ORCHID RFC will be updated also in addition to the > other RFC. I have already a small suggestion. If the prefix changes, it > would be nice to get a prefix multiple of eight bits. The current /28 > prefix is more prone to developer errors. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From julienl@qualcomm.com Wed Jan 20 09:14:29 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1234E3A659B for ; Wed, 20 Jan 2010 09:14:29 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RrU6G+eFLpK for ; Wed, 20 Jan 2010 09:14:27 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 712763A6403 for ; Wed, 20 Jan 2010 09:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1264007664; x=1295543664; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"miika.komu@hiit.fi"=20,=20hip =20WG=20|Date:=20Wed,=2020=20Jan=202010 =2009:14:20=20-0800|Subject:=20RE:=20[Hipsec]=20fault-tol erance=20for=20base=20exchange=20and=20update |Thread-Topic:=20[Hipsec]=20fault-tolerance=20for=20base =20exchange=20and=20update|Thread-Index:=20AcqPafwIDPZ48y eRTHaZQrCKcUqcPAKie86g|Message-ID:=20 |References:=20<4B458BB7.8090000@hiit.fi>|In-Reply-To:=20 <4B458BB7.8090000@hiit.fi>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=7Up9j6Le5kRAVYIGdCs/NlgCx98Qd8+z6d4Pmw0yy8w=; b=IBivpMwAq8zEcoIHp8RJlqy0nd46kUzyf0qtm/TiBmk9FL3SXexZ/l9r FjPq7VYtaAstUl2cCAfS3UX4PYgxySzaSmJ9rTfnD8XO8fU+2JO6ZvZOn kM17+xZJ+mJfeLehCLH7Fc+hvcvOnu5My3T4IN0JsJiMB+ylvIc1rIYxC 0=; X-IronPort-AV: E=McAfee;i="5400,1158,5866"; a="32383348" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 20 Jan 2010 09:14:23 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0KHENKu006949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Jan 2010 09:14:23 -0800 X-IronPort-AV: E=Sophos;i="4.49,311,1262592000"; d="scan'208";a="34626821" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jan 2010 09:14:23 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Jan 2010 09:14:23 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 20 Jan 2010 09:14:22 -0800 From: "Laganier, Julien" To: "miika.komu@hiit.fi" , hip WG Date: Wed, 20 Jan 2010 09:14:20 -0800 Thread-Topic: [Hipsec] fault-tolerance for base exchange and update Thread-Index: AcqPafwIDPZ48yeRTHaZQrCKcUqcPAKie86g Message-ID: References: <4B458BB7.8090000@hiit.fi> In-Reply-To: <4B458BB7.8090000@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:14:29 -0000 Hi, FWIW, RFC5201 already allows sending multiple I1's in parallel: 6.6.1. Sending Multiple I1s in Parallel For the sake of minimizing the session establishment latency, an implementation MAY send the same I1 to more than one of the Responder's addresses. However, it MUST NOT send to more than three (3) addresses in parallel. Furthermore, upon timeout, the implementation MUST refrain from sending the same I1 packet to multiple addresses. That is, if it retries to initialize the connection after timeout, it MUST NOT send the I1 packet to more than one destination address. These limitations are placed in order to avoid congestion of the network, and potential DoS attacks that might happen, e.g., because someone's claim to have hundreds or thousands of addresses could generate a huge number of I1 messages from the Initiator. As the Responder is not guaranteed to distinguish the duplicate I1s it receives at several of its addresses (because it avoids storing states when it answers back an R1), the Initiator may receive several duplicate R1s. The Initiator SHOULD then select the initial preferred destination address using the source address of the selected received R1, and use the preferred address as a source address for the I2. Processing rules for received R1s are discussed in Section 6.8. --julien > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Miika Komu > Sent: Wednesday, January 06, 2010 11:23 PM > To: hip WG > Subject: [Hipsec] fault-tolerance for base exchange and update >=20 > Hi, >=20 > Baris Boyvat has implemented an experimental fault-tolerance extension > for the HIP base exchange and UPDATE in the HIPL implementation. He > will > document it in his master thesis during this year, but I would like to > start discussion of the topic already now. >=20 > At the protocol level, the extension allows sending multiple I1 or > UPDATE-with-locator packets sequentially. The idea is to scan through > all possible source and destination IP pairs at the HIP layer to > improve > the chances for successful initial contact (I1) and to re-establish > contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. > We have playfully called the extension as "shotgun" mode in the > implementation :) >=20 > The obvious difference to ICE is that the shotgun mode works at the HIP > protocol layer. A non-obvious difference is that the approach supports > also fault-tolerance for a single relay/rendezvous (Responder's RVS has > crashed) and it can make use of multiple relay/rendezvous servers for > better redundancy. At the moment, neither of these are possible direcly > with the ICE-NAT extensions. I actually believe the shotgun approach > can > be applied even with the ICE-NAT extensions to improve fault-tolerance. >=20 > The shotgun approach seems useful to improve fault-tolerance with an > without (single or multiple) rendezvous/relay middleboxes, but there is > also another use case for this. The Initiator (or Mobile Node) can > learn > multiple mappings for the peer, some of which may have connectivity and > some not. It is also possible that a malign user intentionally sends > invalid mappings for a well-known service in a multiuser system (this > case also requires some rate control for mappings per user). In such > scenarios, it is useful to try multiple peer addresses sequentially > instead of just single one. >=20 > Minimally, the approach requires few considerations in an > implementation: >=20 > i) Allow sending of multiple I1 and UPDATE-with-locator packets in a > rate-controlled fashion > ii) Filter redundant incoming packets. >=20 > Case (ii) could be implemented as filtering of I1 packets or filtering > of R1 packets. We chose filtering of redundant R1 packets in the > implementation and it required a small change in the state machine. For > the UPDATE filtering, filtering based on sequence numbers was > sufficient. >=20 > I would like the WG feedback on whether we could include this approach > in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). >=20 > P.S. Maybe Baris has something to add or to explain some details better. > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From miika.komu@hiit.fi Wed Jan 20 09:32:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817F73A6A77 for ; Wed, 20 Jan 2010 09:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7nsdzw4IToT for ; Wed, 20 Jan 2010 09:32:05 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 3684A3A696F for ; Wed, 20 Jan 2010 09:32:05 -0800 (PST) Received: from [192.168.0.2] (cs27096138.pp.htv.fi [89.27.96.138]) by argo.otaverkko.fi (Postfix) with ESMTP id BF6A225ED14; Wed, 20 Jan 2010 19:32:00 +0200 (EET) Message-ID: <4B573E15.9080403@hiit.fi> Date: Wed, 20 Jan 2010 19:32:05 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Laganier, Julien" References: <4B458BB7.8090000@hiit.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] fault-tolerance for base exchange and update X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:32:06 -0000 Laganier, Julien wrote: Hi, I didn't recall this text, good that you noticed it. Should we also mention that scanning through different source addresses is ok? > Hi, > > FWIW, RFC5201 already allows sending multiple I1's in parallel: > > 6.6.1. Sending Multiple I1s in Parallel > > For the sake of minimizing the session establishment latency, an > implementation MAY send the same I1 to more than one of the > Responder's addresses. However, it MUST NOT send to more than three > (3) addresses in parallel. Furthermore, upon timeout, the > implementation MUST refrain from sending the same I1 packet to > multiple addresses. That is, if it retries to initialize the > connection after timeout, it MUST NOT send the I1 packet to more than > one destination address. These limitations are placed in order to > avoid congestion of the network, and potential DoS attacks that might > happen, e.g., because someone's claim to have hundreds or thousands > of addresses could generate a huge number of I1 messages from the > Initiator. > > As the Responder is not guaranteed to distinguish the duplicate I1s > it receives at several of its addresses (because it avoids storing > states when it answers back an R1), the Initiator may receive several > duplicate R1s. > > The Initiator SHOULD then select the initial preferred destination > address using the source address of the selected received R1, and use > the preferred address as a source address for the I2. Processing > rules for received R1s are discussed in Section 6.8. > > --julien > >> -----Original Message----- >> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >> Behalf Of Miika Komu >> Sent: Wednesday, January 06, 2010 11:23 PM >> To: hip WG >> Subject: [Hipsec] fault-tolerance for base exchange and update >> >> Hi, >> >> Baris Boyvat has implemented an experimental fault-tolerance extension >> for the HIP base exchange and UPDATE in the HIPL implementation. He >> will >> document it in his master thesis during this year, but I would like to >> start discussion of the topic already now. >> >> At the protocol level, the extension allows sending multiple I1 or >> UPDATE-with-locator packets sequentially. The idea is to scan through >> all possible source and destination IP pairs at the HIP layer to >> improve >> the chances for successful initial contact (I1) and to re-establish >> contact (UPDATE-with-locator) in way similar to the NAT-ICE extensions. >> We have playfully called the extension as "shotgun" mode in the >> implementation :) >> >> The obvious difference to ICE is that the shotgun mode works at the HIP >> protocol layer. A non-obvious difference is that the approach supports >> also fault-tolerance for a single relay/rendezvous (Responder's RVS has >> crashed) and it can make use of multiple relay/rendezvous servers for >> better redundancy. At the moment, neither of these are possible direcly >> with the ICE-NAT extensions. I actually believe the shotgun approach >> can >> be applied even with the ICE-NAT extensions to improve fault-tolerance. >> >> The shotgun approach seems useful to improve fault-tolerance with an >> without (single or multiple) rendezvous/relay middleboxes, but there is >> also another use case for this. The Initiator (or Mobile Node) can >> learn >> multiple mappings for the peer, some of which may have connectivity and >> some not. It is also possible that a malign user intentionally sends >> invalid mappings for a well-known service in a multiuser system (this >> case also requires some rate control for mappings per user). In such >> scenarios, it is useful to try multiple peer addresses sequentially >> instead of just single one. >> >> Minimally, the approach requires few considerations in an >> implementation: >> >> i) Allow sending of multiple I1 and UPDATE-with-locator packets in a >> rate-controlled fashion >> ii) Filter redundant incoming packets. >> >> Case (ii) could be implemented as filtering of I1 packets or filtering >> of R1 packets. We chose filtering of redundant R1 packets in the >> implementation and it required a small change in the state machine. For >> the UPDATE filtering, filtering based on sequence numbers was >> sufficient. >> >> I would like the WG feedback on whether we could include this approach >> in RFC5201-bis and RFC5206-bis (as MAY or SHOULD). >> >> P.S. Maybe Baris has something to add or to explain some details better. >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Sun Jan 24 21:51:28 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962913A672F for ; Sun, 24 Jan 2010 21:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm7xNaV1mDW7 for ; Sun, 24 Jan 2010 21:51:27 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C789B3A63D3 for ; Sun, 24 Jan 2010 21:51:27 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0P5pVt5004379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Jan 2010 21:51:32 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o0P5pVol024364 for ; Sun, 24 Jan 2010 21:51:31 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0P5pV85024361 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Sun, 24 Jan 2010 21:51:31 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 24 Jan 2010 21:51:31 -0800 From: "Henderson, Thomas R" To: hip WG Date: Sun, 24 Jan 2010 21:51:30 -0800 Thread-Topic: [Hipsec] Selection of LSI address block Thread-Index: Acoh3hdouJ/OuY7eSN6HyUyY1ofU0R7pDfCQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A683@XCH-NW-10V.nw.nos.boeing.com> References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com><77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> <4A8DC176.3000608@hiit.fi> In-Reply-To: <4A8DC176.3000608@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 05:51:28 -0000 Note to implementors: 1/8 is allocated now http://seclists.org/nanog/2010/Jan/776 From root@core3.amsl.com Tue Jan 26 06:15:01 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D6753A6874; Tue, 26 Jan 2010 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100126141501.6D6753A6874@core3.amsl.com> Date: Tue, 26 Jan 2010 06:15:01 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-hiccups-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-hiccups-01.txt Pages : 15 Date : 2010-01-26 This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-hiccups-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26060020.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jan 26 06:15:01 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 746413A6859; Tue, 26 Jan 2010 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100126141501.746413A6859@core3.amsl.com> Date: Tue, 26 Jan 2010 06:15:01 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-reload-instance-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) Author(s) : A. Keranen, et al. Filename : draft-ietf-hip-reload-instance-00.txt Pages : 10 Date : 2010-01-26 This document specifies the HIP BONE instance specification for RELOAD. It provides the details needed to build a RELOAD-based overlay that uses HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-reload-instance-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26060855.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jan 26 06:15:01 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 801B03A68B7; Tue, 26 Jan 2010 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100126141501.801B03A68B7@core3.amsl.com> Date: Tue, 26 Jan 2010 06:15:01 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-bone-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment Author(s) : G. Camarillo, et al. Filename : draft-ietf-hip-bone-04.txt Pages : 20 Date : 2010-01-26 This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-bone-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-bone-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26061426.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Tue Jan 26 06:39:23 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8693A688B for ; Tue, 26 Jan 2010 06:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fYOJsWBSkTw for ; Tue, 26 Jan 2010 06:39:22 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 323573A67D9 for ; Tue, 26 Jan 2010 06:39:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A66D34ECB5 for ; Tue, 26 Jan 2010 16:39:31 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FClSZKfONRHl for ; Tue, 26 Jan 2010 16:39:30 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id E44294ECB3 for ; Tue, 26 Jan 2010 16:39:30 +0200 (EET) Message-ID: <4B5EFEA2.6020205@nomadiclab.com> Date: Tue, 26 Jan 2010 16:39:30 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] [Fwd: New Version Notification for draft-keranen-hip-over-hip-00] X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:39:23 -0000 Hi all, In addition to updating the HIP BONE drafts, we wrote a new draft [1] about conveying HIP messages over the ESP tunnels. This is something that is especially useful in overlay scenarios, and has actually been already discussed in multiple places before, but never really specified. Comments are welcome. Cheers, Ari [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt -------- Original Message -------- Subject: New Version Notification for draft-keranen-hip-over-hip-00 Date: Tue, 26 Jan 2010 15:29:14 +0100 From: IETF I-D Submission Tool A new version of I-D, draft-keranen-hip-over-hip-00.txt has been successfuly submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-hip-over-hip Revision: 00 Title: Host Identity Protocol Signaling Message Transport Modes Creation_date: 2010-01-26 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document specifies two transport modes for Host Identity Protocol signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. The IETF Secretariat. From gonzalo.camarillo@ericsson.com Tue Jan 26 07:20:40 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36C03A6879 for ; Tue, 26 Jan 2010 07:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y5AeKDqzLY1 for ; Tue, 26 Jan 2010 07:20:38 -0800 (PST) Received: from mailgw9.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 757423A688E for ; Tue, 26 Jan 2010 07:20:36 -0800 (PST) X-AuditID: c1b4fb24-b7bbdae00000494b-b6-4b5f084dfe14 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.ericsson.se (Symantec Mail Security) with SMTP id 76.46.18763.D480F5B4; Tue, 26 Jan 2010 16:20:45 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:19:19 +0100 Received: from [131.160.126.209] ([131.160.126.209]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:19:19 +0100 Message-ID: <4B5F07F6.7080800@ericsson.com> Date: Tue, 26 Jan 2010 17:19:18 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: HIP X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2010 15:19:19.0709 (UTC) FILETIME=[EE8164D0:01CA9E9A] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] WGLC: HIP-based overlays X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:20:40 -0000 Folks, we would like to WGLC the set of specifications that describe how to build HIP-based overlays. The documents under WGLC are the following: http://tools.ietf.org/html/draft-ietf-hip-bone-04 http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 http://tools.ietf.org/html/draft-ietf-hip-via-00 This WGLC will end on February 23rd. Please, send your comments to this list. As soon as we finish this and the certificate work, we will be able to strongly focus the WG's efforts in the advancement of the main HIP specs to the proposed standard status. Thanks, Gonzalo HIP co-chair From rgm@htt-consult.com Wed Jan 27 06:51:52 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F1D3A6A5F for ; Wed, 27 Jan 2010 06:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j866qRcy4NIz for ; Wed, 27 Jan 2010 06:51:51 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 291843A6359 for ; Wed, 27 Jan 2010 06:51:51 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A11FA68B9A for ; Wed, 27 Jan 2010 15:49:06 +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 U0tVvvNADvaS for ; Wed, 27 Jan 2010 10:48:57 -0500 (EST) Received: from nc2400.htt-consult.com (dhcp184-49-55-18.ash.det.wayport.net [184.49.55.18]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 766BA68B22 for ; Wed, 27 Jan 2010 10:48:47 -0500 (EST) Message-ID: <4B6052EF.6060807@htt-consult.com> Date: Wed, 27 Jan 2010 09:51:27 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: multipart/alternative; boundary="------------010300090701060003000908" Subject: [Hipsec] Fwd: Last Call: draft-krawczyk-hkdf (HMAC-based Extract-and-Expand Key Derivation Function (HKDF)) to Informational RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 14:51:52 -0000 This is a multi-part message in MIME format. --------------010300090701060003000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I want to replace the KEYMAT process in BEX with this. It DOES result in a change to BEX to get 'good' nonces from both parties. Right now the nonces are really only from the Responder. -------- Original Message -------- Subject: Last Call: draft-krawczyk-hkdf (HMAC-based Extract-and-Expand Key Derivation Function (HKDF)) to Informational RFC Date: Tue, 26 Jan 2010 07:36:46 -0800 (PST) From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-23. Exceptionally, comments may be sent toiesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-krawczyk-hkdf-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18675&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------010300090701060003000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I want to replace the KEYMAT process in BEX with this.  It DOES result in a change to BEX to get 'good' nonces from both parties.  Right now the nonces are really only from the Responder.


-------- Original Message --------
Subject: Last Call: draft-krawczyk-hkdf (HMAC-based Extract-and-Expand Key Derivation Function (HKDF)) to Informational RFC
Date: Tue, 26 Jan 2010 07:36:46 -0800 (PST)
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org> 


The IESG has received a request from an individual submitter to consider 
the following document:

- 'HMAC-based Extract-and-Expand Key Derivation Function (HKDF) '
   <draft-krawczyk-hkdf-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-02-23. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-krawczyk-hkdf-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18675&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------010300090701060003000908--