From Internet-Drafts@ietf.org Tue Jan 11 03:15:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C441528C100; Tue, 11 Jan 2011 03:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8HVsN6ekRQh; Tue, 11 Jan 2011 03:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8B128C11B; Tue, 11 Jan 2011 03:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111111501.2109.47986.idtracker@localhost> Date: Tue, 11 Jan 2011 03:15:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-reload-instance-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: Tue, 11 Jan 2011 11:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) Author(s) : A. Keranen, et al. Filename : draft-ietf-hip-reload-instance-03.txt Pages : 10 Date : 2011-01-11 This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-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-reload-instance-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11031130.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Tue Jan 11 04:47:17 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BB428C0EE for ; Tue, 11 Jan 2011 04:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+DKEuZkxqo6 for ; Tue, 11 Jan 2011 04:47:16 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8B72F28C28E for ; Tue, 11 Jan 2011 04:47:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 685E04E6DA for ; Tue, 11 Jan 2011 14:49:31 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEL5YxEPDB0a for ; Tue, 11 Jan 2011 14:49:30 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id DCC764E6D3 for ; Tue, 11 Jan 2011 14:49:30 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <20110111111501.2109.47986.idtracker@localhost> Date: Tue, 11 Jan 2011 14:49:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0DC291DD-9EAD-4B0A-8BBB-782C70F9A186@nomadiclab.com> References: <20110111111501.2109.47986.idtracker@localhost> To: hipsec@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-reload-instance-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: Tue, 11 Jan 2011 12:47:17 -0000 Hi all, FYI, this was just a keep-alive (and reference) update to keep the draft = from expiring while we wait for the P2PSIP base draft to be finalized. Cheers, Ari On Jan 11, 2011, at 1:15 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Host Identity Protocol Working Group = of the IETF. >=20 >=20 > Title : Host Identity Protocol-Based Overlay = Networking Environment (HIP BONE) Instance Specification for REsource = LOcation And Discovery (RELOAD) > Author(s) : A. Keranen, et al. > Filename : draft-ietf-hip-reload-instance-03.txt > Pages : 10 > Date : 2011-01-11 >=20 > This document is the Host Identity Protocol-Based Overlay Networking > Environment (HIP BONE) instance specification for the REsource > LOcation And Discovery (RELOAD) protocol. The document provides the > details needed to build a RELOAD-based overlay that uses HIP. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-hip-reload-instance-03.txt From gonzalo.camarillo@ericsson.com Tue Jan 11 10:16:30 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600513A6A4C for ; Tue, 11 Jan 2011 10:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 1zbusl90wrR9 for ; Tue, 11 Jan 2011 10:16:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4C1283A6A3F for ; Tue, 11 Jan 2011 10:16:29 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-e2-4d2c9f0567d0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 79.16.13987.50F9C2D4; Tue, 11 Jan 2011 19:18:45 +0100 (CET) Received: from [131.160.126.193] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 19:18:45 +0100 Message-ID: <4D2C9F04.9040305@ericsson.com> Date: Tue, 11 Jan 2011 20:18:44 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Samu Varjonen References: <4CFBB4EE.1020608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CED25ABC1@XCH-NW-10V.nw.nos.boeing.com> <4D0F35AE.3030908@hiit.fi> In-Reply-To: <4D0F35AE.3030908@hiit.fi> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-cert-06 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, 11 Jan 2011 18:16:30 -0000 Hi Samu, when do you intend to submit a new revision of this draft including the changes that have been agreed? Thanks, Gonzalo On 20/12/2010 12:53 PM, Samu Varjonen wrote: > On 20/12/10 06:01, Henderson, Thomas R wrote: >> >> >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org >>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>> Sent: Sunday, December 05, 2010 7:51 AM >>> To: HIP >>> Subject: [Hipsec] WGLC: draft-ietf-hip-cert-06 >>> >>> Folks, >>> >>> we hereby start the WGLC on the following draft. This WGLC will end on >>> December 20th. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-cert/ >>> >>> Please, send your comments to this list. >>> >>> Thanks, >>> >> >> Gonzalo, I reread this draft and feel that it is ready to publish, modulo the resolution of a couple of comments below. >> >> At the top of page 6, I believe that the line >> Subject: CN=hit-of-issuer >> should read >> Subject: CN=hit-of-subject >> > > OK, fixed > >> In section 8, the second paragraph recommends to not use grouping or hash and URL encodings when HIP aware middleboxes are anticipated to be on the path. First of all, it is not really clear how a HIP host may know about these boxes except via side information. If the HIP host does know about them, then presumably it could also know (via side information) whether they can support grouping and hash formats, and the host could act accordingly. Second, it is not clear whether the use of these options by a well-behaved host would make these devices more prone to attacks, or whether it is rather the use of these options by other malicious hosts that is the real problem. It seems to me that it may be better to defer this issue to a future HIP-aware middlebox draft, where it could be specified, for instance, how a middlebox that does not want to support these formats may signal to a host that it requires "full credentials" to proceed. So, I would like to suggest for your co ns > id >> eration to remove this paragraph. >> > > I agree with the comment and agree on leaving the subject to a future draft on > HIP-aware middleboxes. Anyone against the removal of the paragraph? If not > consider it removed. > >> - Tom >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > From Internet-Drafts@ietf.org Wed Jan 12 04:30:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312BA3A6B19; Wed, 12 Jan 2011 04:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgEs8qy6WGIa; Wed, 12 Jan 2011 04:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523163A69CE; Wed, 12 Jan 2011 04:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112123002.21718.47022.idtracker@localhost> Date: Wed, 12 Jan 2011 04:30:02 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-07.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, 12 Jan 2011 12:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-07.txt Pages : 13 Date : 2011-01-12 The CERT parameter is a container for X.509.v3 certificates and Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12042451.I-D@ietf.org> --NextPart-- From samu.varjonen@hiit.fi Wed Jan 12 04:30:32 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0023A6B15 for ; Wed, 12 Jan 2011 04:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jDN3f90BB91 for ; Wed, 12 Jan 2011 04:30:31 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D8F3A3A6B1B for ; Wed, 12 Jan 2011 04:30:30 -0800 (PST) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id B016625ED11; Wed, 12 Jan 2011 14:32:48 +0200 (EET) Message-ID: <4D2D9F70.8080802@hiit.fi> Date: Wed, 12 Jan 2011 14:32:48 +0200 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4CFBB4EE.1020608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CED25ABC1@XCH-NW-10V.nw.nos.boeing.com> <4D0F35AE.3030908@hiit.fi> <4D2C9F04.9040305@ericsson.com> In-Reply-To: <4D2C9F04.9040305@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-cert-06 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, 12 Jan 2011 12:30:32 -0000 On 11/01/11 20:18, Gonzalo Camarillo wrote: > Hi Samu, > > when do you intend to submit a new revision of this draft including the > changes that have been agreed? Uploaded it a minute ago. BR, Samu > > Thanks, > > Gonzalo > > On 20/12/2010 12:53 PM, Samu Varjonen wrote: >> On 20/12/10 06:01, Henderson, Thomas R wrote: >>> >>> >>>> -----Original Message----- >>>> From: hipsec-bounces@ietf.org >>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Sunday, December 05, 2010 7:51 AM >>>> To: HIP >>>> Subject: [Hipsec] WGLC: draft-ietf-hip-cert-06 >>>> >>>> Folks, >>>> >>>> we hereby start the WGLC on the following draft. This WGLC will end on >>>> December 20th. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-cert/ >>>> >>>> Please, send your comments to this list. >>>> >>>> Thanks, >>>> >>> >>> Gonzalo, I reread this draft and feel that it is ready to publish, modulo the resolution of a couple of comments below. >>> >>> At the top of page 6, I believe that the line >>> Subject: CN=hit-of-issuer >>> should read >>> Subject: CN=hit-of-subject >>> >> >> OK, fixed >> >>> In section 8, the second paragraph recommends to not use grouping or hash and URL encodings when HIP aware middleboxes are anticipated to be on the path. First of all, it is not really clear how a HIP host may know about these boxes except via side information. If the HIP host does know about them, then presumably it could also know (via side information) whether they can support grouping and hash formats, and the host could act accordingly. Second, it is not clear whether the use of these options by a well-behaved host would make these devices more prone to attacks, or whether it is rather the use of these options by other malicious hosts that is the real problem. It seems to me that it may be better to defer this issue to a future HIP-aware middlebox draft, where it could be specified, for instance, how a middlebox that does not want to support these formats may signal to a host that it requires "full credentials" to proceed. So, I would like to suggest for your co > ns >> id >>> eration to remove this paragraph. >>> >> >> I agree with the comment and agree on leaving the subject to a future draft on >> HIP-aware middleboxes. Anyone against the removal of the paragraph? If not >> consider it removed. >> >>> - Tom >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> > From gonzalo.camarillo@ericsson.com Wed Jan 12 06:09:45 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C928C120 for ; Wed, 12 Jan 2011 06:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.615 X-Spam-Level: X-Spam-Status: No, score=-106.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 75-HZt5+Waed for ; Wed, 12 Jan 2011 06:09:44 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 35DBF28C108 for ; Wed, 12 Jan 2011 06:09:43 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-88-4d2db6b346e1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.84.13987.3B6BD2D4; Wed, 12 Jan 2011 15:12:03 +0100 (CET) Received: from [131.160.126.193] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 12 Jan 2011 15:12:02 +0100 Message-ID: <4D2DB6B2.109@ericsson.com> Date: Wed, 12 Jan 2011 16:12:02 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Samu Varjonen References: <4CFBB4EE.1020608@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CED25ABC1@XCH-NW-10V.nw.nos.boeing.com> <4D0F35AE.3030908@hiit.fi> <4D2C9F04.9040305@ericsson.com> <4D2D9F70.8080802@hiit.fi> In-Reply-To: <4D2D9F70.8080802@hiit.fi> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-cert-06 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, 12 Jan 2011 14:09:45 -0000 Hi Samu, thanks. At this point, I will take care of the PROTO write up and of requesting the publication of the draft. Cheers, Gonzalo On 12/01/2011 2:32 PM, Samu Varjonen wrote: > On 11/01/11 20:18, Gonzalo Camarillo wrote: >> Hi Samu, >> >> when do you intend to submit a new revision of this draft including the >> changes that have been agreed? > > Uploaded it a minute ago. > > BR, > Samu > >> >> Thanks, >> >> Gonzalo >> >> On 20/12/2010 12:53 PM, Samu Varjonen wrote: >>> On 20/12/10 06:01, Henderson, Thomas R wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: hipsec-bounces@ietf.org >>>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>>> Sent: Sunday, December 05, 2010 7:51 AM >>>>> To: HIP >>>>> Subject: [Hipsec] WGLC: draft-ietf-hip-cert-06 >>>>> >>>>> Folks, >>>>> >>>>> we hereby start the WGLC on the following draft. This WGLC will end on >>>>> December 20th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-hip-cert/ >>>>> >>>>> Please, send your comments to this list. >>>>> >>>>> Thanks, >>>>> >>>> >>>> Gonzalo, I reread this draft and feel that it is ready to publish, modulo the resolution of a couple of comments below. >>>> >>>> At the top of page 6, I believe that the line >>>> Subject: CN=hit-of-issuer >>>> should read >>>> Subject: CN=hit-of-subject >>>> >>> >>> OK, fixed >>> >>>> In section 8, the second paragraph recommends to not use grouping or hash and URL encodings when HIP aware middleboxes are anticipated to be on the path. First of all, it is not really clear how a HIP host may know about these boxes except via side information. If the HIP host does know about them, then presumably it could also know (via side information) whether they can support grouping and hash formats, and the host could act accordingly. Second, it is not clear whether the use of these options by a well-behaved host would make these devices more prone to attacks, or whether it is rather the use of these options by other malicious hosts that is the real problem. It seems to me that it may be better to defer this issue to a future HIP-aware middlebox draft, where it could be specified, for instance, how a middlebox that does not want to support these formats may signal to a host that it requires "full credentials" to proceed. So, I would like to suggest for your co > >> ns >>> id >>>> eration to remove this paragraph. >>>> >>> >>> I agree with the comment and agree on leaving the subject to a future draft on >>> HIP-aware middleboxes. Anyone against the removal of the paragraph? If not >>> consider it removed. >>> >>>> - Tom >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> > From gonzalo.camarillo@ericsson.com Mon Jan 17 05:51:10 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407E328C0D9 for ; Mon, 17 Jan 2011 05:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.614 X-Spam-Level: X-Spam-Status: No, score=-106.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkjfd0TZAg47 for ; Mon, 17 Jan 2011 05:51:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E27603A6CAA for ; Mon, 17 Jan 2011 05:51:08 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-96-4d3449e55858 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 52.07.13987.5E9443D4; Mon, 17 Jan 2011 14:53:42 +0100 (CET) Received: from [131.160.126.246] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 14:53:39 +0100 Message-ID: <4D3449E3.50904@ericsson.com> Date: Mon, 17 Jan 2011 15:53:39 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Certs draft: experimental or PS 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, 17 Jan 2011 13:51:10 -0000 Hi, in our last charter update, we decided to move the certs draft to the standards track: o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. However, I would like to double-check with the group. If we intend to specify all this in 5201 bis anyway, it may make sense to publish this as an Experimental RFC. If we want 5201bis to reference this spec, then it needs to be PS. I would like to get your opinions on this issue? Thanks, Gonzalo From mkomu@cs.hut.fi Mon Jan 17 22:38:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880183A6F74 for ; Mon, 17 Jan 2011 22:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8zIqZi+xeWN for ; Mon, 17 Jan 2011 22:38:00 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 9C46C3A6F6D for ; Mon, 17 Jan 2011 22:37:57 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1Pf5F2-0001gA-I1 for hipsec@ietf.org; Tue, 18 Jan 2011 08:40:32 +0200 Message-ID: <4D3535E0.3060704@cs.hut.fi> Date: Tue, 18 Jan 2011 08:40:32 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <4D3449E3.50904@ericsson.com> In-Reply-To: <4D3449E3.50904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 06:38:03 -0000 Hi, On 01/17/2011 03:53 PM, Gonzalo Camarillo wrote: > Hi, > > in our last charter update, we decided to move the certs draft to the > standards track: > > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. > > However, I would like to double-check with the group. If we intend to > specify all this in 5201 bis anyway, it may make sense to publish this > as an Experimental RFC. If we want 5201bis to reference this spec, then > it needs to be PS. I would like to get your opinions on this issue? +1 for standards track From heer@informatik.rwth-aachen.de Tue Jan 18 01:10:29 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BB83A6E95 for ; Tue, 18 Jan 2011 01:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhg34koRoyeu for ; Tue, 18 Jan 2011 01:10:28 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 1B81C3A6DAA for ; Tue, 18 Jan 2011 01:10:28 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LF700010O9SHP20@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 10:13:04 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,338,1291590000"; d="scan'208";a="47109488" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Tue, 18 Jan 2011 10:13:04 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LF7000NBO9SHR50@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 10:13:04 +0100 (CET) From: Tobias Heer In-reply-to: <4D3449E3.50904@ericsson.com> Date: Tue, 18 Jan 2011 10:13:04 +0100 Message-id: <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> References: <4D3449E3.50904@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1082) Cc: HIP Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 09:10:29 -0000 Hello Gonzalo, Am 17.01.2011 um 14:53 schrieb Gonzalo Camarillo: > Hi, > > in our last charter update, we decided to move the certs draft to the > standards track: > > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. > > However, I would like to double-check with the group. If we intend to > specify all this in 5201 bis anyway, it may make sense to publish this > as an Experimental RFC. If we want 5201bis to reference this spec, then > it needs to be PS. I would like to get your opinions on this issue? > I would be interested what the implications of PS or experimetal are for the publication of the draft. Can we publish the draft as PS with downreferences to RFC5201 now (in absence of a 5201-bis) or would we have to wait until 5201-bis is approved? If we go experimental, can we bis the cert draft later and go for PS instead? One reason why I would not like to have the certs in 5201-bis is because it is a separate issue/problem/solution and does not really belong to the _base_ documents but rather extends it. As extension it covers a well defined problem space and can stand on its own. Tobias > Thanks, > > Gonzalo > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From gonzalo.camarillo@ericsson.com Tue Jan 18 01:33:47 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B413A6E7C for ; Tue, 18 Jan 2011 01:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 tNcXH886AQc2 for ; Tue, 18 Jan 2011 01:33:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B58513A6DAA for ; Tue, 18 Jan 2011 01:33:45 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-ab-4d355f158ad0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 62.FD.23694.51F553D4; Tue, 18 Jan 2011 10:36:21 +0100 (CET) Received: from [131.160.126.246] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Tue, 18 Jan 2011 10:36:11 +0100 Message-ID: <4D355F0B.8080305@ericsson.com> Date: Tue, 18 Jan 2011 11:36:11 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Tobias Heer References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> In-Reply-To: <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 09:33:47 -0000 Hi Tobias, yes, those are exactly the points that need to be considered. A straight forward approach would be to publish this draft as experimental and then create a bis draft, this time as a PS, which would reference 5201bis. Another possibility is not to publish the experimental draft at all. We could update the current draft so that it references 5201bis and publish it together with 5201bis. Cheers, Gonzalo On 18/01/2011 11:13 AM, Tobias Heer wrote: > Hello Gonzalo, > > Am 17.01.2011 um 14:53 schrieb Gonzalo Camarillo: > >> Hi, >> >> in our last charter update, we decided to move the certs draft to the >> standards track: >> >> o Specify in a standards track RFC how to carry certificates in the >> base exchange. This was removed from the base HIP spec so that the >> mechanism is specified in a stand-alone spec. >> >> However, I would like to double-check with the group. If we intend to >> specify all this in 5201 bis anyway, it may make sense to publish this >> as an Experimental RFC. If we want 5201bis to reference this spec, then >> it needs to be PS. I would like to get your opinions on this issue? >> > > I would be interested what the implications of PS or experimetal are for the publication of the draft. > > Can we publish the draft as PS with downreferences to RFC5201 now (in absence of a 5201-bis) or would we have to wait until 5201-bis is approved? > > If we go experimental, can we bis the cert draft later and go for PS instead? > > One reason why I would not like to have the certs in 5201-bis is because it is a separate issue/problem/solution and does not really belong to the _base_ documents but rather extends it. As extension it covers a well defined problem space and can stand on its own. > > Tobias > > >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > From Internet-Drafts@ietf.org Tue Jan 18 02:00:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2A33A6FB8; Tue, 18 Jan 2011 02:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ouobAakN3Kz; Tue, 18 Jan 2011 02:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AA83A6FB6; Tue, 18 Jan 2011 02:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118100001.23258.83734.idtracker@localhost> Date: Tue, 18 Jan 2011 02:00:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-08.txt Pages : 13 Date : 2011-01-18 The CERT parameter is a container for X.509.v3 certificates and Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18015844.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Tue Jan 18 02:19:19 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF73A3A6FA9 for ; Tue, 18 Jan 2011 02:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZLhMUovZV88 for ; Tue, 18 Jan 2011 02:19:18 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id AC0213A6FA7 for ; Tue, 18 Jan 2011 02:19:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 763CA4E6D7; Tue, 18 Jan 2011 12:21:49 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQbAElgChDWH; Tue, 18 Jan 2011 12:21:48 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id DFB334E6D1; Tue, 18 Jan 2011 12:21:48 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4D355F0B.8080305@ericsson.com> Date: Tue, 18 Jan 2011 12:21:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> <4D355F0B.8080305@ericsson.com> To: HIP X-Mailer: Apple Mail (2.1082) Cc: Gonzalo Camarillo Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 10:19:19 -0000 Hi, I'd go for publishing experimental CERT now and bis'ed PS version later = with the rest of the PS HIP stuff. Cheers, Ari On Jan 18, 2011, at 11:36 AM, Gonzalo Camarillo wrote: > Hi Tobias, >=20 > yes, those are exactly the points that need to be considered. A = straight > forward approach would be to publish this draft as experimental and = then > create a bis draft, this time as a PS, which would reference 5201bis. >=20 > Another possibility is not to publish the experimental draft at all. = We > could update the current draft so that it references 5201bis and = publish > it together with 5201bis. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On 18/01/2011 11:13 AM, Tobias Heer wrote: >> Hello Gonzalo, >>=20 >> Am 17.01.2011 um 14:53 schrieb Gonzalo Camarillo: >>=20 >>> Hi, >>>=20 >>> in our last charter update, we decided to move the certs draft to = the >>> standards track: >>>=20 >>> o Specify in a standards track RFC how to carry certificates in the >>> base exchange. This was removed from the base HIP spec so that the >>> mechanism is specified in a stand-alone spec. >>>=20 >>> However, I would like to double-check with the group. If we intend = to >>> specify all this in 5201 bis anyway, it may make sense to publish = this >>> as an Experimental RFC. If we want 5201bis to reference this spec, = then >>> it needs to be PS. I would like to get your opinions on this issue? >>>=20 >>=20 >> I would be interested what the implications of PS or experimetal are = for the publication of the draft. >>=20 >> Can we publish the draft as PS with downreferences to RFC5201 now (in = absence of a 5201-bis) or would we have to wait until 5201-bis is = approved? >>=20 >> If we go experimental, can we bis the cert draft later and go for PS = instead? >>=20 >> One reason why I would not like to have the certs in 5201-bis is = because it is a separate issue/problem/solution and does not really = belong to the _base_ documents but rather extends it. As extension it = covers a well defined problem space and can stand on its own. >>=20 >> Tobias >>=20 >>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 From heer@informatik.rwth-aachen.de Tue Jan 18 03:19:54 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602E43A6FC0 for ; Tue, 18 Jan 2011 03:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShQTj5SRVQon for ; Tue, 18 Jan 2011 03:19:53 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 5B1CF3A6F78 for ; Tue, 18 Jan 2011 03:19:53 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LF700KA5U9HWNG0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 12:22:29 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,338,1291590000"; d="scan'208";a="89128155" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 18 Jan 2011 12:22:25 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LF7000S2U9DHR80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 12:22:25 +0100 (CET) From: Tobias Heer In-reply-to: Date: Tue, 18 Jan 2011 12:22:25 +0100 Message-id: References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> <4D355F0B.8080305@ericsson.com> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 11:19:54 -0000 Hello, Am 18.01.2011 um 11:21 schrieb Ari Keranen: > Hi, > > I'd go for publishing experimental CERT now and bis'ed PS version later with the rest of the PS HIP stuff. > I second that. I think it makes sense to publish the RFC as experimental first. The draft is a companion document for 5201 (not bis). I think it should be published as experimental right now. However, I think we might consider a non-experimental version in the future (when 5201-bis is done). Tobias > > Cheers, > Ari > > On Jan 18, 2011, at 11:36 AM, Gonzalo Camarillo wrote: >> Hi Tobias, >> >> yes, those are exactly the points that need to be considered. A straight >> forward approach would be to publish this draft as experimental and then >> create a bis draft, this time as a PS, which would reference 5201bis. >> >> Another possibility is not to publish the experimental draft at all. We >> could update the current draft so that it references 5201bis and publish >> it together with 5201bis. >> >> Cheers, >> >> Gonzalo >> >> >> On 18/01/2011 11:13 AM, Tobias Heer wrote: >>> Hello Gonzalo, >>> >>> Am 17.01.2011 um 14:53 schrieb Gonzalo Camarillo: >>> >>>> Hi, >>>> >>>> in our last charter update, we decided to move the certs draft to the >>>> standards track: >>>> >>>> o Specify in a standards track RFC how to carry certificates in the >>>> base exchange. This was removed from the base HIP spec so that the >>>> mechanism is specified in a stand-alone spec. >>>> >>>> However, I would like to double-check with the group. If we intend to >>>> specify all this in 5201 bis anyway, it may make sense to publish this >>>> as an Experimental RFC. If we want 5201bis to reference this spec, then >>>> it needs to be PS. I would like to get your opinions on this issue? >>>> >>> >>> I would be interested what the implications of PS or experimetal are for the publication of the draft. >>> >>> Can we publish the draft as PS with downreferences to RFC5201 now (in absence of a 5201-bis) or would we have to wait until 5201-bis is approved? >>> >>> If we go experimental, can we bis the cert draft later and go for PS instead? >>> >>> One reason why I would not like to have the certs in 5201-bis is because it is a separate issue/problem/solution and does not really belong to the _base_ documents but rather extends it. As extension it covers a well defined problem space and can stand on its own. >>> >>> Tobias >>> >>> >>>> Thanks, >>>> >>>> Gonzalo >>>> From samu.varjonen@hiit.fi Tue Jan 18 03:22:53 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606D63A6FCA for ; Tue, 18 Jan 2011 03:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWjqqgG4qLvz for ; Tue, 18 Jan 2011 03:22:52 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 2BE923A6F6B for ; Tue, 18 Jan 2011 03:22:52 -0800 (PST) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id 1CB9825ED0F for ; Tue, 18 Jan 2011 13:25:28 +0200 (EET) Message-ID: <4D3578A7.8000101@hiit.fi> Date: Tue, 18 Jan 2011 13:25:27 +0200 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC255F@cs.rwth-aachen.de> <4D355F0B.8080305@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 18 Jan 2011 11:22:53 -0000 On 18/01/11 13:22, Tobias Heer wrote: > Hello, > > Am 18.01.2011 um 11:21 schrieb Ari Keranen: > >> Hi, >> >> I'd go for publishing experimental CERT now and bis'ed PS version later with the rest of the PS HIP stuff. >> > I second that. I think it makes sense to publish the RFC as experimental first. > > The draft is a companion document for 5201 (not bis). > I think it should be published as experimental right now. However, I think we might consider a non-experimental version in the future (when 5201-bis is done). > > Tobias > +1 BR, Samu >> >> Cheers, >> Ari >> >> On Jan 18, 2011, at 11:36 AM, Gonzalo Camarillo wrote: >>> Hi Tobias, >>> >>> yes, those are exactly the points that need to be considered. A straight >>> forward approach would be to publish this draft as experimental and then >>> create a bis draft, this time as a PS, which would reference 5201bis. >>> >>> Another possibility is not to publish the experimental draft at all. We >>> could update the current draft so that it references 5201bis and publish >>> it together with 5201bis. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> On 18/01/2011 11:13 AM, Tobias Heer wrote: >>>> Hello Gonzalo, >>>> >>>> Am 17.01.2011 um 14:53 schrieb Gonzalo Camarillo: >>>> >>>>> Hi, >>>>> >>>>> in our last charter update, we decided to move the certs draft to the >>>>> standards track: >>>>> >>>>> o Specify in a standards track RFC how to carry certificates in the >>>>> base exchange. This was removed from the base HIP spec so that the >>>>> mechanism is specified in a stand-alone spec. >>>>> >>>>> However, I would like to double-check with the group. If we intend to >>>>> specify all this in 5201 bis anyway, it may make sense to publish this >>>>> as an Experimental RFC. If we want 5201bis to reference this spec, then >>>>> it needs to be PS. I would like to get your opinions on this issue? >>>>> >>>> >>>> I would be interested what the implications of PS or experimetal are for the publication of the draft. >>>> >>>> Can we publish the draft as PS with downreferences to RFC5201 now (in absence of a 5201-bis) or would we have to wait until 5201-bis is approved? >>>> >>>> If we go experimental, can we bis the cert draft later and go for PS instead? >>>> >>>> One reason why I would not like to have the certs in 5201-bis is because it is a separate issue/problem/solution and does not really belong to the _base_ documents but rather extends it. As extension it covers a well defined problem space and can stand on its own. >>>> >>>> Tobias >>>> >>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From gonzalo.camarillo@ericsson.com Tue Jan 18 04:41:04 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB8C3A6F2F for ; Tue, 18 Jan 2011 04:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 wyuSTd3h5Miu for ; Tue, 18 Jan 2011 04:41:03 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 36D583A6DAA for ; Tue, 18 Jan 2011 04:41:02 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-1a-4d358afb41f3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B6.83.13987.BFA853D4; Tue, 18 Jan 2011 13:43:39 +0100 (CET) Received: from [131.160.126.246] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Tue, 18 Jan 2011 13:43:39 +0100 Message-ID: <4D358AF7.5000700@ericsson.com> Date: Tue, 18 Jan 2011 14:43:35 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] HIP Session in Prague? 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, 18 Jan 2011 12:41:04 -0000 Folks, some people have indicated that having a face-to-face session in Prague could be helpful to progress some of our current WG items. If you agree, I will request a time slot? Thanks, Gonzalo From Internet-Drafts@ietf.org Tue Jan 18 05:30:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F96A3A6FDA; Tue, 18 Jan 2011 05:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv2H-7qa464s; Tue, 18 Jan 2011 05:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6413A6EF9; Tue, 18 Jan 2011 05:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118133001.11155.59039.idtracker@localhost> Date: Tue, 18 Jan 2011 05:30:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-09.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Certificates Author(s) : T. Heer, S. Varjonen Filename : draft-ietf-hip-cert-09.txt Pages : 13 Date : 2011-01-18 The CERT parameter is a container for X.509.v3 certificates and Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18052724.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jan 18 06:30:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5DF3A7006; Tue, 18 Jan 2011 06:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo4KoB+UlrAt; Tue, 18 Jan 2011 06:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAB03A6F33; Tue, 18 Jan 2011 06:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118143002.4167.19459.idtracker@localhost> Date: Tue, 18 Jan 2011 06:30:02 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-over-hip-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Signaling Message Transport Modes Author(s) : A. Keranen Filename : draft-ietf-hip-over-hip-05.txt Pages : 12 Date : 2011-01-18 This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-over-hip-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18062116.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Tue Jan 18 06:37:19 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFFE28C117 for ; Tue, 18 Jan 2011 06:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MkJAY1v5LtBV for ; Tue, 18 Jan 2011 06:37:18 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 8E6303A700D for ; Tue, 18 Jan 2011 06:37:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B26D84E6D7 for ; Tue, 18 Jan 2011 16:39:54 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKZFF36LZQBV for ; Tue, 18 Jan 2011 16:39:54 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 305B24E6D1 for ; Tue, 18 Jan 2011 16:39:54 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <20110118143002.4167.19459.idtracker@localhost> Date: Tue, 18 Jan 2011 16:39:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86D489B4-A0A6-46DA-B307-FDDD53DF403E@nomadiclab.com> References: <20110118143002.4167.19459.idtracker@localhost> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-over-hip-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:37:19 -0000 Just updated the boilerplate (and the CERT reference as a side product). Cheers, Ari On Jan 18, 2011, at 4:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Host Identity Protocol Working Group = of the IETF. >=20 >=20 > Title : Host Identity Protocol Signaling Message = Transport Modes > Author(s) : A. Keranen > Filename : draft-ietf-hip-over-hip-05.txt > Pages : 12 > Date : 2011-01-18 >=20 > This document specifies two transport modes for Host Identity > Protocol (HIP) signaling messages that allow conveying them over > encrypted connections initiated with the Host Identity Protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-05.txt >=20 From heer@informatik.rwth-aachen.de Tue Jan 18 11:22:16 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158FC3A6F54 for ; Tue, 18 Jan 2011 11:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyTyRxODZ2CQ for ; Tue, 18 Jan 2011 11:22:15 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 36C943A7054 for ; Tue, 18 Jan 2011 11:22:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LF800H72GLG6Y70@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 20:24:52 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,340,1291590000"; d="scan'208";a="89206149" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 18 Jan 2011 20:24:52 +0100 Received: from [192.168.3.3] ([unknown] [91.179.193.179]) 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 <0LF800EUGGLFEO80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 18 Jan 2011 20:24:52 +0100 (CET) From: Tobias Heer In-reply-to: <4D358AF7.5000700@ericsson.com> Date: Tue, 18 Jan 2011 20:24:49 +0100 Message-id: References: <4D358AF7.5000700@ericsson.com> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] HIP Session in Prague? 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, 18 Jan 2011 19:22:16 -0000 Hello Gonzalo, Am 18.01.2011 um 13:43 schrieb Gonzalo Camarillo: > Folks, > > some people have indicated that having a face-to-face session in Prague > could be helpful to progress some of our current WG items. If you agree, > I will request a time slot? > I think at least the bis authors should meet to discuss the next steps. I also think that we can now give a comprehensive summary of what we have done with 5201-bis. Thanks, Tobias From thomas.r.henderson@boeing.com Tue Jan 18 21:43:46 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3AD3A70CA for ; Tue, 18 Jan 2011 21:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 Mm1vQFHVMNDc for ; Tue, 18 Jan 2011 21:43:45 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 6D1DF3A70C9 for ; Tue, 18 Jan 2011 21:43:45 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0J5kGKj009086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Jan 2011 21:46:17 -0800 (PST) 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 p0J5kGp1015969 for ; Tue, 18 Jan 2011 23:46:16 -0600 (CST) 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 p0J5kFYo015943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 18 Jan 2011 23:46:15 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 18 Jan 2011 21:46:14 -0800 From: "Henderson, Thomas R" To: "hipsec@ietf.org" Date: Tue, 18 Jan 2011 21:46:14 -0800 Thread-Topic: [Hipsec] Certs draft: experimental or PS Thread-Index: Acu3AoI0DxMExnEhQieFY8qDkinFHwAmZxDw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25ACE0@XCH-NW-10V.nw.nos.boeing.com> References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC2 55F@cs.rwth-aachen.de> <4D355F0B.8080305@ericsson.com> <4D3578A7.8000101@hiit.fi> In-Reply-To: <4D3578A7.8000101@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 19 Jan 2011 05:43:46 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Samu Varjonen > Sent: Tuesday, January 18, 2011 3:25 AM > To: hipsec@ietf.org > Subject: Re: [Hipsec] Certs draft: experimental or PS >=20 > On 18/01/11 13:22, Tobias Heer wrote: > > Hello, > > > > Am 18.01.2011 um 11:21 schrieb Ari Keranen: > > > >> Hi, > >> > >> I'd go for publishing experimental CERT now and bis'ed PS version > later with the rest of the PS HIP stuff. > >> > > I second that. I think it makes sense to publish the RFC as > experimental first. > > > > The draft is a companion document for 5201 (not bis). > > I think it should be published as experimental right now. However, I > think we might consider a non-experimental version in the future (when > 5201-bis is done). > > > > Tobias > > >=20 > +1 >=20 +1 - Tom From thomas.r.henderson@boeing.com Tue Jan 18 21:48:16 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3003A70D6 for ; Tue, 18 Jan 2011 21:48:16 -0800 (PST) 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 73u-VR6JaKk1 for ; Tue, 18 Jan 2011 21:48:16 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 025E83A6DA2 for ; Tue, 18 Jan 2011 21:48:15 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0J5opds009791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Jan 2011 21:50:51 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p0J5opfe014645; Tue, 18 Jan 2011 21:50:51 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0J5op54014642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 18 Jan 2011 21:50:51 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 18 Jan 2011 21:50:50 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Tue, 18 Jan 2011 21:50:50 -0800 Thread-Topic: [Hipsec] HIP Session in Prague? Thread-Index: Acu3DWeq6FPeES9rRSCRIOkK7I9JNQAjvteQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25ACE2@XCH-NW-10V.nw.nos.boeing.com> References: <4D358AF7.5000700@ericsson.com> In-Reply-To: <4D358AF7.5000700@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] HIP Session in Prague? 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, 19 Jan 2011 05:48:16 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 18, 2011 4:44 AM > To: HIP > Subject: [Hipsec] HIP Session in Prague? >=20 > Folks, >=20 > some people have indicated that having a face-to-face session in Prague > could be helpful to progress some of our current WG items. If you > agree, > I will request a time slot? >=20 Gonzalo, I would be in favor of meeting. - Tom From gonzalo.camarillo@ericsson.com Tue Jan 18 23:37:29 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD52B3A6F95 for ; Tue, 18 Jan 2011 23:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 OezFICa5J6JZ for ; Tue, 18 Jan 2011 23:37:28 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 161583A70EA for ; Tue, 18 Jan 2011 23:37:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-06-4d36955645df Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.84.13987.655963D4; Wed, 19 Jan 2011 08:40:06 +0100 (CET) Received: from [131.160.126.246] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 08:39:59 +0100 Message-ID: <4D36954E.5060000@ericsson.com> Date: Wed, 19 Jan 2011 09:39:58 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP References: <4D358AF7.5000700@ericsson.com> In-Reply-To: <4D358AF7.5000700@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] HIP Session in Prague? 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, 19 Jan 2011 07:37:29 -0000 Hi, based on the responses I got, I have requested a time slot in Prague. Cheers, Gonzalo On 18/01/2011 2:43 PM, Gonzalo Camarillo wrote: > Folks, > > some people have indicated that having a face-to-face session in Prague > could be helpful to progress some of our current WG items. If you agree, > I will request a time slot? > > Thanks, > > Gonzalo > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From mkomu@cs.hut.fi Tue Jan 18 23:51:32 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3283A70D6 for ; Tue, 18 Jan 2011 23:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyTDEJrG8Dtl for ; Tue, 18 Jan 2011 23:51:31 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 577F43A6FB2 for ; Tue, 18 Jan 2011 23:51:31 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1PfSrp-0006Ab-Jk for hipsec@ietf.org; Wed, 19 Jan 2011 09:54:09 +0200 Message-ID: <4D3698A1.7030105@cs.hut.fi> Date: Wed, 19 Jan 2011 09:54:09 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <4D3449E3.50904@ericsson.com> <1486BB76-57BF-49A9-85A0-8136C6EC2 55F@cs.rwth-aachen.de> <4D355F0B.8080305@ericsson.com> <4D3578A7.8000101@hiit.fi> <7CC566635CFE364D87DC5803D4712A6C4CED25ACE0@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25ACE0@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 19 Jan 2011 07:51:32 -0000 Hi, On 01/19/2011 07:46 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >> Behalf Of Samu Varjonen >> Sent: Tuesday, January 18, 2011 3:25 AM >> To: hipsec@ietf.org >> Subject: Re: [Hipsec] Certs draft: experimental or PS >> >> On 18/01/11 13:22, Tobias Heer wrote: >>> Hello, >>> >>> Am 18.01.2011 um 11:21 schrieb Ari Keranen: >>> >>>> Hi, >>>> >>>> I'd go for publishing experimental CERT now and bis'ed PS version >> later with the rest of the PS HIP stuff. >>>> >>> I second that. I think it makes sense to publish the RFC as >> experimental first. >>> >>> The draft is a companion document for 5201 (not bis). >>> I think it should be published as experimental right now. However, I >> think we might consider a non-experimental version in the future (when >> 5201-bis is done). >>> >>> Tobias >>> >> >> +1 >> > > +1 ok, fine by me too. From samu.varjonen@hiit.fi Wed Jan 19 01:33:32 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DBA3A70C7 for ; Wed, 19 Jan 2011 01:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeO8u1OA8ghN for ; Wed, 19 Jan 2011 01:33:31 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 29B003A7028 for ; Wed, 19 Jan 2011 01:33:30 -0800 (PST) Received: from [128.214.114.246] (wel-36.pc.hiit.fi [128.214.114.246]) by argo.otaverkko.fi (Postfix) with ESMTP id 0381225ED15 for ; Wed, 19 Jan 2011 11:36:09 +0200 (EET) Message-ID: <4D36B088.1000008@hiit.fi> Date: Wed, 19 Jan 2011 11:36:08 +0200 From: Samu Varjonen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Comment about Fig.6 in rfc5206-bis-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: Wed, 19 Jan 2011 09:33:32 -0000 Hi, The Fig. 6 in draft-ietf-hip-rfc5206-bis-01 could be clearer on the locator part. IMO the way RFC 5770 handles this would be better. See the proposal below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Loc Type = 0 | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Loc Type = 1 | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 193 Length: Length in octets, excluding Type and Length fields, and excluding padding. Traffic Type: Defines whether the locator pertains to HIP signaling, user data, or both. Locator Type: Defines the semantics of the Locator field. Locator Length: Defines the length of the Locator field, in units of 4-byte words (Locators up to a maximum of 4*255 octets are supported). Reserved: Zero when sent, ignored when received. P: Preferred locator. Set to one if the locator is preferred for that Traffic Type; otherwise, set to zero. Locator Lifetime: Locator lifetime, in seconds. SPI: Security Parameter Index (SPI) value that the host expects to see in incoming ESP packets that use this locator Address: IPv6 address or an "IPv4-Mapped IPv6 address" format IPv4 address [RFC4291] BR, Samu From thomas.r.henderson@boeing.com Wed Jan 19 19:44:38 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1218928C138 for ; Wed, 19 Jan 2011 19:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 nv8aPLb9qcNe for ; Wed, 19 Jan 2011 19:44:37 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 50FC128C133 for ; Wed, 19 Jan 2011 19:44:37 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0K3ktYD017061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 21:47:03 -0600 (CST) 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 p0K3ktWW003416; Wed, 19 Jan 2011 21:46:55 -0600 (CST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0K3ktjT003406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 19 Jan 2011 21:46:55 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 19 Jan 2011 19:46:54 -0800 From: "Henderson, Thomas R" To: "'Samu Varjonen'" , HIP Date: Wed, 19 Jan 2011 19:46:53 -0800 Thread-Topic: [Hipsec] Comment about Fig.6 in rfc5206-bis-01 Thread-Index: Acu3vFTjnbGLUATfSSOGNR5RWDLkfgAmD7Fw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25ACF1@XCH-NW-10V.nw.nos.boeing.com> References: <4D36B088.1000008@hiit.fi> In-Reply-To: <4D36B088.1000008@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Comment about Fig.6 in rfc5206-bis-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: Thu, 20 Jan 2011 03:44:38 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Samu Varjonen > Sent: Wednesday, January 19, 2011 1:36 AM > To: HIP > Subject: [Hipsec] Comment about Fig.6 in rfc5206-bis-01 >=20 > Hi, >=20 > The Fig. 6 in draft-ietf-hip-rfc5206-bis-01 could be clearer on the > locator > part. IMO the way RFC 5770 handles this would be better. See the > proposal below. Hi Samu, thanks for the suggestion; I agree and will put it in the next rev= ision unless anyone raises a concern. - Tom From heer@informatik.rwth-aachen.de Thu Jan 20 12:53:53 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7F23A6824 for ; Thu, 20 Jan 2011 12:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S2EIcD8Xf0m for ; Thu, 20 Jan 2011 12:53:52 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 67E473A681A for ; Thu, 20 Jan 2011 12:53:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LFC00FTPA6BYPH0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 20 Jan 2011 21:56:35 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,353,1291590000"; d="scan'208";a="89530389" 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; Thu, 20 Jan 2011 21:56:36 +0100 Received: from [192.168.3.3] ([unknown] [91.179.203.58]) 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 <0LFC000GCA6B6980@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 20 Jan 2011 21:56:35 +0100 (CET) From: Tobias Heer Date: Thu, 20 Jan 2011 21:56:37 +0100 References: <20110120205032.AB7A23A6824@core3.amsl.com> To: HIP Message-id: X-Mailer: Apple Mail (2.1082) Subject: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-rfc5201-bis-04 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, 20 Jan 2011 20:53:53 -0000 Hello, I just submitted a new version of RFC5201-bis. http://www.ietf.org/id/draft-ietf-hip-rfc5201-bis-04.txt Here is the changelog from version 03: 8.1. Changes from draft-ietf-hip-rfc5201-bis-03 o Editorial changes to improve clarity and readability. o Removed obsoleted (not applicable) attack from security consideration section. o Added a requirement that hosts MUST support processing of ACK parameters with several SEQ numbers even when they do not support sending such parameters. o Removed note on memory bound puzzles. The use of memory bound puzzles was reconsidered but no convincing arguments for inclusion in this document have been made on the list. o Changed references to reference the new bis documents. o Specified the ECC curves and the hashes used for these. o Specified representation of ECC curves in the HI. o Added text on the dependency between RHASH and HMAC. o Rephrased part of the security considerations to make them clearer. o Clarified the use of HITs in opportunistic mode. o Clarified the difference between HIP_MAC and HIP_MAC_2 as well as between SIGNATURE and SIGNATURE_2. o Changed NOTIFY name for value 44 from SERVER_BUSY_PLEASE_RETRY to RESPONDER_BUSY_PLEASE_RETRY. o Mentioned that there are multiple valid puzzle solutions. Feel free to provide reviews, comments and suggestions. Tobias Anfang der weitergeleiteten E-Mail: > Von: IETF I-D Submission Tool > Datum: 20. Januar 2011 21:50:32 MEZ > An: heer@cs.rwth-aachen.de > Kopie: thomas.r.henderson@boeing.com, petri.jokela@nomadiclab.com, robert.moskowitz@icsalabs.com > Betreff: New Version Notification for draft-ietf-hip-rfc5201-bis-04 > > > A new version of I-D, draft-ietf-hip-rfc5201-bis-04.txt has been successfully submitted by Tobias Heer and posted to the IETF repository. > > Filename: draft-ietf-hip-rfc5201-bis > Revision: 04 > Title: Host Identity Protocol > Creation_date: 2011-01-20 > WG ID: hip > Number_of_pages: 119 > > Abstract: > This document specifies the details of the Host Identity Protocol > (HIP). HIP allows consenting hosts to securely establish and > maintain shared IP-layer state, allowing separation of the identifier > and locator roles of IP addresses, thereby enabling continuity of > communications across IP address changes. HIP is based on a SIGMA- > compliant Diffie-Hellman key exchange, using public key identifiers > from a new Host Identity namespace for mutual peer authentication. > The protocol is designed to be resistant to denial-of-service (DoS) > and man-in-the-middle (MitM) attacks. When used together with > another suitable security protocol, such as the Encapsulated Security > Payload (ESP), it provides integrity protection and optional > encryption for upper-layer protocols, such as TCP and UDP. > > This document obsoletes RFC 5201 and addresses the concerns raised by > the IESG, particularly that of crypto agility. It also incorporates > lessons learned from the implementations of RFC 5201. > > > > The IETF Secretariat. > > From Internet-Drafts@ietf.org Thu Jan 20 13:00:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EC43A682F; Thu, 20 Jan 2011 13:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56-1CnHM7F62; Thu, 20 Jan 2011 13:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8BA3A681D; Thu, 20 Jan 2011 13:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110120210001.11465.54992.idtracker@localhost> Date: Thu, 20 Jan 2011 13:00:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc5201-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-rfc5201-bis-04.txt Pages : 119 Date : 2011-01-20 This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-rfc5201-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20125032.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Fri Jan 21 03:36:35 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6343A6925 for ; Fri, 21 Jan 2011 03:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 5RC9TTCeS9LR for ; Fri, 21 Jan 2011 03:36:34 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 230853A692F for ; Fri, 21 Jan 2011 03:36:33 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-50-4d397066534e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 76.56.23694.660793D4; Fri, 21 Jan 2011 12:39:19 +0100 (CET) Received: from [131.160.126.172] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 21 Jan 2011 12:39:19 +0100 Message-ID: <4D397066.90606@ericsson.com> Date: Fri, 21 Jan 2011 13:39:18 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP References: <4D3449E3.50904@ericsson.com> In-Reply-To: <4D3449E3.50904@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] Certs draft: experimental or PS 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, 21 Jan 2011 11:36:35 -0000 Hi, I have just requested its publication as Experimental. Cheers, Gonzalo On 17/01/2011 3:53 PM, Gonzalo Camarillo wrote: > Hi, > > in our last charter update, we decided to move the certs draft to the > standards track: > > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. > > However, I would like to double-check with the group. If we intend to > specify all this in 5201 bis anyway, it may make sense to publish this > as an Experimental RFC. If we want 5201bis to reference this spec, then > it needs to be PS. I would like to get your opinions on this issue? > > Thanks, > > Gonzalo > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From ari.keranen@nomadiclab.com Fri Jan 21 05:39:36 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7D33A6916 for ; Fri, 21 Jan 2011 05:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 8owhcQmjIrkV for ; Fri, 21 Jan 2011 05:39:35 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 80C6D3A6914 for ; Fri, 21 Jan 2011 05:39:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 1F4064E6D1 for ; Fri, 21 Jan 2011 15:42:20 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgJavV7bAkm6 for ; Fri, 21 Jan 2011 15:42:19 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 88B2E4E6BC for ; Fri, 21 Jan 2011 15:42:19 +0200 (EET) From: Ari Keranen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2011 15:42:19 +0200 Message-Id: <0A26152E-F459-4552-B183-7DEF1A05FC75@nomadiclab.com> To: HIP Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Hipsec] Registration Extension bis-draft (5203-bis) comments 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, 21 Jan 2011 13:39:36 -0000 Hi all, Now when we're bis'ing also the registration RFC, it would make sense to = add a few more features there. Some of these have been discussed also = earlier on this list (these relate to requirements discovered with the = native NAT traversal draft [1]), but I'll have them all here for easier = reference. Currently, the registrar has no way of indicating that it would = otherwise accept the registration, but it's currently running low on = resources. For this purpose, a failure type "Insufficient resources" = could be added to the "registration failure types".=20 Registration using authentication with certificates could be part of the = registration RFC. Currently, only authentication with HI is defined, but = knowing all HIs beforehand is not practical in many cases.=20 Text in section 3.2. of [1] could be used as a basis for this (just = replace "HIP' data relay" with "registrar"). Also, if this = authentication mode is added to the draft, failure type "Invalid = certificate" should be added for the failure case. Should we have these in the registration draft? Cheers, Ari [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal= From jeffrey.m.ahrenholz@boeing.com Fri Jan 21 07:50:42 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690813A6A2C for ; Fri, 21 Jan 2011 07:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.400, 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 2peXu8BEY7DF for ; Fri, 21 Jan 2011 07:50:41 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 3C3403A6A29 for ; Fri, 21 Jan 2011 07:50:41 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0LFrMO4014857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Jan 2011 07:53:25 -0800 (PST) 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 p0LFrLwQ026557 for ; Fri, 21 Jan 2011 09:53:22 -0600 (CST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0LFrKVE026491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 21 Jan 2011 09:53:21 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 21 Jan 2011 07:53:21 -0800 From: "Ahrenholz, Jeffrey M" To: "hipsec@ietf.org" Date: Fri, 21 Jan 2011 07:53:20 -0800 Thread-Topic: comments on draft-ietf-hip-rfc4423-bis-01 Thread-Index: Acu5g1NjaeHLxXqNRIC5A0BGnNLp/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-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, 21 Jan 2011 15:50:42 -0000 Here are some comments after reviewing the HIP Architecture -bis draft... Should RFC 5201 be referenced? - the base exchange is discussed - the table of terms in Section 2.2 could refer to=20 RFC 5201 under definition of base exchange - ESP (5202), Rendezvous (5204), and DNS (5205) are listed as normative references, but 5201 is not referenced Section 5.1 talks about moving Host Identities from one physical computer t= o another without breaking transport associations. Really? Section 6.1 mentions "HIP readdress packets"; earlier versions of the=20 spec actually had readdress packets, but now it would be more precise to sa= y "HIP UPDATE packets" Section 6.2 says "To close this attack, HIP includes..." Could this better be phrased as "To close this attack vector" or=20 "To prevent this type of attack"? Section 6.2 last paragraph discusses skipping the address check; CBA can also be used to reduce handover latency here? Section 8.1 "HIP and TCP checksums" should be titled=20 "HIP and Upper-layer checksums"? This was briefly discussed on this list before [1].=20 Section 9 Multicast says: "There was little if any concrete thoughts about how HIP might affect IP-layer or application-layer multicast." This sentence made sense in conjunction with the RFC 4423 abstract: "The memo describes the thinking of the authors as of Fall 2003." ...but without such text that sentence on multicast doesn't really stand on its own. Section 11.1 question 5 missing question mark at the end -Jeff [1] http://www.ietf.org/mail-archive/web/hipsec/current/msg02799.html From jeffrey.m.ahrenholz@boeing.com Fri Jan 21 14:22:59 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266D128B797 for ; Fri, 21 Jan 2011 14:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 smIoMwQZWl8d for ; Fri, 21 Jan 2011 14:22:58 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id ED8B828B23E for ; Fri, 21 Jan 2011 14:22:57 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0LMPbcR012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Jan 2011 16:25:42 -0600 (CST) 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 p0LMPaEU002782 for ; Fri, 21 Jan 2011 14:25:36 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0LMPVqF002518 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 21 Jan 2011 14:25:36 -0800 (PST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 21 Jan 2011 14:25:36 -0800 From: "Ahrenholz, Jeffrey M" To: "hipsec@ietf.org" Date: Fri, 21 Jan 2011 14:25:35 -0800 Thread-Topic: comments on draft-ietf-hip-rfc5201-bis-04 Thread-Index: Acu5uh9qjaIKuHLRQvSV4fgumskJ/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04 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, 21 Jan 2011 22:22:59 -0000 Here are some comments on (the first part of) the 5201-bis draft. First are= some high-level comments and then small editorial nits. (1) The terms "Host Identity" and "Host Identifier" do not mean the same th= ing in 4423-bis and 5201-bis, when comparing the definitions/terminology se= ctions. Section 3 also uses "Identifier Tag" and "Identity Tag" inconsisten= tly. I'd prefer to always call the HIT the "Host Identity Tag". (2) I think the draft-ietf-hip-rfc4843-bis-00 document needs to be updated = to reflect the new HIT format of: 28-bit prefix + 4-bit OGA + 96-bit pubkey= . Section 3 mentions 96 bits from the HI while 4843-bis still has 100 bits.= The OGA (Section 3.1, Appendix E) is not mentioned in 4843-bis, just the C= ontext ID. (3) Section 5.2 the 2nd table of parameter type ranges lists "handshake", a= nd this is used elsewhere in the document, but not necessarily defined. We = know the "HIP handshake" is synonymous with "HIP base exchange" but maybe t= hat should be spelled out somewhere? Below are the nits... -Jeff Section 1. Intro s/called HIP association/called a HIP association/ s/That is it should be a part/That is, it should be a part/ Section 1.3 s/define the detail packet formats/define the detailed packet formats/ Section 3.1 The text that says "Firstly, the fixed length .... Secondly, it presents ..= .", I think this should use same text as Section 5.3 of 4423-bis; or revise= it with something like: "First, the fixed length of the HIT keeps packet sizes manageable and eases protocol coding. Second, it presents a consistent format for the protocol, independent of the underlying identity technology in use." Section 3.2 references FIPS.95-1.1993 and if you follow this reference, it = is not about SHA-1 (it is much more dreary); it seems like the latest FIPS 180= reference is good enough for both SHA-1 and SHA-256 (I think the RFC 5201 = [FIPS95] reference to PUB 180-1 1995 somehow became FIPS.95-1.1993) Section 3.2 second paragraph, the HTML version says "Section Section 5.2.8" (where "Section 5.2.8" is a link) Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc] the HTML tool incorrectly links Section 4.2 (of current doc) Section 4.1 says "In the first two packets, the hosts agree on a set of cry= ptographic identifiers and algorithms..."; wouldn't you say the first 3 pac= kets, since the 3rd/I2 packet contains the chosen HIP_CIPHER? Section 4.1.1 s/Second, hand, the design/Second, the design/ (leftover text from RFC 5201) Section 4.1.2 s/limits the usability of an old/limits the usability that an= old/ Section 4.1.3 s/as well as it uses/as well as uses/ Section 4.1.7 s/if they are remain/if they remain/ Section 4.2 "rekey expiring user data security associations" - I'm not sure that the words "user data" are needed? Section 4.3 s/sendin an I1/sending an I1/ Section 4.5.1 s/in the place of the/in place of the/ Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." while Section 5.1.3 says "A HIP implementation must support IP fragmentation/reas= sembly." ...I think 5.3.1 is discussing HIP packets having an upper-layer p= ayload, but this should be clarified. From heer@informatik.rwth-aachen.de Mon Jan 24 05:49:07 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7D93A6AC4 for ; Mon, 24 Jan 2011 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMiNUrBerJag for ; Mon, 24 Jan 2011 05:49:06 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id D66413A63D3 for ; Mon, 24 Jan 2011 05:49:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LFJ00K7J56NL6F0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 24 Jan 2011 14:51:59 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,370,1291590000"; d="scan'208";a="89935998" 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, 24 Jan 2011 14:51:59 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LFJ00C5E56M2W30@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 24 Jan 2011 14:51:59 +0100 (CET) From: Tobias Heer In-reply-to: Date: Mon, 24 Jan 2011 14:51:58 +0100 Message-id: <90014AE7-DB37-4227-AD71-ED36285A2D5B@cs.rwth-aachen.de> References: To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.1082) Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04 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, 24 Jan 2011 13:49:07 -0000 Hello Jeff, thanks for your comments. Responses are in line. Am 21.01.2011 um 23:25 schrieb Ahrenholz, Jeffrey M: > Here are some comments on (the first part of) the 5201-bis draft. First are some high-level comments and then small editorial nits. > > (1) The terms "Host Identity" and "Host Identifier" do not mean the same thing in 4423-bis and 5201-bis, when comparing the definitions/terminology sections. Section 3 also uses "Identifier Tag" and "Identity Tag" inconsistently. I'd prefer to always call the HIT the "Host Identity Tag". I have taken care of the Identifier vs. Identity issue. It is now always Identity when a concrete representation of a Host's identity is meant. In general, the Host Identity is an identifier (not the identity of the host). I left identifier when the identifier-nature was important. Thanks for noticing it. > > (2) I think the draft-ietf-hip-rfc4843-bis-00 document needs to be updated to reflect the new HIT format of: 28-bit prefix + 4-bit OGA + 96-bit pubkey. Section 3 mentions 96 bits from the HI while 4843-bis still has 100 bits. The OGA (Section 3.1, Appendix E) is not mentioned in 4843-bis, just the Context ID. Julien has agreed to do this update as soon as we are done with the requirements for the new ORCHID document. I think the time has come to do that. > > (3) Section 5.2 the 2nd table of parameter type ranges lists "handshake", and this is used elsewhere in the document, but not necessarily defined. We know the "HIP handshake" is synonymous with "HIP base exchange" but maybe that should be spelled out somewhere? > I added HIP Base Exchange to the "Definitions" section and explained that it is the HIP handshake. > Below are the nits... > > -Jeff > > Section 1. Intro > s/called HIP association/called a HIP association/ > s/That is it should be a part/That is, it should be a part/ > Done. > Section 1.3 > s/define the detail packet formats/define the detailed packet formats/ > > Section 3.1 > The text that says "Firstly, the fixed length .... Secondly, it presents ...", I think this should use same text as Section 5.3 of 4423-bis; or revise it with something like: > "First, the fixed length of the HIT keeps packet sizes manageable and eases > protocol coding. Second, it presents a consistent format for the protocol, > independent of the underlying identity technology in use." I used your suggestion. Thanks. > > Section 3.2 references FIPS.95-1.1993 and if you follow this reference, it is > not about SHA-1 (it is much more dreary); it seems like the latest FIPS 180 reference is good enough for both SHA-1 and SHA-256 (I think the RFC 5201 [FIPS95] reference to PUB 180-1 1995 somehow became FIPS.95-1.1993) Done. Removed the reference. > > Section 3.2 second paragraph, the HTML version says "Section Section 5.2.8" > (where "Section 5.2.8" is a link) Resolved. > > Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc] > the HTML tool incorrectly links Section 4.2 (of current doc) > This is odd. The HTML version tries to be smart but fails. There is no link pointing to that section in the xml document. I have no clue what to do because there is nothing I could remove. > Section 4.1 says "In the first two packets, the hosts agree on a set of cryptographic identifiers and algorithms..."; wouldn't you say the first 3 packets, since the 3rd/I2 packet contains the chosen HIP_CIPHER? I'd say that the agreement has already been reached when the second packet was processed. The third packet only contains the effect of the agreement. Does that make sense? > > Section 4.1.1 s/Second, hand, the design/Second, the design/ > (leftover text from RFC 5201) > Done. > Section 4.1.2 s/limits the usability of an old/limits the usability that an old/ > Done. > Section 4.1.3 s/as well as it uses/as well as uses/ > Done. > Section 4.1.7 s/if they are remain/if they remain/ > Done. > Section 4.2 "rekey expiring user data security associations" - I'm not sure > that the words "user data" are needed? > I removed it. > Section 4.3 s/sendin an I1/sending an I1/ > Done. > Section 4.5.1 s/in the place of the/in place of the/ > Done. > Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." while > Section 5.1.3 says "A HIP implementation must support IP fragmentation/reassembly." ...I think 5.3.1 is discussing HIP packets having an upper-layer payload, but this should be clarified. You mean 5.3 and 5.3.1? The case is a bit schizophrenic anyway. I think the requirement in 5.3 should be lowered to a SHOULD NOT be fragmented, emphasizing the potentially negative effects of fragmentation. What do you think? Thanks again for your comments. Tobias From jeffrey.m.ahrenholz@boeing.com Mon Jan 24 07:37:24 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B9B3A68FA for ; Mon, 24 Jan 2011 07:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 Ire3BMW-d1bJ for ; Mon, 24 Jan 2011 07:37:23 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 694C13A68E4 for ; Mon, 24 Jan 2011 07:37:23 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0OFe8Ev007137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Jan 2011 07:40:10 -0800 (PST) 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 p0OFe5iD017985; Mon, 24 Jan 2011 09:40:05 -0600 (CST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0OFe2i8017874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 24 Jan 2011 09:40:04 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 24 Jan 2011 07:40:02 -0800 From: "Ahrenholz, Jeffrey M" To: Tobias Heer Date: Mon, 24 Jan 2011 07:40:00 -0800 Thread-Topic: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04 Thread-Index: Acu7zfBSRwA6isnsTvKIKUAKhlggFgADNrIQ Message-ID: References: <90014AE7-DB37-4227-AD71-ED36285A2D5B@cs.rwth-aachen.de> In-Reply-To: <90014AE7-DB37-4227-AD71-ED36285A2D5B@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04 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, 24 Jan 2011 15:37:24 -0000 > > Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc] > > the HTML tool incorrectly links Section 4.2 (of current doc) > > >=20 > This is odd. The HTML version tries to be smart but fails. There is no li= nk > pointing to that section in the xml document. I have no clue what to do b= ecause > there is nothing I could remove. I guess there's nothing we can do here, they need to fix the tool. > > Section 4.1 says "In the first two packets, the hosts agree on a set of > cryptographic identifiers and algorithms..."; wouldn't you say the first = 3 > packets, since the 3rd/I2 packet contains the chosen HIP_CIPHER? > I'd say that the agreement has already been reached when the second packe= t was > processed. The third packet only contains the effect of the agreement. > Does that make sense? Yes, makes sense. > > Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." w= hile > > Section 5.1.3 says "A HIP implementation must support IP > fragmentation/reassembly." ...I think 5.3.1 is discussing HIP packets hav= ing an > upper-layer payload, but this should be clarified. >=20 > You mean 5.3 and 5.3.1? I guess it's 5.1.3 and 5.3: 5.1.3 says IP fragmentation MUST be implemented 5.3 says the HIP packet MUST NOT be fragmented So fragmentation in 5.3 refers only to piggy-backed data, I think. > The case is a bit schizophrenic anyway. I think the requirement in 5.3 sh= ould be > lowered to a SHOULD NOT be fragmented, emphasizing the potentially negati= ve > effects of fragmentation. > What do you think? Yes, SHOULD NOT sounds good. This text seems to say: if the data you are tr= ying to piggy-back on the I1 would cause the HIP packet to fragment, send t= he data in its own (TCP/UDP/IP) packet following the BEX. -Jeff From heer@informatik.rwth-aachen.de Mon Jan 24 07:44:54 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736F93A6AEA for ; Mon, 24 Jan 2011 07:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+iQOhlCJf-i for ; Mon, 24 Jan 2011 07:44:53 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 70F913A6AEF for ; Mon, 24 Jan 2011 07:44:53 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LFJ00D0EAJN84H0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 24 Jan 2011 16:47:47 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,370,1291590000"; d="scan'208";a="47526973" 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, 24 Jan 2011 16:47:48 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LFJ00C04AJN2W60@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 24 Jan 2011 16:47:47 +0100 (CET) From: Tobias Heer In-reply-to: Date: Mon, 24 Jan 2011 16:47:47 +0100 Message-id: References: <90014AE7-DB37-4227-AD71-ED36285A2D5B@cs.rwth-aachen.de> To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.1082) Cc: hipsec@ietf.org Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc5201-bis-04 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, 24 Jan 2011 15:44:54 -0000 Hello Jeff, Am 24.01.2011 um 16:40 schrieb Ahrenholz, Jeffrey M: >>> Section 3.2 mentions Section 4.2 and 6 of [I-D.mcgrew-fundamental-ecc] >>> the HTML tool incorrectly links Section 4.2 (of current doc) >>> >> >> This is odd. The HTML version tries to be smart but fails. There is no link >> pointing to that section in the xml document. I have no clue what to do because >> there is nothing I could remove. > > I guess there's nothing we can do here, they need to fix the tool. > >>> Section 4.1 says "In the first two packets, the hosts agree on a set of >> cryptographic identifiers and algorithms..."; wouldn't you say the first 3 >> packets, since the 3rd/I2 packet contains the chosen HIP_CIPHER? >> I'd say that the agreement has already been reached when the second packet was >> processed. The third packet only contains the effect of the agreement. >> Does that make sense? > > Yes, makes sense. Ok, so I'll leave it as it was. > >>> Section 5.3.1 says "The HIP packet, however, MUST NOT be fragmented." while >>> Section 5.1.3 says "A HIP implementation must support IP >> fragmentation/reassembly." ...I think 5.3.1 is discussing HIP packets having an >> upper-layer payload, but this should be clarified. >> >> You mean 5.3 and 5.3.1? > > I guess it's 5.1.3 and 5.3: > 5.1.3 says IP fragmentation MUST be implemented > 5.3 says the HIP packet MUST NOT be fragmented > > So fragmentation in 5.3 refers only to piggy-backed data, I think. > >> The case is a bit schizophrenic anyway. I think the requirement in 5.3 should be >> lowered to a SHOULD NOT be fragmented, emphasizing the potentially negative >> effects of fragmentation. >> What do you think? > > Yes, SHOULD NOT sounds good. This text seems to say: if the data you are trying to piggy-back on the I1 would cause the HIP packet to fragment, send the data in its own (TCP/UDP/IP) packet following the BEX. Yes, that was my interpretation, too. The text is from the original RFC5201. I'll change it to a SHOULD NOT and maybe state this more explicitly. Tobias > > -Jeff From jeffrey.m.ahrenholz@boeing.com Mon Jan 24 13:29:03 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942173A6922 for ; Mon, 24 Jan 2011 13:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wZJjXBz3HE+1 for ; Mon, 24 Jan 2011 13:29:02 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 8178D3A698D for ; Mon, 24 Jan 2011 13:29:02 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p0OLVruT025047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Jan 2011 15:31:53 -0600 (CST) 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 p0OLVrSI024437 for ; Mon, 24 Jan 2011 15:31:53 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p0OLVq1s024396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 24 Jan 2011 15:31:53 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 24 Jan 2011 13:31:51 -0800 From: "Ahrenholz, Jeffrey M" To: "hipsec@ietf.org" Date: Mon, 24 Jan 2011 13:31:50 -0800 Thread-Topic: more comments on draft-ietf-hip-rfc5201-bis-04 Thread-Index: Acu8DhyyWgIj3dR2QqKx6mV8xk5tnw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04 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, 24 Jan 2011 21:29:03 -0000 Here are some additional comments on the 5201-bis draft. Section 5.4.2 says: "However, an implementation MUST NOT send an ICMP message if the checksum f= ails; instead, it MUST silently drop the packet." If we MUST silently drop = a packet, why do we have NOTIFY type 26, "CHECKSUM_FAILED"? (Debugging?) Section 6.11 item 4: this says the association is considered broken if an UPDATE is not ACKed, but one circumstance where the association is NOT brok= en would be when a host is informing its peer of its current address list (without changing the current preferred locators used.) In that case, the association may continue happily without going to CLOSING. Below are more minor editorial nits... -Jeff 5.2.4, 5.2.5 - suggest changing "n bytes" in parameter diagram to "n bits" the descriptions that follow (for random #I, solution #J) discuss n-bit integers, and RHASH_len is stated as a bit length in 5.3.2 To support the "i" used in the diagram, may want to = add a note about multiple ECHO_REQUEST_UNSIGNEDs as described in 5.2.20 with te= xt such as: "The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as described in Section 5.2.20." Then in 5.3.3 may change s/parameter/parameter(s)/ to support the "i" diagram notation. in 5.3.7 and 9 s/an HIP_MAC/a HIP_MAC/ (for consistency with "a HIP..." elsewhere in the document) 5.3.8, suggest changing: "The receiver peer MUST validate both the HMAC and the signature." to: "The receiver MUST verify the echo response and validate both the HIP_MAC a= nd the signature." (because 5.3.7 says you MUST include the ECHO_REQUEST_SIGNED) Section 6.4.1 s/SAH-1/SHA-1/ Section 6.7 s/the Responder a HIT with/the Responder selects a HIT with/ Section 6.8 item 6 s/a Initiator/an Initiator/ Section 5.3.2 and 6.8 item 7 s/SHOULD not/SHOULD NOT/ Section 6.9 item 12 s/packet I2/I2 packet/ Section 6.9 item 13 s/verify the HMAC/verify the HIP_MAC/ for consistency? (elsewhere, "verify the HIP_MAC" is used) Section 6.11 s/steps below ./steps below./ Section 6.11 item 2: support multiple ACKs? replace: "The UPDATE packet MAY also include an ACK of the peer's Update ID found in a received UPDATE SEQ parameter, if any." with: "The UPDATE packet MAY also include zero or more ACKs of the peer's Update ID(s) from previously received UPDATE SEQ parameter(s)." Section 7 suggest defining the first occurrence of ACL: "This access control list (ACL) SHOULD also include..." s/representing which hosts/representing for which hosts/ s/for such ACL also/for such ACLs, and also/ ? Appendix C.2 suggest re-wording slightly: "The IPv4 checksum value for the example I1 packet equals the IPv6 checksum value (since the checksum components due to the IPv4 and IPv6 pseudo-heade= r are the same)." Appendix D=20 s/Today should be used only when/Today these groups should only be used whe= n/ From wwwrun@rfc-editor.org Mon Jan 24 17:31:18 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3F73A6B4D; Mon, 24 Jan 2011 17:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 RCpNH-uZJEHN; Mon, 24 Jan 2011 17:31:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 27F833A6B49; Mon, 24 Jan 2011 17:31:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1C214E0724; Mon, 24 Jan 2011 17:34:13 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110125013413.1C214E0724@rfc-editor.org> Date: Mon, 24 Jan 2011 17:34:13 -0800 (PST) Cc: hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 6078 on Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) 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, 25 Jan 2011 01:31:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6078 Title: Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) Author: G. Camarillo, J. Melen Status: Experimental Stream: IETF Date: January 2011 Mailbox: Gonzalo.Camarillo@ericsson.com, Jan.Melen@ericsson.com Pages: 17 Characters: 41482 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-hip-hiccups-05.txt URL: http://www.rfc-editor.org/rfc/rfc6078.txt This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. 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 From wwwrun@rfc-editor.org Mon Jan 24 17:31:33 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339D23A6B4B; Mon, 24 Jan 2011 17:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZZd1fr4z9FQh; Mon, 24 Jan 2011 17:31:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id F2E2D3A6847; Mon, 24 Jan 2011 17:31:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 206A5E073B; Mon, 24 Jan 2011 17:34:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110125013427.206A5E073B@rfc-editor.org> Date: Mon, 24 Jan 2011 17:34:27 -0800 (PST) Cc: hipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [Hipsec] RFC 6079 on HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) 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, 25 Jan 2011 01:31:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6079 Title: HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) Author: G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston Status: Experimental Stream: IETF Date: January 2011 Mailbox: Gonzalo.Camarillo@ericsson.com, Pekka.Nikander@ericsson.com, Jani.Hautakorpi@ericsson.com, Ari.Keranen@ericsson.com, alan.b.johnston@gmail.com Pages: 21 Characters: 51013 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-hip-bone-07.txt URL: http://www.rfc-editor.org/rfc/rfc6079.txt This document specifies a framework to build HIP-based (Host Identity Protocol) 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". 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 From ari.keranen@nomadiclab.com Thu Jan 27 09:10:34 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5CE28C14B for ; Thu, 27 Jan 2011 09:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_33=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 Ul7u1+DMXFXf for ; Thu, 27 Jan 2011 09:10:33 -0800 (PST) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1CD9F28C145 for ; Thu, 27 Jan 2011 09:10:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 3004F4E6DC for ; Thu, 27 Jan 2011 19:13:34 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agC11jqTzRnK for ; Thu, 27 Jan 2011 19:13:33 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id C4F634E6CF for ; Thu, 27 Jan 2011 19:13:32 +0200 (EET) From: Ari Keranen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jan 2011 19:13:32 +0200 Message-Id: To: HIP Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:10:34 -0000 Hi, I reviewed part of the -04 draft (version dated Jan 27th), and here's = some comments, questions, and suggestions.=20 Since we are specifying the version 2 of the protocol, should we say = that in the title and abstract? 1. Introduction As a result, all cryptographic protocols need to be agile. That is, it should be a part of the protocol to switch from one cryptographic primitive to another, and reasonable effort should be done to support a reasonable set of mainstream algorithms. s/to switch/to be able to switch/ Instead of "reasonable effort should be done [...]" one could say = something like: "[...] it is important to support a reasonable set of = mainstream algorithms to cater for different use cases and allow moving = away from algorithms that are later discovered to be vulnerable". 1.1. A New Namespace and Identifiers The HI is a public key and directly represents the Identity. s/Identity/identity of a host/ Since there are different public key algorithms that can be used with different key lengths, the HI is unsuitable for use as a packet identifier s/HI is unsuitable/HI, as such, is unsuitable/ Consequently, a hash of the HI, the Host Identity Tag (HIT), is the operational representation. s/is/is used as/ 1.2. The HIP Base Exchange (BEX) It should be noted, however, that both the Initiator's and the Responder's HITs are transported as such (in cleartext) in the packets, allowing an eavesdropper with a priori knowledge about the parties to identify them by their HITs. Hence, encrypting the HI of any party does not provide privacy against such attacker. This text goes fairly deep into a specific attack and could better fit = to the Security Considerations section than in the introduction. Data packets start to flow after the 4th packet. The 3rd and 4th HIP packets may carry a data payload in the future. However, the details of this may be defined later. s/may be defined later/are not defined for the time being/ Thus, HIP is not a complete replacement for IKE. This begs for a question "why would I use HIP instead of IKE". Perhaps a = section (to appendix?) on HIP's relationship to IKE (and a reference to = that section here) would be helpful. 2.3. Definitions All the definitions repeat the "defined word" in the beginning; that's a = bit redundant. That is, instead of: HIP Base Exchange (BEX) The HIP Base Exchange is the handshake for establishing a new HIP association. One could say: HIP Base Exchange (BEX): the handshake for establishing a new HIP association Could also add "Initiator", "Responder", "HIP association" and "signed" = to the definitions. 3. Host Identity (HI) and its Structure HIP implementations MUST support the Rivest Shamir Adelman (RSA) [RFC3110] public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve Digital Signature Algorithm (ECDSA) defined in Section 5.2.8.=20 Must support [...] for generating the Host Identity, as defined in [...] Other algorithms MAY be supported. s/Other/Additional/ 3.1. Host Identity Tag (HIT) This section repeats quite a bit the material in the previous section. = Maybe some of the text related to HITs in the previous section could be = removed and discussed only here. This document extends [RFC5201] with measures to support crypto agility. s/extends [RFC5201]/extends the original, experimental HIP specification = [RFC5201]/ or "HIP v1" or something. 3.2. Generating a HIT from an HI The HIT MUST be generated according to the ORCHID generation method described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA Should one say something about the byte order of the value? 4.1. Creating a HIP Association By definition, the system initiating a HIP exchange is the Initiator, and the peer is the Responder. This distinction is forgotten once the base exchange completes, and either party can become the Initiator in future communications. Would one call a host making a HIP transaction (say, UPDATE) during an = active HIP association an Initiator? The text seems to imply that, but = at least I would not have used that term in that case.=20 Also, there are cases where one may need to remember the distinction = after the BEX (e.g., with NAT traversal the Initiator becomes the active = ICE agent; and I vaguely remember discussing some time ago some other = use case too..), so I would say, e.g., that the "distinction is = typically forgotten [...]". The R2 packet acknowledges the receipt of the I2 packet and completes the base exchange. The packet is signed by the Responder. s/The packet/The R2 packet/ The base exchange is illustrated below The figure should be numbered (,center-aligned), and referenced with the = number. Bit surprisingly, none of the figures in the draft are numbered. 4.1.1. HIP Puzzle Mechanism The puzzle mechanism has been explicitly designed to give space for various implementation options. First, it allows a Responder implementation to completely delay session-specific state creation until a valid I2 packet is received. In such a case, a correctly formatted I2 packet can be rejected immediately once the Responder has checked its validity by computing only one hash function. Why is a correctly formatted I2 rejected? Because of incorrect solution? Second, the design also allows a Responder implementation to keep state about received I1 packets, and match the received I2 packets against the state, thereby allowing the implementation to avoid the computational cost of the hash function.=20 It's not clear what this means (how one avoids the cost by matching). 4.1.2. Puzzle Exchange [...] the Receiver can verify that it has itself sent the I to the s/Receiver/Responder/ NOTE: The protocol developers explicitly considered whether a memory bound function should be used for the puzzle instead of a CPU-bound function. The decision was not to use memory-bound functions. A few words of rationale for not using memory-bound functions would be = nice. 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation However, since it is precomputed and therefore does not cover association-specific information in the I1 packet [...] s/it is/the signature is/ or /the R1 is/ ? The Initiator continues the BEX only if the Group ID of the public DH value of the Responder intersects the preferences of both Initiator and Responder.=20 s/intersects the preferences of/is the most preferred of the IDs = supported by/ Otherwise, the communication is subject of a downgrade attack and the Initiator MUST either restart the key exchange with a new I1 packet or abort the key exchange. s/key exchange/base exchange/g The signature of the I2 message covers all signed parameters of the packet without exceptions as in the R1. Saying "all signed parameters are signed" sounds a bit redundant. And = what would be an exception to this rule? 4.1.4. HIP Replay Protection The scope of the counter MAY be system-wide but SHOULD be applied per Host Identity, if there is more than one local host identity. What "applied per Host Identity" means is not clear. Could be "every HI = must have its own counter" or "every HI must use the same counter and = increase it at every usage". Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. Could give some recommendation on how many earlier generations SHOULD be = accepted (otherwise one may conclude that any earlier is always OK). When sending multiple I1 packets, an Initiator SHOULD wait for a small amount of time (a reasonable time may be 2 * expected RTT) after the first R1 reception to allow possibly multiple R1s to arrive s/multiple I1 packets/multiple I1 packets to the same host/ 4.1.5. Refusing a HIP Exchange A HIP-aware host may choose not to accept a HIP exchange. If the host's policy is to only be an Initiator, it should begin its own HIP exchange. A host MAY choose to have such a policy since only the privacy of the Initiator's HI is protected in the exchange. It should be noted that such behavior can introduce the risk of a race condition if each host's policy is to only be an Initiator, at which point the HIP exchange will fail. s/HIP Exchange/HIP Base Exchange/g (title and text) -- unless this = applies to some other exchanges too? Same with Section 4.1.6. Also, should there be some mechanism to detect and prevent the race = situation continuing forever? 4.1.7. HIP Downgrade Protection In a downgrade attack, an attacker manipulates the packets of an Initiator and/or a Responder to unnoticeably influence the result of the cryptographic negotiations in the BEX to its favor. s/an attacker manipulates/an attacker attempts to unnoticeably = manipulate/ (and remove the 2nd unnoticeably) In contrast to the first version of HIP [RFC5201], this version begins the negotiation of the DH Groups already in the first BEX packet, the I1. s/this version/the version 2 of HIP defined in this document/ If the choice of the DH Group in the R1 packet does not equal to the best match of the two lists (the highest priority of the Responder that is present in the Initiator's DH list),=20 s/highest priority/highest priority DH ID/ 4.1.8. HIP Opportunistic Mode Since the Responder's HIT Suite is not determined by the destination HIT of the I1 packet, the Responder can freely select a HIT of any HIT Suite. s/is not determined/in the opportunistic mode is not determined/ the Initiator MAY restart the BEX with an I1 packet with a source HIT that is contained in the list of the Responder's HIT Suites in the R1 packet. s/is contained in/is compatible with one of the Suite IDs in/ 4.4.3. HIP State Processes | Receive I2, process | If successful, send R2 and go to R2-SENT | What does "process" mean here? (same in the other tables) Should that be = "receive and process"? And what is the difference compared to triggers = without "process" (e.g., with receiving I1s and in Table 6)? | Receive ANYOTHER | Drop and stay at UNASSOCIATED | "ANYOTHER" is not defined. Could just say "Receive something else" or = define ANYOTHER somewhere (say, change 4.4.1 into "State Machine = Terminology" and have ANYOTHER there). Table 3 (I1-SENT) | Receive I1 | If the local HIT is smaller than the peer | | | HIT, drop I1 and stay at I1-SENT | s/Receive I1/Receive I1 from the peer/ Or maybe could explain before the table that "Receive X" means here = receiving from a peer one is setting up a HIP SA with -- or does it? Could also add a reference to the Section 6.5 on how to compare HITs Table 5: R2-SENT - Waiting to finish HIP and Table 6: ESTABLISHED - HIP association established What to do if some other HIP message arrives? Probably with message = types not specified in this document that's extension-specific, but = could mention it somewhere here. Also, Table 5 doesn't have CLOSE_ACK. Table 7: CLOSING - HIP association has not been used for UAL minutes | Timeout, increment | If timeout sum is less than UAL+MSL | | timeout sum, reset | minutes, retransmit CLOSE and stay at | | timer | CLOSING | This trigger's definition is not particularly clear. 4.5.1. TCP and UDP Pseudo-Header Computation for User Data When computing TCP and UDP checksums on user data packets that flow through sockets bound to HITs, the IPv6 pseudo-header format [RFC2460] MUST be used, even if the actual addresses on the packet are IPv4 addresses. s/on the packet/on the IP header of the packet/ 4.5.2. Sending Data on HIP Packets A future version of this document may define how to include user data in various HIP packets. However, currently the HIP header is a terminal header, and not followed by any other headers. Do we plan to do this in a future version of *this* document or would = that be better left for some other document? 4.6. Certificate Distribution This document does not define how to use certificates or how to transfer them between hosts. These functions are expected to be defined in a future specification. Informational reference to the CERT draft could be appropriate. I'll send additional nits off-list. Cheers, Ari= From Internet-Drafts@ietf.org Fri Jan 28 00:15:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C766028C0ED; Fri, 28 Jan 2011 00:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ+UTfy6kduA; Fri, 28 Jan 2011 00:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A633A6AAA; Fri, 28 Jan 2011 00:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128081501.31888.98742.idtracker@localhost> Date: Fri, 28 Jan 2011 00:15:01 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-nat-traversal-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 08:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Author(s) : A. Keranen, J. Melen Filename : draft-ietf-hip-native-nat-traversal-01.txt Pages : 15 Date : 2011-01-28 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-nat-traversal-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-native-nat-traversal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28000921.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Fri Jan 28 00:20:51 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2853A6947 for ; Fri, 28 Jan 2011 00:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 D3ZFct9YZhlG for ; Fri, 28 Jan 2011 00:20:48 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 9C6B828C0F0 for ; Fri, 28 Jan 2011 00:20:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E5ADC4E6D7 for ; Fri, 28 Jan 2011 10:23:51 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PBpj2c2l5CA for ; Fri, 28 Jan 2011 10:23:51 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4179E4E6CF for ; Fri, 28 Jan 2011 10:23:51 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <20110128081501.31888.98742.idtracker@localhost> Date: Fri, 28 Jan 2011 10:23:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <228F6774-DFB7-4318-8C66-C789C2841964@nomadiclab.com> References: <20110128081501.31888.98742.idtracker@localhost> To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-native-nat-traversal-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 08:20:51 -0000 Hi all, This update changes the intended status of the draft from Experimental = to Standards Track and references the bis-versions of the base drafts = instead of the experimental ones. Also, we added a note about the fact = that HIP v2 should be used instead of v1 and made a few editorial fixes. Cheers, Ari On Jan 28, 2011, at 10:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Host Identity Protocol Working Group = of the IETF. >=20 >=20 > Title : Native NAT Traversal Mode for the Host = Identity Protocol > Author(s) : A. Keranen, J. Melen > Filename : draft-ietf-hip-native-nat-traversal-01.txt > Pages : 15 > Date : 2011-01-28 >=20 > 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. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-hip-native-nat-traversal-01= .txt >=20 From gonzalo.camarillo@ericsson.com Fri Jan 28 06:26:21 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2201E3A68C9 for ; Fri, 28 Jan 2011 06:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.613 X-Spam-Level: X-Spam-Status: No, score=-106.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 FHd3bLxon3-D for ; Fri, 28 Jan 2011 06:26:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3E1B33A689B for ; Fri, 28 Jan 2011 06:26:18 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-16-4d42d2c39509 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.5E.13987.3C2D24D4; Fri, 28 Jan 2011 15:29:23 +0100 (CET) Received: from [131.160.126.194] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 28 Jan 2011 15:29:23 +0100 Message-ID: <4D42D2C2.4030000@ericsson.com> Date: Fri, 28 Jan 2011 16:29:22 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Fwd: Last Call: (Socket Application Program Interface (API) for Multihoming Shim) to Informational RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:26:21 -0000 Folks, FYI: the IETF LC on the draft below has just started. Note that our native API draft depends on this one. Cheers, Gonzalo -------- Original Message -------- Subject: Last Call: (Socket Application Program Interface (API) for Multihoming Shim) to Informational RFC Date: Thu, 27 Jan 2011 17:37:53 +0100 From: The IESG To: IETF-Announce CC: shim6@ietf.org The IESG has received a request from the Site Multihoming by IPv6 Intermediation WG (shim6) to consider the following document: - 'Socket Application Program Interface (API) for Multihoming Shim' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-shim6-multihome-shim-api/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-shim6-multihome-shim-api/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce