From thomas.r.henderson@boeing.com Mon Apr 5 16:31: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 9F2753A67B1 for ; Mon, 5 Apr 2010 16:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 p96Uknn6dOg4 for ; Mon, 5 Apr 2010 16:31:11 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 6A3EF3A67C1 for ; Mon, 5 Apr 2010 16:31:11 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o35NV6OE022673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Apr 2010 18:31:06 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o35NV6ov012343; Mon, 5 Apr 2010 18:31:06 -0500 (CDT) 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.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o35NV5hv012327 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 5 Apr 2010 18:31:06 -0500 (CDT) 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; Mon, 5 Apr 2010 16:31:05 -0700 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Mon, 5 Apr 2010 16:31:04 -0700 Thread-Topic: more comments on hip-over-hip draft Thread-Index: AcrFtL2qbmv6OyYPQ8iQ09ZmGbsBwQPYur5g Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE8C27207@XCH-NW-10V.nw.nos.boeing.com> References: <4B9F5B79.1080103@nomadiclab.com><2F808992-7A4C-4467-BDB1-47D3E9EA0070@nomadiclab.com> <4BA0A198.2080007@nomadiclab.com> In-Reply-To: <4BA0A198.2080007@nomadiclab.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: HIP Subject: [Hipsec] more comments on hip-over-hip draft 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, 05 Apr 2010 23:31:12 -0000 Ari, Here are a few more comments on the HIP over HIP draft. In section 3.1, it is not clear whether the hosts MUST use the negotiated mode once it is negotiated for all subsequent messages while the associatio= n is active (or until it is renegotiated via UPDATEs). Suggest to clarify this and what is the host behavior if it is expecting a mode but gets another mode instead. In section 3.1, it is not clear whether the order of these parameters expresses a priority preference; plaese clarify. It probably would be easier to treat this as a prioritized list. In section 3.2, would it be better if the sender was required to specify the currently running mode as one of the options so the recipient could always successfully bail out of the renegotiation without responding with an error code? It seems a bit cleaner to me than reporting an error yet continuing on with the association as if nothing happened. Section 3.3, please specify what a receiving host should do if these ESP modes are mistakenly offered in the HIP_TRANSPORT_MODE parameter despite ESP transport format not being used. Section 3.3 has this comment: Instead, a host simply waits for the same time that would be taken by the maximum amount of retransmissions with unreliable transmission before concluding that there is no response. I see a couple of issues with this advice. First, a host may not want to wait for the maximal number of TCP retransmissions before trying a non-TCP approach to getting the message through. Second, HIP process may not have visibility into the maximum number of TCP retransmissions anyway. I would suggest to instead say: "a host waits to detect that the TCP connection has failed to retransmit the packet successfully in a timely manner (such detection is platform- and policy-specific) before concluding that there is no response." Regards, Tom From ari.keranen@nomadiclab.com Tue Apr 6 08:44: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 48FD43A6838 for ; Tue, 6 Apr 2010 08:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 XDjo0NAdndN0 for ; Tue, 6 Apr 2010 08:44:03 -0700 (PDT) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 5B5E63A686A for ; Tue, 6 Apr 2010 08:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id CB1564E6CD; Tue, 6 Apr 2010 18:43:56 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EanCXrmN0PH; Tue, 6 Apr 2010 18:43:56 +0300 (EEST) 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 4B5BA4E6C8; Tue, 6 Apr 2010 18:43:56 +0300 (EEST) Message-ID: <4BBB56BC.4040601@nomadiclab.com> Date: Tue, 06 Apr 2010 18:43:56 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B9F5B79.1080103@nomadiclab.com><2F808992-7A4C-4467-BDB1-47D3E9EA0070@nomadiclab.com> <4BA0A198.2080007@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27207@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE8C27207@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] more comments on hip-over-hip draft 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, 06 Apr 2010 15:44:04 -0000 Hi Tom, Thanks a lot for the comments! Responses inline. Henderson, Thomas R wrote: > Ari, > > Here are a few more comments on the HIP over HIP draft. > > In section 3.1, it is not clear whether the hosts MUST use the negotiated > mode once it is negotiated for all subsequent messages while the association > is active (or until it is renegotiated via UPDATEs). Suggest to clarify > this and what is the host behavior if it is expecting a mode but gets > another mode instead. > > In section 3.1, it is not clear whether the order of these parameters > expresses a priority preference; plaese clarify. It probably would be > easier to treat this as a prioritized list. Good points. The section 3.1 says now: [...] first the Responder lists the supported modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1 packet. The modes are listed in priority order; the more preferred mode(s) first. If the Initiator supports, and is willing to use, any of the modes proposed by the Responder, it selects one of the modes by adding a HIP_TRANSPORT_MODE parameter containing the selected mode to the I2 packet. Finally, if the Initiator selected one of the modes and the base exchange succeeds, hosts MUST use the selected mode for the following HIP signaling messages sent between them for the duration of the HIP association or until another mode is negotiated. If the Initiator cannot or will not use any of the modes proposed by the Responder, the Initiator SHOULD include an empty HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it support this extension but will not use any of the proposed modes. Depending on local policy, the Responder MAY either abort the base exchange or continue HIP signaling without using an encrypted connection. If the Initiator selects a mode that the Responder does not support (and hence was not included in R1), the Responder SHOULD reply with a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet (see Section 4) and abort the base exchange. > In section 3.2, would it be better if the sender was required to specify > the currently running mode as one of the options so the recipient could > always successfully bail out of the renegotiation without responding > with an error code? It seems a bit cleaner to me than reporting an > error yet continuing on with the association as if nothing happened. Makes sense. Although I would make the "currently running mode" an implicit option and the answer could always contain that mode even if the offer didn't. This way we would not have an error case for UPDATE without the currently used mode (and we would save a few bytes :). I would change the 1st paragraph of 3.2 into: If a HIP hosts wants to change to a different transport mode (or start using a transport mode) some time after the base exchange, it sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter containing the mode(s) it would prefer to use. The host receiving the UPDATE MUST respond with an UPDATE packet containing the mode that is selected as in the negotiation during the base exchange. If the receiving host does not support, or is not willing to use, any of the listed modes, it MUST respond with an UPDATE packet containing only the currently used transport mode (even if one was not included in the previous UPDATE packet) and continue using it. > Section 3.3, please specify what a receiving host should do if these > ESP modes are mistakenly offered in the HIP_TRANSPORT_MODE parameter > despite ESP transport format not being used. Added to the first paragraph: [...] If the ESP transport format is not used, these modes MUST NOT be offered in the HIP_TRANSPORT_MODE parameter. If a HIP_TRANSPORT_MODE parameter containing an ESP transport mode is received but the ESP transport format is not used, a host MUST NOT select such a mode but act as specified in Section 3.1 (if performing a base exchange) or Section 3.2 (if performing an UPDATE) when no valid mode is offered. I think this solves the problem cleanly and with smallest amount of new code paths. > Section 3.3 has this comment: > Instead, a host simply waits for the same time that > would be taken by the maximum amount of retransmissions with > unreliable transmission before concluding that there is no response. > > I see a couple of issues with this advice. First, a host may not want > to wait for the maximal number of TCP retransmissions before trying > a non-TCP approach to getting the message through. Second, HIP process > may not have visibility into the maximum number of TCP retransmissions > anyway. I would suggest to instead say: "a host waits to detect that > the TCP connection has failed to retransmit the packet successfully > in a timely manner (such detection is platform- and policy-specific) > before concluding that there is no response." Good point. Added your suggested text almost verbatim: [...] Instead, a host SHOULD wait to detect that the TCP connection has failed to retransmit the packet successfully in a timely manner (such detection is platform- and policy-specific) before concluding that there is no response. Thanks, Ari From rgm@htt-consult.com Wed Apr 7 09:42: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 E736E3A6994 for ; Wed, 7 Apr 2010 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 VCfOyMrhI8Fo for ; Wed, 7 Apr 2010 09:42:30 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 321AD3A6973 for ; Wed, 7 Apr 2010 09:42:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8E1E368B7C for ; Wed, 7 Apr 2010 16:37: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 1N7FvT-5zvR7 for ; Wed, 7 Apr 2010 12:37:14 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id B6AFE68B9C for ; Wed, 7 Apr 2010 12:37:14 -0400 (EDT) Message-ID: <4BBCB5E3.3080707@htt-consult.com> Date: Wed, 07 Apr 2010 12:42:11 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2 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, 07 Apr 2010 16:42:31 -0000 I am back (kind of) from Passover holidays. Given some of the content of the 4843bis thread, I went looking to see if we had any writeup on the security threats for HITs, and really did not find a consistant writeup. Of course we want to minimize collisions, but what are the threats? 4423 has always 'allowed' for HITs from a source other than a Public Key, but does not go through the threats, even if there is a PK Host Identity, but something other than a Cryptographic Hash is used to derive the HIT from it. Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest. From rgm@htt-consult.com Wed Apr 7 09:49: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 9B7BC3A6937 for ; Wed, 7 Apr 2010 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 0I5aTuYvHyh0 for ; Wed, 7 Apr 2010 09:49:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id C4B473A67F6 for ; Wed, 7 Apr 2010 09:49:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5EBF468B7C; Wed, 7 Apr 2010 16:43:58 +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 oMwY8MguFaBA; Wed, 7 Apr 2010 12:43:49 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3E6BD68D90; Wed, 7 Apr 2010 12:43:49 -0400 (EDT) Message-ID: <4BBCB772.8080107@htt-consult.com> Date: Wed, 07 Apr 2010 12:48:50 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "pekka.nikander@ericsson.com" , "hipsec@ietf.org" Subject: Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2 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, 07 Apr 2010 16:49:06 -0000 On 03/30/2010 05:28 PM, Laganier, Julien wrote: > Folks, > > As proposed at last IETF meeting, it seems we have a way forward with 4843bis: > > 1. HIP WG to have a 4843bis deliverable that introduces crypto-agility > - Request permanent allocation of a new /28 prefix for ORCHIDv2 > - Introduces ORCHIDv2 Generation Algorithm (OGA), defined in a given Context > - (e.g. HIP in RFC5201 bis) > - Define new ORCHIv2 Generation Procedure: > Input := any bitstring > ORCHID Input := Context ID | Input > ORCHID Ouput := OGA( ORCHID Input ) > ORCHID := Prefix | OGA Type | Encode_96( ORCHID Ouput) > > => question mark: Do we let the current 2001:10::/28 allocation expire? I recommend we do as it will make it easier to obtain a permanent allocation. > yes. > 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other values as unallocated, allocation requiring IETF specification. > > => question mark: Do we start with SHA-256 instead? I just don't know yet. What else will we be keeping SHA-1 around for? Will an implementation of HIPbis have to include SHA-1 just for HIT calculations? If we keep SHA-1 in 5201-bis, then just, I guess we have a match for still having SHA-1 for ORCHIDs. But if 5201-bis starts with SHA-256, then it seems for code symmetry that ORCHIDs follow. From rgm@htt-consult.com Wed Apr 7 10:10: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 325B03A6956; Wed, 7 Apr 2010 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, 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 hnfdfpIBt4ud; Wed, 7 Apr 2010 10:10:23 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id C12233A6937; Wed, 7 Apr 2010 10:10:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8703168DA1; Wed, 7 Apr 2010 17:04:44 +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 gXQqQ6SiQ0O9; Wed, 7 Apr 2010 13:04:31 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 2794868B84; Wed, 7 Apr 2010 13:04:31 -0400 (EDT) Message-ID: <4BBCBC4D.6090903@htt-consult.com> Date: Wed, 07 Apr 2010 13:09:33 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: wang.jun17@zte.com.cn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060700020502010208030907" Cc: hipsec@ietf.org, hipsec-bounces@ietf.org Subject: Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2 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, 07 Apr 2010 17:10:30 -0000 This is a multi-part message in MIME format. --------------060700020502010208030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/31/2010 04:36 AM, wang.jun17@zte.com.cn wrote: > > Does ORCHID consider any commercial deployment requirements? > If HIP could be commercial deployed, HIP ID should be divided into > many sub-pieces and allocated to service providers or other > organizations . Commerical deployment requirements do not require hierarchical HITS. I can show this by example. But I agree there are places for them. As such it should a separate ORCHID prefix, and most likely its own draft. Go back to my early HIP drafts, they can be found in: http://tools.ietf.org/id/draft-*-hip- For example: http://tools.ietf.org/id/draft-moskowitz-hip-09.txt In fact the Host Assigning Authority (HAA) field can be found in the older drafts like: http://tools.ietf.org/id/draft-moskowitz-hip-04.txt All the moskowit-hip drafts are still there, so you can see my early attempts. But we figured out that hierarchical HITs will not be needed for most usage, and so we have dropped them from the basic documents. > > > Russell Wang > > > > *Varjonen Samu * > ???: hipsec-bounces@ietf.org > > 2010-03-31 14:52 > > > ??? > miika.komu@hiit.fi > ?? > hipsec@ietf.org > ?? > Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2 > > > > > > > > > > Miika Komu wrote: > > On 31/03/10 00:36, Henderson, Thomas R wrote: > > > > Hi, > > > >>> -----Original Message----- From: hipsec-bounces@ietf.org > >>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Laganier, Julien > >>> Sent: Tuesday, March 30, 2010 2:29 PM To: hipsec@ietf.org Cc: > >>> pekka.nikander@ericsson.com Subject: [Hipsec] Follow-up on 4843bis > >>> / ORCHIDv2 > >>> > >>> Folks, > >>> > >>> As proposed at last IETF meeting, it seems we have a way forward > >>> with 4843bis: > >>> > >>> 1. HIP WG to have a 4843bis deliverable that introduces > >>> crypto-agility - Request permanent allocation of a new /28 prefix > >>> for ORCHIDv2 - Introduces ORCHIDv2 Generation Algorithm (OGA), > >>> defined in a given Context - (e.g. HIP in RFC5201 bis) - Define new > >>> ORCHIv2 Generation Procedure: Input := any bitstring ORCHID Input > >>> := Context ID | Input ORCHID Ouput := OGA( ORCHID Input ) ORCHID := > >>> Prefix | OGA Type | Encode_96( ORCHID Ouput) > >>> > >>> => question mark: Do we let the current 2001:10::/28 allocation > >>> expire? I recommend we do as it will make it easier to obtain a > >>> permanent allocation. > >> > >> +1 > > > > +1 > +1 > > > >>> 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other > >>> values as unallocated, allocation requiring IETF specification. > >>> > >>> => question mark: Do we start with SHA-256 instead? > >> > >> I would be happy to delegate the question to the crypto forum or > >> other experts, but my impression is that SHA-1 is already being > >> phased out elsewhere and that existing libraries typically have > >> SHA-256 support. > > > > I was following discussion of other people in the IETF and their > opinion > > seemed to be that... > > > > * SHA-256 may be an overkill for sensors > > * Attacks on SHA1 are collision attacks where as we need just the > > preimage property > > > > For further information, please refer to: > > > > http://tools.ietf.org/search/rfc4270 > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > --------------060700020502010208030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/31/2010 04:36 AM, wang.jun17@zte.com.cn wrote:

Does ORCHID consider any commercial deployment requirements?
If HIP could be commercial deployed, HIP ID should be divided into many sub-pieces and allocated to service providers or other organizations .

Commerical deployment requirements  do not require hierarchical HITS.  I can show this by example.

But I agree there are places for them.  As such it should a separate ORCHID prefix, and most likely its own draft.

Go back to my early HIP drafts, they can be found in:   http://tools.ietf.org/id/draft-*-hip-

For example:  http://tools.ietf.org/id/draft-moskowitz-hip-09.txt

In fact the Host Assigning Authority (HAA) field can be found in the older drafts like:

http://tools.ietf.org/id/draft-moskowitz-hip-04.txt

All the moskowit-hip drafts are still there, so you can see my early attempts.

But we figured out that hierarchical HITs will not be needed for most usage, and so we have dropped them from the basic documents.



Russell Wang



Varjonen Samu <samu.varjonen@hiit.fi>
发件人:  hipsec-bounces@ietf.org

2010-03-31 14:52

收件人
miika.komu@hiit.fi
抄送
hipsec@ietf.org
主题
Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2







Miika Komu wrote:
> On 31/03/10 00:36, Henderson, Thomas R wrote:
>
> Hi,
>
>>> -----Original Message----- From: hipsec-bounces@ietf.org
>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Laganier, Julien
>>> Sent: Tuesday, March 30, 2010 2:29 PM To: hipsec@ietf.org Cc:
>>> pekka.nikander@ericsson.com Subject: [Hipsec] Follow-up on 4843bis
>>> / ORCHIDv2
>>>
>>> Folks,
>>>
>>> As proposed at last IETF meeting, it seems we have a way forward
>>> with 4843bis:
>>>
>>> 1. HIP WG to have a 4843bis deliverable that introduces
>>> crypto-agility - Request permanent allocation of a new /28 prefix
>>> for ORCHIDv2 - Introduces ORCHIDv2 Generation Algorithm (OGA),
>>> defined in a given Context - (e.g. HIP in RFC5201 bis) - Define new
>>> ORCHIv2 Generation Procedure: Input := any bitstring ORCHID Input
>>> := Context ID | Input ORCHID Ouput := OGA( ORCHID Input ) ORCHID :=
>>> Prefix | OGA Type | Encode_96( ORCHID Ouput)
>>>
>>> =>  question mark: Do we let the current 2001:10::/28 allocation
>>> expire? I recommend we do as it will make it easier to obtain a
>>> permanent allocation.
>>
>> +1
>
> +1
+1
>
>>> 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other
>>> values as unallocated, allocation requiring IETF specification.
>>>
>>> =>  question mark: Do we start with SHA-256 instead?
>>
>> I would be happy to delegate the question to the crypto forum or
>> other experts, but my impression is that SHA-1 is already being
>> phased out elsewhere and that existing libraries typically have
>> SHA-256 support.
>
> I was following discussion of other people in the IETF and their opinion
> seemed to be that...
>
> * SHA-256 may be an overkill for sensors
> * Attacks on SHA1 are collision attacks where as we need just the
> preimage property
>
> For further information, please refer to:
>
> http://tools.ietf.org/search/rfc4270
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
  

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
--------------060700020502010208030907-- From julienl@qualcomm.com Wed Apr 7 10:12: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 016333A68E6 for ; Wed, 7 Apr 2010 10:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 kMj5GhO2QXPt for ; Wed, 7 Apr 2010 10:12:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 43B9A3A6811 for ; Wed, 7 Apr 2010 10:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1270660340; x=1302196340; h=from:to:cc: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:=20Robert=20Moskowitz=20|CC:=20" hipsec@ietf.org"=20,=20"pekka.nikander@e ricsson.com"=0D=0A=09|Date: =20Wed,=207=20Apr=202010=2010:12:15=20-0700|Subject:=20RE :=20[Hipsec]=20Follow-up=20on=204843bis=20/=20ORCHIDv2 |Thread-Topic:=20[Hipsec]=20Follow-up=20on=204843bis=20/ =20ORCHIDv2|Thread-Index:=20AcrWclP5k0awipieRFCL8jChIBCCn AAAqUjg|Message-ID:=20|References:=20=0D=0A=20<4BBCB772.8080107@htt-consult.com> |In-Reply-To:=20<4BBCB772.8080107@htt-consult.com> |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=jhXmWv0yVOQiHkCITtfHk2cy/CN4JB2+HpyapPkMGpA=; b=PDDyMs9DtSzHwXnI8UnhwsiAUAhNI4EvTTaoVBUxhrW3dP5JQAex2VLc sLPVrbu82VqF4T1g5hYWLtHztDri/XFYyoWCTdAFL067SoSND1/AzAG+g axLkVG2lkxQi7Uv3Ztx9MK/m7L1rJJltBTO/gdqlpCfm/op3pB243wpEo 0=; X-IronPort-AV: E=McAfee;i="5400,1158,5944"; a="38148636" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 07 Apr 2010 10:12:17 -0700 X-IronPort-AV: E=Sophos;i="4.51,377,1267430400"; d="scan'208";a="7781264" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 07 Apr 2010 10:12:18 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 7 Apr 2010 10:12:17 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 7 Apr 2010 10:12:16 -0700 From: "Laganier, Julien" To: Robert Moskowitz Date: Wed, 7 Apr 2010 10:12:15 -0700 Thread-Topic: [Hipsec] Follow-up on 4843bis / ORCHIDv2 Thread-Index: AcrWclP5k0awipieRFCL8jChIBCCnAAAqUjg Message-ID: References: <4BBCB772.8080107@htt-consult.com> In-Reply-To: <4BBCB772.8080107@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: "pekka.nikander@ericsson.com" , "hipsec@ietf.org" Subject: Re: [Hipsec] Follow-up on 4843bis / ORCHIDv2 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, 07 Apr 2010 17:12:28 -0000 Robert Moskowitz wrote: >=20 > On 03/30/2010 05:28 PM, Laganier, Julien wrote: > > Folks, > > > > As proposed at last IETF meeting, it seems we have a way forward with > 4843bis: > > > > 1. HIP WG to have a 4843bis deliverable that introduces crypto- > agility > > - Request permanent allocation of a new /28 prefix for ORCHIDv2 > > - Introduces ORCHIDv2 Generation Algorithm (OGA), defined in a > given Context > > - (e.g. HIP in RFC5201 bis) > > - Define new ORCHIv2 Generation Procedure: > > Input :=3D any bitstring > > ORCHID Input :=3D Context ID | Input > > ORCHID Ouput :=3D OGA( ORCHID Input ) > > ORCHID :=3D Prefix | OGA Type | Encode_96( ORCHID Ouput) > > > > =3D> question mark: Do we let the current 2001:10::/28 allocation > expire? I recommend we do as it will make it easier to obtain a > permanent allocation. >=20 > yes. >=20 > > 2. HIP WG to allocate OGA Type 1 as SHA1 in 5201bis and keep other > values as unallocated, allocation requiring IETF specification. > > > > =3D> question mark: Do we start with SHA-256 instead? >=20 > I just don't know yet. What else will we be keeping SHA-1 around for? > Will an implementation of HIPbis have to include SHA-1 just for HIT > calculations? Hmm. I understand that HIPbis will need not to support HIPv1 because the OR= CHID allocation is going to expire. So we only need to keep SHA-1 if HIPbis= also uses SHA-1... =20 > If we keep SHA-1 in 5201-bis, then just, I guess we have a match for > still having SHA-1 for ORCHIDs. But if 5201-bis starts with SHA-256, > then it seems for code symmetry that ORCHIDs follow. Agree on both counts.=20 --julien From rgm@htt-consult.com Thu Apr 8 13:59:25 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 81DC63A6AEF for ; Thu, 8 Apr 2010 13:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 xetVwvB1qQ62 for ; Thu, 8 Apr 2010 13:59:24 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 310BB3A6AD8 for ; Thu, 8 Apr 2010 13:59:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7736868B84 for ; Thu, 8 Apr 2010 20:54:12 +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 gnSmyPNWIcH2 for ; Thu, 8 Apr 2010 16:54:03 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 01BA468B82 for ; Thu, 8 Apr 2010 16:54:02 -0400 (EDT) Message-ID: <4BBE4397.1050600@htt-consult.com> Date: Thu, 08 Apr 2010 16:59:03 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] 5201bis -- Public key algorithms and key sizes 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, 08 Apr 2010 20:59:25 -0000 It is our plan to add ECC as a PK algorithm in 5201-bis. My proposal is to use: http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-02.txt All of the math in this ID is pre-94. The ID makes no IPR claims but the implication is there of unemcumbered ECC. Problem is there is no standard libraries for the ID. First thing, is naming :) What might we call curves from this draft to use in 5201bis? Aside from that P-256, P-384, and P-512 are recommended sizes based on RFC 4753. Do we include P-384? Host-ID does not enumerate key size, nor does 5201 recommend a MUST key size for interoperability (at least it is not clearly stated). I contend that we recommend 2048 for RSA/DSA and for anything stronger, ECC. Any point for RSA 1024? It does not match strength with the other crypto components. Diffie-Hellman is all over the place with key sizes: 384-bit group 1 OAKLEY well-known group 1 2 1536-bit MODP group 3 3072-bit MODP group 4 6144-bit MODP group 5 8192-bit MODP group 6 I am not finding reference of DH MODP group size to strength. I would think we would limit MODP key size to match RSA/DSA. For ECDH again 256, 384 (maybe depending on question above) and 512. Comments? From root@core3.amsl.com Fri Apr 9 05:00: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 D2DD33A6A0D; Fri, 9 Apr 2010 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100409120001.D2DD33A6A0D@core3.amsl.com> Date: Fri, 9 Apr 2010 05:00:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-bone-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:00: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-06.txt Pages : 21 Date : 2010-04-09 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-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-bone-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-09044843.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Fri Apr 9 05:17: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 8BB063A684A for ; Fri, 9 Apr 2010 05:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 3wWD-luVoDwe for ; Fri, 9 Apr 2010 05:17:58 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 488FB3A681F for ; Fri, 9 Apr 2010 05:17:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 77F994E6F5 for ; Fri, 9 Apr 2010 15:17:52 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTQtmMgo76i5 for ; Fri, 9 Apr 2010 15:17:51 +0300 (EEST) 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 D1EAF4E6C5 for ; Fri, 9 Apr 2010 15:17:51 +0300 (EEST) Message-ID: <4BBF1AEF.80302@nomadiclab.com> Date: Fri, 09 Apr 2010 15:17:51 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: hipsec@ietf.org References: <20100409120001.D2DD33A6A0D@core3.amsl.com> In-Reply-To: <20100409120001.D2DD33A6A0D@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-bone-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:17:59 -0000 Hi all, This version has fixes for the WGLC comments; especially there is a new section about how the overlay is selected when new HIP messages are created. This draft should be now ready to go forward. Cheers, Ari Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-hip-bone-06.txt > Pages : 21 > Date : 2010-04-09 > > 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-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Fri Apr 9 05:57:05 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 66B4528C0D8 for ; Fri, 9 Apr 2010 05:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Sgwz07vgJ-0r for ; Fri, 9 Apr 2010 05:57:04 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 900F028C0D0 for ; Fri, 9 Apr 2010 05:57:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E76E368B5F for ; Fri, 9 Apr 2010 12:51: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 dLq5nxBBuL7y for ; Fri, 9 Apr 2010 08:51:34 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5EEB068B5D for ; Fri, 9 Apr 2010 08:51:34 -0400 (EDT) Message-ID: <4BBF2409.4060004@htt-consult.com> Date: Fri, 09 Apr 2010 08:56:41 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BBE4397.1050600@htt-consult.com> In-Reply-To: <4BBE4397.1050600@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] 5201bis -- Public key algorithms and key sizes 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, 09 Apr 2010 12:57:05 -0000 On 04/08/2010 04:59 PM, Robert Moskowitz wrote: > It is our plan to add ECC as a PK algorithm in 5201-bis. My proposal > is to use: > > http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-02.txt > > All of the math in this ID is pre-94. The ID makes no IPR claims but > the implication is there of unemcumbered ECC. Problem is there is no > standard libraries for the ID. I would like the HIP developers to look this ID over to see what it would take to implement. I am not aware of any code in standard libraries; I have asked Dave McGrew about this. > First thing, is naming :) What might we call curves from this draft to > use in 5201bis? > > Aside from that P-256, P-384, and P-512 are recommended sizes based on > RFC 4753. Do we include P-384? > > Host-ID does not enumerate key size, nor does 5201 recommend a MUST > key size for interoperability (at least it is not clearly stated). I > contend that we recommend 2048 for RSA/DSA and for anything stronger, > ECC. > > Any point for RSA 1024? It does not match strength with the other > crypto components. > > Diffie-Hellman is all over the place with key sizes: > > 384-bit group 1 > OAKLEY well-known group 1 2 > 1536-bit MODP group 3 > 3072-bit MODP group 4 > 6144-bit MODP group 5 > 8192-bit MODP group 6 > > I am not finding reference of DH MODP group size to strength. I would > think we would limit MODP key size to match RSA/DSA. For ECDH again > 256, 384 (maybe depending on question above) and 512. > > Comments? > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From gonzalo.camarillo@ericsson.com Fri Apr 9 05:57: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 6E5973A6A64 for ; Fri, 9 Apr 2010 05:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.930, 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 UdYzbicADM3s for ; Fri, 9 Apr 2010 05:57:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7CAA13A6A4B for ; Fri, 9 Apr 2010 05:57:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-0a-4bbf2425f446 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F9.B5.23532.5242FBB4; Fri, 9 Apr 2010 14:57:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 14:57:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 14:57:09 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 401E72469; Fri, 9 Apr 2010 15:57:09 +0300 (EEST) Message-ID: <4BBF2423.6050604@ericsson.com> Date: Fri, 09 Apr 2010 15:57:07 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2010 12:57:09.0532 (UTC) FILETIME=[2A476DC0:01CAD7E4] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Draft minutes of the HIP WG session in Anaheim 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, 09 Apr 2010 12:57:15 -0000 Folks, you can fetch the draft minutes from our session in Anaheim from the following link: http://www.ietf.org/proceedings/10mar/minutes/hip.txt Cheers, Gonzalo HIP WG co-chair From gonzalo.camarillo@ericsson.com Fri Apr 9 06:12:02 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 B291B28C112 for ; Fri, 9 Apr 2010 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.786 X-Spam-Level: X-Spam-Status: No, score=-105.786 tagged_above=-999 required=5 tests=[AWL=0.813, 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 9RVRauLecW2N for ; Fri, 9 Apr 2010 06:12:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3BCD73A6A7C for ; Fri, 9 Apr 2010 06:11:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5b-4bbf2784595e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 72.97.23532.4872FBB4; Fri, 9 Apr 2010 15:11:32 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 15:11:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 15:11:31 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8D1D92469; Fri, 9 Apr 2010 16:11:31 +0300 (EEST) Message-ID: <4BBF2783.4020706@ericsson.com> Date: Fri, 09 Apr 2010 16:11:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2010 13:11:31.0731 (UTC) FILETIME=[2C308E30:01CAD7E6] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Adopting the hip-over-hip draft as a WG item 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, 09 Apr 2010 13:12:02 -0000 Hi, in Anaheim there was consensus in the room to adopt the following draft as a WG item: https://datatracker.ietf.org/doc/draft-keranen-hip-over-hip/ If nobody objects on the list, the author will submit a new revision of the draft including the comments received since then as a WG item. Cheers, Gonzalo HIP WG co-chair From gonzalo.camarillo@ericsson.com Fri Apr 9 06:14: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 79BBA3A67FE for ; Fri, 9 Apr 2010 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.876 X-Spam-Level: X-Spam-Status: No, score=-105.876 tagged_above=-999 required=5 tests=[AWL=0.723, 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 U-BVW78+5xuJ for ; Fri, 9 Apr 2010 06:14:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B0A363A676A for ; Fri, 9 Apr 2010 06:14:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-87-4bbf283b5d6d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 99.E7.23532.B382FBB4; Fri, 9 Apr 2010 15:14:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 15:14:34 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 15:14:34 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 985E62469 for ; Fri, 9 Apr 2010 16:14:34 +0300 (EEST) Message-ID: <4BBF283A.9080408@ericsson.com> Date: Fri, 09 Apr 2010 16:14:34 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2010 13:14:34.0874 (UTC) FILETIME=[9959F5A0:01CAD7E6] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] HIP Native NAT Traversal 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, 09 Apr 2010 13:14:47 -0000 Hi, in Anaheim, we decided to continue discussing on the list the following draft: https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ In particular, I would like to see discussions on the lessons learned from the STUN-based implementations and potential benefits of implementing STUN-like functionality in HIP. Thanks, Gonzalo HIP WG co-chair From rgm@htt-consult.com Fri Apr 9 06:23:26 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 08D6828C0EE for ; Fri, 9 Apr 2010 06:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 8-Us7JmqPrjD for ; Fri, 9 Apr 2010 06:23:24 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id E5E7C3A6A4B for ; Fri, 9 Apr 2010 06:22:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E007268B6D for ; Fri, 9 Apr 2010 13:17:11 +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 MSZOtF3wfaDm for ; Fri, 9 Apr 2010 09:17:02 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5E0F068C3E for ; Fri, 9 Apr 2010 09:16:57 -0400 (EDT) Message-ID: <4BBF29FC.4090808@htt-consult.com> Date: Fri, 09 Apr 2010 09:22:04 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BBE4397.1050600@htt-consult.com> In-Reply-To: <4BBE4397.1050600@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] 5201bis -- Public key algorithms and key sizes 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, 09 Apr 2010 13:23:26 -0000 On 04/08/2010 04:59 PM, Robert Moskowitz wrote: > It is our plan to add ECC as a PK algorithm in 5201-bis. My proposal > is to use: > > http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-02.txt > > All of the math in this ID is pre-94. The ID makes no IPR claims but > the implication is there of unemcumbered ECC. Problem is there is no > standard libraries for the ID. First thing, is naming :) What might we > call curves from this draft to use in 5201bis? Would putting a lower case 'f' in front of all the 'standard' ECC names be enough of a name designation? So you would have fECC, fP-256, and fECDH? > > Aside from that P-256, P-384, and P-512 are recommended sizes based on > RFC 4753. Do we include P-384? > > Host-ID does not enumerate key size, nor does 5201 recommend a MUST > key size for interoperability (at least it is not clearly stated). I > contend that we recommend 2048 for RSA/DSA and for anything stronger, > ECC. > > Any point for RSA 1024? It does not match strength with the other > crypto components. > > Diffie-Hellman is all over the place with key sizes: > > 384-bit group 1 > OAKLEY well-known group 1 2 > 1536-bit MODP group 3 > 3072-bit MODP group 4 > 6144-bit MODP group 5 > 8192-bit MODP group 6 > > I am not finding reference of DH MODP group size to strength. I would > think we would limit MODP key size to match RSA/DSA. For ECDH again > 256, 384 (maybe depending on question above) and 512. > > Comments? > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From ari.keranen@nomadiclab.com Fri Apr 9 06:32: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 377CB3A69CE for ; Fri, 9 Apr 2010 06:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 fZjf5lBpCLjf for ; Fri, 9 Apr 2010 06:32:49 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8179928C10E for ; Fri, 9 Apr 2010 06:32:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id DE1D64E6D5 for ; Fri, 9 Apr 2010 16:32:09 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DirNoCY2LHQF for ; Fri, 9 Apr 2010 16:32:09 +0300 (EEST) 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 366AF4E6C0 for ; Fri, 9 Apr 2010 16:32:09 +0300 (EEST) Message-ID: <4BBF2C58.6090503@nomadiclab.com> Date: Fri, 09 Apr 2010 16:32:08 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100317) 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-native-nat-traversal-01] 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, 09 Apr 2010 13:32:50 -0000 Hi all, Here's the announcement for the updated Native NAT Traversal Mode draft. As discussed in the WG meeting, the password-based authentication was replaced with certificates. Cheers, Ari -------- Original Message -------- Subject: New Version Notification for draft-keranen-hip-native-nat-traversal-01 A new version of I-D, draft-keranen-hip-native-nat-traversal-01.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-hip-native-nat-traversal Revision: 01 Title: Native NAT Traversal Mode for the Host Identity Protocol Creation_date: 2010-04-09 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF Secretariat. From mkomu@cs.hut.fi Fri Apr 9 13:21: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 0FCE83A6999 for ; Fri, 9 Apr 2010 13:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpxGWQiQrsMB for ; Fri, 9 Apr 2010 13:21:44 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id A369D3A69E1 for ; Fri, 9 Apr 2010 13:21:13 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O0KhP-00078Q-Nm for hipsec@ietf.org; Fri, 09 Apr 2010 23:21:07 +0300 Message-ID: <4BBF8C33.8050203@cs.hut.fi> Date: Fri, 09 Apr 2010 23:21:07 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100407 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BBF283A.9080408@ericsson.com> In-Reply-To: <4BBF283A.9080408@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 09 Apr 2010 20:21:46 -0000 On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: Hi, > Hi, > > in Anaheim, we decided to continue discussing on the list the following > draft: > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ > > In particular, I would like to see discussions on the lessons learned > from the STUN-based implementations and potential benefits of > implementing STUN-like functionality in HIP. from a protocol design perspective, demultiplexing of HIP, ESP and STUN packets is complicated. At implementation level, this introduced an additional requirement of packet capture using iptables. I believe this part would become cleaner design and implementation-wise by replacing STUN with HIP. It actually took quite a lot effort to hook in a standalone ICE library to the base exchange code. I believe it would also further complicate the mobility code. +1 for the new draft, I believe having a single control plane instead of two makes things simpler. I would suggest the new draft to replace the existing one for standards track. From ari.keranen@nomadiclab.com Mon Apr 12 02:33: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 89C473A68B6 for ; Mon, 12 Apr 2010 02:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 AT6NDY4nEj6o for ; Mon, 12 Apr 2010 02:33:37 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 002B13A6407 for ; Mon, 12 Apr 2010 02:33:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 72D754E6F8; Mon, 12 Apr 2010 12:33:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrR012rv1GcT; Mon, 12 Apr 2010 12:33:12 +0300 (EEST) 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 62F2A4E6C0; Mon, 12 Apr 2010 12:33:12 +0300 (EEST) Message-ID: <4BC2E8D6.6030404@nomadiclab.com> Date: Mon, 12 Apr 2010 12:33:10 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: hipsec@ietf.org References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> In-Reply-To: <4BBF8C33.8050203@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 12 Apr 2010 09:33:38 -0000 Hi, On 04/09/2010 11:21 PM, Miika Komu wrote: > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: >> in Anaheim, we decided to continue discussing on the list the following >> draft: >> >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ >> >> In particular, I would like to see discussions on the lessons learned >> from the STUN-based implementations and potential benefits of >> implementing STUN-like functionality in HIP. > > from a protocol design perspective, demultiplexing of HIP, ESP and STUN > packets is complicated. At implementation level, this introduced an > additional requirement of packet capture using iptables. I believe this > part would become cleaner design and implementation-wise by replacing > STUN with HIP. This is indeed a problem if you don't want to patch kernel code. While HIP packets can be simply demultiplexed using the non-ESP marker, STUN packets can't and therefore you need to either use some filtering before the IPsec processing (e.g., iptables) or process all the packets at user space, which causes some performance penalty. > It actually took quite a lot effort to hook in a standalone ICE library > to the base exchange code. I believe it would also further complicate > the mobility code. Also, using TURN for relaying IPsec ESP is not all that simple since you need to add and remove the TURN framing when sending data via a TURN relay. With an ESP relay you don't need any framing at all and all the ESP processing can be done as if no relay was used. That said, also TURN relaying can be used with the native NAT traversal mode and only the host using TURN relay needs to implement TURN. I think the amount of implementation effort needed for integrating an ICE library into a HIP implementation turned out to be quite a bit higher that initially estimated. Also, the amount of extra code (some 10 kLoC) needed for all the new parsers, state machines, etc., is quite high and by re-using the HIP code one should be able to do with much less. This should result in smaller binary size, less bugs, and easier debugging. > +1 for the new draft, I believe having a single control plane instead of > two makes things simpler. I would suggest the new draft to replace the > existing one for standards track. Considering the experiences with the STUN-based approach, the native HIP mode does sound like a better idea for the standards track. Cheers, Ari From heer@informatik.rwth-aachen.de Mon Apr 12 07:14:14 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 386193A6A1C for ; Mon, 12 Apr 2010 07:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 TJroLL5TFsWk for ; Mon, 12 Apr 2010 07:14:11 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 9AC133A684A for ; Mon, 12 Apr 2010 07:14:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L0R00B9FOVEXC80@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 12 Apr 2010 16:14:03 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,190,1270418400"; d="scan'208";a="52597799" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 12 Apr 2010 16:14:03 +0200 Received: from ip96.infrahip.net ([unknown] [193.167.187.96]) 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 <0L0R00LT3OVEQE10@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 12 Apr 2010 16:14:02 +0200 (CEST) From: Tobias Heer In-reply-to: <4BBCB5E3.3080707@htt-consult.com> Date: Mon, 12 Apr 2010 17:14:39 +0300 Message-id: <2B36458D-CD76-4FFA-8C29-EB6F90DB5248@cs.rwth-aachen.de> References: <4BBCB5E3.3080707@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2 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, 12 Apr 2010 14:14:14 -0000 Hi Bob, sorry for the late reply - I have been traveling / was on holiday, too. Am 07.04.2010 um 19:42 schrieb Robert Moskowitz: > I am back (kind of) from Passover holidays. > > Given some of the content of the 4843bis thread, I went looking to see if we had any writeup on the security threats for HITs, and really did not find a consistant writeup. Of course we want to minimize collisions, but what are the threats? > > 4423 has always 'allowed' for HITs from a source other than a Public Key, but does not go through the threats, even if there is a PK Host Identity, but something other than a Cryptographic Hash is used to derive the HIT from it. > I am not aware of such document but from my understanding, having a non-cryptographic HIT still requires some cryptographic binding to a public key so that you have a signature algorithm that you can use in the BEX. Such binding could be a certificate that binds the non-cryptographic identity to a public key. However, I do not know any direct source of information. I would certainly be interested if there is some work on this already. Tobias > Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest. > > > _______________________________________________ > 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 dwing@cisco.com Mon Apr 12 16:06: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 F15AD3A68CB for ; Mon, 12 Apr 2010 16:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GCrDsnXS7aqq for ; Mon, 12 Apr 2010 16:06:06 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 766A33A6868 for ; Mon, 12 Apr 2010 16:06:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcHAK9Ew0urR7Ht/2dsb2JhbACHWYEUklVxo1eZJYUMBIMl X-IronPort-AV: E=Sophos;i="4.52,193,1270425600"; d="scan'208";a="114190908" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Apr 2010 23:05:55 +0000 Received: from dwingwxp01 (dhcp-128-107-165-173.cisco.com [128.107.165.173]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CN5tEd025984; Mon, 12 Apr 2010 23:05:55 GMT From: "Dan Wing" To: "'Ari Keranen'" , References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> Date: Mon, 12 Apr 2010 16:05:55 -0700 Message-ID: <010501cada94$b4cbcab0$ada56b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BC2E8D6.6030404@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcraI0iWfTnSedsPSOOa6VNXec4SkQAcMe5A Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 12 Apr 2010 23:06:08 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > Sent: Monday, April 12, 2010 2:33 AM > To: hipsec@ietf.org > Subject: Re: [Hipsec] HIP Native NAT Traversal > > Hi, > > On 04/09/2010 11:21 PM, Miika Komu wrote: > > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > >> in Anaheim, we decided to continue discussing on the list > the following > >> draft: > >> > >> > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > traversal/ > >> > >> In particular, I would like to see discussions on the > lessons learned > >> from the STUN-based implementations and potential benefits of > >> implementing STUN-like functionality in HIP. > > > > from a protocol design perspective, demultiplexing of HIP, > ESP and STUN > > packets is complicated. At implementation level, this introduced an > > additional requirement of packet capture using iptables. I > believe this > > part would become cleaner design and implementation-wise by > replacing > > STUN with HIP. > > This is indeed a problem if you don't want to patch kernel > code. While > HIP packets can be simply demultiplexed using the non-ESP > marker, STUN > packets can't and therefore you need to either use some > filtering before > the IPsec processing (e.g., iptables) or process all the > packets at user > space, which causes some performance penalty. Has there been a discussion to send STUN directly over HIP, rather than replacing STUN with STUN-mimicing HIP messages? Sending STUN messages directly over HIP would remove the need to demux STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel (as with today's HIP), and deal with a single HIP 'container' for the STUN messages. > > It actually took quite a lot effort to hook in a standalone > > ICE library > > to the base exchange code. I believe it would also further > > complicate > > the mobility code. > > Also, using TURN for relaying IPsec ESP is not all that > simple since you > need to add and remove the TURN framing when sending data via a TURN > relay. IPsec ESP native (IP protocol 50) across a NAT? This isn't going to work well with large scale NATs with lots of clients going to the same destination (e.g., the same TURN server), as I understand IPsec rekeying changes the SPI and the large scale NAT won't know which IPsec session just got rekeyed. -d > With an ESP relay you don't need any framing at all > and all the > ESP processing can be done as if no relay was used. That > said, also TURN > relaying can be used with the native NAT traversal mode and only the > host using TURN relay needs to implement TURN. > > I think the amount of implementation effort needed for integrating an > ICE library into a HIP implementation turned out to be quite a bit > higher that initially estimated. Also, the amount of extra > code (some 10 > kLoC) needed for all the new parsers, state machines, etc., is quite > high and by re-using the HIP code one should be able to do with much > less. This should result in smaller binary size, less bugs, > and easier > debugging. > > > +1 for the new draft, I believe having a single control > plane instead of > > two makes things simpler. I would suggest the new draft to > replace the > > existing one for standards track. > > Considering the experiences with the STUN-based approach, the > native HIP > mode does sound like a better idea for the standards track. > > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From frogsir@gmail.com Mon Apr 12 20:13: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 1B0C13A6AF8 for ; Mon, 12 Apr 2010 20:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] 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 8swIqaIS4vW6 for ; Mon, 12 Apr 2010 20:13:20 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BF9513A6AF5 for ; Mon, 12 Apr 2010 20:13:19 -0700 (PDT) Received: by pwj2 with SMTP id 2so5079249pwj.31 for ; Mon, 12 Apr 2010 20:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:cc:content-type; bh=7Qzz2O3prhdb4nA2AtRpeg0u69N8Qo9RODn1Olw2Kpg=; b=NG2yViP/EF5WKwTs8O8/A+CtgMAqt7yeKB7ywFfldxW1wcuGktbWoIBijBME45YmYj I/WpCld4JdG5BQTwBfmuUaUHZ+EgUGYrhDI2wFVm93kBVIxz7aTzUv1/T6V1A1bIAFSQ 643s3PLvSCvcHcU2UtH/icQWaKE7/YS3wTNRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=VL2+m7E9R3epxa+oLPialudo/oipr50tA7ICVp8zq3rsFQUJujKhwiggacVbyUhGc9 sSSeZLwtooNKGYvGaabCf9mUZcqVIm434vvzG1QkXZmBLjuove3pjBZ/nZGE+4tFoxbf BiHcMpc3JaPkHu4HoqeEqkEXZb4An/4Ysgi+4= MIME-Version: 1.0 Received: by 10.140.161.18 with HTTP; Mon, 12 Apr 2010 20:13:09 -0700 (PDT) In-Reply-To: <4BBF8C33.8050203@cs.hut.fi> References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> Date: Tue, 13 Apr 2010 06:13:09 +0300 Received: by 10.140.252.10 with SMTP id z10mr4580898rvh.45.1271128389559; Mon, 12 Apr 2010 20:13:09 -0700 (PDT) Message-ID: From: frogsir Cc: hipsec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd107301fa5a9048415a46c Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 03:13:21 -0000 --000e0cd107301fa5a9048415a46c Content-Type: text/plain; charset=UTF-8 It will be easier to demultiplex connectivity checks for different HAs, if we use HIP native NAT traversal ICE is not a RFC yet. Therefore, it is not reliable. We have to consider the incompatibility of ICE versions and also STUN message versions. On Fri, Apr 9, 2010 at 11:21 PM, Miika Komu wrote: > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > > Hi, > > > Hi, >> >> in Anaheim, we decided to continue discussing on the list the following >> draft: >> >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ >> >> In particular, I would like to see discussions on the lessons learned >> from the STUN-based implementations and potential benefits of >> implementing STUN-like functionality in HIP. >> > > from a protocol design perspective, demultiplexing of HIP, ESP and STUN > packets is complicated. At implementation level, this introduced an > additional requirement of packet capture using iptables. I believe this part > would become cleaner design and implementation-wise by replacing STUN with > HIP. > > It actually took quite a lot effort to hook in a standalone ICE library to > the base exchange code. I believe it would also further complicate the > mobility code. > > +1 for the new draft, I believe having a single control plane instead of > two makes things simpler. I would suggest the new draft to replace the > existing one for standards track. > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > -- Best Regards Santtu (Nick name) Xiang Liu Operation Manager Frosmo Ltd. http://www.frosmo.com twitter.com/Frosmo Erottajankatu 15-17A 00130 Helsinki, Finland mobile: +358 44 3688809 fax: +358 20 7419 9099 Email: santtu.liu@frosmo.com MSN: frogsir@hotmail.com --000e0cd107301fa5a9048415a46c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It will be easier to demultiplex connectivity checks for different HAs, if = we use HIP native NAT traversal

ICE is not a RFC yet. Therefore, it is not reliable. We have to consider=20 the incompatibility of=C2=A0 ICE versions and also STUN message versions. <= br>


On Fri, Apr 9, 2010 at 11:21 PM, = Miika Komu <mkomu@c= s.hut.fi> wrote:
On 04/09/2010 04:= 14 PM, Gonzalo Camarillo wrote:

Hi,


Hi,

in Anaheim, we decided to continue discussing on the list the following
draft:

https://datatracker.ietf.org/doc/draft-keranen-= hip-native-nat-traversal/

In particular, I would like to see discussions on the lessons learned
from the STUN-based implementations and potential benefits of
implementing STUN-like functionality in HIP.

from a protocol design perspective, demultiplexing of HIP, ESP and STUN pac= kets is complicated. At implementation level, this introduced an additional= requirement of packet capture using iptables. I believe this part would be= come cleaner design and implementation-wise by replacing STUN with HIP.

It actually took quite a lot effort to hook in a standalone ICE library to = the base exchange code. I believe it would also further complicate the mobi= lity code.

+1 for the new draft, I believe having a single control plane instead of tw= o makes things simpler. I would suggest the new draft to replace the existi= ng one for standards track.

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org = https://www.ietf.org/mailman/listinfo/hipsec



--
Best Regard= s

Santtu (Nick name)
Xiang Liu

Operation Manager
Frosm= o Ltd.
http://www.frosmo.com
twitter.com/Frosmo

Erottajankatu 15-17A
00130 Helsinki,
Finland

mobile: +358 = 44 3688809
fax: +358 20 7419 9099
Email: santtu.liu@frosmo.com
MSN: frogsir@hotmail.com
--000e0cd107301fa5a9048415a46c-- From frogsir@gmail.com Mon Apr 12 20:22: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 E43603A6851 for ; Mon, 12 Apr 2010 20:22:17 -0700 (PDT) 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 G7trsriBzZQk for ; Mon, 12 Apr 2010 20:22:13 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id CF1CA28C163 for ; Mon, 12 Apr 2010 20:21:59 -0700 (PDT) Received: by pvf33 with SMTP id 33so2877810pvf.31 for ; Mon, 12 Apr 2010 20:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=lKTj51ihq/xXt1mYMpcW4Jacyf8/+7EetVkmCwCqfAw=; b=DyZw+2S8wNZxgJUBxDV06yJuLXLhe6o+tv2/0eSqzFEbO6QzhDczGmKiuiagiOCMcu 2ChYnBEORQ6w2fuOVkzApVGNDKho/SQx/MHPRpsU7nN/LBRYW5bZilPG5LKQR0bBpiZ2 CdanpbhrOgJmcOkjn8o+wA1nAL7txW51WPdHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xF2mR1FnvIia+i6jG6vEHts63BsfaBZ7izD+vYTOEmp8x+zB83jhTluMP96FN/VjX/ +dhd5nB/tbJUg6Touyhnos68ZmnDuh0mCaxHaEpNfmjEbnlLQD97qN6uw7TiDyRnO0re MF+3co5wIhPQXGcKIuxY9gCxUsCTAs2kxsaVk= MIME-Version: 1.0 Received: by 10.140.161.18 with HTTP; Mon, 12 Apr 2010 20:21:51 -0700 (PDT) In-Reply-To: <010501cada94$b4cbcab0$ada56b80@cisco.com> References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> <010501cada94$b4cbcab0$ada56b80@cisco.com> Date: Tue, 13 Apr 2010 06:21:51 +0300 Received: by 10.141.15.9 with SMTP id s9mr4529501rvi.219.1271128911681; Mon, 12 Apr 2010 20:21:51 -0700 (PDT) Message-ID: From: frogsir To: Dan Wing Content-Type: multipart/alternative; boundary=000e0cd111963e9a91048415c3fd Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 03:22:19 -0000 --000e0cd111963e9a91048415c3fd Content-Type: text/plain; charset=UTF-8 On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing wrote: > > > > -----Original Message----- > > From: hipsec-bounces@ietf.org > > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > > Sent: Monday, April 12, 2010 2:33 AM > > To: hipsec@ietf.org > > Subject: Re: [Hipsec] HIP Native NAT Traversal > > > > Hi, > > > > On 04/09/2010 11:21 PM, Miika Komu wrote: > > > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > > >> in Anaheim, we decided to continue discussing on the list > > the following > > >> draft: > > >> > > >> > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > > traversal/ > > >> > > >> In particular, I would like to see discussions on the > > lessons learned > > >> from the STUN-based implementations and potential benefits of > > >> implementing STUN-like functionality in HIP. > > > > > > from a protocol design perspective, demultiplexing of HIP, > > ESP and STUN > > > packets is complicated. At implementation level, this introduced an > > > additional requirement of packet capture using iptables. I > > believe this > > > part would become cleaner design and implementation-wise by > > replacing > > > STUN with HIP. > > > > This is indeed a problem if you don't want to patch kernel > > code. While > > HIP packets can be simply demultiplexed using the non-ESP > > marker, STUN > > packets can't and therefore you need to either use some > > filtering before > > the IPsec processing (e.g., iptables) or process all the > > packets at user > > space, which causes some performance penalty. > > Has there been a discussion to send STUN directly over HIP, rather > than replacing STUN with STUN-mimicing HIP messages? Sending > STUN messages directly over HIP would remove the need to demux > STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel > (as with today's HIP), and deal with a single HIP 'container' for > the STUN messages. > *We have made such implementation. The whole STUN message is encapsulate into HIP_STUN parameter which is carried by HIP_UPDATE packets. it solves most of the demultiplexing problems indeed.* > > > > It actually took quite a lot effort to hook in a standalone > > > ICE library > > > to the base exchange code. I believe it would also further > > > complicate > > > the mobility code. > > > > Also, using TURN for relaying IPsec ESP is not all that > > simple since you > > need to add and remove the TURN framing when sending data via a TURN > > relay. > > IPsec ESP native (IP protocol 50) across a NAT? This isn't > going to work well with large scale NATs with lots of clients > going to the same destination (e.g., the same TURN server), > as I understand IPsec rekeying changes the SPI and the large > scale NAT won't know which IPsec session just got rekeyed. > > -d > > > With an ESP relay you don't need any framing at all > > and all the > > ESP processing can be done as if no relay was used. That > > said, also TURN > > relaying can be used with the native NAT traversal mode and only the > > host using TURN relay needs to implement TURN. > > > > I think the amount of implementation effort needed for integrating an > > ICE library into a HIP implementation turned out to be quite a bit > > higher that initially estimated. Also, the amount of extra > > code (some 10 > > kLoC) needed for all the new parsers, state machines, etc., is quite > > high and by re-using the HIP code one should be able to do with much > > less. This should result in smaller binary size, less bugs, > > and easier > > debugging. > > > > > +1 for the new draft, I believe having a single control > > plane instead of > > > two makes things simpler. I would suggest the new draft to > > replace the > > > existing one for standards track. > > > > Considering the experiences with the STUN-based approach, the > > native HIP > > mode does sound like a better idea for the standards track. > > > > > > Cheers, > > Ari > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > -- Best Regards Santtu (Nick name) Xiang Liu Operation Manager Frosmo Ltd. http://www.frosmo.com twitter.com/Frosmo Erottajankatu 15-17A 00130 Helsinki, Finland mobile: +358 44 3688809 fax: +358 20 7419 9099 Email: santtu.liu@frosmo.com MSN: frogsir@hotmail.com --000e0cd111963e9a91048415c3fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 13, 2010 at 2:05 AM, Dan Win= g <dwing@cisco.com<= /a>> wrote:


> -----Original Message-----
> From: hipsec-bounces@ietf.o= rg
> [mailto:hipsec-bounces@ietf= .org] On Behalf Of Ari Keranen
> Sent: Monday, April 12, 2010 2:33 AM
> To: hipsec@ietf.org
> Subject: Re: [Hipsec] HIP Native NAT Traversal
>
> Hi,
>
> On 04/09/2010 11:21 PM, Miika Komu wrote:
> > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote:
> >> in Anaheim, we decided to continue discussing on the list
> the following
> >> draft:
> >>
> >>
> https://datatracker.ietf.org/doc/draft-keranen-hip-n= ative-nat-
> traversal/
> >>
> >> In particular, I would like to see discussions on the
> lessons learned
> >> from the STUN-based implementations and potential benefits of=
> >> implementing STUN-like functionality in HIP.
> >
> > from a protocol design perspective, demultiplexing of HIP,
> ESP and STUN
> > packets is complicated. At implementation level, this introduced = an
> > additional requirement of packet capture using iptables. I
> believe this
> > part would become cleaner design and implementation-wise by
> replacing
> > STUN with HIP.
>
> This is indeed a problem if you don't want to patch kernel
> code. While
> HIP packets can be simply demultiplexed using the non-ESP
> marker, STUN
> packets can't and therefore you need to either use some
> filtering before
> the IPsec processing (e.g., iptables) or process all the
> packets at user
> space, which causes some performance penalty.

Has there been a discussion to send STUN directly over HIP, rat= her
than replacing STUN with STUN-mimicing HIP messages? =C2=A0Sending
STUN messages directly over HIP would remove the need to demux
STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel
(as with today's HIP), and deal with a single HIP 'container' f= or
the STUN messages.


We have made such implem= entation.=C2=A0 The whole STUN message is encapsulate into HIP_STUN paramet= er which is carried by HIP_UPDATE packets. it solves most of=C2=A0 the demu= ltiplexing problems indeed. =C2=A0 =C2=A0

> > It actually took quite a lot effort to hook in a standalone
> > ICE library
> > to the base exchange code. I believe it would also further
> > complicate
> > the mobility code.
>
> Also, using TURN for relaying IPsec ESP is not all that
> simple since you
> need to add and remove the TURN framing when sending data via a TURN > relay.

IPsec ESP native (IP protocol 50) across a NAT? =C2=A0This isn't<= br> going to work well with large scale NATs with lots of clients
going to the same destination (e.g., the same TURN server),
as I understand IPsec rekeying changes the SPI and the large
scale NAT won't know which IPsec session just got rekeyed.

-d

> With an ESP relay you don't need any framing at all
> and all the
> ESP processing can be done as if no relay was used. That
> said, also TURN
> relaying can be used with the native NAT traversal mode and only the > host using TURN relay needs to implement TURN.
>
> I think the amount of implementation effort needed for integrating an<= br> > ICE library into a HIP implementation turned out to be quite a bit
> higher that initially estimated. Also, the amount of extra
> code (some 10
> kLoC) needed for all the new parsers, state machines, etc., is quite > high and by re-using the HIP code one should be able to do with much > less. This should result in smaller binary size, less bugs,
> and easier
> debugging.
>
> > +1 for the new draft, I believe having a single control
> plane instead of
> > two makes things simpler. I would suggest the new draft to
> replace the
> > existing one for standards track.
>
> Considering the experiences with the STUN-based approach, the
> native HIP
> mode does sound like a better idea for the standards track.
>
>
> Cheers,
> Ari
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
= https://www.ietf.org/mailman/listinfo/hipsec



--
Best Regard= s

Santtu (Nick name)
Xiang Liu

Operation Manager
Frosm= o Ltd.
http://www.frosmo.com
twitter.com/Frosmo

Erottajankatu 15-17A
00130 Helsinki,
Finland

mobile: +358 = 44 3688809
fax: +358 20 7419 9099
Email: santtu.liu@frosmo.com
MSN: frogsir@hotmail.com
--000e0cd111963e9a91048415c3fd-- From mkomu@cs.hut.fi Mon Apr 12 22:31:54 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 5B22028C0CE for ; Mon, 12 Apr 2010 22:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrTL7DVTj0n8 for ; Mon, 12 Apr 2010 22:31:52 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id BAEC13A682D for ; Mon, 12 Apr 2010 22:31:52 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O1Yiu-0003Fj-Qo for hipsec@ietf.org; Tue, 13 Apr 2010 08:31:44 +0300 Message-ID: <4BC401C5.1090800@cs.hut.fi> Date: Tue, 13 Apr 2010 08:31:49 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100407 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> <010501cada94$b4cbcab0$ada56b80@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 05:31:54 -0000 On 13/04/10 06:21, frogsir wrote: Hi, > On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing > wrote: > > > > > -----Original Message----- > > From: hipsec-bounces@ietf.org > > [mailto:hipsec-bounces@ietf.org ] > On Behalf Of Ari Keranen > > Sent: Monday, April 12, 2010 2:33 AM > > To: hipsec@ietf.org > > Subject: Re: [Hipsec] HIP Native NAT Traversal > > > > Hi, > > > > On 04/09/2010 11:21 PM, Miika Komu wrote: > > > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > > >> in Anaheim, we decided to continue discussing on the list > > the following > > >> draft: > > >> > > >> > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > > traversal/ > > >> > > >> In particular, I would like to see discussions on the > > lessons learned > > >> from the STUN-based implementations and potential benefits of > > >> implementing STUN-like functionality in HIP. > > > > > > from a protocol design perspective, demultiplexing of HIP, > > ESP and STUN > > > packets is complicated. At implementation level, this introduced an > > > additional requirement of packet capture using iptables. I > > believe this > > > part would become cleaner design and implementation-wise by > > replacing > > > STUN with HIP. > > > > This is indeed a problem if you don't want to patch kernel > > code. While > > HIP packets can be simply demultiplexed using the non-ESP > > marker, STUN > > packets can't and therefore you need to either use some > > filtering before > > the IPsec processing (e.g., iptables) or process all the > > packets at user > > space, which causes some performance penalty. > > Has there been a discussion to send STUN directly over HIP, rather > than replacing STUN with STUN-mimicing HIP messages? Sending > STUN messages directly over HIP would remove the need to demux > STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel > (as with today's HIP), and deal with a single HIP 'container' for > the STUN messages. > > > > *We have made such implementation. The whole STUN message is > encapsulate into HIP_STUN parameter which is carried by HIP_UPDATE > packets. it solves most of the demultiplexing problems indeed.* to be more precise, it was just an internal implementation trick to get incoming STUN messages from the packet capture module to hipd. So it really did not solve the problem because it still required HIP/ESP/STUN demuxing somewhere in the system. Having STUN messages in HIP encapsulated format *on-the-wire* would solve the demux problem, but the extra parser and marshaling library would still be necessary for STUN which would further increase the footprint of hipd. From ari.keranen@nomadiclab.com Tue Apr 13 00:10: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 ECB9D3A6896 for ; Tue, 13 Apr 2010 00:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.685, 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 AzjQgdN3DhlK for ; Tue, 13 Apr 2010 00:10:24 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 86E563A6853 for ; Tue, 13 Apr 2010 00:10:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id DA4794E6C1; Tue, 13 Apr 2010 10:10:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZpTYdoBMKx9; Tue, 13 Apr 2010 10:10:07 +0300 (EEST) 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 E2AE84E667; Tue, 13 Apr 2010 10:10:07 +0300 (EEST) Message-ID: <4BC418CF.8040605@nomadiclab.com> Date: Tue, 13 Apr 2010 10:10:07 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Dan Wing References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> <010501cada94$b4cbcab0$ada56b80@cisco.com> In-Reply-To: <010501cada94$b4cbcab0$ada56b80@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 07:10:27 -0000 On 04/13/2010 02:05 AM, Dan Wing wrote: >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen >> Sent: Monday, April 12, 2010 2:33 AM >> To: hipsec@ietf.org >> Subject: Re: [Hipsec] HIP Native NAT Traversal >> >> Hi, >> >> On 04/09/2010 11:21 PM, Miika Komu wrote: >>> On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: >>>> in Anaheim, we decided to continue discussing on the list >> the following >>>> draft: >>>> >>>> >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >> traversal/ >>>> In particular, I would like to see discussions on the >> lessons learned >>>> from the STUN-based implementations and potential benefits of >>>> implementing STUN-like functionality in HIP. >>> from a protocol design perspective, demultiplexing of HIP, >> ESP and STUN >>> packets is complicated. At implementation level, this introduced an >>> additional requirement of packet capture using iptables. I >> believe this >>> part would become cleaner design and implementation-wise by >> replacing >>> STUN with HIP. >> This is indeed a problem if you don't want to patch kernel >> code. While >> HIP packets can be simply demultiplexed using the non-ESP >> marker, STUN >> packets can't and therefore you need to either use some >> filtering before >> the IPsec processing (e.g., iptables) or process all the >> packets at user >> space, which causes some performance penalty. > > Has there been a discussion to send STUN directly over HIP, rather > than replacing STUN with STUN-mimicing HIP messages? Sending > STUN messages directly over HIP would remove the need to demux > STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel > (as with today's HIP), and deal with a single HIP 'container' for > the STUN messages. As Miika pointed out, this would still require implementing a STUN stack and considering that what is missing from HIP compared to STUN is just a couple of parameters, it does not seem worth while to duplicate all those features with STUN on top of HIP. Also, you would lose the possibility for middleboxes doing something smart when they see STUN if STUN was carried over HIP (if middleboxes would understand STUN over HIP, they would probably understand HIP too), so many of the benefits of using STUN would not apply here. >>> It actually took quite a lot effort to hook in a standalone >>> ICE library >>> to the base exchange code. I believe it would also further >>> complicate >>> the mobility code. >> Also, using TURN for relaying IPsec ESP is not all that >> simple since you >> need to add and remove the TURN framing when sending data via a TURN >> relay. > > IPsec ESP native (IP protocol 50) across a NAT? This isn't > going to work well with large scale NATs with lots of clients > going to the same destination (e.g., the same TURN server), > as I understand IPsec rekeying changes the SPI and the large > scale NAT won't know which IPsec session just got rekeyed. Actually, I meant UDP encapsulated IPsec ESP as described in draft-ietf-hip-nat-traversal. Cheers, Ari From rgm@htt-consult.com Tue Apr 13 05:34: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 254BC3A6AFF for ; Tue, 13 Apr 2010 05:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-0.990, 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 prSkUG8wWkVH for ; Tue, 13 Apr 2010 05:34:33 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A78B33A6A1D for ; Tue, 13 Apr 2010 05:34:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B0AC068B7A; Tue, 13 Apr 2010 12:28:45 +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 L9I0T9KoRtCE; Tue, 13 Apr 2010 08:28:36 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 42F5868B76; Tue, 13 Apr 2010 08:28:36 -0400 (EDT) Message-ID: <4BC464B2.1040609@htt-consult.com> Date: Tue, 13 Apr 2010 08:33:54 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BBCB5E3.3080707@htt-consult.com> <2B36458D-CD76-4FFA-8C29-EB6F90DB5248@cs.rwth-aachen.de> In-Reply-To: <2B36458D-CD76-4FFA-8C29-EB6F90DB5248@cs.rwth-aachen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2 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, 13 Apr 2010 12:34:34 -0000 On 04/12/2010 10:14 AM, Tobias Heer wrote: > Hi Bob, > > sorry for the late reply - I have been traveling / was on holiday, too. > > Am 07.04.2010 um 19:42 schrieb Robert Moskowitz: > > >> I am back (kind of) from Passover holidays. >> >> Given some of the content of the 4843bis thread, I went looking to see if we had any writeup on the security threats for HITs, and really did not find a consistant writeup. Of course we want to minimize collisions, but what are the threats? >> >> 4423 has always 'allowed' for HITs from a source other than a Public Key, but does not go through the threats, even if there is a PK Host Identity, but something other than a Cryptographic Hash is used to derive the HIT from it. >> >> > I am not aware of such document read RFC 4423. There are warnings, but as a 'nod' to work elsewhere we covered non-cryptographically based HITs with NO backing crypto. > but from my understanding, having a non-cryptographic HIT still requires some cryptographic binding to a public key so that you have a signature algorithm that you can use in the BEX. Obviously such a HIT would not use BEX, but some other HIP exchange. > Such binding could be a certificate that binds the non-cryptographic identity to a public key. However, I do not know any direct source of information. I would certainly be interested if there is some work on this already. > > Tobias > > >> Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest. >> >> >> _______________________________________________ >> 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 Tue Apr 13 06:02: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 734663A68E7 for ; Tue, 13 Apr 2010 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_50=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 P8-V3wAXtX2x for ; Tue, 13 Apr 2010 06:02:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 479F83A68A3 for ; Tue, 13 Apr 2010 06:02:48 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 014DE6829C for ; Tue, 13 Apr 2010 12:57:22 +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 LfkyTcfjYjrH for ; Tue, 13 Apr 2010 08:57:13 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 75A0568B5C for ; Tue, 13 Apr 2010 08:57:13 -0400 (EDT) Message-ID: <4BC46B67.5070906@htt-consult.com> Date: Tue, 13 Apr 2010 09:02:31 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BBCB5E3.3080707@htt-consult.com> In-Reply-To: <4BBCB5E3.3080707@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2 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, 13 Apr 2010 13:02:49 -0000 Collision Resistance HITs SHOULD be generated in a manner that is collision resistant. The application only knows the HIT, not the HI. So if an application were communicating with two hosts that had the same HIT, the API would not be able to route traffic appropriately. With the 96 bit space in ORCHIDv2, what is the probability of a collision, given Collision Resistance, with a host connected to 10 peers? To 10,000 peers? To 1,000,000 peers? (can someone do the math?) There is no advantage for Malice to find 2 HIs that have the same HIT. There does not seem to be a cryptographic risk related to Collision Resistance. Preimage Resistance If a host only has the HIT of its peer, then it is at risk of a Preimage attack. This applies to implementations that use a /etc/host file style ACL. Those that use HIP DNS records obtain both the HIT and HI and thus are resistant to a preimage attack. Opertunistic mode 'does not care'. It gets what it gets in R1; Malice can do whatever it wants in constructing an R1 and does not need to resort to a Preimage attack. Second Preimage Resistance Malice could launch a HIP state attack if the HIT generation is subject to a Second Preimage attack. If Malice determines that Bob and Alice are currently communicating, and Bob has HI1 and HIT1 and Malice can generate HI2 with HIT1, then Malice can 'take over' the communication channel from Bob to Alice with a new HIP exchange. This will be exposed, however as soon as Bob communicates with Alice and gets HIP errors. So this attack is only of value when Bob is a listener only (Alice is a sensor that only sends data) and does not check to ensure it is regularly receiving data from Alice. The Opertunistic mode analysis here is the same as for Preimage Resistance with the above state attack caveat. From this brief analysis I get that provided that HIT/HI connection is maintained in all ACLs (and state machines), then the only hash security feature HITs/ORCHIDs need is Collision Resistance. As noted above, this is NOT the case for implementations that rely on a /etc/hosts style ACL. On 04/07/2010 12:42 PM, Robert Moskowitz wrote: > I am back (kind of) from Passover holidays. > > Given some of the content of the 4843bis thread, I went looking to see > if we had any writeup on the security threats for HITs, and really did > not find a consistant writeup. Of course we want to minimize > collisions, but what are the threats? > > 4423 has always 'allowed' for HITs from a source other than a Public > Key, but does not go through the threats, even if there is a PK Host > Identity, but something other than a Cryptographic Hash is used to > derive the HIT from it. > > Or maybe it is all there (the threat analysis) and I am not seeing the > tree in the forest. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From heer@informatik.rwth-aachen.de Tue Apr 13 07:56:56 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 5C0343A6A1A for ; Tue, 13 Apr 2010 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 GtbJ3A9YcXks for ; Tue, 13 Apr 2010 07:56:55 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id E362A3A68B9 for ; Tue, 13 Apr 2010 07:56:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L0T000B0LIN7O20@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 13 Apr 2010 16:56:47 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,197,1270418400"; d="scan'208";a="28263455" 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; Tue, 13 Apr 2010 16:56:47 +0200 Received: from ip96.infrahip.net ([unknown] [193.167.187.96]) 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 <0L0T00GZ1LINK910@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 13 Apr 2010 16:56:47 +0200 (CEST) From: Tobias Heer In-reply-to: <4BC46B67.5070906@htt-consult.com> Date: Tue, 13 Apr 2010 17:57:25 +0300 Message-id: <4982A16E-AD6C-42DD-91E7-F3D50A205C19@cs.rwth-aachen.de> References: <4BBCB5E3.3080707@htt-consult.com> <4BC46B67.5070906@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2 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, 13 Apr 2010 14:56:56 -0000 Hi Bob, some quick comments from me... Am 13.04.2010 um 16:02 schrieb Robert Moskowitz: > Collision Resistance > > HITs SHOULD be generated in a manner that is collision resistant. The application only knows the HIT, not the HI. So if an application were communicating with two hosts that had the same HIT, the API would not be able to route traffic appropriately. With the 96 bit space in ORCHIDv2, what is the probability of a collision, given Collision Resistance, with a host connected to 10 peers? To 10,000 peers? To 1,000,000 peers? (can someone do the math?) > I had sent a mail to the list doing the math for finding collisions in equal-sized sets (any HIT collision will do). However for attacking any host in a ACL the sets are not equal-sized (you have a lot of possible HITs but only few that are useful for an attack). This makes it considerably harder. > There is no advantage for Malice to find 2 HIs that have the same HIT. There does not seem to be a cryptographic risk related to Collision Resistance. Uh, ... if Malice would find a HI/HIT collision for a HIT in use, she could impersonate the other host - that would be bad. Again, this does not apply to arbitrary HI collisions but to collisions for a set of target HIs. > > Preimage Resistance > > If a host only has the HIT of its peer, then it is at risk of a Preimage attack. This applies to implementations that use a /etc/host file style ACL. Those that use HIP DNS records obtain both the HIT and HI and thus are resistant to a preimage attack. Opertunistic mode 'does not care'. It gets what it gets in R1; Malice can do whatever it wants in constructing an R1 and does not need to resort to a Preimage attack. Finding the preimage of the HIT is not bad in the first place because in most cases the HI is public anyway. Second preimage is more relevant but only if the second preimage is a HI for which the attacker has the private key. IMHO just looking at preimage resistance boils down to breaking the HI. > > Second Preimage Resistance > > Malice could launch a HIP state attack if the HIT generation is subject to a Second Preimage attack. If Malice determines that Bob and Alice are currently communicating, and Bob has HI1 and HIT1 and Malice can generate HI2 with HIT1, then Malice can 'take over' the communication channel from Bob to Alice with a new HIP exchange. I guess this really depends how the HIP implementation handles HIs. If the implementation identifies HIP associations by HITs it is possible, if it identifies them by using HIs it is not a problem. RFC5201 Section 4.5.4. "Reboot and SA Timeout Restart of HIP" provides little information how to handle a second HIP association for the same HIT. RFC4423 states "In the extremely rare case of a single HIT mapping to more than one Host Identity, the Host Identifiers (public keys) will make the final difference.". Hence, the different HI should prevent an attacker from taking over a connection. However, the handling of the IPsec security associations (bound to HITs) will prevent the second host to open a connection - this could work as DoS attack... although I doubt that it is of practical relevance. > This will be exposed, however as soon as Bob communicates with Alice and gets HIP errors. So this attack is only of value when Bob is a listener only (Alice is a sensor that only sends data) and does not check to ensure it is regularly receiving data from Alice. I don't get the passage above. Tobias > > The Opertunistic mode analysis here is the same as for Preimage Resistance with the above state attack caveat. > > From this brief analysis I get that provided that HIT/HI connection is maintained in all ACLs (and state machines), then the only hash security feature HITs/ORCHIDs need is Collision Resistance. As noted above, this is NOT the case for implementations that rely on a /etc/hosts style ACL. > > > On 04/07/2010 12:42 PM, Robert Moskowitz wrote: >> I am back (kind of) from Passover holidays. >> >> Given some of the content of the 4843bis thread, I went looking to see if we had any writeup on the security threats for HITs, and really did not find a consistant writeup. Of course we want to minimize collisions, but what are the threats? >> >> 4423 has always 'allowed' for HITs from a source other than a Public Key, but does not go through the threats, even if there is a PK Host Identity, but something other than a Cryptographic Hash is used to derive the HIT from it. >> >> Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest. >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- 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 dwing@cisco.com Tue Apr 13 12:31:31 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 E5BEC3A6A63 for ; Tue, 13 Apr 2010 12:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VoqPsuAyqWOX for ; Tue, 13 Apr 2010 12:31:30 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 611413A6A4F for ; Tue, 13 Apr 2010 12:31:30 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIIANVjxEurR7Hu/2dsb2JhbACHWoEUhkWMEXGiZJoehQ0Egyc X-IronPort-AV: E=Sophos;i="4.52,199,1270425600"; d="scan'208";a="114674277" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 13 Apr 2010 19:31:24 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3DJVO2X009979; Tue, 13 Apr 2010 19:31:24 GMT From: "Dan Wing" To: "'frogsir'" References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> <010501cada94$b4cbcab0$ada56b80@cisco.com> Date: Tue, 13 Apr 2010 12:31:24 -0700 Message-ID: <05a901cadb3f$e7506a30$ada56b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcrauHZ5TGmtmGCFSviWX1K3amtcaAAh1guA Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 19:31:32 -0000 > -----Original Message----- > From: frogsir [mailto:frogsir@gmail.com] > Sent: Monday, April 12, 2010 8:22 PM > To: Dan Wing > Cc: Ari Keranen; hipsec@ietf.org > Subject: Re: [Hipsec] HIP Native NAT Traversal > > > > On Tue, Apr 13, 2010 at 2:05 AM, Dan Wing wrote: > > > > > > -----Original Message----- > > From: hipsec-bounces@ietf.org > > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > > Sent: Monday, April 12, 2010 2:33 AM > > To: hipsec@ietf.org > > Subject: Re: [Hipsec] HIP Native NAT Traversal > > > > > Hi, > > > > On 04/09/2010 11:21 PM, Miika Komu wrote: > > > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > > >> in Anaheim, we decided to continue discussing on the list > > the following > > >> draft: > > >> > > >> > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > > traversal/ > > >> > > >> In particular, I would like to see discussions on the > > lessons learned > > >> from the STUN-based implementations and potential > benefits of > > >> implementing STUN-like functionality in HIP. > > > > > > from a protocol design perspective, demultiplexing of HIP, > > ESP and STUN > > > packets is complicated. At implementation level, > this introduced an > > > additional requirement of packet capture using iptables. I > > believe this > > > part would become cleaner design and implementation-wise by > > replacing > > > STUN with HIP. > > > > This is indeed a problem if you don't want to patch kernel > > code. While > > HIP packets can be simply demultiplexed using the non-ESP > > marker, STUN > > packets can't and therefore you need to either use some > > filtering before > > the IPsec processing (e.g., iptables) or process all the > > packets at user > > space, which causes some performance penalty. > > > Has there been a discussion to send STUN directly over > HIP, rather > than replacing STUN with STUN-mimicing HIP messages? Sending > STUN messages directly over HIP would remove the need to demux > STUN/HIP/ESP -- you would only need to demux HIP/ESP in > the kernel > (as with today's HIP), and deal with a single HIP > 'container' for > the STUN messages. > > > > > We have made such implementation. The whole STUN message is > encapsulate into HIP_STUN parameter which is carried by > HIP_UPDATE packets. it solves most of the demultiplexing > problems indeed. Is that preferable to re-inventing STUN and ICE as HIP messages? -d > > > It actually took quite a lot effort to hook in a standalone > > > ICE library > > > to the base exchange code. I believe it would also further > > > complicate > > > the mobility code. > > > > Also, using TURN for relaying IPsec ESP is not all that > > simple since you > > need to add and remove the TURN framing when sending > data via a TURN > > relay. > > > IPsec ESP native (IP protocol 50) across a NAT? This isn't > going to work well with large scale NATs with lots of clients > going to the same destination (e.g., the same TURN server), > as I understand IPsec rekeying changes the SPI and the large > scale NAT won't know which IPsec session just got rekeyed. > > -d > > > > With an ESP relay you don't need any framing at all > > and all the > > ESP processing can be done as if no relay was used. That > > said, also TURN > > relaying can be used with the native NAT traversal > mode and only the > > host using TURN relay needs to implement TURN. > > > > I think the amount of implementation effort needed > for integrating an > > ICE library into a HIP implementation turned out to > be quite a bit > > higher that initially estimated. Also, the amount of extra > > code (some 10 > > kLoC) needed for all the new parsers, state machines, > etc., is quite > > high and by re-using the HIP code one should be able > to do with much > > less. This should result in smaller binary size, less bugs, > > and easier > > debugging. > > > > > +1 for the new draft, I believe having a single control > > plane instead of > > > two makes things simpler. I would suggest the new draft to > > replace the > > > existing one for standards track. > > > > Considering the experiences with the STUN-based approach, the > > native HIP > > mode does sound like a better idea for the standards track. > > > > > > Cheers, > > Ari > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > -- > Best Regards > > Santtu (Nick name) > Xiang Liu > > Operation Manager > Frosmo Ltd. > http://www.frosmo.com > twitter.com/Frosmo > > Erottajankatu 15-17A > 00130 Helsinki, > Finland > > mobile: +358 44 3688809 > fax: +358 20 7419 9099 > Email: santtu.liu@frosmo.com > MSN: frogsir@hotmail.com > > From dwing@cisco.com Tue Apr 13 12:42: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 B3F3D3A6AA9 for ; Tue, 13 Apr 2010 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ziPTGLrEywLt for ; Tue, 13 Apr 2010 12:42:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0DC8728C125 for ; Tue, 13 Apr 2010 12:41:30 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEIACdmxEurR7Ht/2dsb2JhbACHWoEUklZxom+aIYUNBIMn X-IronPort-AV: E=Sophos;i="4.52,199,1270425600"; d="scan'208";a="316845365" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2010 19:41:24 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3DJfOWJ003434; Tue, 13 Apr 2010 19:41:24 GMT From: "Dan Wing" To: "'Ari Keranen'" References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> <4BC2E8D6.6030404@nomadiclab.com> <010501cada94$b4cbcab0$ada56b80@cisco.com> <4BC418CF.8040605@nomadiclab.com> Date: Tue, 13 Apr 2010 12:41:23 -0700 Message-ID: <05c001cadb41$4cbc3380$ada56b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BC418CF.8040605@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acra2Fzov6YTCZm0TraC0y8Yw/8RoAAaM1Qw Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 13 Apr 2010 19:42:06 -0000 > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Tuesday, April 13, 2010 12:10 AM > To: Dan Wing > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] HIP Native NAT Traversal > > On 04/13/2010 02:05 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: hipsec-bounces@ietf.org > >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > >> Sent: Monday, April 12, 2010 2:33 AM > >> To: hipsec@ietf.org > >> Subject: Re: [Hipsec] HIP Native NAT Traversal > >> > >> Hi, > >> > >> On 04/09/2010 11:21 PM, Miika Komu wrote: > >>> On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > >>>> in Anaheim, we decided to continue discussing on the list > >> the following > >>>> draft: > >>>> > >>>> > >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > >> traversal/ > >>>> In particular, I would like to see discussions on the > >> lessons learned > >>>> from the STUN-based implementations and potential benefits of > >>>> implementing STUN-like functionality in HIP. > >>> from a protocol design perspective, demultiplexing of HIP, > >> ESP and STUN > >>> packets is complicated. At implementation level, this > introduced an > >>> additional requirement of packet capture using iptables. I > >> believe this > >>> part would become cleaner design and implementation-wise by > >> replacing > >>> STUN with HIP. > >> This is indeed a problem if you don't want to patch kernel > >> code. While > >> HIP packets can be simply demultiplexed using the non-ESP > >> marker, STUN > >> packets can't and therefore you need to either use some > >> filtering before > >> the IPsec processing (e.g., iptables) or process all the > >> packets at user > >> space, which causes some performance penalty. > > > > Has there been a discussion to send STUN directly over HIP, rather > > than replacing STUN with STUN-mimicing HIP messages? Sending > > STUN messages directly over HIP would remove the need to demux > > STUN/HIP/ESP -- you would only need to demux HIP/ESP in the kernel > > (as with today's HIP), and deal with a single HIP 'container' for > > the STUN messages. > > As Miika pointed out, this would still require implementing a > STUN stack > and considering that what is missing from HIP compared to > STUN is just a > couple of parameters, it does not seem worth while to duplicate all > those features with STUN on top of HIP. Also, you would lose the > possibility for middleboxes doing something smart when they > see STUN if > STUN was carried over HIP (if middleboxes would understand STUN over > HIP, they would probably understand HIP too), so many of the > benefits of > using STUN would not apply here. Ok. (I fear the day that middleboxes try to understand and 'help' STUN.) > >>> It actually took quite a lot effort to hook in a standalone > >>> ICE library > >>> to the base exchange code. I believe it would also further > >>> complicate > >>> the mobility code. > >> Also, using TURN for relaying IPsec ESP is not all that > >> simple since you > >> need to add and remove the TURN framing when sending data > via a TURN > >> relay. > > > > IPsec ESP native (IP protocol 50) across a NAT? This isn't > > going to work well with large scale NATs with lots of clients > > going to the same destination (e.g., the same TURN server), > > as I understand IPsec rekeying changes the SPI and the large > > scale NAT won't know which IPsec session just got rekeyed. > > Actually, I meant UDP encapsulated IPsec ESP as described in > draft-ietf-hip-nat-traversal. Ok, thanks. -d From dwing@cisco.com Tue Apr 13 20:43:14 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 499B128C229 for ; Tue, 13 Apr 2010 20:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QcUOApXCrBrE for ; Tue, 13 Apr 2010 20:43:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6589B28C224 for ; Tue, 13 Apr 2010 20:43:13 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4IACrWxEurR7H+/2dsb2JhbACHWoEUhlOMEnGjJZoFhQ0Egyg X-IronPort-AV: E=Sophos;i="4.52,202,1270425600"; d="scan'208";a="182624130" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2010 03:43:07 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3E3h7Su021262; Wed, 14 Apr 2010 03:43:07 GMT From: "Dan Wing" To: "'frogsir'" References: <4BBF283A.9080408@ericsson.com> <4BBF8C33.8050203@cs.hut.fi> Date: Tue, 13 Apr 2010 20:43:07 -0700 Message-ID: <07d001cadb84$98aef7d0$ada56b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acrat1QzMR62yng9Qc2FhWrVpFHFLAAzGyWQ Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP Native NAT Traversal 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, 14 Apr 2010 03:43:14 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of frogsir > Sent: Monday, April 12, 2010 8:13 PM > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] HIP Native NAT Traversal > > It will be easier to demultiplex connectivity checks for > different HAs, if we use HIP native NAT traversal > > ICE is not a RFC yet. ICE is in the RFC Editor's queue and will be RFC5245, http://www.rfc-editor.org/authors/rfc5245.txt > Therefore, it is not reliable. We have > to consider the incompatibility of ICE versions and also > STUN message versions. There is only one version of ICE and it supports only one version of STUN. There are certainly pre-standard implementations of ICE (such as that used by Microsoft's MSN), but HIP would never need to interoperate with those. -d > > > > On Fri, Apr 9, 2010 at 11:21 PM, Miika Komu wrote: > > > On 04/09/2010 04:14 PM, Gonzalo Camarillo wrote: > > Hi, > > > > Hi, > > in Anaheim, we decided to continue discussing > on the list the following > draft: > > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > traversal/ > > In particular, I would like to see discussions > on the lessons learned > from the STUN-based implementations and > potential benefits of > implementing STUN-like functionality in HIP. > > > > from a protocol design perspective, demultiplexing of > HIP, ESP and STUN packets is complicated. At implementation > level, this introduced an additional requirement of packet > capture using iptables. I believe this part would become > cleaner design and implementation-wise by replacing STUN with HIP. > > It actually took quite a lot effort to hook in a > standalone ICE library to the base exchange code. I believe > it would also further complicate the mobility code. > > +1 for the new draft, I believe having a single control > plane instead of two makes things simpler. I would suggest > the new draft to replace the existing one for standards track. > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > -- > Best Regards > > Santtu (Nick name) > Xiang Liu > > Operation Manager > Frosmo Ltd. > http://www.frosmo.com > twitter.com/Frosmo > > Erottajankatu 15-17A > 00130 Helsinki, > Finland > > mobile: +358 44 3688809 > fax: +358 20 7419 9099 > Email: santtu.liu@frosmo.com > MSN: frogsir@hotmail.com > > From rgm@htt-consult.com Wed Apr 14 07:03: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 092EA3A69EA for ; Wed, 14 Apr 2010 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_50=0.001, J_CHICKENPOX_51=0.6] 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 VAvD4SGvhxHN for ; Wed, 14 Apr 2010 07:03:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 3A53A3A69E2 for ; Wed, 14 Apr 2010 07:03:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 28B5F68B50 for ; Wed, 14 Apr 2010 13:58:05 +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 tOTcyVXelhp2 for ; Wed, 14 Apr 2010 09:57:56 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id CFF2268B49 for ; Wed, 14 Apr 2010 09:57:55 -0400 (EDT) Message-ID: <4BC5CB24.9050101@htt-consult.com> Date: Wed, 14 Apr 2010 10:03:16 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIT construction for ECC HIs 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, 14 Apr 2010 14:03:44 -0000 This may only be applied to Diet HIP, but ECC public keys have some interesting properties: The Private key is a uniformly distributed random number. From: draft-mcgrew-fundamental-ecc-02.txt, sec 5.3.1: The private key z is an integer between 1 and q - 1, inclusive, generated uniformly at random. (See Appendix B regarding random integers.) The public key is the group element Y = alpha^z. Each public key is associated with a particular particular parameter set as per Section 3.3. Thus the private key is uniformly distributed from the set: { 1, 2, .... , q-1 } Further a subset of the bits of the PK are uniformly distributed. Thus it is conceivable that the HIT for an ECC HI is just 96 bits selected from the HI. To put it within the ORCHID context, it could be a simple XOR with the HIP ECC context. Comments? Oh, this ASSuMEs that the EC private key was indeed uniformly randomly selected from the possible private keys... From root@core3.amsl.com Wed Apr 14 07:45: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 BAB203A69C1; Wed, 14 Apr 2010 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100414144501.BAB203A69C1@core3.amsl.com> Date: Wed, 14 Apr 2010 07:45:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-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: Wed, 14 Apr 2010 14:45: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 Signaling Message Transport Modes Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-00.txt Pages : 9 Date : 2010-04-14 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-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-over-hip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14073935.I-D@ietf.org> --NextPart-- From rgm@htt-consult.com Wed Apr 14 08:10: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 D2D4F28C27C for ; Wed, 14 Apr 2010 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, J_CHICKENPOX_51=0.6] 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 RxPdfHgb0oKQ for ; Wed, 14 Apr 2010 08:10:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9DAA128C27F for ; Wed, 14 Apr 2010 08:10:26 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id BB01568B6F for ; Wed, 14 Apr 2010 15:04:55 +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 RF9fNja1fl1e for ; Wed, 14 Apr 2010 11:04:46 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 756C168B67 for ; Wed, 14 Apr 2010 11:04:46 -0400 (EDT) Message-ID: <4BC5DAD0.6010400@htt-consult.com> Date: Wed, 14 Apr 2010 11:10:08 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BC5CB24.9050101@htt-consult.com> In-Reply-To: <4BC5CB24.9050101@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIT construction for ECC HIs 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, 14 Apr 2010 15:10:45 -0000 More on this from the On 04/14/2010 10:03 AM, Robert Moskowitz wrote: > This may only be applied to Diet HIP, but ECC public keys have some > interesting properties: > > The Private key is a uniformly distributed random number. From: > > draft-mcgrew-fundamental-ecc-02.txt, sec 5.3.1: > > The private key z is an integer between 1 and q - 1, inclusive, > generated uniformly at random. (See Appendix B regarding random > integers.) The public key is the group element > Y = alpha^z. Each public key is associated with a particular > particular parameter set as per Section 3.3. > > > Thus the private key is uniformly distributed from the set: > > { 1, 2, .... , q-1 } > > Further a subset of the bits of the PK are uniformly distributed. > > Thus it is conceivable that the HIT for an ECC HI is just 96 bits > selected from the HI. To put it within the ORCHID context, it could be > a simple XOR with the HIP ECC context. > > Comments? From the IRTF cfrg list: ============================ Don't have a proof, but here's a couple of thoughts: I actually wondered about the same question a few years ago and ran an experiment: I generated a few thousand public keys and ran the NIST randomness tests on them. Based on those tests, at least, the bits in the public keys did indeed look pretty random. Actually, here's a proof sketch: -- ECC public key has the form (x,y), where x,y in GF(2^n) satisfy the curve equations -- Since the curve equations are quadratic in y, the standard compact form of a public key is (x,b), where b is a single bit that indicates which of the two possible y values (see, e.g., [1]) -- A random public key is generated as a random element of a cyclic group of order p~=2^n -- So the entropy of the public key is approximately n bits, in a representation with n+1 bits -- So the public key distribution has to be close to uniform, for some definition of "close" (e.g., in terms of Kullback-Liebler divergence) [1] [1] =========================================== From rgm@htt-consult.com Fri Apr 16 13:37: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 8DAA63A6B6E for ; Fri, 16 Apr 2010 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_50=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 eIgj7iZ+mPqP for ; Fri, 16 Apr 2010 13:37:45 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7BF593A6A26 for ; Fri, 16 Apr 2010 13:37:45 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7FBD768BD5 for ; Fri, 16 Apr 2010 20:32:08 +0000 (UTC) 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 6vua+tNrBegt for ; Fri, 16 Apr 2010 16:31:58 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A4819696B7 for ; Fri, 16 Apr 2010 10:47:11 -0400 (EDT) Message-ID: <4BC879B6.5060305@htt-consult.com> Date: Fri, 16 Apr 2010 10:52:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Proposed cipers for 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 20:37:46 -0000 I have worked through a number of documents and have come up with the following recommendations that will go into 5201-bis. I am posting them separately here so others can think about them without having to wade through the changes we are making to 5201. First and foremost we are adding EC support. EC MAY be used for 128bit strenght crypto and MUST be used for 192 and 256bit crypto. This means that I am dropping many of the larger DH mod sizes. Also with the advent of fECC, I can drop some of the early ECC curves. fECC gives us the tools to work with well researched stuff. For now we are adding the larger SHA sizes and will await results of the NIST hash competition. Anyway, here we go... HOST_ID Algorithms Values RESERVED 0 DSA 3 [RFC2536] (RECOMMENDED) RSA 5 [RFC3110] (REQUIRED) ECDSA 6 [draft-?????.txt] Is there a doc for ECDSA in DNS records? Note that I dropped RSA/SHA1 for just RSA, as that is what we are really doing. DIFFIE_HELLMAN Group Value Reserved 0 DEPRECATED 1 DEPRECATED 2 DEPRECATED 3 3072-bit MODP group 4 RFC3526 DEPRECATED 5 DEPRECATED 6 256-bit random ECP group 7 RFC4753, draft-mcgrew-fundamental-ecc-02.txt 384-bit random ECP group 8 RFC4753, draft-mcgrew-fundamental-ecc-02.txt 521-bit random ECP group 9 RFC4753, draft-mcgrew-fundamental-ecc-02.txt Note all that is getting deprecated. Speak up if you have reasons to NOT drop what I did... HASH Hash Value Reserved 0 SHA-1 1 SHA-256 2 SHA-384 3 SHA-512 4 Nothing special here. HIP_TRANSFORM Suite ID Value RESERVED 0 AES-128-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) DEPRECATED 3 DEPRECATED 4 NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) DEPRECATED 6 NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) AES-128-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) AES-256-CBC with HMAC-SHA2 9 ([RFC3602], [RFC4868]) AES-CCM-8 9 [RFC4309] AES-CCM-16 10 [RFC4309] AES-GCM with a 8 octet ICV 11 [RFC4106] AES-GCM with a 16 octet ICV 12 [RFC4106] Again, note what is being deprecated. I believe I am adding only that which is of value. From samu.varjonen@hiit.fi Fri Apr 16 15:00:53 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 10E673A686D for ; Fri, 16 Apr 2010 15:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nBCf3Cy-0k2 for ; Fri, 16 Apr 2010 15:00:52 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id DB47E3A67EC for ; Fri, 16 Apr 2010 15:00:51 -0700 (PDT) Received: from [192.168.0.11] (cs78226116.pp.htv.fi [62.78.226.116]) by argo.otaverkko.fi (Postfix) with ESMTP id 05D5B25ED06 for ; Sat, 17 Apr 2010 01:00:44 +0300 (EEST) Message-ID: <4BC8DDF3.3090304@hiit.fi> Date: Sat, 17 Apr 2010 01:00:19 +0300 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fi; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org References: <4BC879B6.5060305@htt-consult.com> In-Reply-To: <4BC879B6.5060305@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Proposed cipers for 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 22:00:53 -0000 16.4.2010 17:52, Robert Moskowitz kirjoitti: > I have worked through a number of documents and have come up with the > following recommendations that will go into 5201-bis. I am posting them > separately here so others can think about them without having to wade > through the changes we are making to 5201. > > First and foremost we are adding EC support. EC MAY be used for 128bit > strenght crypto and MUST be used for 192 and 256bit crypto. This means > that I am dropping many of the larger DH mod sizes. Also with the advent > of fECC, I can drop some of the early ECC curves. fECC gives us the > tools to work with well researched stuff. For now we are adding the > larger SHA sizes and will await results of the NIST hash competition. > > Anyway, here we go... > > HOST_ID > > Algorithms Values > > RESERVED 0 > DSA 3 [RFC2536] (RECOMMENDED) > RSA 5 [RFC3110] (REQUIRED) > ECDSA 6 [draft-?????.txt] > > Is there a doc for ECDSA in DNS records? Note that I dropped RSA/SHA1 > for just RSA, as that is what we are really doing. > There was one draft (http://tools.ietf.org/html/draft-ietf-dnsext-ecc-key-10) years ago that has now expired. Have not found any newer one. > > DIFFIE_HELLMAN > > Group Value > > Reserved 0 > DEPRECATED 1 > DEPRECATED 2 > DEPRECATED 3 > 3072-bit MODP group 4 RFC3526 > DEPRECATED 5 > DEPRECATED 6 > 256-bit random ECP group 7 RFC4753, draft-mcgrew-fundamental-ecc-02.txt > 384-bit random ECP group 8 RFC4753, draft-mcgrew-fundamental-ecc-02.txt > 521-bit random ECP group 9 RFC4753, draft-mcgrew-fundamental-ecc-02.txt > > > Note all that is getting deprecated. Speak up if you have reasons to NOT > drop what I did... > > HASH > > Hash Value > > Reserved 0 > SHA-1 1 > SHA-256 2 > SHA-384 3 > SHA-512 4 > > Nothing special here. > > > HIP_TRANSFORM > > Suite ID Value > > RESERVED 0 > AES-128-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) > 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) > DEPRECATED 3 > DEPRECATED 4 > NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) > DEPRECATED 6 > NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) > AES-128-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) > AES-256-CBC with HMAC-SHA2 9 ([RFC3602], [RFC4868]) > AES-CCM-8 9 [RFC4309] > AES-CCM-16 10 [RFC4309] > AES-GCM with a 8 octet ICV 11 [RFC4106] > AES-GCM with a 16 octet ICV 12 [RFC4106] > > Again, note what is being deprecated. I believe I am adding only that > which is of value. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Fri Apr 16 16:23:05 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 4CF4C3A6862 for ; Fri, 16 Apr 2010 16:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.755, 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 L2BIDgkEKIIi for ; Fri, 16 Apr 2010 16:23:02 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 813DE3A68D9 for ; Fri, 16 Apr 2010 16:22:45 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4AB5A68D66 for ; Fri, 16 Apr 2010 23:17:06 +0000 (UTC) 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 iHtJsRdi0Upz for ; Fri, 16 Apr 2010 19:16:56 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7DFAF68FAA for ; Fri, 16 Apr 2010 15:57:50 -0400 (EDT) Message-ID: <4BC8C286.7050208@htt-consult.com> Date: Fri, 16 Apr 2010 16:03:18 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Proposed cipers for 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 23:23:05 -0000 I had some mail server problems and can't tell if this went out.... I have worked through a number of documents and have come up with the following recommendations that will go into 5201-bis. I am posting them separately here so others can think about them without having to wade through the changes we are making to 5201. First and foremost we are adding EC support. EC MAY be used for 128bit strenght crypto and MUST be used for 192 and 256bit crypto. This means that I am dropping many of the larger DH mod sizes. Also with the advent of fECC, I can drop some of the early ECC curves. fECC gives us the tools to work with well researched stuff. For now we are adding the larger SHA sizes and will await results of the NIST hash competition. Anyway, here we go... HOST_ID Algorithms Values RESERVED 0 DSA 3 [RFC2536] (RECOMMENDED) RSA 5 [RFC3110] (REQUIRED) ECDSA 6 [draft-?????.txt] Is there a doc for ECDSA in DNS records? Note that I dropped RSA/SHA1 for just RSA, as that is what we are really doing. DIFFIE_HELLMAN Group Value Reserved 0 DEPRECATED 1 DEPRECATED 2 DEPRECATED 3 3072-bit MODP group 4 RFC3526 DEPRECATED 5 DEPRECATED 6 256-bit random ECP group 7 RFC4753, draft-mcgrew-fundamental-ecc-02.txt 384-bit random ECP group 8 RFC4753, draft-mcgrew-fundamental-ecc-02.txt 521-bit random ECP group 9 RFC4753, draft-mcgrew-fundamental-ecc-02.txt Note all that is getting deprecated. Speak up if you have reasons to NOT drop what I did... HASH Hash Value Reserved 0 SHA-1 1 SHA-256 2 SHA-384 3 SHA-512 4 Nothing special here. HIP_TRANSFORM Suite ID Value RESERVED 0 AES-128-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) DEPRECATED 3 DEPRECATED 4 NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) DEPRECATED 6 NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) AES-128-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) AES-256-CBC with HMAC-SHA2 9 ([RFC3602], [RFC4868]) AES-CCM-8 9 [RFC4309] AES-CCM-16 10 [RFC4309] AES-GCM with a 8 octet ICV 11 [RFC4106] AES-GCM with a 16 octet ICV 12 [RFC4106] Again, note what is being deprecated. I believe I am adding only that which is of value. From rgm@htt-consult.com Sat Apr 17 21:35: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 8C9793A6AB7 for ; Sat, 17 Apr 2010 21:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_05=-1.11] 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 BNjprFT0jxBh for ; Sat, 17 Apr 2010 21:35:20 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DEA8B3A63EC for ; Sat, 17 Apr 2010 21:35:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 75EBC68D72; Sun, 18 Apr 2010 04:29:35 +0000 (UTC) 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 1JOPecry-a-o; Sun, 18 Apr 2010 00:29:25 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 95D3468BA1; Sun, 18 Apr 2010 00:29:25 -0400 (EDT) Message-ID: <4BCA8BF0.9060001@htt-consult.com> Date: Sun, 18 Apr 2010 00:34:56 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Samu Varjonen References: <4BC879B6.5060305@htt-consult.com> <4BC8DDF3.3090304@hiit.fi> In-Reply-To: <4BC8DDF3.3090304@hiit.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Proposed cipers for 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 04:35:21 -0000 On 04/16/2010 06:00 PM, Samu Varjonen wrote: > 16.4.2010 17:52, Robert Moskowitz kirjoitti: >> I have worked through a number of documents and have come up with the >> following recommendations that will go into 5201-bis. I am posting them >> separately here so others can think about them without having to wade >> through the changes we are making to 5201. >> >> First and foremost we are adding EC support. EC MAY be used for 128bit >> strenght crypto and MUST be used for 192 and 256bit crypto. This means >> that I am dropping many of the larger DH mod sizes. Also with the advent >> of fECC, I can drop some of the early ECC curves. fECC gives us the >> tools to work with well researched stuff. For now we are adding the >> larger SHA sizes and will await results of the NIST hash competition. >> >> Anyway, here we go... >> >> HOST_ID >> >> Algorithms Values >> >> RESERVED 0 >> DSA 3 [RFC2536] (RECOMMENDED) >> RSA 5 [RFC3110] (REQUIRED) >> ECDSA 6 [draft-?????.txt] >> >> Is there a doc for ECDSA in DNS records? Note that I dropped RSA/SHA1 >> for just RSA, as that is what we are really doing. >> > > There was one draft > (http://tools.ietf.org/html/draft-ietf-dnsext-ecc-key-10) years ago > that has now expired. Have not found any newer one. I will ask Donald about this. Thanks. > >> >> DIFFIE_HELLMAN >> >> Group Value >> >> Reserved 0 >> DEPRECATED 1 >> DEPRECATED 2 >> DEPRECATED 3 >> 3072-bit MODP group 4 RFC3526 >> DEPRECATED 5 >> DEPRECATED 6 >> 256-bit random ECP group 7 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> 384-bit random ECP group 8 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> 521-bit random ECP group 9 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> >> >> Note all that is getting deprecated. Speak up if you have reasons to NOT >> drop what I did... >> >> HASH >> >> Hash Value >> >> Reserved 0 >> SHA-1 1 >> SHA-256 2 >> SHA-384 3 >> SHA-512 4 >> >> Nothing special here. >> >> >> HIP_TRANSFORM >> >> Suite ID Value >> >> RESERVED 0 >> AES-128-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) >> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) >> DEPRECATED 3 >> DEPRECATED 4 >> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) >> DEPRECATED 6 >> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) >> AES-128-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) >> AES-256-CBC with HMAC-SHA2 9 ([RFC3602], [RFC4868]) >> AES-CCM-8 9 [RFC4309] >> AES-CCM-16 10 [RFC4309] >> AES-GCM with a 8 octet ICV 11 [RFC4106] >> AES-GCM with a 16 octet ICV 12 [RFC4106] >> >> Again, note what is being deprecated. I believe I am adding only that >> which is of value. >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From heer@informatik.rwth-aachen.de Sun Apr 18 08:33:25 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 5A7643A69B2 for ; Sun, 18 Apr 2010 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 UeaswWGm9U9u for ; Sun, 18 Apr 2010 08:33:24 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 4B3303A695B for ; Sun, 18 Apr 2010 08:33:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L1200FM0WJC5H70@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sun, 18 Apr 2010 17:33:12 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,231,1270418400"; d="scan'208";a="28559603" 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; Sun, 18 Apr 2010 17:33:12 +0200 Received: from host-57-236.lasipalatsi.fi ([unknown] [77.72.57.236]) 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 <0L12001WRWJB7P40@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sun, 18 Apr 2010 17:33:12 +0200 (CEST) From: Tobias Heer In-reply-to: <4BC8C24E.1090403@htt-consult.com> Date: Sun, 18 Apr 2010 18:33:55 +0300 Message-id: References: <4BBED40F.8040905@cs.hut.fi> <4BC77D3D.7000109@htt-consult.com> <4BC866A5.2060907@cs.hut.fi> <4BC8C24E.1090403@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Host ID question X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 15:33:25 -0000 Hi, Am 16.04.2010 um 23:02 schrieb Robert Moskowitz: > On 04/16/2010 09:31 AM, Miika Komu wrote: >> On 15/04/10 23:55, Robert Moskowitz wrote: >> >> Hi, >> >> maybe understood the intent of the question incorrectly, but here goes nothing.. >> >>> Why did we specify RSA/SHA1 for a Host ID value in 5201? >> >> RSA does not have any patents and it was interoperated successfully. >> >>> Why the inclusion of SHA1? >> >> Well supported everywhere and it was interoperated successfully. > > I have looked at the offending RFC: 3110 and see that there are TWO RR defined there. One for RSA keys one for RSA/SHA1 sig RR. And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA. Afterall, there is nothing hash related in HIPv1 Host-IDs. > If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both. IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course. 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 Sun Apr 18 14:56: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 4514B3A69D0 for ; Sun, 18 Apr 2010 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.696, 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 QYMouxO4e9NL for ; Sun, 18 Apr 2010 14:56:33 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9C1623A69C5 for ; Sun, 18 Apr 2010 14:56:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6B02F68C0D; Sun, 18 Apr 2010 21:50:46 +0000 (UTC) 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 Vjt2wgGv460d; Sun, 18 Apr 2010 17:50:36 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id E48D568BEF; Sun, 18 Apr 2010 17:50:36 -0400 (EDT) Message-ID: <4BCB7FF9.1030706@htt-consult.com> Date: Sun, 18 Apr 2010 17:56:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BBED40F.8040905@cs.hut.fi> <4BC77D3D.7000109@htt-consult.com> <4BC866A5.2060907@cs.hut.fi> <4BC8C24E.1090403@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Host ID question X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 21:56:34 -0000 On 04/18/2010 11:33 AM, Tobias Heer wrote: > Hi, > > Am 16.04.2010 um 23:02 schrieb Robert Moskowitz: > > >> On 04/16/2010 09:31 AM, Miika Komu wrote: >> >>> On 15/04/10 23:55, Robert Moskowitz wrote: >>> >>> Hi, >>> >>> maybe understood the intent of the question incorrectly, but here goes nothing.. >>> >>> >>>> Why did we specify RSA/SHA1 for a Host ID value in 5201? >>>> >>> RSA does not have any patents and it was interoperated successfully. >>> >>> >>>> Why the inclusion of SHA1? >>>> >>> Well supported everywhere and it was interoperated successfully. >>> >> I have looked at the offending RFC: 3110 and see that there are TWO RR defined there. One for RSA keys one for RSA/SHA1 sig RR. And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA. Afterall, there is nothing hash related in HIPv1 Host-IDs. >> >> > If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both. > > IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course. > This applies to Host_ID, which the TLV mimes just the RSA RR, not the RSA/SHA1 RR; at least as I look at the RFCs. Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash with RSA, when we will be adding a separate TLV for hash.... > 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 Mon Apr 19 13:36:26 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 D7FDA3A6872 for ; Mon, 19 Apr 2010 13:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_50=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 KPzDaflmw3YE for ; Mon, 19 Apr 2010 13:36:24 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 5B3D83A683E for ; Mon, 19 Apr 2010 13:36:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8B04768C30 for ; Mon, 19 Apr 2010 20:30:31 +0000 (UTC) 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 D94uto+rdiYx for ; Mon, 19 Apr 2010 16:30:22 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A604768C2C for ; Mon, 19 Apr 2010 16:30:22 -0400 (EDT) Message-ID: <4BCCBEAD.1080900@htt-consult.com> Date: Mon, 19 Apr 2010 16:35:57 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Full hash flexibility 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, 19 Apr 2010 20:36:27 -0000 As I plow through 5201, I am finding that we have the hash too tightly bound to the Host Identity. Here is from sec 3: HIP implementations MUST support the Rivest Shamir Adelman (RSA/SHA1) [RFC3110] public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) [RFC2536] algorithm; other algorithms MAY be supported. The Host Identity is JUST a public key, not also a hash. Both of these RFCs are for DNSSEC and describe BOTH a DNSKEY RR and a SIG RR. The DNSKEY RR has no hashing involved, only the SIG RR. I think this crept in along the way as people were always thinking about the hashing done on the HI to generate the HIT. But HIs are just the public key of an asymmetric crypto algorithm. So it is my intent to clean this language up and ask for people to look for places where we got 'sloppy' and slipped in a hash when discussing the HI. From rgm@htt-consult.com Mon Apr 19 14:01: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 940833A68D4 for ; Mon, 19 Apr 2010 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.690, 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 IWd96fVpOUQp for ; Mon, 19 Apr 2010 14:01:06 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 27E453A69D2 for ; Mon, 19 Apr 2010 14:00:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id F242868CDE; Mon, 19 Apr 2010 20:54:59 +0000 (UTC) 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 1OYrMHggvy25; Mon, 19 Apr 2010 16:54:50 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1FD8068C39; Mon, 19 Apr 2010 16:54:50 -0400 (EDT) Message-ID: <4BCCC469.2080807@htt-consult.com> Date: Mon, 19 Apr 2010 17:00:25 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Samu Varjonen References: <4BC879B6.5060305@htt-consult.com> <4BC8DDF3.3090304@hiit.fi> In-Reply-To: <4BC8DDF3.3090304@hiit.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Proposed cipers for 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:01:08 -0000 On 04/16/2010 06:00 PM, Samu Varjonen wrote: > 16.4.2010 17:52, Robert Moskowitz kirjoitti: >> I have worked through a number of documents and have come up with the >> following recommendations that will go into 5201-bis. I am posting them >> separately here so others can think about them without having to wade >> through the changes we are making to 5201. >> >> First and foremost we are adding EC support. EC MAY be used for 128bit >> strenght crypto and MUST be used for 192 and 256bit crypto. This means >> that I am dropping many of the larger DH mod sizes. Also with the advent >> of fECC, I can drop some of the early ECC curves. fECC gives us the >> tools to work with well researched stuff. For now we are adding the >> larger SHA sizes and will await results of the NIST hash competition. >> >> Anyway, here we go... >> >> HOST_ID >> >> Algorithms Values >> >> RESERVED 0 >> DSA 3 [RFC2536] (RECOMMENDED) >> RSA 5 [RFC3110] (REQUIRED) >> ECDSA 6 [draft-?????.txt] >> >> Is there a doc for ECDSA in DNS records? Note that I dropped RSA/SHA1 >> for just RSA, as that is what we are really doing. >> > > There was one draft > (http://tools.ietf.org/html/draft-ietf-dnsext-ecc-key-10) years ago > that has now expired. Have not found any newer one. I found it: http://www.ietf.org/internet-drafts/draft-hoffman-dnssec-ecdsa-01.txt And there was a short thread on it on the DNS list, so there will be a 02.txt. > >> >> DIFFIE_HELLMAN >> >> Group Value >> >> Reserved 0 >> DEPRECATED 1 >> DEPRECATED 2 >> DEPRECATED 3 >> 3072-bit MODP group 4 RFC3526 >> DEPRECATED 5 >> DEPRECATED 6 >> 256-bit random ECP group 7 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> 384-bit random ECP group 8 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> 521-bit random ECP group 9 RFC4753, draft-mcgrew-fundamental-ecc-02.txt >> >> >> Note all that is getting deprecated. Speak up if you have reasons to NOT >> drop what I did... >> >> HASH >> >> Hash Value >> >> Reserved 0 >> SHA-1 1 >> SHA-256 2 >> SHA-384 3 >> SHA-512 4 >> >> Nothing special here. >> >> >> HIP_TRANSFORM >> >> Suite ID Value >> >> RESERVED 0 >> AES-128-CBC with HMAC-SHA1 1 ([RFC3602], [RFC2404]) >> 3DES-CBC with HMAC-SHA1 2 ([RFC2451], [RFC2404]) >> DEPRECATED 3 >> DEPRECATED 4 >> NULL-ENCRYPT with HMAC-SHA1 5 ([RFC2410], [RFC2404]) >> DEPRECATED 6 >> NULL-ENCRYPT with HMAC-SHA2 7 ([RFC2410], [RFC4868]) >> AES-128-CBC with HMAC-SHA2 8 ([RFC3602], [RFC4868]) >> AES-256-CBC with HMAC-SHA2 9 ([RFC3602], [RFC4868]) >> AES-CCM-8 9 [RFC4309] >> AES-CCM-16 10 [RFC4309] >> AES-GCM with a 8 octet ICV 11 [RFC4106] >> AES-GCM with a 16 octet ICV 12 [RFC4106] >> >> Again, note what is being deprecated. I believe I am adding only that >> which is of value. >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Tue Apr 20 04:44:42 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 31A6A28C139 for ; Tue, 20 Apr 2010 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.647, 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 d0doSkzdTprx for ; Tue, 20 Apr 2010 04:44:41 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 44CDC3A6B9B for ; Tue, 20 Apr 2010 04:44:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5426868D16 for ; Tue, 20 Apr 2010 11:38:51 +0000 (UTC) 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 q0WX9ZrZQjZY for ; Tue, 20 Apr 2010 07:38:42 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 83D8368B89 for ; Tue, 20 Apr 2010 07:38:42 -0400 (EDT) Message-ID: <4BCD9393.3010803@htt-consult.com> Date: Tue, 20 Apr 2010 07:44:19 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] RFC 4869 - All we need is P-384 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, 20 Apr 2010 11:44:42 -0000 I have been conversing with Paul Hoffman about only ECC 384 in draft-hoffman-dnssec-ecdsa-01.txt He pointed out to me that all the US gov is requring is 192 bit strength for the EC keys, even though they are requring 256 bit SIZE in the symmetric key. So I am backing out the Host_ID of P-512, as Paul is not making a DNSKEY RR for it cause it is not being asked for. I will keep in the ECDH-521 for now unless there is a hum here that it is not needed either. From gonzalo.camarillo@ericsson.com Tue Apr 20 05:44: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 4667D3A6A77 for ; Tue, 20 Apr 2010 05:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.609 X-Spam-Level: X-Spam-Status: No, score=-105.609 tagged_above=-999 required=5 tests=[AWL=0.990, 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 VHRJB1byJR95 for ; Tue, 20 Apr 2010 05:44:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 377823A6A56 for ; Tue, 20 Apr 2010 05:44:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-e4-4bcda1bcc889 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BC.B9.23532.CB1ADCB4; Tue, 20 Apr 2010 14:44:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 14:44:44 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 14:44:44 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8214124D0 for ; Tue, 20 Apr 2010 15:44:44 +0300 (EEST) Message-ID: <4BCDA1BC.1020701@ericsson.com> Date: Tue, 20 Apr 2010 15:44:44 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2010 12:44:44.0678 (UTC) FILETIME=[40DAFA60:01CAE087] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] NAT traversal and the standards track work 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, 20 Apr 2010 12:44:57 -0000 Hi, we need to decide what to do with NAT traversal when moving to the standards track. We have the following drafts: https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ The draft above will soon become an Experimental RFC. https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ The draft above proposes implementing HIP-based connectivity checks instead of STUN-based ones. http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt The draft above, which needs to be revised, describes the mobility and multihoming extensions for NAT traversal. I would like to hear people's views on what to do here. Cheers, Gonzalo HIP co-chair From mkomu@cs.hut.fi Tue Apr 20 06:17:39 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 8D7403A69E2 for ; Tue, 20 Apr 2010 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QMk66fZz-Jc for ; Tue, 20 Apr 2010 06:17:36 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 1EE3E3A6BC8 for ; Tue, 20 Apr 2010 06:16:46 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O4DJc-00052D-8i for hipsec@ietf.org; Tue, 20 Apr 2010 16:16:36 +0300 Message-ID: <4BCDA933.4090005@cs.hut.fi> Date: Tue, 20 Apr 2010 16:16:35 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100410 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BCDA1BC.1020701@ericsson.com> In-Reply-To: <4BCDA1BC.1020701@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 20 Apr 2010 13:17:39 -0000 On 04/20/2010 03:44 PM, Gonzalo Camarillo wrote: Hi, for the design and implementation reasons discussed earlier on this mailing list, I'd give my support on draft-keranen-hip-native-nat-traversal. > Hi, > > we need to decide what to do with NAT traversal when moving to the > standards track. We have the following drafts: > > https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ > > The draft above will soon become an Experimental RFC. > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ > > The draft above proposes implementing HIP-based connectivity checks > instead of STUN-based ones. > > http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt > > The draft above, which needs to be revised, describes the mobility and > multihoming extensions for NAT traversal. > > I would like to hear people's views on what to do here. > > Cheers, > > Gonzalo > HIP co-chair > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Tue Apr 20 06:43: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 7837B28C148 for ; Tue, 20 Apr 2010 06:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_50=0.001, J_CHICKENPOX_13=0.6] 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 513EtJb3wJPA for ; Tue, 20 Apr 2010 06:43:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6D1BD3A6A9A for ; Tue, 20 Apr 2010 06:43:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 99BE468D16 for ; Tue, 20 Apr 2010 13:37:53 +0000 (UTC) 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 tk9NM0bLrJF0 for ; Tue, 20 Apr 2010 09:37:43 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 80FFF68D2C for ; Tue, 20 Apr 2010 09:37:39 -0400 (EDT) Message-ID: <4BCDAF74.9090600@htt-consult.com> Date: Tue, 20 Apr 2010 09:43:16 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] draft-ietf-v6ops-cpe-simple-security last call 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, 20 Apr 2010 13:43:44 -0000 This ID is in last call, and we kind of screwed up NOT getting on their plate long ago. But I spoke with James Woodyatt at IETF 77 and he just said to send in REAL text during last call. Here is the message I just posted to ipv6ops: ===================================================================== I discussed this briefly with James during IETF 77. HIP is on track to be reved for standards track. It is assigned Protocol number 139, and should be treated by cpe-simple-security the same as IKE. I will offer my best effort at text below. I apologize for the few week delay, Passover came RIGHT after IETF. And I SUPPOSE I should have pushed this 6 months ago while we were pushing to get HIP moving towards standards. But that is water under the bridge... On 03/29/2010 05:43 PM, james woodyatt wrote: > concerned-- > > This is to inform the chairs of the V6OPS working group that it is the > sense of the editor of draft-ietf-v6ops-cpe-simple-security and the > design team that worked most closely on it during its development, > that the latest posted revision, i.e. -10, is ready for Working Group > Last Call. In sec 2.2 add at the end of the para: HIP is also explicitly secured by definition, so this document recommends the DEFAULT operating mode permit Host Identity Protocol (HIP) flows to pass without filtering. Add sec 3.2.6: 3.2.6 Host Identity Protocol (HIP) Host Identity Protocol (HIP) offers greater flexibility and better overall security than the simple security of stateful packet filtering at network perimeters. Therefore, residential IPv6 gateways need not prohibit HIP traffic flows. REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Host Identity Protocol (HIP)" [RFC5201] in their outer IP extension header chain. {note here, 5201-bis exists, but it will take a few months to finish this (we are NOT expecting a long process to add the agreed changes to 5201). The new RFC will be tagged as Standard, but will use the same protocol number.} REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain. {note this is the same text as REC-21, as HIP uses ESP in TRANSPORT mode.} {note: There is no easy equivalence of REC-23 with HIP due to its mobility. In RFC 5206 we cover mobility and mid-box updating of moves. But do you want that here? In HIP the SPI is all you can count on, as the IP address pair are mutable during the life of the SPI.} In sec 8.1 add: RFC 5201 Thank you. ==================================================================== From gonzalo.camarillo@ericsson.com Tue Apr 20 10:48: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 381A93A6AE0 for ; Tue, 20 Apr 2010 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.597 X-Spam-Level: X-Spam-Status: No, score=-105.597 tagged_above=-999 required=5 tests=[AWL=1.002, 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 Cww7BDOZ8cgu for ; Tue, 20 Apr 2010 10:48:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 488563A67FD for ; Tue, 20 Apr 2010 10:48:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-8e-4bcde8f2a1ea Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 36.0D.23532.2F8EDCB4; Tue, 20 Apr 2010 19:48:34 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 19:48:33 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 19:48:33 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8FAEB24D0; Tue, 20 Apr 2010 20:48:33 +0300 (EEST) Message-ID: <4BCDE8F0.6020105@ericsson.com> Date: Tue, 20 Apr 2010 20:48:32 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Miika Komu References: <4BCDA1BC.1020701@ericsson.com> <4BCDA933.4090005@cs.hut.fi> In-Reply-To: <4BCDA933.4090005@cs.hut.fi> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2010 17:48:33.0872 (UTC) FILETIME=[B24D3D00:01CAE0B1] X-Brightmail-Tracker: AAAAAA== Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 20 Apr 2010 17:48:46 -0000 Hi Miika, thanks for your input. Note that I would also like to get input on what to do with the mobility and multihoming NAT traversal extensions. We can rule them out or in scope. Cheers, Gonzalo On 20/04/2010 4:16 PM, Miika Komu wrote: > On 04/20/2010 03:44 PM, Gonzalo Camarillo wrote: > > Hi, > > for the design and implementation reasons discussed earlier on this > mailing list, I'd give my support on draft-keranen-hip-native-nat-traversal. > >> Hi, >> >> we need to decide what to do with NAT traversal when moving to the >> standards track. We have the following drafts: >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >> >> The draft above will soon become an Experimental RFC. >> >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ >> >> The draft above proposes implementing HIP-based connectivity checks >> instead of STUN-based ones. >> >> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >> >> The draft above, which needs to be revised, describes the mobility and >> multihoming extensions for NAT traversal. >> >> I would like to hear people's views on what to do here. >> >> Cheers, >> >> Gonzalo >> HIP co-chair >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From mkomu@cs.hut.fi Tue Apr 20 11:05: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 8C2D53A6A53 for ; Tue, 20 Apr 2010 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ0wADLMlrO4 for ; Tue, 20 Apr 2010 11:05:03 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 4E96728C192 for ; Tue, 20 Apr 2010 11:04:52 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O4HoQ-0001CB-AE; Tue, 20 Apr 2010 21:04:42 +0300 Message-ID: <4BCDECEB.7080909@cs.hut.fi> Date: Tue, 20 Apr 2010 21:05:31 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100416 Shredder/3.0.5pre MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BCDA1BC.1020701@ericsson.com> <4BCDA933.4090005@cs.hut.fi> <4BCDE8F0.6020105@ericsson.com> In-Reply-To: <4BCDE8F0.6020105@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 20 Apr 2010 18:05:06 -0000 On 20/04/10 20:48, Gonzalo Camarillo wrote: Hi, I believe we could also fold mobility extensions into the native draft (or a separate one). I can volunteer to help to get this done if the WG agrees that the native way is the path to proceed. > Hi Miika, > > thanks for your input. Note that I would also like to get input on what > to do with the mobility and multihoming NAT traversal extensions. We can > rule them out or in scope. > > Cheers, > > Gonzalo > > On 20/04/2010 4:16 PM, Miika Komu wrote: >> On 04/20/2010 03:44 PM, Gonzalo Camarillo wrote: >> >> Hi, >> >> for the design and implementation reasons discussed earlier on this >> mailing list, I'd give my support on draft-keranen-hip-native-nat-traversal. >> >>> Hi, >>> >>> we need to decide what to do with NAT traversal when moving to the >>> standards track. We have the following drafts: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>> >>> The draft above will soon become an Experimental RFC. >>> >>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ >>> >>> The draft above proposes implementing HIP-based connectivity checks >>> instead of STUN-based ones. >>> >>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>> >>> The draft above, which needs to be revised, describes the mobility and >>> multihoming extensions for NAT traversal. >>> >>> I would like to hear people's views on what to do here. >>> >>> Cheers, >>> >>> Gonzalo >>> HIP co-chair >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > From rgm@htt-consult.com Wed Apr 21 08:40: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 6A79728C246 for ; Wed, 21 Apr 2010 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.664, 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 nVCflLMBUgex for ; Wed, 21 Apr 2010 08:40:57 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id C0EA128C2B7 for ; Wed, 21 Apr 2010 08:17:25 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5143968E2F for ; Wed, 21 Apr 2010 15:11:32 +0000 (UTC) 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 ce458-hlTEmH for ; Wed, 21 Apr 2010 11:11:23 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 9D94068B75 for ; Wed, 21 Apr 2010 11:11:23 -0400 (EDT) Message-ID: <4BCF16EC.6080806@htt-consult.com> Date: Wed, 21 Apr 2010 11:17:00 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Sending data on HIP packets 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, 21 Apr 2010 15:40:58 -0000 Is there any experience in sending data along with I2 and R2? Is this easy to do or very hard even with HIP aware apps? Do we provide for carrying data here with 5201-bis? From julienl@qualcomm.com Wed Apr 21 09:42: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 0D13428C0E2 for ; Wed, 21 Apr 2010 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 TzH+hoHOhYgx for ; Wed, 21 Apr 2010 09:42:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 17A5C28C30E for ; Wed, 21 Apr 2010 09:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1271866517; x=1303402517; 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:=20Robert=20Moskowitz=20,=20"hip sec@ietf.org"=0D=0A=09|Date:=20Wed,=2021 =20Apr=202010=2009:14:33=20-0700|Subject:=20RE:=20[Hipsec ]=20Sending=20data=20on=20HIP=20packets|Thread-Topic:=20[ Hipsec]=20Sending=20data=20on=20HIP=20packets |Thread-Index:=20AcrhaQb+ObERF0fNRhaVEcra1uzZ+AABEOGA |Message-ID:=20|References:=20<4BCF16EC.60 80806@htt-consult.com>|In-Reply-To:=20<4BCF16EC.6080806@h tt-consult.com>|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=CTEj9y/HUF2jIT+EIJgHe4C6C2YceNN0XfLIEr+DS/k=; b=R1lIt1QrOdB3sX/2t0041ATBvjL6W3Ru3DPsnjX4Jk2SJie+Pc5/dMHb 3iAxuMM9tTh695y1gvQTRhIZuMZlPsYXo2+RlQFljeS1EpxZNCap5s7va PGB3bVkIJkIp8/HkQZSAuYawWg2TQRRJnIpnMoIQRiIpMpn3ktoSw+sya Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5958"; a="39363328" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 21 Apr 2010 09:15:07 -0700 X-IronPort-AV: E=Sophos;i="4.52,247,1270450800"; d="scan'208";a="13514338" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Apr 2010 09:14:36 -0700 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.234.1; Wed, 21 Apr 2010 09:14:36 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 21 Apr 2010 09:14:35 -0700 From: "Laganier, Julien" To: Robert Moskowitz , "hipsec@ietf.org" Date: Wed, 21 Apr 2010 09:14:33 -0700 Thread-Topic: [Hipsec] Sending data on HIP packets Thread-Index: AcrhaQb+ObERF0fNRhaVEcra1uzZ+AABEOGA Message-ID: References: <4BCF16EC.6080806@htt-consult.com> In-Reply-To: <4BCF16EC.6080806@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] Sending data on HIP packets 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, 21 Apr 2010 16:42:29 -0000 Robert Moskowitz wrote: >=20 > Is there any experience in sending data along with I2 and R2? I don't. =20 > Is this easy to do or very hard even with HIP aware apps? Hmmm. Isn't this going to create problem with PMTUD because the PMTU on the= data sent over I2 and R2 will be lower than can be expected after the HIP = handshake concludes? On the other hand if the first sent is TCP SYN on I2 a= nd TCP SYN ACK on R2 then there's no problem with PMTUD... --julien From ari.keranen@nomadiclab.com Wed Apr 21 10:12: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 5D0F83A6A9E for ; Wed, 21 Apr 2010 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, 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 apyUV7wgP8cC for ; Wed, 21 Apr 2010 10:12:42 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 21CB33A6B45 for ; Wed, 21 Apr 2010 09:59:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id BBEBC4E6EE; Wed, 21 Apr 2010 19:59:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZiPJRshNEEx; Wed, 21 Apr 2010 19:58:59 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 3A37A4E6ED; Wed, 21 Apr 2010 19:58:56 +0300 (EEST) Message-ID: <4BCF2C84.2070208@nomadiclab.com> Date: Thu, 22 Apr 2010 02:49:08 +1000 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BCDA1BC.1020701@ericsson.com> <4BCDA933.4090005@cs.hut.fi> <4BCDE8F0.6020105@ericsson.com> <4BCDECEB.7080909@cs.hut.fi> In-Reply-To: <4BCDECEB.7080909@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 21 Apr 2010 17:12:46 -0000 Hi, I think the mobility and multihoming with NAT traversal is important (we're pretty much crippling HIP otherwise) and should be included as a work item. Cheers, Ari Miika Komu wrote: > On 20/04/10 20:48, Gonzalo Camarillo wrote: > > Hi, > > I believe we could also fold mobility extensions into the native draft > (or a separate one). I can volunteer to help to get this done if the WG > agrees that the native way is the path to proceed. > >> Hi Miika, >> >> thanks for your input. Note that I would also like to get input on what >> to do with the mobility and multihoming NAT traversal extensions. We can >> rule them out or in scope. >> >> Cheers, >> >> Gonzalo >> >> On 20/04/2010 4:16 PM, Miika Komu wrote: >>> On 04/20/2010 03:44 PM, Gonzalo Camarillo wrote: >>> >>> Hi, >>> >>> for the design and implementation reasons discussed earlier on this >>> mailing list, I'd give my support on >>> draft-keranen-hip-native-nat-traversal. >>> >>>> Hi, >>>> >>>> we need to decide what to do with NAT traversal when moving to the >>>> standards track. We have the following drafts: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>>> >>>> The draft above will soon become an Experimental RFC. >>>> >>>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-traversal/ >>>> >>>> >>>> The draft above proposes implementing HIP-based connectivity checks >>>> instead of STUN-based ones. >>>> >>>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>>> >>>> The draft above, which needs to be revised, describes the mobility and >>>> multihoming extensions for NAT traversal. >>>> >>>> I would like to hear people's views on what to do here. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> HIP co-chair >>>> >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hipsec >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Wed Apr 21 10:41: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 A3E233A6C2E for ; Wed, 21 Apr 2010 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, 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 AjEjqm5948Kd for ; Wed, 21 Apr 2010 10:41:06 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DA6A73A6CA3 for ; Wed, 21 Apr 2010 10:30:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 01F0D6912C; Wed, 21 Apr 2010 17:24:14 +0000 (UTC) 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 yCjlfN4Yhu4o; Wed, 21 Apr 2010 13:24:04 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8900E6912B; Wed, 21 Apr 2010 13:24:04 -0400 (EDT) Message-ID: <4BCF3608.7030108@htt-consult.com> Date: Wed, 21 Apr 2010 13:29:44 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4BCF16EC.6080806@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Sending data on HIP packets 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, 21 Apr 2010 17:41:07 -0000 On 04/21/2010 12:14 PM, Laganier, Julien wrote: > Robert Moskowitz wrote: > >> Is there any experience in sending data along with I2 and R2? >> > I don't. > > >> Is this easy to do or very hard even with HIP aware apps? >> > Hmmm. Isn't this going to create problem with PMTUD because the PMTU on the data sent over I2 and R2 will be lower than can be expected after the HIP handshake concludes? On the other hand if the first sent is TCP SYN on I2 and TCP SYN ACK on R2 then there's no problem with PMTUD... The Initiator would have to 'know' that the data would fit within the allowed frame size. The Responder (after validating I2 and setting up the HIP Association state) might just pass the data up the stack and immediate send R2 without any data, the data response following later in its own datagram. Or if the Responder 'knows' there should be a response, it holds off on sending R2 until it gets the data (typically a TCP SYN/ACK). In fact if the higher layer rejects the connection with a quite drop, the Responder could not even send R2 and quitely drop the Association as well. Lots of room for smart behaviour. Or bad programming :) From rgm@htt-consult.com Thu Apr 22 08:24: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 6FCAC28C1E4 for ; Thu, 22 Apr 2010 08:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, 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 gVuYsPlXYs7s for ; Thu, 22 Apr 2010 08:24:29 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 8A1D728C12A for ; Thu, 22 Apr 2010 08:21:54 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2DAD868E83 for ; Thu, 22 Apr 2010 15:15:52 +0000 (UTC) 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 bPF6m0u6pI1V for ; Thu, 22 Apr 2010 11:15:43 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 29DC368C14 for ; Thu, 22 Apr 2010 11:15:43 -0400 (EDT) Message-ID: <4BD06975.9040605@htt-consult.com> Date: Thu, 22 Apr 2010 11:21:25 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Removing DH 384-bit group 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, 22 Apr 2010 15:24:35 -0000 This is a very weak DH group we put in to have some DH for weak systems. How does the computational cost of ECDH-256 compare to it? How small of a ECDH key would be of similar computational cost (and probably stronger)? Seems easier to add a small ECDH that keep this weak key in. I am working on Diet HIP exchange that will be for truly little systems. Work is dragging, as I want to get through 5201-bis first (and dealing with items like this one). From rgm@htt-consult.com Thu Apr 22 13:28: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 978363A68CC for ; Thu, 22 Apr 2010 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 UgiWU9AXgZZr for ; Thu, 22 Apr 2010 13:28:02 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 411EA3A6359 for ; Thu, 22 Apr 2010 13:28:02 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A0F0E68C76 for ; Thu, 22 Apr 2010 20:22:05 +0000 (UTC) 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 86hkTOvGNzlJ for ; Thu, 22 Apr 2010 16:21:55 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 20B9868B6E for ; Thu, 22 Apr 2010 16:21:55 -0400 (EDT) Message-ID: <4BD0B13A.4050403@htt-consult.com> Date: Thu, 22 Apr 2010 16:27:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BD06975.9040605@htt-consult.com> In-Reply-To: <4BD06975.9040605@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Removing DH 384-bit group 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, 22 Apr 2010 20:28:03 -0000 On 04/22/2010 11:21 AM, Robert Moskowitz wrote: > This is a very weak DH group we put in to have some DH for weak systems. > > How does the computational cost of ECDH-256 compare to it? How small > of a ECDH key would be of similar computational cost (and probably > stronger)? Seems easier to add a small ECDH that keep this weak key in. I found: http://www.nsa.gov/business/programs/elliptic_curve.shtml and it gives some basic numbers on the computational cost of ECDH vs DH. 80 bit security 160 ECDH which is 1/3 the cost of the DH equiv. This is probably NOT as cheap as DH-384, but probably 'good enough', plus it is documented what you get with ECDH-160. If someone feels we should have something weaker than ECDH-160, please chime in. > > I am working on Diet HIP exchange that will be for truly little > systems. Work is dragging, as I want to get through 5201-bis first > (and dealing with items like this one). > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From oleg.ponomarev@hiit.fi Fri Apr 23 00:03: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 C7D243A6970 for ; Fri, 23 Apr 2010 00:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 COoBnvIz0TRM for ; Fri, 23 Apr 2010 00:03:06 -0700 (PDT) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 864C13A6895 for ; Fri, 23 Apr 2010 00:03:04 -0700 (PDT) Received: from stargazer.pc.infrahip.net (stargazer.pc.infrahip.net [IPv6:2001:708:140:220:21e:4fff:fe92:4522]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id o3N71jSC007411; Fri, 23 Apr 2010 10:01:45 +0300 Date: Fri, 23 Apr 2010 10:01:44 +0300 (EEST) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer.pc.infrahip.net To: Robert Moskowitz In-Reply-To: <4BD06975.9040605@htt-consult.com> Message-ID: References: <4BD06975.9040605@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: "hipsec@ietf.org" Subject: Re: [Hipsec] Removing DH 384-bit group 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, 23 Apr 2010 07:03:06 -0000 Hi! On Thu, 22 Apr 2010, Robert Moskowitz wrote: > This is a very weak DH group we put in to have some DH for weak systems. > > How does the computational cost of ECDH-256 compare to it? How small of a > ECDH key would be of similar computational cost (and probably stronger)? > Seems easier to add a small ECDH that keep this weak key in. DH384 takes ~124 usec using Intel Xeon E5440 @ 2.83GHz ECDH112 -/- 175 usec (56-bit strong and weakest available in OpenSSL) With Nokia tablet N810: DH384 ~5.0 msec ECDH112 ~4.6 msec ECDH128 ~5.2 msec ECDH160 ~7.7 msec (DH768 ~33.9 msec) -- Regards, Oleg. From rgm@htt-consult.com Fri Apr 23 05:05: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 EC5E228C477 for ; Fri, 23 Apr 2010 05:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, 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 PEOUsR9h+hLm for ; Fri, 23 Apr 2010 05:05:46 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 931AB3A6B92 for ; Fri, 23 Apr 2010 04:38:56 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 09B6968BF0; Fri, 23 Apr 2010 11:32:59 +0000 (UTC) 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 p1wrZ8heBi0k; Fri, 23 Apr 2010 07:32:49 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id CC72E68C28; Fri, 23 Apr 2010 07:32:43 -0400 (EDT) Message-ID: <4BD186B4.1010002@htt-consult.com> Date: Fri, 23 Apr 2010 07:38:28 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Oleg Ponomarev References: <4BD06975.9040605@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Removing DH 384-bit group 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, 23 Apr 2010 12:05:47 -0000 On 04/23/2010 03:01 AM, Oleg Ponomarev wrote: > Hi! On Thu, 22 Apr 2010, Robert Moskowitz wrote: > >> This is a very weak DH group we put in to have some DH for weak systems. >> >> How does the computational cost of ECDH-256 compare to it? How small >> of a ECDH key would be of similar computational cost (and probably >> stronger)? Seems easier to add a small ECDH that keep this weak key in. > > DH384 takes ~124 usec using Intel Xeon E5440 @ 2.83GHz > ECDH112 -/- 175 usec (56-bit strong and weakest available in OpenSSL) > > With Nokia tablet N810: > DH384 ~5.0 msec > ECDH112 ~4.6 msec > ECDH128 ~5.2 msec > ECDH160 ~7.7 msec > (DH768 ~33.9 msec) Great numbers. thanks. Do you have a ECDH equiv for 100bits strength (as the DH-1536 seems to work out to)? Probably ECDH-200 or there abouts. In my searching for info on this, I encountered a dead link for a paper of yours on EC with HIP.... From rgm@htt-consult.com Fri Apr 23 11:20:53 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 7C17B3A6A71 for ; Fri, 23 Apr 2010 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmUipJiblKDF for ; Fri, 23 Apr 2010 11:20:52 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DF2E93A6A00 for ; Fri, 23 Apr 2010 11:20:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1D77668B6E for ; Fri, 23 Apr 2010 18:14:52 +0000 (UTC) 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 PizLqT13tK4o for ; Fri, 23 Apr 2010 14:14:42 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5FA6A68B6D for ; Fri, 23 Apr 2010 14:14:42 -0400 (EDT) Message-ID: <4BD1E4EC.6000706@htt-consult.com> Date: Fri, 23 Apr 2010 14:20:28 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Manditory to implement Host ID Lengths 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, 23 Apr 2010 18:20:54 -0000 I don't see any text on Manditory to implement Host ID lengths. Kind of do what you think is right and we will probably get interoperability. Seems this is the one area we missed. So what is the smallest RSA key size, what is manditory, and what is recommended? Given that we had manditory DH-1536, is RSA 1536 the matching manditory Host ID length? Or does DH-1536 match up with RSA 1024? We recommend DH-3072, but go with RSA 2048? I would REALLY like to have some reasonable recommendations here for RSA and DSA. For ECDSA and ECDH, we are starting clean, and I **THINK** I have the literature figured out. We will mandate p-256 and recommend p-384 for suite-b compliance. Some help here, please, so I can finish up another loose end in 5201-bis. From rgm@htt-consult.com Fri Apr 23 13:59: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 AFC7C3A691F for ; Fri, 23 Apr 2010 13:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.537, 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 q8XW69Rt1p01 for ; Fri, 23 Apr 2010 13:59:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DB8A83A68AF for ; Fri, 23 Apr 2010 13:59:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1C2AE68B8A for ; Fri, 23 Apr 2010 20:53:40 +0000 (UTC) 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 ZgLnfMdHumRH for ; Fri, 23 Apr 2010 16:53:30 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id D553F68B89 for ; Fri, 23 Apr 2010 16:53:30 -0400 (EDT) Message-ID: <4BD20A20.7020402@htt-consult.com> Date: Fri, 23 Apr 2010 16:59:12 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BD1E4EC.6000706@htt-consult.com> In-Reply-To: <4BD1E4EC.6000706@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Manditory to implement Host ID Lengths 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, 23 Apr 2010 20:59:40 -0000 This leads to thoughts on cipher suites. See the end.... On 04/23/2010 02:20 PM, Robert Moskowitz wrote: > I don't see any text on Manditory to implement Host ID lengths. Kind > of do what you think is right and we will probably get > interoperability. Seems this is the one area we missed. > > So what is the smallest RSA key size, what is manditory, and what is > recommended? > > Given that we had manditory DH-1536, is RSA 1536 the matching > manditory Host ID length? Or does DH-1536 match up with RSA 1024? > > We recommend DH-3072, but go with RSA 2048? > > I would REALLY like to have some reasonable recommendations here for > RSA and DSA. > > For ECDSA and ECDH, we are starting clean, and I **THINK** I have the > literature figured out. We will mandate p-256 and recommend p-384 for > suite-b compliance. > > Some help here, please, so I can finish up another loose end in 5201-bis. Here are some proposed cipher suites. Using RFCs 4308 and 4869 as guidelines... HIP BEX Cipher suites: Suite Host_ID Diffie_Hellman Hash Recommended HIP-Transform 1 ECDSA-160 ECDH-160 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with HMAC-SHA1 2 RSA 1024 DH-1536 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with HMAC-SHA1 3 RSA-2048 DH-3072 SHA-256 AES-128-CBC with HMAC-SHA2 or AES-CCM-8 4 ECDSA-256 ECDH-256 SHA-256 AES-256-CBC with HMAC-SHA2 or AES-CCM-16 or AES-GCM with a 16 octet ICV 5 ECDSA-384 ECDH-384 SHA-384 AES-256-CBC with HMAC-SHA2 or AES-CCM-16 or AES-GCM with a 16 octet ICV 3 is Manditory. 1 & 4 are recommended (1 for servers supporting weak clients)? 5 is for Suite-B. From thomas.r.henderson@boeing.com Sun Apr 25 21:52: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 130AC3A6AF5 for ; Sun, 25 Apr 2010 21:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-0.418, 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 fsPS96uc51QR for ; Sun, 25 Apr 2010 21:52:21 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 862503A683C for ; Sun, 25 Apr 2010 21:52:20 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3Q4q2Rp009667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Apr 2010 23:52:02 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3Q4q1PH007510; Sun, 25 Apr 2010 23:52:01 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3Q4q1aE007507 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 25 Apr 2010 23:52:01 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Sun, 25 Apr 2010 21:52:01 -0700 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Sun, 25 Apr 2010 21:51:59 -0700 Thread-Topic: [Hipsec] NAT traversal and the standards track work Thread-Index: Acrgh0wNBrIlx01BRN6G6GJXzN9dCQEdD+nQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> References: <4BCDA1BC.1020701@ericsson.com> In-Reply-To: <4BCDA1BC.1020701@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 26 Apr 2010 04:52:23 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, April 20, 2010 5:45 AM > To: HIP > Subject: [Hipsec] NAT traversal and the standards track work > > Hi, > > we need to decide what to do with NAT traversal when moving to the > standards track. We have the following drafts: > > https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ > > The draft above will soon become an Experimental RFC. > > https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- > traversal/ > > The draft above proposes implementing HIP-based connectivity checks > instead of STUN-based ones. > > http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt > > The draft above, which needs to be revised, describes the mobility and > multihoming extensions for NAT traversal. > > I would like to hear people's views on what to do here. > Gonzalo, I would like to see both topics (NAT traversal, and mobility manag= ement aspects of NAT traversal) on the revised charter, as the second phase= of standards-track work, as we discussed in Anaheim. I am neutral on the = questions of which one of the two drafts to adopt (if a choice needs to be = made now) and on whether the nat-mm draft should remain separate or should = be combined into one NAT traversal draft. - Tom From heer@informatik.rwth-aachen.de Mon Apr 26 03:05: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 B24863A6B61 for ; Mon, 26 Apr 2010 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 kFiIlswNOXGE for ; Mon, 26 Apr 2010 03:05:45 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id A09E33A6902 for ; Mon, 26 Apr 2010 03:05:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L1H000IDAP7URB0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 12:05:31 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,272,1270418400"; d="scan'208";a="29094627" 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; Mon, 26 Apr 2010 12:05:32 +0200 Received: from informatik-lufgi-4-137-226-59-251.nn.rwth-aachen.de ([unknown] [137.226.59.251]) 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 <0L1H00JJ9AP7DJ50@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 12:05:31 +0200 (CEST) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> Date: Mon, 26 Apr 2010 12:06:25 +0200 Message-id: <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> References: <4BCDA1BC.1020701@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1077) Cc: HIP Subject: Re: [Hipsec] NAT traversal and the standards track work 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, 26 Apr 2010 10:05:47 -0000 Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Tuesday, April 20, 2010 5:45 AM >> To: HIP >> Subject: [Hipsec] NAT traversal and the standards track work >> >> Hi, >> >> we need to decide what to do with NAT traversal when moving to the >> standards track. We have the following drafts: >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >> >> The draft above will soon become an Experimental RFC. >> >> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >> traversal/ >> >> The draft above proposes implementing HIP-based connectivity checks >> instead of STUN-based ones. >> >> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >> >> The draft above, which needs to be revised, describes the mobility and >> multihoming extensions for NAT traversal. >> >> I would like to hear people's views on what to do here. >> > > Gonzalo, I would like to see both topics (NAT traversal, and mobility management aspects of NAT traversal) on the revised charter, as the second phase of standards-track work, as we discussed in Anaheim. I am neutral on the questions of which one of the two drafts to adopt (if a choice needs to be made now) and on whether the nat-mm draft should remain separate or should be combined into one NAT traversal draft. > I share Tom's opinion here. I would like to see both progress (provided there is enough manpower to support both). However, I think it might be useful to address mobility in the actual NAT documents since it poses special challenges that are special to NATs. Tobias > - 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 heer@informatik.rwth-aachen.de Mon Apr 26 07:06: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 6C45128C162 for ; Mon, 26 Apr 2010 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 RoujIk2-NQYY for ; Mon, 26 Apr 2010 07:06:36 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 754A728C12D for ; Mon, 26 Apr 2010 07:06:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L1H0037ULUI64E0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 16:06:18 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,273,1270418400"; d="scan'208";a="54871360" 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; Mon, 26 Apr 2010 16:06:19 +0200 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 <0L1H0066WLUIZN40@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 16:06:18 +0200 (CEST) From: Tobias Heer In-reply-to: <4BCB7FF9.1030706@htt-consult.com> Date: Mon, 26 Apr 2010 16:07:12 +0200 Message-id: <018D4667-CFD0-4FB9-A6DF-4412A493FDAB@cs.rwth-aachen.de> References: <4BBED40F.8040905@cs.hut.fi> <4BC77D3D.7000109@htt-consult.com> <4BC866A5.2060907@cs.hut.fi> <4BC8C24E.1090403@htt-consult.com> <4BCB7FF9.1030706@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] Host ID question 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, 26 Apr 2010 14:06:37 -0000 Am 18.04.2010 um 23:56 schrieb Robert Moskowitz: > On 04/18/2010 11:33 AM, Tobias Heer wrote: >> Hi, >> >> Am 16.04.2010 um 23:02 schrieb Robert Moskowitz: >> >> >>> On 04/16/2010 09:31 AM, Miika Komu wrote: >>> >>>> On 15/04/10 23:55, Robert Moskowitz wrote: >>>> >>>> Hi, >>>> >>>> maybe understood the intent of the question incorrectly, but here goes nothing.. >>>> >>>> >>>>> Why did we specify RSA/SHA1 for a Host ID value in 5201? >>>>> >>>> RSA does not have any patents and it was interoperated successfully. >>>> >>>> >>>>> Why the inclusion of SHA1? >>>>> >>>> Well supported everywhere and it was interoperated successfully. >>>> >>> I have looked at the offending RFC: 3110 and see that there are TWO RR defined there. One for RSA keys one for RSA/SHA1 sig RR. And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA. Afterall, there is nothing hash related in HIPv1 Host-IDs. >>> >>> >> If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both. >> >> IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course. >> > > This applies to Host_ID, which the TLV mimes just the RSA RR, not the RSA/SHA1 RR; at least as I look at the RFCs. > > Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash with RSA, when we will be adding a separate TLV for hash.... > > I did not full get your point but I will try to answer nonetheless - so I may be wrong or I might even answer the wrong question. I think the concept of HIP suites covers the issue quite well. We can define combinations of hash functions and signature schemes that make sense or that enable the use of HIP for a special purpose. These suites ca bundle a set of roughly equivalent hash functions and signature schemes - the actual choice of hash function and signature scheme can be communicated during the BEX or the update (for on-path elements). We do not have parameters for conveying that choice yet but as long as it is granted that a host can pick the right suite, the actual algorithms are negotiable. BR, Tobias > >> 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 >> >> >> >> >> >> >> >> >> -- 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 Mon Apr 26 07:32: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 24F0B28C1C7 for ; Mon, 26 Apr 2010 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_50=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 RUEZAPQeDqie for ; Mon, 26 Apr 2010 07:32:31 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 97F2E28C1CD for ; Mon, 26 Apr 2010 07:21:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 76A7768B28 for ; Mon, 26 Apr 2010 14:14:08 +0000 (UTC) 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 piq5Nj5+BuJF for ; Mon, 26 Apr 2010 10:13:59 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 61BB168A87 for ; Mon, 26 Apr 2010 10:13:59 -0400 (EDT) Message-ID: <4BD5A108.1070407@htt-consult.com> Date: Mon, 26 Apr 2010 10:19:52 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] What is in a name -- HMAC HIP 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: Mon, 26 Apr 2010 14:32:32 -0000 I do not like naming this parameter HMAC and HMAC2: Eventhough according to draft-irtf-cfrg-kdf-uses-00.txt, we can only use HMAC (D-H derived key is NOT uniformly distributed), There may be a future hkdf that is NOT HMAC that is secure to use with a D-H derived key, or a different key derivation method is used. This parameter is really the MAC operation of SIGMA compliance, which is currently achieved via HMAC. So I offer two possible alternative parameter names: HIP_MAC and HIP_MAC2 or HIP_MIC and HIP_MIC2 The alternative 'MIC' TLA stands for Message Integrity Check. This comes out of the IEEE 802 community that already had a MAC and needed a different TLA. Hum 1) Change HMAC to HIP-MxC Hum 2) x :== A or x:== I From mkomu@cs.hut.fi Mon Apr 26 07:53:00 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 032C83A6CCD for ; Mon, 26 Apr 2010 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 bEZu-mGuWTcC for ; Mon, 26 Apr 2010 07:52:59 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id C132628C2D5 for ; Mon, 26 Apr 2010 07:38:37 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O6PS4-0007OO-B5 for hipsec@ietf.org; Mon, 26 Apr 2010 17:38:24 +0300 Message-ID: <4BD5A5B2.2060602@cs.hut.fi> Date: Mon, 26 Apr 2010 17:39:46 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100416 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BD5A108.1070407@htt-consult.com> In-Reply-To: <4BD5A108.1070407@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] What is in a name -- HMAC HIP 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: Mon, 26 Apr 2010 14:53:00 -0000 On 26/04/10 17:19, Robert Moskowitz wrote: Hi, I would hum for option 2 (with slight preference for "MAC"). > I do not like naming this parameter HMAC and HMAC2: > > Eventhough according to draft-irtf-cfrg-kdf-uses-00.txt, we can only use > HMAC (D-H derived key is NOT uniformly distributed), There may be a > future hkdf that is NOT HMAC that is secure to use with a D-H derived > key, or a different key derivation method is used. > > This parameter is really the MAC operation of SIGMA compliance, which is > currently achieved via HMAC. > > So I offer two possible alternative parameter names: > > HIP_MAC and HIP_MAC2 > > or > > HIP_MIC and HIP_MIC2 > > The alternative 'MIC' TLA stands for Message Integrity Check. This comes > out of the IEEE 802 community that already had a MAC and needed a > different TLA. > > Hum 1) > > Change HMAC to HIP-MxC > > Hum 2) > > x :== A or x:== I > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Mon Apr 26 07:57:54 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 396013A6BA3 for ; Mon, 26 Apr 2010 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_05=-1.11] 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 rWBto4RBbypP for ; Mon, 26 Apr 2010 07:57:53 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 0B3D03A6C52 for ; Mon, 26 Apr 2010 07:48:25 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0B0B268B45; Mon, 26 Apr 2010 14:42:17 +0000 (UTC) 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 7B5J7qxWmjfS; Mon, 26 Apr 2010 10:42:07 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id B070368B43; Mon, 26 Apr 2010 10:42:07 -0400 (EDT) Message-ID: <4BD5A7A1.4040103@htt-consult.com> Date: Mon, 26 Apr 2010 10:48:01 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BBED40F.8040905@cs.hut.fi> <4BC77D3D.7000109@htt-consult.com> <4BC866A5.2060907@cs.hut.fi> <4BC8C24E.1090403@htt-consult.com> <4BCB7FF9.1030706@htt-consult.com> <018D4667-CFD0-4FB9-A6DF-4412A493FDAB@cs.rwth-aachen.de> In-Reply-To: <018D4667-CFD0-4FB9-A6DF-4412A493FDAB@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] Host ID question 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, 26 Apr 2010 14:57:54 -0000 On 04/26/2010 10:07 AM, Tobias Heer wrote: > Am 18.04.2010 um 23:56 schrieb Robert Moskowitz: > > >> On 04/18/2010 11:33 AM, Tobias Heer wrote: >> >>> Hi, >>> >>> Am 16.04.2010 um 23:02 schrieb Robert Moskowitz: >>> >>> >>> >>>> On 04/16/2010 09:31 AM, Miika Komu wrote: >>>> >>>> >>>>> On 15/04/10 23:55, Robert Moskowitz wrote: >>>>> >>>>> Hi, >>>>> >>>>> maybe understood the intent of the question incorrectly, but here goes nothing.. >>>>> >>>>> >>>>> >>>>>> Why did we specify RSA/SHA1 for a Host ID value in 5201? >>>>>> >>>>>> >>>>> RSA does not have any patents and it was interoperated successfully. >>>>> >>>>> >>>>> >>>>>> Why the inclusion of SHA1? >>>>>> >>>>>> >>>>> Well supported everywhere and it was interoperated successfully. >>>>> >>>>> >>>> I have looked at the offending RFC: 3110 and see that there are TWO RR defined there. One for RSA keys one for RSA/SHA1 sig RR. And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA. Afterall, there is nothing hash related in HIPv1 Host-IDs. >>>> >>>> >>>> >>> If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both. >>> >>> IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course. >>> >>> >> This applies to Host_ID, which the TLV mimes just the RSA RR, not the RSA/SHA1 RR; at least as I look at the RFCs. >> >> Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash with RSA, when we will be adding a separate TLV for hash.... >> >> >> > I did not full get your point but I will try to answer nonetheless - so I may be wrong or I might even answer the wrong question. > > I think the concept of HIP suites covers the issue quite well. We can define combinations of hash functions and signature schemes that make sense or that enable the use of HIP for a special purpose. These suites ca bundle a set of roughly equivalent hash functions and signature schemes - the actual choice of hash function and signature scheme can be communicated during the BEX or the update (for on-path elements). We do not have parameters for conveying that choice yet but as long as it is granted that a host can pick the right suite, the actual algorithms are negotiable. Yes. And HOST_ID is ONLY the Public Key algorithm with appropriate parameters and key size. Nothing about Hash is included. Thus our current HOST_IDs are: DSA RSA ECDSA From heer@informatik.rwth-aachen.de Mon Apr 26 08:40:20 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 5539028C10A for ; Mon, 26 Apr 2010 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=1.300, 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 6EJO1XFQD8xv for ; Mon, 26 Apr 2010 08:40:19 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 2F0103A67D1 for ; Mon, 26 Apr 2010 08:40:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L1H001H7Q6UTBI0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 17:40:06 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,273,1270418400"; d="scan'208";a="29124508" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Mon, 26 Apr 2010 17:40:06 +0200 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 <0L1H006XZQ63ZN50@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 26 Apr 2010 17:40:06 +0200 (CEST) From: Tobias Heer In-reply-to: <4BD5A108.1070407@htt-consult.com> Date: Mon, 26 Apr 2010 17:41:00 +0200 Message-id: References: <4BD5A108.1070407@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] What is in a name -- HMAC HIP 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: Mon, 26 Apr 2010 15:40:20 -0000 Hello Robert. Am 26.04.2010 um 16:19 schrieb Robert Moskowitz: ... > > Hum 1) > > Change HMAC to HIP-MxC > +1 > Hum 2) > > x :== A or x:== I > I prefer A. We don't have the MAC in the protocol specs and I think the term MIC is not that often used in IETF documents (at least I it did not make a strong impression to me). 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 rgm@htt-consult.com Tue Apr 27 06:50: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 4A0BD3A69CF for ; Tue, 27 Apr 2010 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_50=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 S4q8tlMj1tuP for ; Tue, 27 Apr 2010 06:50:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 613743A6880 for ; Tue, 27 Apr 2010 06:50:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4409168B40 for ; Tue, 27 Apr 2010 13:44:28 +0000 (UTC) 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 fUN6PK3AFKEj for ; Tue, 27 Apr 2010 09:44:19 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 583A168A94 for ; Tue, 27 Apr 2010 09:44:19 -0400 (EDT) Message-ID: <4BD6EB97.8080106@htt-consult.com> Date: Tue, 27 Apr 2010 09:50:15 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] ENCRYPTED parameter when HIP_Transform is Duo mode 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, 27 Apr 2010 13:50:49 -0000 One of the many differences between HIP and IKE is that IKE negotiates TWO encryption suites. One for IKE to use itself, and one for the data transport. HIP only negotiates a single encryption suite and uses it for both. This was fine with AES modes of operation like CBC, but presents interesting challenges with the AES duo modes of operation. In 5201-bis we are adding both CCM and GCM (RFCs 4309 & 4106). Both define an ICV and use an AAD. What would the AAD be in the HIP payload and what to do with the ICV? If for the ICV is to drop it on encryption, what impact does this have on decryption? What security risks are there to use CCM or GCM for the ENCRYPTED parameter? Will we need to add a separate transform negotiation for this parameter? From jeffrey.m.ahrenholz@boeing.com Tue Apr 27 07:29:36 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 9041E3A6B9A for ; Tue, 27 Apr 2010 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 hceoy9D49HGY for ; Tue, 27 Apr 2010 07:29:35 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E9A1C28C133 for ; Tue, 27 Apr 2010 07:24:50 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3REOYSO017138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Apr 2010 07:24:35 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3REOXlT029065; Tue, 27 Apr 2010 09:24:33 -0500 (CDT) 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.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3RENrcX028097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 27 Apr 2010 09:24:33 -0500 (CDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 27 Apr 2010 07:24:13 -0700 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" , "hipsec@ietf.org WG" Date: Tue, 27 Apr 2010 07:24:12 -0700 Thread-Topic: [Hipsec] ENCRYPTED parameter when HIP_Transform is Duo mode Thread-Index: AcrmEK3O/eSPtqz2QZKyTLaIubqLYQAA75Ag Message-ID: References: <4BD6EB97.8080106@htt-consult.com> In-Reply-To: <4BD6EB97.8080106@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] ENCRYPTED parameter when HIP_Transform is Duo mode 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, 27 Apr 2010 14:29:36 -0000 =20 > One of the many differences between HIP and IKE is that IKE=20 > negotiates TWO encryption suites. One for IKE to use itself, > and one for the data transport. HIP only negotiates a single > encryption suite and uses it for both. No, with HIP one can negotiate HIP_TRANSFORM and ESP_TRANSFORM as different= suites, one for HIP itself and one for data. -Jeff >=20 > This was fine with AES modes of operation like CBC, but presents=20 > interesting challenges with the AES duo modes of operation. >=20 > In 5201-bis we are adding both CCM and GCM (RFCs 4309 & 4106). Both=20 > define an ICV and use an AAD. What would the AAD be in the=20 > HIP payload=20 > and what to do with the ICV? If for the ICV is to drop it on=20 > encryption, what impact does this have on decryption? What security=20 > risks are there to use CCM or GCM for the ENCRYPTED=20 > parameter? Will we=20 > need to add a separate transform negotiation for this parameter? >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > = From rgm@htt-consult.com Tue Apr 27 07:55: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 E477D3A6CA2 for ; Tue, 27 Apr 2010 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TQ7mBki+Y1N for ; Tue, 27 Apr 2010 07:55:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7D62A28C284 for ; Tue, 27 Apr 2010 07:50:10 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4584768B41; Tue, 27 Apr 2010 14:43:58 +0000 (UTC) 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 W8EXZNvU6E6V; Tue, 27 Apr 2010 10:43:48 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A43B668B25; Tue, 27 Apr 2010 10:43:48 -0400 (EDT) Message-ID: <4BD6F988.2040508@htt-consult.com> Date: Tue, 27 Apr 2010 10:49:44 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4BD6EB97.8080106@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: [Hipsec] OOPS!!! Re: ENCRYPTED parameter when HIP_Transform is Duo mode 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, 27 Apr 2010 14:55:41 -0000 OOPS!!! On 04/27/2010 10:24 AM, Ahrenholz, Jeffrey M wrote: > > >> One of the many differences between HIP and IKE is that IKE >> negotiates TWO encryption suites. One for IKE to use itself, >> and one for the data transport. HIP only negotiates a single >> encryption suite and uses it for both. >> > No, with HIP one can negotiate HIP_TRANSFORM and ESP_TRANSFORM as different suites, one for HIP itself and one for data. > Oh, that is in 5202, and I am only looking at 5201.... But this then 'begs the question' about modes. Duo modes are not needed for HIP_TRANSFORM, but are of value for ESP_TRANSFORM. Values are only defined for HIP_TRANSFORM, ASSUMING that what works for one works for the other. This is no longer the case, so do we define the CCM and GCM transforms in 5202-bis? And for the HIP Suites, we need to define which ESP_TRANSFORM to which suite also in 5202-bis? thanks for setting me straight there Jeff, I have been staring at 5201 for too long... >> This was fine with AES modes of operation like CBC, but presents >> interesting challenges with the AES duo modes of operation. >> >> In 5201-bis we are adding both CCM and GCM (RFCs 4309& 4106). Both >> define an ICV and use an AAD. What would the AAD be in the >> HIP payload >> and what to do with the ICV? If for the ICV is to drop it on >> encryption, what impact does this have on decryption? What security >> risks are there to use CCM or GCM for the ENCRYPTED >> parameter? Will we >> need to add a separate transform negotiation for this parameter? >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> From jeffrey.m.ahrenholz@boeing.com Tue Apr 27 08:42: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 0918E3A6B89 for ; Tue, 27 Apr 2010 08:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 8s4FqIXcJYmf for ; Tue, 27 Apr 2010 08:42:07 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 73E0A28C226 for ; Tue, 27 Apr 2010 08:37:04 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3RFanlA002995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Apr 2010 08:36:50 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3RFanQg018211; Tue, 27 Apr 2010 08:36:49 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3RFan2p018205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 27 Apr 2010 08:36:49 -0700 (PDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Tue, 27 Apr 2010 08:36:49 -0700 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" Date: Tue, 27 Apr 2010 08:36:48 -0700 Thread-Topic: OOPS!!! Re: [Hipsec] ENCRYPTED parameter when HIP_Transform is Duomode Thread-Index: AcrmGO1/vyRmHItxSGSm0jfoNPC7FAAAjW/g Message-ID: References: <4BD6EB97.8080106@htt-consult.com> <4BD6F988.2040508@htt-consult.com> In-Reply-To: <4BD6F988.2040508@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] OOPS!!! Re: ENCRYPTED parameter when HIP_Transform is Duomode 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, 27 Apr 2010 15:42:08 -0000 > Duo modes are not needed for HIP_TRANSFORM, but are of value for=20 > ESP_TRANSFORM. >=20 > Values are only defined for HIP_TRANSFORM, ASSUMING that what=20 > works for=20 > one works for the other. This is no longer the case, so do we define=20 > the CCM and GCM transforms in 5202-bis? And for the HIP=20 > Suites, we need=20 > to define which ESP_TRANSFORM to which suite also in 5202-bis? Yes it seems like 5202-bis now requires its own list of suite IDs (includin= g CCM and GCM) instead of just referring to 5201. Will the limit of 6 suite IDs in the ESP_TRANSFORM be enough? > thanks for setting me straight there Jeff, I have been=20 > staring at 5201 for too long... np, you're doing good work :) -Jeff= From rgm@htt-consult.com Tue Apr 27 08:57: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 0A6303A6C29 for ; Tue, 27 Apr 2010 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg1-nE-velsx for ; Tue, 27 Apr 2010 08:57:49 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A99893A6C07 for ; Tue, 27 Apr 2010 08:54:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AAD4D68B26; Tue, 27 Apr 2010 15:48:06 +0000 (UTC) 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 pcxWC+YLIy1K; Tue, 27 Apr 2010 11:47:57 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7029568B23; Tue, 27 Apr 2010 11:47:57 -0400 (EDT) Message-ID: <4BD70891.5080708@htt-consult.com> Date: Tue, 27 Apr 2010 11:53:53 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4BD6EB97.8080106@htt-consult.com> <4BD6F988.2040508@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] OOPS!!! Re: ENCRYPTED parameter when HIP_Transform is Duomode 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, 27 Apr 2010 15:57:50 -0000 On 04/27/2010 11:36 AM, Ahrenholz, Jeffrey M wrote: >> Duo modes are not needed for HIP_TRANSFORM, but are of value for >> ESP_TRANSFORM. >> >> Values are only defined for HIP_TRANSFORM, ASSUMING that what >> works for >> one works for the other. This is no longer the case, so do we define >> the CCM and GCM transforms in 5202-bis? And for the HIP >> Suites, we need >> to define which ESP_TRANSFORM to which suite also in 5202-bis? >> > Yes it seems like 5202-bis now requires its own list of suite IDs (including CCM and GCM) instead of just referring to 5201. > > Will the limit of 6 suite IDs in the ESP_TRANSFORM be enough? > With the focus on HIP Suites, it will be. Developers will tend to 'group' like strengthed things together, and not just list everything. Though I do remember early in the ICSAlabs testing of IPsec products we had one that ALWAYS put out (I Think) 12 proposals and crashed a lot of other products. It became a stable in our testbed. So since 6 are allowed for HIP and ESP transform, make sure you test with 6 and don't crash... > >> thanks for setting me straight there Jeff, I have been >> staring at 5201 for too long... >> > np, you're doing good work :) > > -Jeff > From jeffrey.m.ahrenholz@boeing.com Tue Apr 27 10:08: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 9713B3A6B58 for ; Tue, 27 Apr 2010 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, 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 f8QPSUmX5r51 for ; Tue, 27 Apr 2010 10:08:11 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 30C163A6A11 for ; Tue, 27 Apr 2010 10:08:08 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3RH7lwu016145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Apr 2010 10:07:53 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3RH7ktG016758; Tue, 27 Apr 2010 10:07:47 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3RH7k1O016740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 27 Apr 2010 10:07:46 -0700 (PDT) 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, 27 Apr 2010 10:07:46 -0700 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" , "hipsec@ietf.org" Date: Tue, 27 Apr 2010 10:07:45 -0700 Thread-Topic: [Hipsec] Manditory to implement Host ID Lengths Thread-Index: AcrjJ+9uNMyul8GCSk+fGelY23c9nADAbFqg Message-ID: References: <4BD1E4EC.6000706@htt-consult.com> <4BD20A20.7020402@htt-consult.com> In-Reply-To: <4BD20A20.7020402@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] Manditory to implement Host ID Lengths 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, 27 Apr 2010 17:08:12 -0000 > > Some help here, please, so I can finish up another loose=20 > end in 5201-bis. >=20 > Here are some proposed cipher suites. Using RFCs 4308 and 4869 as=20 > guidelines... >=20 > HIP BEX Cipher suites: >=20 > Suite Host_ID Diffie_Hellman Hash Recommended HIP-Transform >=20 > 1 ECDSA-160 ECDH-160 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with=20 > HMAC-SHA1 > 2 RSA 1024 DH-1536 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with=20 > HMAC-SHA1 > 3 RSA-2048 DH-3072 SHA-256 AES-128-CBC with HMAC-SHA2 or AES-CCM-8 > 4 ECDSA-256 ECDH-256 SHA-256 AES-256-CBC with HMAC-SHA2 or=20 > AES-CCM-16 or=20 > AES-GCM with a 16 octet ICV > 5 ECDSA-384 ECDH-384 SHA-384 AES-256-CBC with HMAC-SHA2 or=20 > AES-CCM-16 or=20 > AES-GCM with a 16 octet ICV >=20 > 3 is Manditory. 1 & 4 are recommended (1 for servers supporting weak=20 > clients)? 5 is for Suite-B. These suites seem OK to me. Hopefully the above are well supported by OpenS= SL or other libraries. We've been using 2 as the default with HIPv1 (RSA 10= 24 / DH-1536). It should be noted, with HIPv1 and an MTU size of 1500, that using large ke= ys of RSA 4096 + DH-1536 will cause a 1458 byte I2 packet (proto 139 withou= t UDP), and using RSA 4096 + DH-3072 causes fragmentation of the I2. That l= eads to problems (bugs?) at least with our OpenHIP implementation. -Jeff= From rgm@htt-consult.com Tue Apr 27 10:33: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 D57E33A6A61 for ; Tue, 27 Apr 2010 10:33:28 -0700 (PDT) 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.603, 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 POiNpDpLw5xX for ; Tue, 27 Apr 2010 10:33:27 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id E46263A6A89 for ; Tue, 27 Apr 2010 10:33:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9E11D68B25; Tue, 27 Apr 2010 17:27:03 +0000 (UTC) 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 KdH0IyyXU91a; Tue, 27 Apr 2010 13:26:53 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 2B50A68A94; Tue, 27 Apr 2010 13:26:53 -0400 (EDT) Message-ID: <4BD71FC1.1000506@htt-consult.com> Date: Tue, 27 Apr 2010 13:32:49 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4BD1E4EC.6000706@htt-consult.com> <4BD20A20.7020402@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] Manditory to implement Host ID Lengths 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, 27 Apr 2010 17:33:28 -0000 On 04/27/2010 01:07 PM, Ahrenholz, Jeffrey M wrote: > >>> Some help here, please, so I can finish up another loose >>> >> end in 5201-bis. >> >> Here are some proposed cipher suites. Using RFCs 4308 and 4869 as >> guidelines... >> >> HIP BEX Cipher suites: >> >> Suite Host_ID Diffie_Hellman Hash Recommended HIP-Transform >> >> 1 ECDSA-160 ECDH-160 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with >> HMAC-SHA1 >> 2 RSA 1024 DH-1536 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with >> HMAC-SHA1 >> 3 RSA-2048 DH-3072 SHA-256 AES-128-CBC with HMAC-SHA2 or AES-CCM-8 >> 4 ECDSA-256 ECDH-256 SHA-256 AES-256-CBC with HMAC-SHA2 or >> AES-CCM-16 or >> AES-GCM with a 16 octet ICV >> 5 ECDSA-384 ECDH-384 SHA-384 AES-256-CBC with HMAC-SHA2 or >> AES-CCM-16 or >> AES-GCM with a 16 octet ICV >> >> 3 is Manditory. 1& 4 are recommended (1 for servers supporting weak >> clients)? 5 is for Suite-B. >> > These suites seem OK to me. Hopefully the above are well supported by OpenSSL or other libraries. We've been using 2 as the default with HIPv1 (RSA 1024 / DH-1536). > > It should be noted, with HIPv1 and an MTU size of 1500, that using large keys of RSA 4096 + DH-1536 will cause a 1458 byte I2 packet (proto 139 without UDP), and using RSA 4096 + DH-3072 causes fragmentation of the I2. That leads to problems (bugs?) at least with our OpenHIP implementation. > p-384 gives you a greater strength at a smaller size with a much lower CPU cost. For example see: http://www.nsa.gov/business/programs/elliptic_curve.shtml Yet another reason to move to EC. Per Dave McGrew back on /4/9: "so far, nobody has published software that specifically targets this draft. The openssl implementation of ECC could be used as something interoperable (though it implements a lot more than just the fECC subset of ECC)." We do need to get the OpenSSL authors looking at this draft.... From rgm@htt-consult.com Tue Apr 27 11:05: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 6BAA53A69B4 for ; Tue, 27 Apr 2010 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 yKXD1a4SjF5E for ; Tue, 27 Apr 2010 11:05:34 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 18FBE3A6967 for ; Tue, 27 Apr 2010 11:05:31 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 79D8168B25; Tue, 27 Apr 2010 17:58:51 +0000 (UTC) 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 LSkn-zM0vki2; Tue, 27 Apr 2010 13:58:41 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1F96068B26; Tue, 27 Apr 2010 13:58:41 -0400 (EDT) Message-ID: <4BD72735.9000003@htt-consult.com> Date: Tue, 27 Apr 2010 14:04:37 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4BD1E4EC.6000706@htt-consult.com> <4BD20A20.7020402@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] Manditory to implement Host ID Lengths 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, 27 Apr 2010 18:05:35 -0000 On 04/27/2010 01:07 PM, Ahrenholz, Jeffrey M wrote: > >>> Some help here, please, so I can finish up another loose >>> >> end in 5201-bis. >> >> Here are some proposed cipher suites. Using RFCs 4308 and 4869 as >> guidelines... >> >> HIP BEX Cipher suites: >> >> Suite Host_ID Diffie_Hellman Hash Recommended HIP-Transform >> >> 1 ECDSA-160 ECDH-160 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with >> HMAC-SHA1 >> 2 RSA 1024 DH-1536 SHA1 AES-128-CBC with HMAC-SHA1 or 3DES-CBC with >> HMAC-SHA1 >> 3 RSA-2048 DH-3072 SHA-256 AES-128-CBC with HMAC-SHA2 or AES-CCM-8 >> 4 ECDSA-256 ECDH-256 SHA-256 AES-256-CBC with HMAC-SHA2 or >> AES-CCM-16 or >> AES-GCM with a 16 octet ICV >> 5 ECDSA-384 ECDH-384 SHA-384 AES-256-CBC with HMAC-SHA2 or >> AES-CCM-16 or >> AES-GCM with a 16 octet ICV >> >> 3 is Manditory. 1& 4 are recommended (1 for servers supporting weak >> clients)? 5 is for Suite-B. >> > These suites seem OK to me. Hopefully the above are well supported by OpenSSL or other libraries. We've been using 2 as the default with HIPv1 (RSA 1024 / DH-1536). > > It should be noted, with HIPv1 and an MTU size of 1500, that using large keys of RSA 4096 + DH-1536 will cause a 1458 byte I2 packet (proto 139 without UDP), and using RSA 4096 + DH-3072 causes fragmentation of the I2. That leads to problems (bugs?) at least with our OpenHIP implementation. > Oh, and with the addtion of ECDSA, I will be recommending RSA key size maxlimit of 2048. This is in line with NIST and NSA recommendations and with fECC, we SHOULD avoid IPR issues (unless you want the IPR algorithms for even greater efficiency). From oleg.ponomarev@hiit.fi Tue Apr 27 13:10: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 5061F3A6845 for ; Tue, 27 Apr 2010 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 tz6M+trsdQ4V for ; Tue, 27 Apr 2010 13:10:47 -0700 (PDT) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 4C8223A6803 for ; Tue, 27 Apr 2010 13:10:46 -0700 (PDT) Received: from stargazer.pc.infrahip.net (stargazer.pc.infrahip.net [IPv6:2001:708:140:220:21e:4fff:fe92:4522]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id o3RK9N5c030344; Tue, 27 Apr 2010 23:09:23 +0300 Date: Tue, 27 Apr 2010 23:09:23 +0300 (EEST) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer.pc.infrahip.net To: Robert Moskowitz In-Reply-To: <4BD186B4.1010002@htt-consult.com> Message-ID: References: <4BD06975.9040605@htt-consult.com> <4BD186B4.1010002@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; charset=US-ASCII; format=flowed Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Removing DH 384-bit group 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, 27 Apr 2010 20:10:50 -0000 Greetings! On Fri, 23 Apr 2010, Robert Moskowitz wrote: >>> This is a very weak DH group we put in to have some DH for weak systems. >>> >>> How does the computational cost of ECDH-256 compare to it? How small of a >>> ECDH key would be of similar computational cost (and probably stronger)? >>> Seems easier to add a small ECDH that keep this weak key in. >> >> DH384 takes ~124 usec using Intel Xeon E5440 @ 2.83GHz >> ECDH112 -/- 175 usec (56-bit strong and weakest available in OpenSSL) >> >> With Nokia tablet N810: >> DH384 ~5.0 msec >> ECDH112 ~4.6 msec >> ECDH128 ~5.2 msec >> ECDH160 ~7.7 msec >> (DH768 ~33.9 msec) > > Great numbers. thanks. Do you have a ECDH equiv for 100bits strength (as the > DH-1536 seems to work out to)? Probably ECDH-200 or there abouts. Sure, ECDH-192 takes 384 usec for the Xeon and 11.8 msec for N810. > In my searching for info on this, I encountered a dead link for a paper of > yours on EC with HIP.... It is available, e.g. at http://www.cs.helsinki.fi/u/gurtov/papers/ecc.pdf -- Regards, Oleg. From root@core3.amsl.com Wed Apr 28 01:45: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 795053A6869; Wed, 28 Apr 2010 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100428084501.795053A6869@core3.amsl.com> Date: Wed, 28 Apr 2010 01:45:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-03.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, 28 Apr 2010 08:45: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 Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-03.txt Pages : 10 Date : 2010-04-28 This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in HIP control packets. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and in SPKI certificates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-cert-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-28014400.I-D@ietf.org> --NextPart-- From david.mattes@boeing.com Wed Apr 28 10:01:33 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 67DF63A69A9 for ; Wed, 28 Apr 2010 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 4B9h7idcdDsR for ; Wed, 28 Apr 2010 10:01:32 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 8C6603A68E0 for ; Wed, 28 Apr 2010 10:01:32 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3SH0ulF015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Apr 2010 10:00:58 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3SH0ulh029711; Wed, 28 Apr 2010 12:00:56 -0500 (CDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3SH0tTG029701 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Apr 2010 12:00:56 -0500 (CDT) Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.86]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 28 Apr 2010 10:00:55 -0700 From: "Mattes, David" To: "heer@cs.rwth-aachen.de" , "samu.varjonen@hiit.fi" Date: Wed, 28 Apr 2010 10:00:53 -0700 Thread-Topic: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Thread-Index: AcrmrxHGXpr8pHDlTLWY6CBTEJV42gAQao7Q Message-ID: References: <20100428084501.795053A6869@core3.amsl.com> In-Reply-To: <20100428084501.795053A6869@core3.amsl.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] I-D Action:draft-ietf-hip-cert-03.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, 28 Apr 2010 17:01:33 -0000 Hi Tobias and Samu, Thank you for this work! Some comments: Section 2, last paragraph, 2nd sentence: s/LDAP URL/DN/ Section 3, paragraph 1: I don't agree that HITs need to be enclosed within = X.509 certificates. Many users will not have control over the Certificate = Issuing Authorities, or even if they do have that control, will be unable t= o specify inclusion of the HIT in the certificate. Furthermore, the issuer= may not be involved in HIP communications at all! I think it is a mistake= to require _any_ HIP details to be present in a certificate used for HIP c= ommunications, nor do I see why it is necessary. Section 3, can we add another example that describes a managed PKI environm= ent? If you agree with my comment about HITs in the certificate, I will wr= ite up an example for this case. Regards, David Mattes -----Original Message----- From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf Of= Internet-Drafts@ietf.org Sent: Wednesday, April 28, 2010 1:45 AM To: i-d-announce@ietf.org Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of th= e IETF. Title : HIP Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-03.txt Pages : 10 Date : 2010-04-28 This document specifies a certificate parameter called CERT for the Host Id= entity Protocol (HIP). The CERT parameter is a container for X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) certi= ficates. It is used for carrying these certificates in HIP control packets= . Additionally, this document specifies the representations of Host Identi= ty Tags in X.509.v3 and in SPKI certificates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-03.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From rgm@htt-consult.com Fri Apr 30 11:31: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 26FBB28C188 for ; Fri, 30 Apr 2010 11:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8acpn5YZTPd for ; Fri, 30 Apr 2010 11:31:20 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 590313A691F for ; Fri, 30 Apr 2010 11:31:20 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A903868A8A for ; Fri, 30 Apr 2010 18:24:58 +0000 (UTC) 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 8xx2o5kFAzhb for ; Fri, 30 Apr 2010 14:24:49 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1C01F68B26 for ; Fri, 30 Apr 2010 14:24:38 -0400 (EDT) Message-ID: <4BDB21CE.9050108@htt-consult.com> Date: Fri, 30 Apr 2010 14:30:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] draft-vyncke-advanced-ipv6-security-01 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, 30 Apr 2010 18:31:21 -0000 I bring this ID to the list's attention. Just as I got HIP into draft-ietf-v6ops-cpe-simple-security-11, we need to see that HIP is covered for Advanced IPv6 security. Particularly the mid-box support for HIP mobility needs to be covered. Can someone(s) take on this work item? From wwwrun@rfc-editor.org Fri Apr 30 17:00: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 DE0A33A693D; Fri, 30 Apr 2010 17:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.340, 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 P+aZ7jNu8xeg; Fri, 30 Apr 2010 17:00:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 1C51A3A6A1F; Fri, 30 Apr 2010 17:00:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9DB35130001; Fri, 30 Apr 2010 17:00:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100501000026.9DB35130001@rfc-editor.org> Date: Fri, 30 Apr 2010 17:00:26 -0700 (PDT) Cc: hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 5770 on Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators 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: Sat, 01 May 2010 00:00:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5770 Title: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators Author: M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed. Status: Experimental Stream: IETF Date: April 2010 Mailbox: miika@iki.fi, thomas.r.henderson@boeing.com, Hannes.Tschofenig@gmx.net, jan.melen@ericsson.com, ari.keranen@ericsson.com Pages: 34 Characters: 79767 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-hip-nat-traversal-09.txt URL: http://www.rfc-editor.org/rfc/rfc5770.txt This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. This document defines an Experimental Protocol for the Internet community. This document is a product of the Host Identity Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC