From gonzalo.camarillo@ericsson.com Sat May 1 00:12:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11F83A68AF for ; Sat, 1 May 2010 00:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.366 X-Spam-Level: X-Spam-Status: No, score=-103.366 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, 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 J56znD5+HJhf for ; Sat, 1 May 2010 00:12:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 38AEE3A6783 for ; Sat, 1 May 2010 00:12:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-3b-4bdbd44d60b3 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.63.08537.D44DBDB4; Sat, 1 May 2010 09:12:13 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 09:11:29 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 09:11:28 +0200 Received: from [131.160.126.240] (rvi2-126-240.lmf.ericsson.se [131.160.126.240]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 49A28254A; Sat, 1 May 2010 10:11:28 +0300 (EEST) Message-ID: <4BDBD41E.5030107@ericsson.com> Date: Sat, 01 May 2010 10:11:26 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------070608010204080102010801" X-OriginalArrivalTime: 01 May 2010 07:11:28.0971 (UTC) FILETIME=[850779B0:01CAE8FD] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] New HIP WG charter proposal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 07:12:31 -0000 This is a multi-part message in MIME format. --------------070608010204080102010801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, as you know, we need to recharter the WG in order to move our specs to the standards track. I have put together a charter proposal (see attachment). Please, let me know if you have any comments on it. I have used a less aggressive time frame than what was presented in in Anaheim: http://www.ietf.org/proceedings/10mar/slides/hip-1/hip-1_files/v3_document.htm Also, I think we have enough on our plate for now. We can add the HIP proxy and Diet HIP exchange work to our charter when we finish the first RFCs we will be working on. Cheers, Gonzalo HIP co-chair --------------070608010204080102010801 Content-Type: text/plain; name="HIP Charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="HIP Charter.txt" HIP WG's Charter Description of Working Group The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Originally, the HIP WG was chartered to produce Experimental RFCs. However, even though the WG produced Experimental RFCs, it was understood that their quality and security properties had to match the standards track requirements. The main reason for producing Experimental documents instead of standards track ones was the unknown effects that the mechanisms may have had on applications and on the Internet at large. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. At this point, HIP is considered to be mature enough to be specified in standards track RFCs. This WG will produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, and 5206 as standards track RFCs. 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. Goals and Milestones Done First version of the HIP basic mobility and multi-homing mechanism specification. Done First version of the HIP DNS resource record(s) specification. Done First version of the HIP basic rendezvous mechanism specification. Done WGLC on the HIP architecture specification Done Submit the HIP architecture specification to the IESG Done WG LC on the base protocol specification Done WG LC on the ESP usage specification Done WGLC the HIP registration extensions specification Done WGLC the HIP DNS resource record(s) specification Done WG LC on the basic HIP rendezvous mechanism specification. Done Submit the ESP usage specification to the IESG for Experimental Done Submit the base protocol specification to the IESG for Experimental Done WG LC on the HIP basic mobility and multi-homing specification. Done Submit the HIP registration extensions specification for Experimental Done Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Done Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Done Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Done WGLC Legacy Application Interworking specification Done Submit the Legacy Application Interworking specification to the IESG Done WGLC Legacy NAT traversal specification Done WGLC Native API specification Done Submit the Legacy NAT traversal specification to the IESG Done Submit Native API specification to the IESG Done WGLC Framework for HIP overlays specification Done WGLC Multi-hop routing mechanism for HIP Done WGLC Upper-layer data transport in HIP Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2010 Submit RFC5203bis to the IESG Jan 2010 Submit RFC5204bis to the IESG Jan 2010 Submit RFC5205bis to the IESG Jan 2010 Submit the mobility portion of RFC5206bis to the IESG Feb 2010 WGLC RFCxxxxbis (NAT traversal) Feb 2010 WGLC the multihoming portion of RFC5206bis Mar 2010 Submit RFCxxxxbis (NAT traversal) to the IESG Mar 2010 Submit the multihoming portion of RFC5206bis to the IESG Apr 2010 Recharter or close the WG --------------070608010204080102010801-- From gonzalo.camarillo@ericsson.com Sat May 1 00:26:08 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B2F3A6AA1 for ; Sat, 1 May 2010 00:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.667 X-Spam-Level: X-Spam-Status: No, score=-104.667 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, 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 HHpAwrGbvII5 for ; Sat, 1 May 2010 00:26:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 88DC33A6A7C for ; Sat, 1 May 2010 00:26:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-0f-4bdbd77f8d69 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 77.C3.08537.F77DBDB4; Sat, 1 May 2010 09:25:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 09:24:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 May 2010 09:24:37 +0200 Received: from [131.160.126.240] (rvi2-126-240.lmf.ericsson.se [131.160.126.240]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6444B254A for ; Sat, 1 May 2010 10:24:37 +0300 (EEST) Message-ID: <4BDBD735.7050402@ericsson.com> Date: Sat, 01 May 2010 10:24:37 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP References: <4BDBD41E.5030107@ericsson.com> In-Reply-To: <4BDBD41E.5030107@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------080001030408090506090201" X-OriginalArrivalTime: 01 May 2010 07:24:37.0784 (UTC) FILETIME=[5B32C980:01CAE8FF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] New HIP WG charter proposal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 07:26:08 -0000 This is a multi-part message in MIME format. --------------080001030408090506090201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I have updated the charter with the RFC number of the NAT traversal spec. Cheers, Gonzalo On 01/05/2010 10:11 AM, Gonzalo Camarillo wrote: > Hi, > > as you know, we need to recharter the WG in order to move our specs to > the standards track. I have put together a charter proposal (see > attachment). Please, let me know if you have any comments on it. > > I have used a less aggressive time frame than what was presented in in > Anaheim: > > http://www.ietf.org/proceedings/10mar/slides/hip-1/hip-1_files/v3_document.htm > > Also, I think we have enough on our plate for now. We can add the HIP > proxy and Diet HIP exchange work to our charter when we finish the first > RFCs we will be working on. > > Cheers, > > Gonzalo > HIP co-chair > --------------080001030408090506090201 Content-Type: text/plain; name="HIP Charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="HIP Charter.txt" HIP WG's Charter Description of Working Group The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Originally, the HIP WG was chartered to produce Experimental RFCs. However, even though the WG produced Experimental RFCs, it was understood that their quality and security properties had to match the standards track requirements. The main reason for producing Experimental documents instead of standards track ones was the unknown effects that the mechanisms may have had on applications and on the Internet at large. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. At this point, HIP is considered to be mature enough to be specified in standards track RFCs. This WG will produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. 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. Goals and Milestones Done First version of the HIP basic mobility and multi-homing mechanism specification. Done First version of the HIP DNS resource record(s) specification. Done First version of the HIP basic rendezvous mechanism specification. Done WGLC on the HIP architecture specification Done Submit the HIP architecture specification to the IESG Done WG LC on the base protocol specification Done WG LC on the ESP usage specification Done WGLC the HIP registration extensions specification Done WGLC the HIP DNS resource record(s) specification Done WG LC on the basic HIP rendezvous mechanism specification. Done Submit the ESP usage specification to the IESG for Experimental Done Submit the base protocol specification to the IESG for Experimental Done WG LC on the HIP basic mobility and multi-homing specification. Done Submit the HIP registration extensions specification for Experimental Done Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Done Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Done Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Done WGLC Legacy Application Interworking specification Done Submit the Legacy Application Interworking specification to the IESG Done WGLC Legacy NAT traversal specification Done WGLC Native API specification Done Submit the Legacy NAT traversal specification to the IESG Done Submit Native API specification to the IESG Done WGLC Framework for HIP overlays specification Done WGLC Multi-hop routing mechanism for HIP Done WGLC Upper-layer data transport in HIP Done Submit Framework for HIP overlays specification to the IESG Done Submit Multi-hop routing mechanism for HIP Done Submit Upper-layer data transport in HIP to the IESG Sep 2010 WGLC Certs in HIP base exchange specification Sep 2010 WGLC RFC4423bis Sep 2010 WGLC RFC4843bis Sep 2010 WGLC RFC5201bis Sep 2010 WGLC RFC5202bis Oct 2010 Submit Certs in HIP base exchange specification to the IESG Oct 2010 Submit RFC4423bis to the IESG Oct 2010 Submit RFC4843bis to the IESG Oct 2010 Submit RFC5201bis to the IESG Oct 2010 Submit RFC5202bis to the IESG Dec 2010 WGLC RFC5203bis Dec 2010 WGLC RFC5204bis Dec 2010 WGLC RFC5205bis Dec 2010 WGLC the mobility portion of RFC5206bis Jan 2010 Submit RFC5203bis to the IESG Jan 2010 Submit RFC5204bis to the IESG Jan 2010 Submit RFC5205bis to the IESG Jan 2010 Submit the mobility portion of RFC5206bis to the IESG Feb 2010 WGLC RFC5770bis Feb 2010 WGLC the multihoming portion of RFC5206bis Mar 2010 Submit RFC5770bis to the IESG Mar 2010 Submit the multihoming portion of RFC5206bis to the IESG Apr 2010 Recharter or close the WG --------------080001030408090506090201-- From samu.varjonen@hiit.fi Mon May 3 00:45:00 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFF93A696E for ; Mon, 3 May 2010 00:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPc8f911-5zl for ; Mon, 3 May 2010 00:44:59 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 8D67B3A67B6 for ; Mon, 3 May 2010 00:44:59 -0700 (PDT) Received: from [128.214.191.139] (dhcp-eduroam-10.mobile.helsinki.fi [128.214.191.139]) by argo.otaverkko.fi (Postfix) with ESMTP id 9DC8A25ED11; Mon, 3 May 2010 10:44:43 +0300 (EEST) Message-ID: <4BDE7EEB.6080103@hiit.fi> Date: Mon, 03 May 2010 10:44:43 +0300 From: Samu Varjonen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Mattes, David" References: <20100428084501.795053A6869@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 07:45:00 -0000 Hi, Sorry for the delayed answer. Comments inline. Mattes, David wrote: > Hi Tobias and Samu, > > Thank you for this work! > > Some comments: > Section 2, last paragraph, 2nd sentence: s/LDAP URL/DN/ OK > > Section 3, paragraph 1: I don't agree that HITs need to be enclosed within X.509 certificates. Many users will not have control over the Certificate Issuing Authorities, or even if they do have that control, will be unable to specify inclusion of the HIT in the certificate. Furthermore, the issuer may not be involved in HIP communications at all! I think it is a mistake to require _any_ HIP details to be present in a certificate used for HIP communications, nor do I see why it is necessary. Yes, we agree that HITs are not always needed or even possible for the user to add to the certificates. The text should be lessened to say something along the lines of "if HITs are needed in the certificates this is how you use them" > > Section 3, can we add another example that describes a managed PKI environment? If you agree with my comment about HITs in the certificate, I will write up an example for this case. > This is one of the remaining items on the todo list and we would appreciate your contribution. > Regards, > David Mattes > > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, April 28, 2010 1:45 AM > To: i-d-announce@ietf.org > Cc: hipsec@ietf.org > Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > > Title : HIP Certificates > Author(s) : T. Heer, S. Varjonen > Filename : draft-ietf-hip-cert-03.txt > Pages : 10 > Date : 2010-04-28 > > This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for > X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in HIP control packets. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and in SPKI certificates. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From gonzalo.camarillo@ericsson.com Mon May 3 02:48:15 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBC828C0F5 for ; Mon, 3 May 2010 02:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.207 X-Spam-Level: X-Spam-Status: No, score=-104.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_50=0.001, 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 AIWp4wLW1hIw for ; Mon, 3 May 2010 02:48:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0D17628C0F1 for ; Mon, 3 May 2010 02:48:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-1f-4bde9bc896cd Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.20.08537.8CB9EDB4; Mon, 3 May 2010 11:47:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 11:47:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 11:47:51 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 72B99249B for ; Mon, 3 May 2010 12:47:51 +0300 (EEST) Message-ID: <4BDE9BC7.5090201@ericsson.com> Date: Mon, 03 May 2010 12:47:51 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP References: <4BCDA1BC.1020701@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> In-Reply-To: <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2010 09:47:51.0527 (UTC) FILETIME=[B24B6770:01CAEAA5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] NAT traversal and the standards track work X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 09:48:15 -0000 Folks, it seems we have consensus on including the mobility and multihoming extensions in the scope of our new to-be-chartered NAT traversal effort. With respect to whether we want to go native or still use the STUN-based connectivity checks, it would be good to have more discussions on the list. Thanks, Gonzalo On 26/04/2010 1:06 PM, Tobias Heer wrote: > > Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R: > >> >> >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org >>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>> Sent: Tuesday, April 20, 2010 5:45 AM >>> To: HIP >>> Subject: [Hipsec] NAT traversal and the standards track work >>> >>> Hi, >>> >>> we need to decide what to do with NAT traversal when moving to the >>> standards track. We have the following drafts: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>> >>> The draft above will soon become an Experimental RFC. >>> >>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >>> traversal/ >>> >>> The draft above proposes implementing HIP-based connectivity checks >>> instead of STUN-based ones. >>> >>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>> >>> The draft above, which needs to be revised, describes the mobility and >>> multihoming extensions for NAT traversal. >>> >>> I would like to hear people's views on what to do here. >>> >> >> Gonzalo, I would like to see both topics (NAT traversal, and mobility management aspects of NAT traversal) on the revised charter, as the second phase of standards-track work, as we discussed in Anaheim. I am neutral on the questions of which one of the two drafts to adopt (if a choice needs to be made now) and on whether the nat-mm draft should remain separate or should be combined into one NAT traversal draft. >> > I share Tom's opinion here. I would like to see both progress (provided there is enough manpower to support both). However, I think it might be useful to address mobility in the actual NAT documents since it poses special challenges that are special to NATs. > > Tobias > >> - Tom >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > > > > -- > > Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > > > > > > > > From alberty.2004@gmail.com Tue May 4 01:06:29 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064F93A68DB for ; Tue, 4 May 2010 01:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1bTuJehprvp for ; Tue, 4 May 2010 01:06:28 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 10EEB3A68B1 for ; Tue, 4 May 2010 01:06:27 -0700 (PDT) Received: by ywh3 with SMTP id 3so1575459ywh.31 for ; Tue, 04 May 2010 01:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=mDarBZllxJGguul2rjjVDk57BtrmdGhsEIR0oQBWIuw=; b=cPCCG43nMhYoZuDddq5CgLJAhnstZEfBMUvaU0GAKi0fXiHq8r7DkNSNyUlkXWiauO ZYK56AflpWjcrDKgKMuAR/O6cp3rMq7d9YN5ZQAXmCY4BtJ6E4gwojvQznof8Y/l606I ECte+0WkVwyy19hCkB6JhPoXsvBISDHN1QlLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Ucj2X1P3evmGmMkTJoNAsB2k8xvUNj29qRtZIWEhoDvPJMktE+xy1Hmufl0fmzv+gC JJGdD7uobWPcmaBWU37TkgxeLVLfHzKAgk4Oww/H+IEgsp6yH2MudlVYzNjl3D/ejCGi WFjLdMedGpZqaJH5irWyvbBRwtF7VtC9W+g2M= MIME-Version: 1.0 Received: by 10.151.19.22 with SMTP id w22mr11502273ybi.349.1272960371070; Tue, 04 May 2010 01:06:11 -0700 (PDT) Received: by 10.150.96.2 with HTTP; Tue, 4 May 2010 01:06:10 -0700 (PDT) Date: Tue, 4 May 2010 16:06:10 +0800 Message-ID: From: TAO YUAN To: hipsec@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Hipsec] HIP host multihoming questions 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, 04 May 2010 08:06:29 -0000 Hi, all I have some questions about HIP host multihoming. Consider a scenario described below: Host A is a multihomed HIP host, which using address IP1 on iterface_1 to communicate with host B. For fault-tolerant or maybe some other purposes, A decides to inform B about its another address IP2 on interface_2. According to rfc5206, it is a 3-way update process. After this, a new pair of SA is created between A and B. We assumed A needs to switch its communication with B from interface_1 to interface_2.This may caused by the breakdown of interface_1's connected link or upper applications' requirements for better performance. Host A initiates another 3-way update process, which aims at informing B to send packets to A's interface_2 instead of interface_1. If not doing this, B may still send packet to interface_1, since it always regards IP1 as the preferred address until receives A's notification. More explicitly, B won't send packet to interface_2 until it is aware of the disconnection of current link due to transport layer mechanism. The latency could be very large. Is this means for an interface switching, host A needs to initiate the 3-way update process twice? Host A uses the first one to create a new SA, and the second one to notify B about interface switching. And if so, why can't we let host A initiate only one update process after its interface switching to create a new SA and notify the preferred address, which just like the normal mobility event? It looks like more reasonable, and initiate update process twice is wasteful. It is no doubt that host B knows several available addresses of host A is useful. These addresses can be used for load sharing or fault-tolerant. As described above, it seems like current HIP multihoming solution fails to handle this flexible. If a interface/address switching mechanism is adopted, the switching can be more efficient. Does anyone know if there are solutions related to HIP multihomed host=92s interface/address switching except rfc5206? Thanks~ Albert From erik.nordmark@oracle.com Tue May 4 02:16:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDAB3A69A2 for ; Tue, 4 May 2010 02:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYBu-55dNz2K for ; Tue, 4 May 2010 02:16:15 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7667B3A676A for ; Tue, 4 May 2010 02:16:11 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o449Fqwc021139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 May 2010 09:15:53 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43KwJE8020757; Tue, 4 May 2010 09:15:51 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 212235231272964549; Tue, 04 May 2010 02:15:49 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 02:15:49 -0700 Message-ID: <4BDFE5B7.3020500@oracle.com> Date: Tue, 04 May 2010 02:15:35 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BDBD41E.5030107@ericsson.com> In-Reply-To: <4BDBD41E.5030107@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090202.4BDFE5CA.008B:SCFMA4539811,ss=1,fgs=0 Cc: HIP Subject: Re: [Hipsec] New HIP WG charter proposal 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, 04 May 2010 09:16:16 -0000 On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote: > Hi, > > as you know, we need to recharter the WG in order to move our specs to > the standards track. I have put together a charter proposal (see > attachment). Please, let me know if you have any comments on it. What is the current state of handling applications that do referrals with HIP? Last time I looked there wasn't any useful support for this. I think preserving that part of the Internet architecture is important in whatever we put on the standards track. Erik From miika.komu@hiit.fi Tue May 4 02:42:53 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AA73A6AAA for ; Tue, 4 May 2010 02:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXZRiAJXliLt for ; Tue, 4 May 2010 02:42:52 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id E06E73A6A3A for ; Tue, 4 May 2010 02:42:33 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1O9Edu-0007Be-Eu for hipsec@ietf.org; Tue, 04 May 2010 12:42:18 +0300 Message-ID: <4BDFEC09.1020308@hiit.fi> Date: Tue, 04 May 2010 12:42:33 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com> In-Reply-To: <4BDFE5B7.3020500@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] New HIP WG charter proposal X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 09:42:53 -0000 On 04/05/10 12:15, Erik Nordmark wrote: Hi, > On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote: >> Hi, >> >> as you know, we need to recharter the WG in order to move our specs to >> the standards track. I have put together a charter proposal (see >> attachment). Please, let me know if you have any comments on it. > > What is the current state of handling applications that do referrals > with HIP? Last time I looked there wasn't any useful support for this. > > I think preserving that part of the Internet architecture is important > in whatever we put on the standards track. HIP as an experiment has been a success and we want it to proceed to the standards track. So, would it make sense to discuss about HIT prefix delegation in DNS? There is is already some small-scale experience on this. From rgm@htt-consult.com Tue May 4 06:48:28 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6790A3A692E for ; Tue, 4 May 2010 06:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug0i255E26P7 for ; Tue, 4 May 2010 06:48:27 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 908AD3A6A70 for ; Tue, 4 May 2010 06:48:26 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C6BC66829C; Tue, 4 May 2010 13:41:57 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGpQn8vr5jLL; Tue, 4 May 2010 09:41:48 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3413568A8C; Tue, 4 May 2010 09:41:44 -0400 (EDT) Message-ID: <4BE02580.8060808@htt-consult.com> Date: Tue, 04 May 2010 09:47:44 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Erik Nordmark References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com> In-Reply-To: <4BDFE5B7.3020500@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] New HIP WG charter proposal 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, 04 May 2010 13:48:28 -0000 On 05/04/2010 05:15 AM, Erik Nordmark wrote: > On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote: >> Hi, >> >> as you know, we need to recharter the WG in order to move our specs to >> the standards track. I have put together a charter proposal (see >> attachment). Please, let me know if you have any comments on it. > > What is the current state of handling applications that do referrals > with HIP? Last time I looked there wasn't any useful support for this. Here is pretty much what we have learned over the past many years... If the referral is an IP address the following MAY occur: If the app just issues an http:/// the HIP shim MAY perform an opportunistic HIP BEX and if successful proceed with the connection over HIP. If opportunistic failed or was not configured, then the connection will occur "open". That is without HIP. If the app issues a reverse lookup on and retrieves a DNS HI record, then again, HIP would be used for the connection. If the referral is a HIT, then the HIP shim would need some mechanism to perform the HIT to IP lookup. One would have to ASSuME that since a HIT was provided in a referral that a lookup mechanism was provided by the server and hopefully the client will use the 'right one'. One possiblity is DHT. Another is DNS. DNS reverse lookups of HITs is a problem, as they are flat within the ORCHID prefix (well flat within the new concept of HIT suites). This is where Hierarchical HITs MAY be of value. So the short answer is: referrals work if the referral is an IP address. referrals MAY work if the referral is a HIT. > > I think preserving that part of the Internet architecture is important > in whatever we put on the standards track. We all think this and see regular cases where things work only sometimes. I feel that in HIP we have found that it makes more things work (like IPv4 dumb apps running over IPv6 networks) than it makes things hard. Perhaps the abouve discussion can be captured in one of the HIP documents if it is already not there. From jan.melen@nomadiclab.com Tue May 4 07:01:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05193A6C2C for ; Tue, 4 May 2010 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez2m8EecQrbE for ; Tue, 4 May 2010 07:01:05 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id D43C13A67EC for ; Tue, 4 May 2010 07:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 607794E6CF; Tue, 4 May 2010 17:00:35 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMZqtffdL+SZ; Tue, 4 May 2010 17:00:34 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 09C014E67D; Tue, 4 May 2010 17:00:34 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id C8FCE10709C; Tue, 4 May 2010 17:00:33 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 92DFD107022; Tue, 4 May 2010 17:00:33 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jan Melen In-Reply-To: <4BDE9BC7.5090201@ericsson.com> Date: Tue, 4 May 2010 17:00:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9322D096-2889-4001-B091-47FE5EDD4B3D@nomadiclab.com> References: <4BCDA1BC.1020701@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> <4BDE9BC7.5090201@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP Subject: Re: [Hipsec] NAT traversal and the standards track work X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 14:01:07 -0000 Hi 1) I agree that the mobility and multihoming should be included in to = the new scope. 2) STUN vs. Native! My opinion is that we should go for native as it = reduces the implementation complexity quite a bit and there is not that = much as is re-usable components in ICE/STUN. Regards, Jan On May 3, 2010, at 12:47 PM, Gonzalo Camarillo wrote: > Folks, >=20 > it seems we have consensus on including the mobility and multihoming > extensions in the scope of our new to-be-chartered NAT traversal = effort. >=20 > With respect to whether we want to go native or still use the = STUN-based > connectivity checks, it would be good to have more discussions on the = list. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 26/04/2010 1:06 PM, Tobias Heer wrote: >>=20 >> Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: hipsec-bounces@ietf.org >>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Tuesday, April 20, 2010 5:45 AM >>>> To: HIP >>>> Subject: [Hipsec] NAT traversal and the standards track work >>>>=20 >>>> Hi, >>>>=20 >>>> we need to decide what to do with NAT traversal when moving to the >>>> standards track. We have the following drafts: >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>>>=20 >>>> The draft above will soon become an Experimental RFC. >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >>>> traversal/ >>>>=20 >>>> The draft above proposes implementing HIP-based connectivity checks >>>> instead of STUN-based ones. >>>>=20 >>>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>>>=20 >>>> The draft above, which needs to be revised, describes the mobility = and >>>> multihoming extensions for NAT traversal. >>>>=20 >>>> I would like to hear people's views on what to do here. >>>>=20 >>>=20 >>> Gonzalo, I would like to see both topics (NAT traversal, and = mobility management aspects of NAT traversal) on the revised charter, as = the second phase of standards-track work, as we discussed in Anaheim. I = am neutral on the questions of which one of the two drafts to adopt (if = a choice needs to be made now) and on whether the nat-mm draft should = remain separate or should be combined into one NAT traversal draft. >>>=20 >> I share Tom's opinion here. I would like to see both progress = (provided there is enough manpower to support both). However, I think it = might be useful to address mobility in the actual NAT documents since it = poses special challenges that are special to NATs.=20 >>=20 >> Tobias >>=20 >>> - Tom >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>=20 >>=20 >>=20 >>=20 >> -- =20 >>=20 >> Dipl.-Inform. Tobias Heer, Ph.D. Student >> Distributed Systems Group=20 >> RWTH Aachen University, Germany >> tel: +49 241 80 207 76 >> web: http://ds.cs.rwth-aachen.de/members/heer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From ari.keranen@nomadiclab.com Tue May 4 08:47:24 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0423A6C82 for ; Tue, 4 May 2010 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHqIh7zU-+Ex for ; Tue, 4 May 2010 08:47:21 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 629F828C12F for ; Tue, 4 May 2010 08:47:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A04CD4E6CF; Tue, 4 May 2010 18:46:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd1BDPEFs63S; Tue, 4 May 2010 18:46:56 +0300 (EEST) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6B5224E67D; Tue, 4 May 2010 18:46:56 +0300 (EEST) Message-ID: <4BE04170.8080401@nomadiclab.com> Date: Tue, 04 May 2010 18:46:56 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BCDA1BC.1020701@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> <4BDE9BC7.5090201@ericsson.com> In-Reply-To: <4BDE9BC7.5090201@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] NAT traversal and the standards track work X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 15:47:24 -0000 On 05/03/2010 12:47 PM, Gonzalo Camarillo wrote: > Folks, > > it seems we have consensus on including the mobility and multihoming > extensions in the scope of our new to-be-chartered NAT traversal > effort. > > With respect to whether we want to go native or still use the > STUN-based connectivity checks, it would be good to have more > discussions on the list. I think the best way forward would be to use native HIP messages for the standards track specification and the native NAT traversal mode draft should be a suitable basis for the work. Our implementation experience and the benefits of the native mode (implementation effort, demuxing issues, etc.) were discussed at the last WG meeting and also on other threads on this list. After the discussions there have been no objections on, and quite a few of us feel strongly, that the native mode is a better idea. Or would someone still disagree on this? I don't have a strong opinion on whether the mobility and multihoming with NAT traversal should be a separate document, but I think it is important that also this work gets done. If someone can devote enough quality cycles on this, a separate document could have more background and intro text explaining the different mm-scenarios and thus be useful. Otherwise we can have a shorter version as a part of the native mode draft. Cheers, Ari > On 26/04/2010 1:06 PM, Tobias Heer wrote: >> Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R: >> >>> >>>> -----Original Message----- From: hipsec-bounces@ietf.org >>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Tuesday, April 20, 2010 5:45 AM To: HIP Subject: >>>> [Hipsec] NAT traversal and the standards track work >>>> >>>> Hi, >>>> >>>> we need to decide what to do with NAT traversal when moving to >>>> the standards track. We have the following drafts: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>>> >>>> The draft above will soon become an Experimental RFC. >>>> >>>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >>>> traversal/ >>>> >>>> The draft above proposes implementing HIP-based connectivity >>>> checks instead of STUN-based ones. >>>> >>>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>>> >>>> >>>> The draft above, which needs to be revised, describes the >>>> mobility and multihoming extensions for NAT traversal. >>>> >>>> I would like to hear people's views on what to do here. >>>> >>> Gonzalo, I would like to see both topics (NAT traversal, and >>> mobility management aspects of NAT traversal) on the revised >>> charter, as the second phase of standards-track work, as we >>> discussed in Anaheim. I am neutral on the questions of which one >>> of the two drafts to adopt (if a choice needs to be made now) and >>> on whether the nat-mm draft should remain separate or should be >>> combined into one NAT traversal draft. >>> >> I share Tom's opinion here. I would like to see both progress >> (provided there is enough manpower to support both). However, I >> think it might be useful to address mobility in the actual NAT >> documents since it poses special challenges that are special to >> NATs. >> >> Tobias >> >>> - Tom _ From thomas.r.henderson@boeing.com Tue May 4 20:08:26 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B573A693A for ; Tue, 4 May 2010 20:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkStp5v191G7 for ; Tue, 4 May 2010 20:08:23 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C82AD3A68C3 for ; Tue, 4 May 2010 20:08:23 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o45386Ic009972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 May 2010 22:08:07 -0500 (CDT) 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 o453862l011360; Tue, 4 May 2010 20:08:06 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o45386Xd011347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 4 May 2010 20:08:06 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 4 May 2010 20:08:06 -0700 From: "Henderson, Thomas R" To: "'TAO YUAN'" , "hipsec@ietf.org" Date: Tue, 4 May 2010 20:08:04 -0700 Thread-Topic: [Hipsec] HIP host multihoming questions Thread-Index: AcrrYK2l480IGtV5Roq2JJZdAFOZPwAnTgXQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE97160F2@XCH-NW-10V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] HIP host multihoming questions 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, 05 May 2010 03:08:26 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of TAO YUAN > Sent: Tuesday, May 04, 2010 1:06 AM > To: hipsec@ietf.org > Subject: [Hipsec] HIP host multihoming questions > > Hi, all > > I have some questions about HIP host multihoming. > > Consider a scenario described below: > > Host A is a multihomed HIP host, which using address IP1 on iterface_1 > to communicate with host B. For fault-tolerant or maybe some other > purposes, A decides to inform B about its another address IP2 on > interface_2. > According to rfc5206, it is a 3-way update process. After this, a new > pair of SA is created between A and B. We assumed A needs to switch > its communication with B from interface_1 to interface_2.This may > caused by the breakdown of interface_1's connected link or upper > applications' requirements for better performance. Host A initiates > another 3-way update process, which aims at informing B to send > packets to A's interface_2 instead of interface_1. If not doing this, > B may still send packet to interface_1, since it always regards IP1 as > the preferred address until receives A's notification. More > explicitly, B won't send packet to interface_2 until it is aware of > the disconnection of current link due to transport layer mechanism. > The latency could be very large. > > Is this means for an interface switching, host A needs to initiate the > 3-way update process twice? Host A uses the first one to create a new > SA, and the second one to notify B about interface switching. And if > so, why can't we let host A initiate only one update process after its > interface switching to create a new SA and notify the preferred > address, which just like the normal mobility event? It looks like more > reasonable, and initiate update process twice is wasteful. I believe that what you are suggesting would be appropriate in this case. = The current spec is written such that these SAs are made before being put i= nto service, which requires the three-way handshake. However, I am not sur= e that the second update (A to tell B to use interface_2's address as a pre= ferred address) would be a three way handshake, since no address verificati= on needs to take place (if there is already an SA set up to that interface)= . Instead, it may just be a two-way handshake. But I agree with you that it may be better in some cases to just have a sin= gle three-way handshake when an address needs to be put into service. It m= ay also be the case that a host's other (non-preferred) addresses can be ad= vertised during the base exchange and not require the separate three-way ha= ndshake. > > It is no doubt that host B knows several available addresses of host A > is useful. These addresses can be used for load sharing or > fault-tolerant. As described above, it seems like current HIP > multihoming solution fails to handle this flexible. If a > interface/address switching mechanism is adopted, the switching can be > more efficient. We discussed the future of multihoming at the Anaheim meeting. As you obs= erved, multihoming is somewhat underspecified in RFC 5206. We agreed to fo= cus the revision of RFC 5206 on mobility, and again leave a more detailed m= ultihoming specification as a second phase work effort. There was also se= ntiment expressed that the current suggestion in RFC 5206 to proactively se= t up all pairs of SAs between all addresses is excessive. > Does anyone know if there are solutions related to HIP > multihomed host's interface/address switching except rfc5206? > It has been discussed in the past that the shim6 failure detection and loca= tor selection protocol (RFC 5534) could be applied to HIP multihoming use c= ases. Also, the shim6 API document relates to HIP multihoming: http://too= ls.ietf.org/html/draft-ietf-shim6-multihome-shim-api-13 Also, Mika Kousa and Baris Boyvat's theses discuss multihoming: http://infrahip.hiit.fi/index.php?index=3Dpublications - Tom From jan.melen@nomadiclab.com Wed May 5 09:29:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17733A682E for ; Wed, 5 May 2010 09:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhcShtxwoF-N for ; Wed, 5 May 2010 09:29:24 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id C0A823A67B7 for ; Wed, 5 May 2010 09:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id EB1E44E6DE; Wed, 5 May 2010 19:29:06 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnlpKe932Hdu; Wed, 5 May 2010 19:29:05 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 9BED44E6D5; Wed, 5 May 2010 19:29:05 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id 6812510709C; Wed, 5 May 2010 19:29:05 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id C544E107022; Wed, 5 May 2010 19:28:58 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jan Melen In-Reply-To: <4BE02580.8060808@htt-consult.com> Date: Wed, 5 May 2010 19:28:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5E24EE17-E367-4CA9-9453-EF3DFF264DFD@nomadiclab.com> References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com> <4BE02580.8060808@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP Subject: Re: [Hipsec] New HIP WG charter proposal 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, 05 May 2010 16:29:32 -0000 Hi, To me the new charter looks good. For referrals I don't see any big = problems as mentioned already by Miika and Bob we have gained quite a = bit experience on how much of an problem the referrals are and according = to that experience there is only very few cases where they cannot be = made to work, in all other cases the referrals can be resolved through = mechanisms described by Bob. Of course these are issues that need to be documented in architecture = and DNS documents Regards, Jan On May 4, 2010, at 4:47 PM, Robert Moskowitz wrote: > On 05/04/2010 05:15 AM, Erik Nordmark wrote: >> On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote: >>> Hi, >>>=20 >>> as you know, we need to recharter the WG in order to move our specs = to >>> the standards track. I have put together a charter proposal (see >>> attachment). Please, let me know if you have any comments on it. >>=20 >> What is the current state of handling applications that do referrals = with HIP? Last time I looked there wasn't any useful support for this. >=20 > Here is pretty much what we have learned over the past many years... >=20 > If the referral is an IP address the following MAY occur: >=20 > If the app just issues an http:/// the HIP shim MAY = perform an opportunistic HIP BEX and if successful proceed with the = connection over HIP. If opportunistic failed or was not configured, then = the connection will occur "open". That is without HIP. >=20 > If the app issues a reverse lookup on and retrieves a DNS HI = record, then again, HIP would be used for the connection. >=20 > If the referral is a HIT, then the HIP shim would need some mechanism = to perform the HIT to IP lookup. One would have to ASSuME that since a = HIT was provided in a referral that a lookup mechanism was provided by = the server and hopefully the client will use the 'right one'. One = possiblity is DHT. Another is DNS. DNS reverse lookups of HITs is a = problem, as they are flat within the ORCHID prefix (well flat within the = new concept of HIT suites). This is where Hierarchical HITs MAY be of = value. >=20 > So the short answer is: referrals work if the referral is an IP = address. referrals MAY work if the referral is a HIT. >=20 >>=20 >> I think preserving that part of the Internet architecture is = important in whatever we put on the standards track. >=20 > We all think this and see regular cases where things work only = sometimes. I feel that in HIP we have found that it makes more things = work (like IPv4 dumb apps running over IPv6 networks) than it makes = things hard. >=20 > Perhaps the abouve discussion can be captured in one of the HIP = documents if it is already not there. >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From david.mattes@boeing.com Wed May 5 14:36:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7493A6D1A for ; Wed, 5 May 2010 14:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kevUJwoMm0R for ; Wed, 5 May 2010 14:36:15 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id ADA493A68EB for ; Wed, 5 May 2010 14:36:11 -0700 (PDT) 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 o45LZbm0011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 May 2010 14:35:44 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o45LZaaw005377; Wed, 5 May 2010 16:35:36 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o45LZa0e005335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 5 May 2010 16:35:36 -0500 (CDT) Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 5 May 2010 14:35:35 -0700 From: "Mattes, David" To: Samu Varjonen Date: Wed, 5 May 2010 14:35:34 -0700 Thread-Topic: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Thread-Index: AcrqlIKCqOyyaqnoTN6fwJpux7lMhgCBhLNw Message-ID: References: <20100428084501.795053A6869@core3.amsl.com> <4BDE7EEB.6080103@hiit.fi> In-Reply-To: <4BDE7EEB.6080103@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 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 21:36:16 -0000 > > Section 3, can we add another example that describes a managed PKI > environment? If you agree with my comment about HITs in the > certificate, I will write up an example for this case. > > >=20 > This is one of the remaining items on the todo list and we would > appreciate your > contribution. >=20 Here is proposed text for Section 3 and Section 4: 3. X.509.v3 Certificate Object and Host Identities When using X.509.v3 certificates to transmit information related to HIP hosts, HITs may be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In X.509.v3 HITs are represented as issuer and subject alternative name extensions as defined in [RFC2459]. If only HIP information is presented as either the issuer or the subject the HIT is also placed into the respective entity's DNs Common Name (CN) section in a colon delimited presentation format. Inclusion of CN is not necessary if DN contains any other information. It is RECOMMENDED to use FQDN/NAI from the hosts HOST_ID parameter in DN if one exists. Full HIs are presented in the public key entries of X.509.v3 certificates. As an example, in a case where the issuer and the subject are both HIP enabled, the HITs are expressed as follows: Format: Issuer: CN=3Dhit-of-host Subject: CN=3Dhit-of-host X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:HIT-OF-HOST X509v3 Subject Alternative Name: IP Address:HIT-OF-HOST Example: Issuer: CN=3D2001:14:6cf:fae7:bb79:bf78:7d64:c056 Subject: CN=3D2001:14:6cf:fae7:bb79:bf78:7d64:c056 X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 X509v3 Subject Alternative Name: IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 Appendix B shows a full example X.509.v3 certificate with HIP content. As another example, consider a managed PKI environment in which the peers have certificates that are anchored in (potentially different) managed trust chains. In this scenario, the certificates issued to HIP hosts are signed by intermediate Certificate Authorities (CAs) up to a root CA. In this example, the managed PKI environment is neither HIP aware, nor can it be configured to compute HITs and include them in the certificates. In this scenario, it is recommended that the HIP peers have and use some mechanism of defining trusted root CAs for the purpose of establishing HIP communications. Furthermore it is recommended that the HIP peers have and use some mechanism of checking peer certificate validity for revocation, signature, minimum cryptographic strength, etc., up to the trusted root CA. When HIP communications are established, the HIP hosts not only need to send their identity certificates (or pointers to their certificates), but also the chain of intermediate CAs (or pointers to the CAs) up to the root CA, or to a CA that is trusted by the remote peer. This chain of certificates must be sent in a Cert group as specified in Section 2. The HIP peers validate each other's Certificates and compute peer HITs based on the Certificate public keys.=20 4. SPKI Cert Object and Host Identities When using SPKI certificates to transmit information related to HIP hosts, HITs need to be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In the following we define the representation of those identifiers for SPKI given as S-expressions. Note that the S-expressions are only the human- readable representation of SPKI certificates. Full HIs are presented in the public key sequences of SPKI certificates. As an example the Host Identity Tag of a host is expressed as follows: Format: (hash hit hit-of-host) Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) Appendix A shows a full example SPKI certificate with HIP content. From alberty.2004@gmail.com Thu May 6 00:55:33 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829DD3A6A60 for ; Thu, 6 May 2010 00:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_44=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 HBC4OyaDh13k for ; Thu, 6 May 2010 00:55:32 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 1794C3A68DC for ; Thu, 6 May 2010 00:55:31 -0700 (PDT) Received: by gxk9 with SMTP id 9so2612505gxk.8 for ; Thu, 06 May 2010 00:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y7MLY3Kc/i6h4g5HzqfIZiusu8EiR0rSQ+f0+YXGIAg=; b=dAz+XPIsbSochIM2r91mn+6hsK6/MS4XGMh4Zrh9r6wYoFcJV4Il098Kz+i5bwSIVe vAXm6D9a9Ra8t6qPkVyTIZFoK894JuSH4HalI15/eTgJJmTok7mDbHjZfsvX3Og4d1dq UvRBvGiKdaN+4Vs2FpvzOlkJZ7NNJ283ECfRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KOWAovJPCUq5emGTel2d8nTvOUDCKOhulDzwmmvO4IBxufPf2CMQCPKystEEAHsc37 QZZ0L+sfvRwx5RLeVQOEKeHy0jWqskzyY8Y7a8OJI3r908hb+s3PmVUjyzi+7KrWAjV1 1yqSeHuDTMBlD36zDKR6YnBfcSqRTVpwO7mgk= MIME-Version: 1.0 Received: by 10.150.59.19 with SMTP id h19mr901408yba.61.1273132514587; Thu, 06 May 2010 00:55:14 -0700 (PDT) Received: by 10.150.96.2 with HTTP; Thu, 6 May 2010 00:55:14 -0700 (PDT) In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE97160F2@XCH-NW-10V.nw.nos.boeing.com> References: <7CC566635CFE364D87DC5803D4712A6C4CE97160F2@XCH-NW-10V.nw.nos.boeing.com> Date: Thu, 6 May 2010 15:55:14 +0800 Message-ID: From: TAO YUAN To: "Henderson, Thomas R" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] HIP host multihoming questions 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, 06 May 2010 07:55:33 -0000 2010/5/5 Henderson, Thomas R : > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of TAO YUAN >> Sent: Tuesday, May 04, 2010 1:06 AM >> To: hipsec@ietf.org >> Subject: [Hipsec] HIP host multihoming questions >> >> Hi, all >> >> I have some questions about HIP host multihoming. >> >> Consider a scenario described below: >> >> Host A is a multihomed HIP host, which using address IP1 on iterface_1 >> to communicate with host B. For fault-tolerant or maybe some other >> purposes, A decides to inform B about its another address IP2 on >> interface_2. >> According to rfc5206, it is a 3-way update process. After this, a new >> pair of SA is created between A and B. We assumed A needs to switch >> its communication with B from interface_1 to interface_2.This may >> caused by the breakdown of interface_1's connected link or upper >> applications' requirements for better performance. Host A initiates >> another 3-way update process, which aims at informing B to send >> packets to A's interface_2 instead of interface_1. If not doing this, >> B may still send packet to interface_1, since it always regards IP1 as >> the preferred address until receives A's notification. More >> explicitly, B won't send packet to interface_2 until it is aware of >> the disconnection of current link due to transport layer mechanism. >> The latency could be very large. >> >> Is this means for an interface switching, host A needs to initiate the >> 3-way update process twice? Host A uses the first one to create a new >> SA, and the second one to notify B about interface switching. And if >> so, why can't we let host A initiate only one update process after its >> interface switching to create a new SA and notify the preferred >> address, which just like the normal mobility event? It looks like more >> reasonable, and initiate update process twice is wasteful. > > I believe that what you are suggesting would be appropriate in this case.= =A0The current spec is written such that these SAs are made before being p= ut into service, which requires the three-way handshake. =A0However, I am n= ot sure that the second update (A to tell B to use interface_2's address as= a preferred address) would be a three way handshake, since no address veri= fication needs to take place (if there is already an SA set up to that inte= rface). =A0Instead, it may just be a two-way handshake. > > But I agree with you that it may be better in some cases to just have a s= ingle three-way handshake when an address needs to be put into service. =A0= It may also be the case that a host's other (non-preferred) addresses can b= e advertised during the base exchange and not require the separate three-wa= y handshake. > A host can send multiple ESP_INFO and multiple LOCATOR parameters during the base exchange to advertise its non-preferred addresses. But this would not reduce the numbers of messages largely, since address verification still needs to take place for each address separately.It only changes the timing of sending. I think the primary problem here is not how A tell B about its available addresses, but how can A and B use these address after the initialization phase. >> >> It is no doubt that host B knows several available addresses of host A >> is useful. These addresses can be used for load sharing or >> fault-tolerant. As described above, it seems like current HIP >> multihoming solution fails to handle this flexible. If a >> interface/address switching mechanism is adopted, the switching can be >> more efficient. > > We discussed the future of multihoming at the Anaheim meeting. =A0 As you= observed, multihoming is somewhat underspecified in RFC 5206. =A0We agreed= to focus the revision of RFC 5206 on mobility, and again leave a more deta= iled multihoming specification as a second phase work effort. There was als= o sentiment expressed that the current suggestion in RFC 5206 to proactivel= y set up all pairs of SAs between all addresses is excessive. > >> Does anyone know if there are solutions related to HIP >> multihomed host's interface/address switching except rfc5206? >> > It has been discussed in the past that the shim6 failure detection and lo= cator selection protocol (RFC 5534) could be applied to HIP multihoming use= cases. =A0Also, the shim6 API document relates to HIP multihoming: =A0http= ://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-13 > > Also, Mika Kousa and Baris Boyvat's theses discuss multihoming: > http://infrahip.hiit.fi/index.php?index=3Dpublications > > - Tom > Yes, it is really wasteful to set up all pairs of SAs proactively if they can not be used,such as in interface switching scenario. Add some features of RFC 5534 in is a good idea~ Thank you for your reply From heer@informatik.rwth-aachen.de Fri May 7 01:56:27 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03203A63EC for ; Fri, 7 May 2010 01:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3Yqp8mA7ijy for ; Fri, 7 May 2010 01:56:25 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id E8CA53A6AF5 for ; Fri, 7 May 2010 01:56:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L210049EKTD48G0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 07 May 2010 10:56:01 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,347,1270418400"; d="scan'208";a="29964130" 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; Fri, 07 May 2010 10:56:02 +0200 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L21005Z7KTDN500@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 07 May 2010 10:56:01 +0200 (CEST) From: Tobias Heer In-reply-to: <5E24EE17-E367-4CA9-9453-EF3DFF264DFD@nomadiclab.com> Date: Fri, 07 May 2010 10:57:06 +0200 Message-id: <8F0B7D94-14FC-4F80-B02B-8150BCF561B1@cs.rwth-aachen.de> References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com> <4BE02580.8060808@htt-consult.com> <5E24EE17-E367-4CA9-9453-EF3DFF264DFD@nomadiclab.com> To: Jan Melen X-Mailer: Apple Mail (2.1077) Cc: HIP Subject: Re: [Hipsec] New HIP WG charter proposal 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, 07 May 2010 08:56:27 -0000 Hi, Am 05.05.2010 um 18:28 schrieb Jan Melen: > Hi, > > To me the new charter looks good. For referrals I don't see any big problems as mentioned already by Miika and Bob we have gained quite a bit experience on how much of an problem the referrals are and according to that experience there is only very few cases where they cannot be made to work, in all other cases the referrals can be resolved through mechanisms described by Bob. I would like to stress that crypto agility might add some more spice to the referral issue because it may lead to transitivity problems caused by namespace fragmentation. Therefore, it is necessary to keep the number of different HIT types (i.e., signature and hash algorithms) really small and the support for the algorithms broad. Otherwise, referrals will require more sophisticated mechanisms like certificates that bind different HITs together. BR, Tobias > > Of course these are issues that need to be documented in architecture and DNS documents > > Regards, > Jan > > On May 4, 2010, at 4:47 PM, Robert Moskowitz wrote: > >> On 05/04/2010 05:15 AM, Erik Nordmark wrote: >>> On 05/ 1/10 12:11 AM, Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> as you know, we need to recharter the WG in order to move our specs to >>>> the standards track. I have put together a charter proposal (see >>>> attachment). Please, let me know if you have any comments on it. >>> >>> What is the current state of handling applications that do referrals with HIP? Last time I looked there wasn't any useful support for this. >> >> Here is pretty much what we have learned over the past many years... >> >> If the referral is an IP address the following MAY occur: >> >> If the app just issues an http:/// the HIP shim MAY perform an opportunistic HIP BEX and if successful proceed with the connection over HIP. If opportunistic failed or was not configured, then the connection will occur "open". That is without HIP. >> >> If the app issues a reverse lookup on and retrieves a DNS HI record, then again, HIP would be used for the connection. >> >> If the referral is a HIT, then the HIP shim would need some mechanism to perform the HIT to IP lookup. One would have to ASSuME that since a HIT was provided in a referral that a lookup mechanism was provided by the server and hopefully the client will use the 'right one'. One possiblity is DHT. Another is DNS. DNS reverse lookups of HITs is a problem, as they are flat within the ORCHID prefix (well flat within the new concept of HIT suites). This is where Hierarchical HITs MAY be of value. >> >> So the short answer is: referrals work if the referral is an IP address. referrals MAY work if the referral is a HIT. >> >>> >>> I think preserving that part of the Internet architecture is important in whatever we put on the standards track. >> >> We all think this and see regular cases where things work only sometimes. I feel that in HIP we have found that it makes more things work (like IPv4 dumb apps running over IPv6 networks) than it makes things hard. >> >> Perhaps the abouve discussion can be captured in one of the HIP documents if it is already not there. >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Mon May 10 05:58:58 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5763A68AF for ; Mon, 10 May 2010 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 zcEw02l6C7hA for ; Mon, 10 May 2010 05:58:57 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 5C3583A689A for ; Mon, 10 May 2010 05:58:57 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 19DA368B25 for ; Mon, 10 May 2010 12:52:21 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbbqbuCaamVT for ; Mon, 10 May 2010 08:52:12 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [12.173.204.197]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3724168B24 for ; Mon, 10 May 2010 08:52:12 -0400 (EDT) Message-ID: <4BE802F4.9070005@htt-consult.com> Date: Mon, 10 May 2010 08:58:28 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 12:58:58 -0000 If no one can provide a compelling argument for the NULL cipher for HIP_TRANSFORM, I am pulling it. Of course it makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM. The only argument I have come up with is for testing the HIP encryption process; but that seems very weak. So if no one speaks up, it will be pulled from 5201-bis. From heer@informatik.rwth-aachen.de Mon May 10 06:03:11 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6103A68D1 for ; Mon, 10 May 2010 06:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1ll5FZL1NK8 for ; Mon, 10 May 2010 06:03:08 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id B24423A6927 for ; Mon, 10 May 2010 06:03:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L2700JXRG8SGWG0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 10 May 2010 15:02:52 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,362,1270418400"; d="scan'208";a="30124480" 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, 10 May 2010 15:02:51 +0200 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L27002QCG8RAZ80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 10 May 2010 15:02:52 +0200 (CEST) From: Tobias Heer In-reply-to: <4BE802F4.9070005@htt-consult.com> Date: Mon, 10 May 2010 15:02:51 +0200 Message-id: References: <4BE802F4.9070005@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: HIP WG Subject: Re: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 13:03:11 -0000 Hi, Am 10.05.2010 um 14:58 schrieb Robert Moskowitz: > If no one can provide a compelling argument for the NULL cipher for HIP_TRANSFORM, I am pulling it. Of course it makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM. The only argument I have come up with is for testing the HIP encryption process; but that seems very weak. I think it would only affect the HIP_ENCRYPTED part of the packet, right? This seems more like a debugging feature than something that we need in the protocol specs. I am fine with removing it. Tobias > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Mon May 10 06:08:40 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DB93A68A0 for ; Mon, 10 May 2010 06:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.21 X-Spam-Level: ** X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 CvdzAv4dx2JU for ; Mon, 10 May 2010 06:08:39 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id CC3D43A684D for ; Mon, 10 May 2010 06:08:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6CC2F68B25; Mon, 10 May 2010 13:02:04 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SJedu+pEApe; Mon, 10 May 2010 09:01:55 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [12.173.204.197]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 6AB2D68B24; Mon, 10 May 2010 09:01:55 -0400 (EDT) Message-ID: <4BE80540.9080501@htt-consult.com> Date: Mon, 10 May 2010 09:08:16 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BE802F4.9070005@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 13:08:40 -0000 On 05/10/2010 09:02 AM, Tobias Heer wrote: > Hi, > > Am 10.05.2010 um 14:58 schrieb Robert Moskowitz: > > >> If no one can provide a compelling argument for the NULL cipher for HIP_TRANSFORM, I am pulling it. Of course it makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM. The only argument I have come up with is for testing the HIP encryption process; but that seems very weak. >> > I think it would only affect the HIP_ENCRYPTED part of the packet, right? This seems more like a debugging feature than something that we need in the protocol specs. I am fine with removing it. > That is the only place I see it used. And I don't see that changing, perhaps more things in HIP_ENCRYPTED with plans for DIET HIP, but still only makes sense for testing. From jeffrey.m.ahrenholz@boeing.com Mon May 10 09:18:11 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CCD3A69E4 for ; Mon, 10 May 2010 09:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC+VI1phXxXe for ; Mon, 10 May 2010 09:18:03 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C49163A6A05 for ; Mon, 10 May 2010 09:17:39 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o4AGHIvZ000163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 May 2010 09:17:19 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o4AGHI3q025870; Mon, 10 May 2010 09:17:18 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o4AGHIf6025852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 10 May 2010 09:17:18 -0700 (PDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 10 May 2010 09:17:17 -0700 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" , Tobias Heer Date: Mon, 10 May 2010 09:17:17 -0700 Thread-Topic: [Hipsec] HIP_TRANSFORM and NULL Encryption Thread-Index: AcrwQeUhSf2PDT+MTKSLU4pWvWStCwAGcq5Q Message-ID: References: <4BE802F4.9070005@htt-consult.com> <4BE80540.9080501@htt-consult.com> In-Reply-To: <4BE80540.9080501@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP WG Subject: Re: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 16:18:11 -0000 > >> If no one can provide a compelling argument for the NULL=20 > cipher for HIP_TRANSFORM, I am pulling it. Of course it=20 > makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM. The=20 > only argument I have come up with is for testing the HIP=20 > encryption process; but that seems very weak. > >> =20 > > I think it would only affect the HIP_ENCRYPTED part of the=20 > packet, right? This seems more like a debugging feature than=20 > something that we need in the protocol specs. I am fine with=20 > removing it. > > =20 >=20 > That is the only place I see it used. And I don't see that changing,=20 > perhaps more things in HIP_ENCRYPTED with plans for DIET HIP,=20 > but still=20 > only makes sense for testing. Yes, using NULL as the HIP_TRANSFORM seems useful only for debugging. One e= xample use is for snooping the HIP_ENCRYPTED TLV using wireshark, so you ca= n tell that the host identity is properly wrapped and padded. Another examp= le would be testing crypto performance, you can use NULL as a baseline. -Jeff= From rgm@htt-consult.com Mon May 10 12:35:48 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC17F28C322 for ; Mon, 10 May 2010 12:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+GUeoKDb3XZ for ; Mon, 10 May 2010 12:35:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9796E28C2DE for ; Mon, 10 May 2010 12:22:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 22A9E68B28; Mon, 10 May 2010 19:16:03 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RYPxs6CiQFc; Mon, 10 May 2010 15:15:54 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 14C3F68A8D; Mon, 10 May 2010 15:15:54 -0400 (EDT) Message-ID: <4BE85CE7.8080603@htt-consult.com> Date: Mon, 10 May 2010 15:22:15 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4BE802F4.9070005@htt-consult.com> <4BE80540.9080501@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 19:35:49 -0000 On 05/10/2010 12:17 PM, Ahrenholz, Jeffrey M wrote: >>>> If no one can provide a compelling argument for the NULL >>>> >> cipher for HIP_TRANSFORM, I am pulling it. Of course it >> makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM. The >> only argument I have come up with is for testing the HIP >> encryption process; but that seems very weak. >> >>>> >>>> >>> I think it would only affect the HIP_ENCRYPTED part of the >>> >> packet, right? This seems more like a debugging feature than >> something that we need in the protocol specs. I am fine with >> removing it. >> >>> >>> >> That is the only place I see it used. And I don't see that changing, >> perhaps more things in HIP_ENCRYPTED with plans for DIET HIP, >> but still >> only makes sense for testing. >> > Yes, using NULL as the HIP_TRANSFORM seems useful only for debugging. One example use is for snooping the HIP_ENCRYPTED TLV using wireshark, so you can tell that the host identity is properly wrapped and padded. Another example would be testing crypto performance, you can use NULL as a baseline. > So you vote for leaving it in. But are you OK with removing it from MANDITORY to implement? From jeffrey.m.ahrenholz@boeing.com Mon May 10 12:57:56 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2964D3A6CB1 for ; Mon, 10 May 2010 12:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=0.813, 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 XCoeh8REaLkI for ; Mon, 10 May 2010 12:57:55 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id ABD2428C196 for ; Mon, 10 May 2010 12:46:03 -0700 (PDT) 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 o4AJjgfL018651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 May 2010 12:45:43 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o4AJjgUY023596; Mon, 10 May 2010 14:45:42 -0500 (CDT) 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 o4AJjfWX023544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 10 May 2010 14:45:42 -0500 (CDT) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Mon, 10 May 2010 12:45:41 -0700 From: "Ahrenholz, Jeffrey M" To: "'Robert Moskowitz'" Date: Mon, 10 May 2010 12:45:40 -0700 Thread-Topic: [Hipsec] HIP_TRANSFORM and NULL Encryption Thread-Index: AcrwdiIzUEKPwwR5SzeUnZwfZoMghwAAsJ6w Message-ID: References: <4BE802F4.9070005@htt-consult.com> <4BE80540.9080501@htt-consult.com> <4BE85CE7.8080603@htt-consult.com> In-Reply-To: <4BE85CE7.8080603@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP WG Subject: Re: [Hipsec] HIP_TRANSFORM and NULL Encryption 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, 10 May 2010 19:57:56 -0000 > > Yes, using NULL as the HIP_TRANSFORM seems useful only for=20 > debugging. One example use is for snooping the HIP_ENCRYPTED=20 > TLV using wireshark, so you can tell that the host identity=20 > is properly wrapped and padded. Another example would be=20 > testing crypto performance, you can use NULL as a baseline. > > =20 >=20 > So you vote for leaving it in. But are you OK with removing it from=20 > MANDITORY to implement? I think it's OK to remove, or yes just leave it as optional. When performin= g such tests you would probably carefully configure each side of the associ= ation to use NULL. -Jeff= From rgm@htt-consult.com Tue May 11 09:57:07 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF053A68AB for ; Tue, 11 May 2010 09:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qi+btScsGJ7 for ; Tue, 11 May 2010 09:57:07 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 938613A68DE for ; Tue, 11 May 2010 09:57:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1727F68B79 for ; Tue, 11 May 2010 16:50:27 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gve5iUX1myR for ; Tue, 11 May 2010 12:50:17 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 99CAE68B77 for ; Tue, 11 May 2010 12:50:17 -0400 (EDT) Message-ID: <4BE98C4A.1080805@htt-consult.com> Date: Tue, 11 May 2010 12:56:42 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP WG Content-Type: multipart/alternative; boundary="------------060506060908080108010704" Subject: [Hipsec] FWD: [Cfrg] HKDF paper 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 May 2010 16:57:08 -0000 This is a multi-part message in MIME format. --------------060506060908080108010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Frowarded from Hugo: ================================================================ In anticipation of the publication of HKDF as an RFC (which will happen very shortly) and of the publication of the HKDF paper in Crypto'2010 I finally updated the paper and posted it to the IACR eprint repository: The new title for the paper is "Cryptographic Extraction and Key Derivation: The HKDF Scheme", and its URL is http://eprint.iacr.org/2010/264 The paper is heavier on the technical side than a previous version (that I still keep under http://webee.technion.ac.il/~hugo/kdf/ for those less technically inclined). In particular, it answers requests for quantitative statements of security (answering, among others, good questions by David McGrew). There is an attempt in the paper to reflect many of the many-many discussions on this list regarding KDF security. I am sure that there will be more questions but the paper is too long already... Hopefully the combination of the RFC and the extensive rationale in the paper will encourage people to use this KDF. Hugo --------------060506060908080108010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Frowarded from Hugo:

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

In anticipation of the publication of HKDF as an RFC (which will happen very shortly) and of the publication of the HKDF paper in Crypto'2010 I finally updated the paper and posted it to the IACR eprint repository:

The new title for the paper is "Cryptographic Extraction and Key Derivation: The HKDF Scheme", and its URL is http://eprint.iacr.org/2010/264

The paper is heavier on the technical side than a previous version (that I still keep under http://webee.technion.ac.il/~hugo/kdf/ for those less technically inclined).
In particular, it answers requests for quantitative statements of security (answering, among others, good questions by David McGrew).

There is an attempt in the paper to reflect many of the many-many discussions on this list regarding KDF security. I am sure that there will be more questions but the paper is too long already...

Hopefully the combination of the RFC and the extensive rationale in the paper will encourage people to use this KDF.

Hugo

--------------060506060908080108010704-- From rgm@htt-consult.com Wed May 12 13:08:20 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC973A68E7 for ; Wed, 12 May 2010 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r0PUuoW5Yg4 for ; Wed, 12 May 2010 13:08:20 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DE2753A68AF for ; Wed, 12 May 2010 13:08:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2A13068D47 for ; Wed, 12 May 2010 20:01:35 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxN-dN6+4xU0 for ; Wed, 12 May 2010 16:01:26 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 259D468CA2 for ; Wed, 12 May 2010 16:01:26 -0400 (EDT) Message-ID: <4BEB0A99.6020309@htt-consult.com> Date: Wed, 12 May 2010 16:07:53 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Salt for KEYMAT 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 May 2010 20:08:21 -0000 In draft-krawczyk-hkdf-01.txt: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. Currently KEYMAT uses I & J which is 128 bits of nonce for the salt. This is better than nothing; the question is should I & J be increased in size (Tobias and I have discussed making them 128 bits each), add a nonce HIP parameter, or do something else? Actually for SHA-384 you would need even a larger salt, so what is the desire here? From heer@informatik.rwth-aachen.de Wed May 12 13:16:55 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F903A6937 for ; Wed, 12 May 2010 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I2CdhdLk0HV for ; Wed, 12 May 2010 13:16:53 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 6B92E3A691D for ; Wed, 12 May 2010 13:16:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L2B00HRLPNDQWA0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 12 May 2010 22:16:25 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,217,1272837600"; d="scan'208";a="30345019" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 12 May 2010 22:16:25 +0200 Received: from coyote.lan ([unknown] [80.200.151.23]) 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 <0L2B00KA2PNDFP80@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 12 May 2010 22:16:25 +0200 (CEST) From: Tobias Heer In-reply-to: <4BEB0A99.6020309@htt-consult.com> Date: Wed, 12 May 2010 22:16:23 +0200 Message-id: <4C1B4F99-6A17-4272-945A-8D9009A3CAD7@cs.rwth-aachen.de> References: <4BEB0A99.6020309@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1077) Cc: HIP WG Subject: Re: [Hipsec] Salt for KEYMAT 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 May 2010 20:16:55 -0000 Am 12.05.2010 um 22:07 schrieb Robert Moskowitz: > In draft-krawczyk-hkdf-01.txt: > > Ideally, the salt value is a random (or pseudorandom) string of the > length HashLen. Yet, even a salt value of less quality (shorter in > size or with limited entropy) may still make a significant > contribution to the security of the output keying material; designers > of applications are therefore encouraged to provide salt values to > HKDF if such values can be obtained by the application. > > Currently KEYMAT uses I & J which is 128 bits of nonce for the salt. This is better than nothing; the question is should I & J be increased in size (Tobias and I have discussed making them 128 bits each), add a nonce HIP parameter, or do something else? Actually for SHA-384 you would need even a larger salt, so what is the desire here? > We had discussed making the salt size (wherever it comes from) depend on the HIT_SUITE. This doesn't work perfectly because the cipher for esp also depends on the shared secret and it is independent from the HIT. Making the dependency work in the other direction (salt length depends on esp suite) isn't correct either. Making it the maximum of both could work but it would be slightly more complicated. BR, Tobias > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Wed May 12 13:27:54 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F4D3A68F5 for ; Wed, 12 May 2010 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd0GUQPij58w for ; Wed, 12 May 2010 13:27:53 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 73B4B3A6957 for ; Wed, 12 May 2010 13:27:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2C59468CA2; Wed, 12 May 2010 20:21:12 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz-nd470a1JT; Wed, 12 May 2010 16:21:03 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F360E68D3E; Wed, 12 May 2010 16:21:02 -0400 (EDT) Message-ID: <4BEB0F32.2050901@htt-consult.com> Date: Wed, 12 May 2010 16:27:30 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BEB0A99.6020309@htt-consult.com> <4C1B4F99-6A17-4272-945A-8D9009A3CAD7@cs.rwth-aachen.de> In-Reply-To: <4C1B4F99-6A17-4272-945A-8D9009A3CAD7@cs.rwth-aachen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Salt for KEYMAT 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 May 2010 20:27:54 -0000 On 05/12/2010 04:16 PM, Tobias Heer wrote: > Am 12.05.2010 um 22:07 schrieb Robert Moskowitz: > > >> In draft-krawczyk-hkdf-01.txt: >> >> Ideally, the salt value is a random (or pseudorandom) string of the >> length HashLen. Yet, even a salt value of less quality (shorter in >> size or with limited entropy) may still make a significant >> contribution to the security of the output keying material; designers >> of applications are therefore encouraged to provide salt values to >> HKDF if such values can be obtained by the application. >> >> Currently KEYMAT uses I& J which is 128 bits of nonce for the salt. This is better than nothing; the question is should I& J be increased in size (Tobias and I have discussed making them 128 bits each), add a nonce HIP parameter, or do something else? Actually for SHA-384 you would need even a larger salt, so what is the desire here? >> >> > We had discussed making the salt size (wherever it comes from) depend on the HIT_SUITE. This doesn't work perfectly because the cipher for esp also depends on the shared secret and it is independent from the HIT. Making the dependency work in the other direction (salt length depends on esp suite) isn't correct either. Making it the maximum of both could work but it would be slightly more complicated. Actually the salt size seems to only be linked to the hash used. Currently for HIP that is SHA-1, SHA-256, or SHA-384. This places a salt size recommendation of 160, 256, or 384 bits respectively regardless of the key sizes pulled out of the Expand phase. So tying this to the HIT_SUITE makes sense as this is where the hash used within HIP is specified. Just what do we do, make I & J sizes vary with the hash or add a HIP parameter to get the additional bits. Note that making I & J bigger should NOT impact puzzle calculation. That is determined by the hash used and the value of K. Or at least that is my reading of the puzzle mechanism; those that have actually coded it are welcomed to comment. From rgm@htt-consult.com Thu May 13 07:11:36 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345BA3A6B3C for ; Thu, 13 May 2010 07:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxJ8bS3vCHjM for ; Thu, 13 May 2010 07:11:34 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6D7953A6B21 for ; Thu, 13 May 2010 07:11:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D857668B73 for ; Thu, 13 May 2010 14:04:44 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJMc47vzG7nN for ; Thu, 13 May 2010 10:04:35 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DAD8468B70 for ; Thu, 13 May 2010 10:04:35 -0400 (EDT) Message-ID: <4BEC0879.8030902@htt-consult.com> Date: Thu, 13 May 2010 10:11:05 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] The simplest password authentication for HIP 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, 13 May 2010 14:11:36 -0000 The scenario is a client needs access to a server when it is not already in the server's ACL and the server will ONLY accept ACL listed clients, but has a password available. An example is a grid substation controller as the server and a field engineer's tester as the client. In this example, the engineer would be able to pull the password for the server as part of the service call (as an example). In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password, then placed within the HIP ENCRYPT parameter. The advantages of this approach are: The server does not advertise in any manner that it accepts password authentication for clients. If a client is not in its ACL or does not provide the proper ENCRYPT parameter, the connection attempt is dropped. The password is never exposed to dictionary attack to silent listeners, as it is encrypted by the DH derived key. It is EXTREMELY lightweight, not expanding HIP exchange by more than a slightly larger ENCRYPT payload. The disadvantages of this approach are: The server has to go through most of the I2 processing to determine that this is a password-based authentication. Though perhaps if the client is NOT in its ACL it could process the ENCRYPT parameter before it checks HIP_MAC and HIP_SIGNATURE? New use for ECHO_REQUEST_SIGNED and content for ENCRYPT. I can't come up with much else on a down side :) From mkomu@cs.hut.fi Thu May 13 07:25:53 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7834F3A6B59 for ; Thu, 13 May 2010 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.113 X-Spam-Level: X-Spam-Status: No, score=-5.113 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8khHiwBrwZO for ; Thu, 13 May 2010 07:25:52 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id AA7A13A6B73 for ; Thu, 13 May 2010 07:25:25 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OCZLd-0001ow-VM for hipsec@ietf.org; Thu, 13 May 2010 17:25:14 +0300 Message-ID: <4BEC0BCB.2010606@cs.hut.fi> Date: Thu, 13 May 2010 17:25:15 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BEC0879.8030902@htt-consult.com> In-Reply-To: <4BEC0879.8030902@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] The simplest password authentication for HIP 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, 13 May 2010 14:25:53 -0000 On 13/05/10 17:11, Robert Moskowitz wrote: Hi, > The scenario is a client needs access to a server when it is not already > in the server's ACL and the server will ONLY accept ACL listed clients, > but has a password available. An example is a grid substation controller > as the server and a field engineer's tester as the client. In this > example, the engineer would be able to pull the password for the server > as part of the service call (as an example). > > In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password, > then placed within the HIP ENCRYPT parameter. > > The advantages of this approach are: > > The server does not advertise in any manner that it accepts password > authentication for clients. If a client is not in its ACL or does not > provide the proper ENCRYPT parameter, the connection attempt is dropped. > > The password is never exposed to dictionary attack to silent listeners, > as it is encrypted by the DH derived key. > > It is EXTREMELY lightweight, not expanding HIP exchange by more than a > slightly larger ENCRYPT payload. > > The disadvantages of this approach are: > > The server has to go through most of the I2 processing to determine that > this is a password-based authentication. Though perhaps if the client is > NOT in its ACL it could process the ENCRYPT parameter before it checks > HIP_MAC and HIP_SIGNATURE? > > New use for ECHO_REQUEST_SIGNED and content for ENCRYPT. > > I can't come up with much else on a down side :) what about sending a hash of the password (and using a salt like in UNIX passwords)? This should offer some protection against tainted servers and password reuse... Btw, Samu's related draft is available from here: http://tools.ietf.org/html/draft-varjonen-hip-eap-00 From rgm@htt-consult.com Thu May 13 07:25:56 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32CD3A6A70 for ; Thu, 13 May 2010 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0vB7IcK4jGS for ; Thu, 13 May 2010 07:25:55 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A0C943A6B40 for ; Thu, 13 May 2010 07:25:31 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1F25568B73; Thu, 13 May 2010 14:18:49 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u1q7rSAVhMO; Thu, 13 May 2010 10:18:39 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A457C68B53; Thu, 13 May 2010 10:18:39 -0400 (EDT) Message-ID: <4BEC0BC5.2080204@htt-consult.com> Date: Thu, 13 May 2010 10:25:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tobias Heer References: <4BEB0A99.6020309@htt-consult.com> <4C1B4F99-6A17-4272-945A-8D9009A3CAD7@cs.rwth-aachen.de> <4BEB0F32.2050901@htt-consult.com> In-Reply-To: <4BEB0F32.2050901@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Salt for KEYMAT 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, 13 May 2010 14:25:56 -0000 On 05/12/2010 04:27 PM, Robert Moskowitz wrote: > On 05/12/2010 04:16 PM, Tobias Heer wrote: >> Am 12.05.2010 um 22:07 schrieb Robert Moskowitz: >> >>> In draft-krawczyk-hkdf-01.txt: >>> >>> Ideally, the salt value is a random (or pseudorandom) string of the >>> length HashLen. Yet, even a salt value of less quality (shorter in >>> size or with limited entropy) may still make a significant >>> contribution to the security of the output keying material; designers >>> of applications are therefore encouraged to provide salt values to >>> HKDF if such values can be obtained by the application. >>> >>> Currently KEYMAT uses I& J which is 128 bits of nonce for the salt. >>> This is better than nothing; the question is should I& J be >>> increased in size (Tobias and I have discussed making them 128 bits >>> each), add a nonce HIP parameter, or do something else? Actually for >>> SHA-384 you would need even a larger salt, so what is the desire here? >>> >> We had discussed making the salt size (wherever it comes from) depend >> on the HIT_SUITE. This doesn't work perfectly because the cipher for >> esp also depends on the shared secret and it is independent from the >> HIT. Making the dependency work in the other direction (salt length >> depends on esp suite) isn't correct either. Making it the maximum of >> both could work but it would be slightly more complicated. > > Actually the salt size seems to only be linked to the hash used. > Currently for HIP that is SHA-1, SHA-256, or SHA-384. This places a > salt size recommendation of 160, 256, or 384 bits respectively > regardless of the key sizes pulled out of the Expand phase. So tying > this to the HIT_SUITE makes sense as this is where the hash used > within HIP is specified. Just what do we do, make I & J sizes vary > with the hash or add a HIP parameter to get the additional bits. > > Note that making I & J bigger should NOT impact puzzle calculation. > That is determined by the hash used and the value of K. Or at least > that is my reading of the puzzle mechanism; those that have actually > coded it are welcomed to comment. So what I am going with is that I & J are RHASH-len/2 bits long. This will be 80, 128, or 192 bits. K is still 8 bits, thus limiting the puzzle to a 64 bit proof at worst case. From rgm@htt-consult.com Thu May 13 08:42:37 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EEE3A6919 for ; Thu, 13 May 2010 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icigJKX8Jg3R for ; Thu, 13 May 2010 08:42:35 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A2A923A6B90 for ; Thu, 13 May 2010 08:42:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A839E68BE1; Thu, 13 May 2010 15:35:28 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaFZSqGV9J04; Thu, 13 May 2010 11:35:18 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 9BB9B68B70; Thu, 13 May 2010 11:35:18 -0400 (EDT) Message-ID: <4BEC1DBC.7030203@htt-consult.com> Date: Thu, 13 May 2010 11:41:48 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Miika Komu References: <4BEC0879.8030902@htt-consult.com> <4BEC0BCB.2010606@cs.hut.fi> In-Reply-To: <4BEC0BCB.2010606@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] The simplest password authentication for HIP 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, 13 May 2010 15:42:37 -0000 On 05/13/2010 10:25 AM, Miika Komu wrote: > On 13/05/10 17:11, Robert Moskowitz wrote: > > Hi, > >> The scenario is a client needs access to a server when it is not already >> in the server's ACL and the server will ONLY accept ACL listed clients, >> but has a password available. An example is a grid substation controller >> as the server and a field engineer's tester as the client. In this >> example, the engineer would be able to pull the password for the server >> as part of the service call (as an example). >> >> In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password, >> then placed within the HIP ENCRYPT parameter. >> >> The advantages of this approach are: >> >> The server does not advertise in any manner that it accepts password >> authentication for clients. If a client is not in its ACL or does not >> provide the proper ENCRYPT parameter, the connection attempt is dropped. >> >> The password is never exposed to dictionary attack to silent listeners, >> as it is encrypted by the DH derived key. >> >> It is EXTREMELY lightweight, not expanding HIP exchange by more than a >> slightly larger ENCRYPT payload. >> >> The disadvantages of this approach are: >> >> The server has to go through most of the I2 processing to determine that >> this is a password-based authentication. Though perhaps if the client is >> NOT in its ACL it could process the ENCRYPT parameter before it checks >> HIP_MAC and HIP_SIGNATURE? >> >> New use for ECHO_REQUEST_SIGNED and content for ENCRYPT. >> >> I can't come up with much else on a down side :) > > what about sending a hash of the password (and using a salt like in > UNIX passwords)? This should offer some protection against tainted > servers and password reuse... I wanted something a little bit more, plus protected from dictionary attack. > > Btw, Samu's related draft is available from here: > > http://tools.ietf.org/html/draft-varjonen-hip-eap-00 Yes, I have read it, but this less intrusive; better for small devices. From mkomu@cs.hut.fi Thu May 13 09:28:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557433A6954 for ; Thu, 13 May 2010 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in0tytnxQ4Nt for ; Thu, 13 May 2010 09:28:21 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id C9D013A6C5E for ; Thu, 13 May 2010 09:26:36 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OCbEu-00037K-Pk for hipsec@ietf.org; Thu, 13 May 2010 19:26:24 +0300 Message-ID: <4BEC2832.8050708@cs.hut.fi> Date: Thu, 13 May 2010 19:26:26 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BEC0879.8030902@htt-consult.com> <4BEC0BCB.2010606@cs.hut.fi> <4BEC1DBC.7030203@htt-consult.com> In-Reply-To: <4BEC1DBC.7030203@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] The simplest password authentication for HIP 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, 13 May 2010 16:28:22 -0000 On 13/05/10 18:41, Robert Moskowitz wrote: Hi Bob, > On 05/13/2010 10:25 AM, Miika Komu wrote: >> On 13/05/10 17:11, Robert Moskowitz wrote: >> >> Hi, >> >>> The scenario is a client needs access to a server when it is not already >>> in the server's ACL and the server will ONLY accept ACL listed clients, >>> but has a password available. An example is a grid substation controller >>> as the server and a field engineer's tester as the client. In this >>> example, the engineer would be able to pull the password for the server >>> as part of the service call (as an example). >>> >>> In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password, >>> then placed within the HIP ENCRYPT parameter. >>> >>> The advantages of this approach are: >>> >>> The server does not advertise in any manner that it accepts password >>> authentication for clients. If a client is not in its ACL or does not >>> provide the proper ENCRYPT parameter, the connection attempt is dropped. >>> >>> The password is never exposed to dictionary attack to silent listeners, >>> as it is encrypted by the DH derived key. >>> >>> It is EXTREMELY lightweight, not expanding HIP exchange by more than a >>> slightly larger ENCRYPT payload. >>> >>> The disadvantages of this approach are: >>> >>> The server has to go through most of the I2 processing to determine that >>> this is a password-based authentication. Though perhaps if the client is >>> NOT in its ACL it could process the ENCRYPT parameter before it checks >>> HIP_MAC and HIP_SIGNATURE? >>> >>> New use for ECHO_REQUEST_SIGNED and content for ENCRYPT. >>> >>> I can't come up with much else on a down side :) >> >> what about sending a hash of the password (and using a salt like in >> UNIX passwords)? This should offer some protection against tainted >> servers and password reuse... > > I wanted something a little bit more, plus protected from dictionary > attack. to be sure that we did not misunderstand each other, I basically agree with your idea but wanted to add something to it. Instead of having a plaintext password inside the encrypted parameter, I suggested hashing the password inside the encrypted parameter. A lot of people reuse the same password on different services. This way, an attacker that has successfully compromised one service cannot use the password to exploit other services. >> Btw, Samu's related draft is available from here: >> >> http://tools.ietf.org/html/draft-varjonen-hip-eap-00 > > Yes, I have read it, but this less intrusive; better for small devices. Your idea seems nice but should be an extension to RFC5201, right? From mkomu@cs.hut.fi Thu May 13 09:46:07 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47353A6C43 for ; Thu, 13 May 2010 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ooRk+HUnHp5 for ; Thu, 13 May 2010 09:46:06 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 68CF03A6C19 for ; Thu, 13 May 2010 09:46:06 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OCbXm-0003Hw-PS for hipsec@ietf.org; Thu, 13 May 2010 19:45:54 +0300 Message-ID: <4BEC2CC4.3040803@cs.hut.fi> Date: Thu, 13 May 2010 19:45:56 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4BEB0A99.6020309@htt-consult.com> <4C1B4F99-6A17-4272-945A-8D9009A3CAD7@cs.rwth-aachen.de> <4BEB0F32.2050901@htt-consult.com> In-Reply-To: <4BEB0F32.2050901@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Salt for KEYMAT 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, 13 May 2010 16:46:07 -0000 On 12/05/10 23:27, Robert Moskowitz wrote: Hi, > On 05/12/2010 04:16 PM, Tobias Heer wrote: >> Am 12.05.2010 um 22:07 schrieb Robert Moskowitz: >> >>> In draft-krawczyk-hkdf-01.txt: >>> >>> Ideally, the salt value is a random (or pseudorandom) string of the >>> length HashLen. Yet, even a salt value of less quality (shorter in >>> size or with limited entropy) may still make a significant >>> contribution to the security of the output keying material; designers >>> of applications are therefore encouraged to provide salt values to >>> HKDF if such values can be obtained by the application. >>> >>> Currently KEYMAT uses I& J which is 128 bits of nonce for the salt. >>> This is better than nothing; the question is should I& J be increased >>> in size (Tobias and I have discussed making them 128 bits each), add >>> a nonce HIP parameter, or do something else? Actually for SHA-384 you >>> would need even a larger salt, so what is the desire here? >>> >> We had discussed making the salt size (wherever it comes from) depend >> on the HIT_SUITE. This doesn't work perfectly because the cipher for >> esp also depends on the shared secret and it is independent from the >> HIT. Making the dependency work in the other direction (salt length >> depends on esp suite) isn't correct either. Making it the maximum of >> both could work but it would be slightly more complicated. > > Actually the salt size seems to only be linked to the hash used. > Currently for HIP that is SHA-1, SHA-256, or SHA-384. This places a salt > size recommendation of 160, 256, or 384 bits respectively regardless of > the key sizes pulled out of the Expand phase. So tying this to the > HIT_SUITE makes sense as this is where the hash used within HIP is > specified. Just what do we do, make I & J sizes vary with the hash or > add a HIP parameter to get the additional bits. > > Note that making I & J bigger should NOT impact puzzle calculation. That > is determined by the hash used and the value of K. Or at least that is > my reading of the puzzle mechanism; those that have actually coded it > are welcomed to comment. there seems to be a trade off between saving bits and trying to keep the puzzle computation clear. What about adding a varying length field "L" to the puzzle and say explicitly that it doesn't affect puzzle computation in any way? From rgm@htt-consult.com Thu May 13 10:15:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A77A3A6C92 for ; Thu, 13 May 2010 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ujj4eniZUjx for ; Thu, 13 May 2010 10:15:14 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id DD4F33A6C71 for ; Thu, 13 May 2010 10:14:21 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4397C68B78; Thu, 13 May 2010 17:07:32 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLC155v2fOIH; Thu, 13 May 2010 13:07:21 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id AD72D68B67; Thu, 13 May 2010 13:07:21 -0400 (EDT) Message-ID: <4BEC334F.3010705@htt-consult.com> Date: Thu, 13 May 2010 13:13:51 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Miika Komu References: <4BEC0879.8030902@htt-consult.com> <4BEC0BCB.2010606@cs.hut.fi> <4BEC1DBC.7030203@htt-consult.com> <4BEC2832.8050708@cs.hut.fi> In-Reply-To: <4BEC2832.8050708@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] The simplest password authentication for HIP 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, 13 May 2010 17:15:19 -0000 On 05/13/2010 12:26 PM, Miika Komu wrote: > On 13/05/10 18:41, Robert Moskowitz wrote: > > Hi Bob, > >> On 05/13/2010 10:25 AM, Miika Komu wrote: >>> On 13/05/10 17:11, Robert Moskowitz wrote: >>> >>> Hi, >>> >>>> The scenario is a client needs access to a server when it is not >>>> already >>>> in the server's ACL and the server will ONLY accept ACL listed >>>> clients, >>>> but has a password available. An example is a grid substation >>>> controller >>>> as the server and a field engineer's tester as the client. In this >>>> example, the engineer would be able to pull the password for the >>>> server >>>> as part of the service call (as an example). >>>> >>>> In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password, >>>> then placed within the HIP ENCRYPT parameter. >>>> >>>> The advantages of this approach are: >>>> >>>> The server does not advertise in any manner that it accepts password >>>> authentication for clients. If a client is not in its ACL or does not >>>> provide the proper ENCRYPT parameter, the connection attempt is >>>> dropped. >>>> >>>> The password is never exposed to dictionary attack to silent >>>> listeners, >>>> as it is encrypted by the DH derived key. >>>> >>>> It is EXTREMELY lightweight, not expanding HIP exchange by more than a >>>> slightly larger ENCRYPT payload. >>>> >>>> The disadvantages of this approach are: >>>> >>>> The server has to go through most of the I2 processing to determine >>>> that >>>> this is a password-based authentication. Though perhaps if the >>>> client is >>>> NOT in its ACL it could process the ENCRYPT parameter before it checks >>>> HIP_MAC and HIP_SIGNATURE? >>>> >>>> New use for ECHO_REQUEST_SIGNED and content for ENCRYPT. >>>> >>>> I can't come up with much else on a down side :) >>> >>> what about sending a hash of the password (and using a salt like in >>> UNIX passwords)? This should offer some protection against tainted >>> servers and password reuse... >> >> I wanted something a little bit more, plus protected from dictionary >> attack. > > to be sure that we did not misunderstand each other, I basically agree > with your idea but wanted to add something to it. Instead of having a > plaintext password inside the encrypted parameter, I suggested hashing > the password inside the encrypted parameter. > > A lot of people reuse the same password on different services. This > way, an attacker that has successfully compromised one service cannot > use the password to exploit other services. Yes we ARE misunderstanding each other! The password is NOT in the encrypted parameter. Rather the password is used in PKCS-5 to encyrpt the opaque data in ECHO_REQUEST_SIGNED. This makes it a challenge/response protocol without extending BEX. > >>> Btw, Samu's related draft is available from here: >>> >>> http://tools.ietf.org/html/draft-varjonen-hip-eap-00 >> >> Yes, I have read it, but this less intrusive; better for small devices. > > Your idea seems nice but should be an extension to RFC5201, right? It will actually be a part of DIET HIP with notation that it can be used in HIP BEX as well. It makes for a great ACL table bootstrap mechanism for sensors in a backwards manner: The sensor has a factory installed password. This password is loaded into a installation server. This installation server makes a HIP password authenticated connection to the sensor, overwrites the factory password with an owner password and adds the sensor the the owner's sensor ACL. This makes it easy to field install a new meter and add it to the utility's meter ACL. From rgm@htt-consult.com Mon May 17 09:07:05 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2934E3A6D56 for ; Mon, 17 May 2010 09:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_95=3] 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 vF1TJYLuSyJp for ; Mon, 17 May 2010 09:07:04 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 8DC7B3A6A8E for ; Mon, 17 May 2010 09:03:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A4FCC68D1B; Mon, 17 May 2010 15:57:00 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN9bNCKqsyXo; Mon, 17 May 2010 11:56:51 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 227F068D1E; Mon, 17 May 2010 11:56:51 -0400 (EDT) Message-ID: <4BF168C8.8070608@htt-consult.com> Date: Mon, 17 May 2010 12:03:20 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: hipsec@ietf.org, hiprg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Putting HIP on a Diet 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 May 2010 16:07:05 -0000 I am posting this update to both mailing lists. Eventhough I started all of this and am now working hard to rev HIP for Standards Track, I still will follow establish procedures on evolving HIP. To that end, we are all fairly well aware that sensor vendors chafe at how much crypto cruft we load into a Key Management System like HIP and go about taking things out without really looking at the basis of why we do things as they are. Back during IETF 77 I committed to developing a slimmer HIP. A HIP Diet EXchange (DEX). To this end I reviewed all we have done and why and what the options are. A few key points have come out: The cost of Diffie-Hellman. Diffie-Hellman, even the Elliptic Curve version, is an important component in HIP, but it forces the use of HMAC to extract a uniformly distributed key. Other areas where HMAC are used COULD use CMAC (though need to work out a new puzzle mechanism, see below). The alternative to Diffie-Hellman is a key wrap by a RSA/ECC key, like in TLS. The Initiator CAN do this in I2, but it is HARD to get a key from the Responder in 4 packets. Putting an encrypted key in R2 would mean that the MAC in I2 is different than R2 (one possiblity) or if the encrypted key is in R1, then there are flooding attack concerns. All things to work out to pull D-H from a Dietetic HIP. Also, by definition, SIGMA compliance is built on Diffie-Helman. Perfect Forward Secrecy is build on Diffie-Hellman we would have to 'approximate' SIGMA with PK key wrapping; the same with PFS. The cost of HMAC. As I mentioned above, Diffie-Hellman currently requires HMAC. Otherwise HMAC use in both the puzzle and the HIP_MAC COULD be replaced with CMAC. The cost of hashing. Whew, HIP is built on hashing. What security claims do we really need for the HIT? Collision Avoidance enough? Could some compress function be used in place of SHA for HIT generation? Switching to CMAC over HMAC addresses the other uses of hashing. In summary. What is HIP? Is HIP the exchange we have now have and only that? Or is HIP a class of protocols built on a Host Identity, each bring a slightly different set of security claims and risks and a slightly different domain of use? I am willing leaving my comfort zone with BEX and am defining DEX: HIP Diet EXchange: A compress function that generates a HIT from an ECDSA Host Identity (160, 224, and possibly 256 bits large). CMAC for macing functions and key expansion. Public Key secret wrapping for key distribution. If anyone wants to help on the details, let me know. I need a new puzzle using CMAC. I need a compress function for HIT generation. The goal is a full draft before the IETF 78 cutoff date and hopefully a good start by the end of this month. Work will be done in HIPrg if it does not fit in HIPsec, but this will really be pushed towards the IEEE 802.15 community. Thank you for listening to my ramblings. If you have addtional thoughts, share them here or privately with me. From gao.yang2@zte.com.cn Mon May 17 17:47:02 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9B13A68E3 for ; Mon, 17 May 2010 17:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.023 X-Spam-Level: X-Spam-Status: No, score=-96.023 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 sYV99UnxWgiu for ; Mon, 17 May 2010 17:47:00 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 20D6F3A67C2 for ; Mon, 17 May 2010 17:46:57 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 580712133923422; Tue, 18 May 2010 08:42:02 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.6073810819; Tue, 18 May 2010 08:46:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o4I0kPib052175; Tue, 18 May 2010 08:46:25 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BF168C8.8070608@htt-consult.com> To: Robert Moskowitz MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 18 May 2010 08:43:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-18 08:46:22, Serialize complete at 2010-05-18 08:46:22 Content-Type: multipart/alternative; boundary="=_alternative 0004366748257727_=" X-MAIL: mse2.zte.com.cn o4I0kPib052175 Cc: hipsec@ietf.org, hiprg@irtf.org Subject: Re: [Hipsec] [hiprg] Putting HIP on a Diet 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 May 2010 00:47:02 -0000 This is a multipart message in MIME format. --=_alternative 0004366748257727_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQpJIHNxdWludCB0b3dhcmRzIHRoaXMgZGVmaW5pdGlvbiBhbmQgZXZvbHV0aW9u IGRpcmVjdGlvbiBmb3IgSElQOg0KDQoiSElQIGEgY2xhc3Mgb2YgcHJvdG9jb2xzIGJ1aWx0IG9u IGEgSG9zdCBJZGVudGl0eSwgZWFjaCBicmluZyBhIHNsaWdodGx5IA0KZGlmZmVyZW50IHNldCBv ZiBzZWN1cml0eSBjbGFpbXMgYW5kIHJpc2tzIGFuZCBhIHNsaWdodGx5IGRpZmZlcmVudCANCmRv bWFpbiBvZiB1c2UuIg0KDQpUaGlzIG1pZ2h0IG1ha2UgSElQIG1vcmUgT1BFTiBmb3IgbWFueSBh c3BlY3QuDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYp LTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KUm9iZXJ0IE1vc2tvd2l0eiA8cmdtQGh0 dC1jb25zdWx0LmNvbT4gDQq3orz+yMs6ICBoaXByZy1ib3VuY2VzQGlydGYub3JnDQoyMDEwLTA1 LTE4IDAwOjAzDQoNCsrVvP7Iyw0KaGlwc2VjQGlldGYub3JnLCBoaXByZ0BpcnRmLm9yZw0Ks63L zQ0KDQrW98ziDQpbaGlwcmddIFB1dHRpbmcgSElQIG9uIGEgRGlldA0KDQoNCg0KDQoNCg0KSSBh bSBwb3N0aW5nIHRoaXMgdXBkYXRlIHRvIGJvdGggbWFpbGluZyBsaXN0cy4gIEV2ZW50aG91Z2gg SSBzdGFydGVkIA0KYWxsIG9mIHRoaXMgYW5kIGFtIG5vdyB3b3JraW5nIGhhcmQgdG8gcmV2IEhJ UCBmb3IgU3RhbmRhcmRzIFRyYWNrLCBJIA0Kc3RpbGwgd2lsbCBmb2xsb3cgZXN0YWJsaXNoIHBy b2NlZHVyZXMgb24gZXZvbHZpbmcgSElQLg0KDQpUbyB0aGF0IGVuZCwgd2UgYXJlIGFsbCBmYWly bHkgd2VsbCBhd2FyZSB0aGF0IHNlbnNvciB2ZW5kb3JzIGNoYWZlIGF0IA0KaG93IG11Y2ggY3J5 cHRvIGNydWZ0IHdlIGxvYWQgaW50byBhIEtleSBNYW5hZ2VtZW50IFN5c3RlbSBsaWtlIEhJUCBh bmQgDQpnbyBhYm91dCB0YWtpbmcgdGhpbmdzIG91dCB3aXRob3V0IHJlYWxseSBsb29raW5nIGF0 IHRoZSBiYXNpcyBvZiB3aHkgd2UgDQpkbyB0aGluZ3MgYXMgdGhleSBhcmUuICBCYWNrIGR1cmlu ZyBJRVRGIDc3IEkgY29tbWl0dGVkIHRvIGRldmVsb3BpbmcgYSANCnNsaW1tZXIgSElQLiAgQSBI SVAgRGlldCBFWGNoYW5nZSAoREVYKS4gIFRvIHRoaXMgZW5kIEkgcmV2aWV3ZWQgYWxsIHdlIA0K aGF2ZSBkb25lIGFuZCB3aHkgYW5kIHdoYXQgdGhlIG9wdGlvbnMgYXJlLiAgQSBmZXcga2V5IHBv aW50cyBoYXZlIGNvbWUgDQpvdXQ6DQoNClRoZSBjb3N0IG9mIERpZmZpZS1IZWxsbWFuLg0KDQpE aWZmaWUtSGVsbG1hbiwgZXZlbiB0aGUgRWxsaXB0aWMgQ3VydmUgdmVyc2lvbiwgaXMgYW4gaW1w b3J0YW50IA0KY29tcG9uZW50IGluIEhJUCwgYnV0IGl0IGZvcmNlcyB0aGUgdXNlIG9mIEhNQUMg dG8gZXh0cmFjdCBhIHVuaWZvcm1seSANCmRpc3RyaWJ1dGVkIGtleS4gIE90aGVyIGFyZWFzIHdo ZXJlIEhNQUMgYXJlIHVzZWQgQ09VTEQgdXNlIENNQUMgKHRob3VnaCANCm5lZWQgdG8gd29yayBv dXQgYSBuZXcgcHV6emxlIG1lY2hhbmlzbSwgc2VlIGJlbG93KS4gIFRoZSBhbHRlcm5hdGl2ZSB0 byANCkRpZmZpZS1IZWxsbWFuIGlzIGEga2V5IHdyYXAgYnkgYSBSU0EvRUNDIGtleSwgbGlrZSBp biBUTFMuICAgVGhlIA0KSW5pdGlhdG9yIENBTiBkbyB0aGlzIGluIEkyLCBidXQgaXQgaXMgSEFS RCB0byBnZXQgYSBrZXkgZnJvbSB0aGUgDQpSZXNwb25kZXIgaW4gNCBwYWNrZXRzLiAgUHV0dGlu ZyBhbiBlbmNyeXB0ZWQga2V5IGluIFIyIHdvdWxkIG1lYW4gdGhhdCANCnRoZSBNQUMgaW4gSTIg aXMgZGlmZmVyZW50IHRoYW4gUjIgKG9uZSBwb3NzaWJsaXR5KSBvciBpZiB0aGUgZW5jcnlwdGVk IA0Ka2V5IGlzIGluIFIxLCB0aGVuIHRoZXJlIGFyZSBmbG9vZGluZyBhdHRhY2sgY29uY2VybnMu ICBBbGwgdGhpbmdzIHRvIA0Kd29yayBvdXQgdG8gcHVsbCBELUggZnJvbSBhIERpZXRldGljIEhJ UC4NCg0KQWxzbywgYnkgZGVmaW5pdGlvbiwgU0lHTUEgY29tcGxpYW5jZSBpcyBidWlsdCBvbiBE aWZmaWUtSGVsbWFuLiANClBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5IGlzIGJ1aWxkIG9uIERpZmZp ZS1IZWxsbWFuIHdlIHdvdWxkIGhhdmUgdG8gDQonYXBwcm94aW1hdGUnIFNJR01BIHdpdGggUEsg a2V5IHdyYXBwaW5nOyB0aGUgc2FtZSB3aXRoIFBGUy4NCg0KDQpUaGUgY29zdCBvZiBITUFDLg0K DQpBcyBJIG1lbnRpb25lZCBhYm92ZSwgRGlmZmllLUhlbGxtYW4gY3VycmVudGx5IHJlcXVpcmVz IEhNQUMuICBPdGhlcndpc2UgDQpITUFDIHVzZSBpbiBib3RoIHRoZSBwdXp6bGUgYW5kIHRoZSBI SVBfTUFDIENPVUxEIGJlIHJlcGxhY2VkIHdpdGggQ01BQy4NCg0KDQpUaGUgY29zdCBvZiBoYXNo aW5nLg0KDQpXaGV3LCBISVAgaXMgYnVpbHQgb24gaGFzaGluZy4gIFdoYXQgc2VjdXJpdHkgY2xh aW1zIGRvIHdlIHJlYWxseSBuZWVkIA0KZm9yIHRoZSBISVQ/ICBDb2xsaXNpb24gQXZvaWRhbmNl IGVub3VnaD8gIENvdWxkIHNvbWUgY29tcHJlc3MgZnVuY3Rpb24gDQpiZSB1c2VkIGluIHBsYWNl IG9mIFNIQSBmb3IgSElUIGdlbmVyYXRpb24/ICBTd2l0Y2hpbmcgdG8gQ01BQyBvdmVyIEhNQUMg DQphZGRyZXNzZXMgdGhlIG90aGVyIHVzZXMgb2YgaGFzaGluZy4NCg0KDQpJbiBzdW1tYXJ5Lg0K DQpXaGF0IGlzIEhJUD8gIElzIEhJUCB0aGUgZXhjaGFuZ2Ugd2UgaGF2ZSBub3cgaGF2ZSBhbmQg b25seSB0aGF0PyAgT3IgaXMgDQpISVAgYSBjbGFzcyBvZiBwcm90b2NvbHMgYnVpbHQgb24gYSBI b3N0IElkZW50aXR5LCBlYWNoIGJyaW5nIGEgc2xpZ2h0bHkgDQpkaWZmZXJlbnQgc2V0IG9mIHNl Y3VyaXR5IGNsYWltcyBhbmQgcmlza3MgYW5kIGEgc2xpZ2h0bHkgZGlmZmVyZW50IA0KZG9tYWlu IG9mIHVzZT8gIEkgYW0gd2lsbGluZyBsZWF2aW5nIG15IGNvbWZvcnQgem9uZSB3aXRoIEJFWCBh bmQgYW0gDQpkZWZpbmluZyBERVg6ICBISVAgRGlldCBFWGNoYW5nZToNCg0KQSBjb21wcmVzcyBm dW5jdGlvbiB0aGF0IGdlbmVyYXRlcyBhIEhJVCBmcm9tIGFuIEVDRFNBIEhvc3QgSWRlbnRpdHkg DQooMTYwLCAyMjQsIGFuZCBwb3NzaWJseSAyNTYgYml0cyBsYXJnZSkuDQpDTUFDIGZvciBtYWNp bmcgZnVuY3Rpb25zIGFuZCBrZXkgZXhwYW5zaW9uLg0KUHVibGljIEtleSBzZWNyZXQgd3JhcHBp bmcgZm9yIGtleSBkaXN0cmlidXRpb24uDQoNCklmIGFueW9uZSB3YW50cyB0byBoZWxwIG9uIHRo ZSBkZXRhaWxzLCBsZXQgbWUga25vdy4gIEkgbmVlZCBhIG5ldyANCnB1enpsZSB1c2luZyBDTUFD LiAgSSBuZWVkIGEgY29tcHJlc3MgZnVuY3Rpb24gZm9yIEhJVCBnZW5lcmF0aW9uLiAgVGhlIA0K Z29hbCBpcyBhIGZ1bGwgZHJhZnQgYmVmb3JlIHRoZSBJRVRGIDc4IGN1dG9mZiBkYXRlIGFuZCBo b3BlZnVsbHkgYSBnb29kIA0Kc3RhcnQgYnkgdGhlIGVuZCBvZiB0aGlzIG1vbnRoLiAgV29yayB3 aWxsIGJlIGRvbmUgaW4gSElQcmcgaWYgaXQgZG9lcyANCm5vdCBmaXQgaW4gSElQc2VjLCBidXQg dGhpcyB3aWxsIHJlYWxseSBiZSBwdXNoZWQgdG93YXJkcyB0aGUgSUVFRSANCjgwMi4xNSBjb21t dW5pdHkuDQoNClRoYW5rIHlvdSBmb3IgbGlzdGVuaW5nIHRvIG15IHJhbWJsaW5ncy4gIElmIHlv dSBoYXZlIGFkZHRpb25hbCANCnRob3VnaHRzLCBzaGFyZSB0aGVtIGhlcmUgb3IgcHJpdmF0ZWx5 IHdpdGggbWUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmhpcHJnIG1haWxpbmcgbGlzdA0KaGlwcmdAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3Lmly dGYub3JnL21haWxtYW4vbGlzdGluZm8vaGlwcmcNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg aXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFp bCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0K VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBt ZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2Yg dGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0004366748257727_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEJvYiw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgc3F1aW50IHRvd2FyZHMgdGhp cyBkZWZpbml0aW9uIGFuZA0KZXZvbHV0aW9uIGRpcmVjdGlvbiBmb3IgSElQOjwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0hJUCBhIGNsYXNzIG9mIHByb3RvY29scyBi dWlsdCBvbiBhIEhvc3QgSWRlbnRpdHksDQplYWNoIGJyaW5nIGEgc2xpZ2h0bHkgPGJyPg0KZGlm ZmVyZW50IHNldCBvZiBzZWN1cml0eSBjbGFpbXMgYW5kIHJpc2tzIGFuZCBhIHNsaWdodGx5IGRp ZmZlcmVudCA8YnI+DQpkb21haW4gb2YgdXNlLiZxdW90OzwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+VGhpcyBtaWdodCBtYWtlIEhJUCBtb3JlIE9QRU4gZm9yIG1hbnkg YXNwZWN0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtzLDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+R2FvPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQog VGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4 NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Sb2JlcnQgTW9za293aXR6ICZsdDtyZ21AaHR0LWNvbnN1 bHQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+t6K8/sjLOiAmbmJzcDtoaXByZy1ib3VuY2VzQGlydGYub3JnPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDUtMTggMDA6MDM8L2ZvbnQ+DQo8dGQgd2lk dGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aGlwc2VjQGlldGYub3Jn LCBoaXByZ0BpcnRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+W2hpcHJnXSBQdXR0aW5nIEhJUCBvbiBhIERpZXQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgYW0gcG9z dGluZyB0aGlzIHVwZGF0ZSB0byBib3RoIG1haWxpbmcgbGlzdHMuICZuYnNwO0V2ZW50aG91Z2gN Ckkgc3RhcnRlZCA8YnI+DQphbGwgb2YgdGhpcyBhbmQgYW0gbm93IHdvcmtpbmcgaGFyZCB0byBy ZXYgSElQIGZvciBTdGFuZGFyZHMgVHJhY2ssIEkgPGJyPg0Kc3RpbGwgd2lsbCBmb2xsb3cgZXN0 YWJsaXNoIHByb2NlZHVyZXMgb24gZXZvbHZpbmcgSElQLjxicj4NCjxicj4NClRvIHRoYXQgZW5k LCB3ZSBhcmUgYWxsIGZhaXJseSB3ZWxsIGF3YXJlIHRoYXQgc2Vuc29yIHZlbmRvcnMgY2hhZmUg YXQNCjxicj4NCmhvdyBtdWNoIGNyeXB0byBjcnVmdCB3ZSBsb2FkIGludG8gYSBLZXkgTWFuYWdl bWVudCBTeXN0ZW0gbGlrZSBISVAgYW5kDQo8YnI+DQpnbyBhYm91dCB0YWtpbmcgdGhpbmdzIG91 dCB3aXRob3V0IHJlYWxseSBsb29raW5nIGF0IHRoZSBiYXNpcyBvZiB3aHkgd2UNCjxicj4NCmRv IHRoaW5ncyBhcyB0aGV5IGFyZS4gJm5ic3A7QmFjayBkdXJpbmcgSUVURiA3NyBJIGNvbW1pdHRl ZCB0byBkZXZlbG9waW5nDQphIDxicj4NCnNsaW1tZXIgSElQLiAmbmJzcDtBIEhJUCBEaWV0IEVY Y2hhbmdlIChERVgpLiAmbmJzcDtUbyB0aGlzIGVuZCBJIHJldmlld2VkDQphbGwgd2UgPGJyPg0K aGF2ZSBkb25lIGFuZCB3aHkgYW5kIHdoYXQgdGhlIG9wdGlvbnMgYXJlLiAmbmJzcDtBIGZldyBr ZXkgcG9pbnRzIGhhdmUNCmNvbWUgb3V0Ojxicj4NCjxicj4NClRoZSBjb3N0IG9mIERpZmZpZS1I ZWxsbWFuLjxicj4NCjxicj4NCkRpZmZpZS1IZWxsbWFuLCBldmVuIHRoZSBFbGxpcHRpYyBDdXJ2 ZSB2ZXJzaW9uLCBpcyBhbiBpbXBvcnRhbnQgPGJyPg0KY29tcG9uZW50IGluIEhJUCwgYnV0IGl0 IGZvcmNlcyB0aGUgdXNlIG9mIEhNQUMgdG8gZXh0cmFjdCBhIHVuaWZvcm1seQ0KPGJyPg0KZGlz dHJpYnV0ZWQga2V5LiAmbmJzcDtPdGhlciBhcmVhcyB3aGVyZSBITUFDIGFyZSB1c2VkIENPVUxE IHVzZSBDTUFDICh0aG91Z2gNCjxicj4NCm5lZWQgdG8gd29yayBvdXQgYSBuZXcgcHV6emxlIG1l Y2hhbmlzbSwgc2VlIGJlbG93KS4gJm5ic3A7VGhlIGFsdGVybmF0aXZlDQp0byA8YnI+DQpEaWZm aWUtSGVsbG1hbiBpcyBhIGtleSB3cmFwIGJ5IGEgUlNBL0VDQyBrZXksIGxpa2UgaW4gVExTLiAm bmJzcDsgVGhlDQo8YnI+DQpJbml0aWF0b3IgQ0FOIGRvIHRoaXMgaW4gSTIsIGJ1dCBpdCBpcyBI QVJEIHRvIGdldCBhIGtleSBmcm9tIHRoZSA8YnI+DQpSZXNwb25kZXIgaW4gNCBwYWNrZXRzLiAm bmJzcDtQdXR0aW5nIGFuIGVuY3J5cHRlZCBrZXkgaW4gUjIgd291bGQgbWVhbg0KdGhhdCA8YnI+ DQp0aGUgTUFDIGluIEkyIGlzIGRpZmZlcmVudCB0aGFuIFIyIChvbmUgcG9zc2libGl0eSkgb3Ig aWYgdGhlIGVuY3J5cHRlZA0KPGJyPg0Ka2V5IGlzIGluIFIxLCB0aGVuIHRoZXJlIGFyZSBmbG9v ZGluZyBhdHRhY2sgY29uY2VybnMuICZuYnNwO0FsbCB0aGluZ3MNCnRvIDxicj4NCndvcmsgb3V0 IHRvIHB1bGwgRC1IIGZyb20gYSBEaWV0ZXRpYyBISVAuPGJyPg0KPGJyPg0KQWxzbywgYnkgZGVm aW5pdGlvbiwgU0lHTUEgY29tcGxpYW5jZSBpcyBidWlsdCBvbiBEaWZmaWUtSGVsbWFuLiAmbmJz cDs8YnI+DQpQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSBpcyBidWlsZCBvbiBEaWZmaWUtSGVsbG1h biB3ZSB3b3VsZCBoYXZlIHRvIDxicj4NCidhcHByb3hpbWF0ZScgU0lHTUEgd2l0aCBQSyBrZXkg d3JhcHBpbmc7IHRoZSBzYW1lIHdpdGggUEZTLjxicj4NCjxicj4NCjxicj4NClRoZSBjb3N0IG9m IEhNQUMuPGJyPg0KPGJyPg0KQXMgSSBtZW50aW9uZWQgYWJvdmUsIERpZmZpZS1IZWxsbWFuIGN1 cnJlbnRseSByZXF1aXJlcyBITUFDLiAmbmJzcDtPdGhlcndpc2UNCjxicj4NCkhNQUMgdXNlIGlu IGJvdGggdGhlIHB1enpsZSBhbmQgdGhlIEhJUF9NQUMgQ09VTEQgYmUgcmVwbGFjZWQgd2l0aCBD TUFDLjxicj4NCjxicj4NCjxicj4NClRoZSBjb3N0IG9mIGhhc2hpbmcuPGJyPg0KPGJyPg0KV2hl dywgSElQIGlzIGJ1aWx0IG9uIGhhc2hpbmcuICZuYnNwO1doYXQgc2VjdXJpdHkgY2xhaW1zIGRv IHdlIHJlYWxseQ0KbmVlZCA8YnI+DQpmb3IgdGhlIEhJVD8gJm5ic3A7Q29sbGlzaW9uIEF2b2lk YW5jZSBlbm91Z2g/ICZuYnNwO0NvdWxkIHNvbWUgY29tcHJlc3MNCmZ1bmN0aW9uIDxicj4NCmJl IHVzZWQgaW4gcGxhY2Ugb2YgU0hBIGZvciBISVQgZ2VuZXJhdGlvbj8gJm5ic3A7U3dpdGNoaW5n IHRvIENNQUMgb3Zlcg0KSE1BQyA8YnI+DQphZGRyZXNzZXMgdGhlIG90aGVyIHVzZXMgb2YgaGFz aGluZy48YnI+DQo8YnI+DQo8YnI+DQpJbiBzdW1tYXJ5Ljxicj4NCjxicj4NCldoYXQgaXMgSElQ PyAmbmJzcDtJcyBISVAgdGhlIGV4Y2hhbmdlIHdlIGhhdmUgbm93IGhhdmUgYW5kIG9ubHkgdGhh dD8NCiZuYnNwO09yIGlzIDxicj4NCkhJUCBhIGNsYXNzIG9mIHByb3RvY29scyBidWlsdCBvbiBh IEhvc3QgSWRlbnRpdHksIGVhY2ggYnJpbmcgYSBzbGlnaHRseQ0KPGJyPg0KZGlmZmVyZW50IHNl dCBvZiBzZWN1cml0eSBjbGFpbXMgYW5kIHJpc2tzIGFuZCBhIHNsaWdodGx5IGRpZmZlcmVudCA8 YnI+DQpkb21haW4gb2YgdXNlPyAmbmJzcDtJIGFtIHdpbGxpbmcgbGVhdmluZyBteSBjb21mb3J0 IHpvbmUgd2l0aCBCRVggYW5kDQphbSA8YnI+DQpkZWZpbmluZyBERVg6ICZuYnNwO0hJUCBEaWV0 IEVYY2hhbmdlOjxicj4NCjxicj4NCkEgY29tcHJlc3MgZnVuY3Rpb24gdGhhdCBnZW5lcmF0ZXMg YSBISVQgZnJvbSBhbiBFQ0RTQSBIb3N0IElkZW50aXR5IDxicj4NCigxNjAsIDIyNCwgYW5kIHBv c3NpYmx5IDI1NiBiaXRzIGxhcmdlKS48YnI+DQpDTUFDIGZvciBtYWNpbmcgZnVuY3Rpb25zIGFu ZCBrZXkgZXhwYW5zaW9uLjxicj4NClB1YmxpYyBLZXkgc2VjcmV0IHdyYXBwaW5nIGZvciBrZXkg ZGlzdHJpYnV0aW9uLjxicj4NCjxicj4NCklmIGFueW9uZSB3YW50cyB0byBoZWxwIG9uIHRoZSBk ZXRhaWxzLCBsZXQgbWUga25vdy4gJm5ic3A7SSBuZWVkIGEgbmV3DQo8YnI+DQpwdXp6bGUgdXNp bmcgQ01BQy4gJm5ic3A7SSBuZWVkIGEgY29tcHJlc3MgZnVuY3Rpb24gZm9yIEhJVCBnZW5lcmF0 aW9uLg0KJm5ic3A7VGhlIDxicj4NCmdvYWwgaXMgYSBmdWxsIGRyYWZ0IGJlZm9yZSB0aGUgSUVU RiA3OCBjdXRvZmYgZGF0ZSBhbmQgaG9wZWZ1bGx5IGEgZ29vZA0KPGJyPg0Kc3RhcnQgYnkgdGhl IGVuZCBvZiB0aGlzIG1vbnRoLiAmbmJzcDtXb3JrIHdpbGwgYmUgZG9uZSBpbiBISVByZyBpZiBp dA0KZG9lcyA8YnI+DQpub3QgZml0IGluIEhJUHNlYywgYnV0IHRoaXMgd2lsbCByZWFsbHkgYmUg cHVzaGVkIHRvd2FyZHMgdGhlIElFRUUgPGJyPg0KODAyLjE1IGNvbW11bml0eS48YnI+DQo8YnI+ DQpUaGFuayB5b3UgZm9yIGxpc3RlbmluZyB0byBteSByYW1ibGluZ3MuICZuYnNwO0lmIHlvdSBo YXZlIGFkZHRpb25hbCA8YnI+DQp0aG91Z2h0cywgc2hhcmUgdGhlbSBoZXJlIG9yIHByaXZhdGVs eSB3aXRoIG1lLjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KaGlwcmcgbWFpbGluZyBsaXN0PGJyPg0KaGlwcmdAaXJ0 Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hpcHJnPGJy Pg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJz cDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNw O2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJz cDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3Ro ZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5i c3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7 cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5i c3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7 YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVt Lg0KPC9wcmU+ --=_alternative 0004366748257727_=-- From thomas.r.henderson@boeing.com Tue May 18 10:22:52 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064753A6C1D for ; Tue, 18 May 2010 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQWL13dZz1t5 for ; Tue, 18 May 2010 10:22:48 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D735A28C196 for ; Tue, 18 May 2010 10:18:03 -0700 (PDT) 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 o4IHHcV6004922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 12:17:39 -0500 (CDT) 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 o4IHHcVB029924; Tue, 18 May 2010 10:17:38 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o4IHHbSR029891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 18 May 2010 10:17:37 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 18 May 2010 10:17:37 -0700 From: "Henderson, Thomas R" To: "'Jan Melen'" , Robert Moskowitz Date: Tue, 18 May 2010 10:17:36 -0700 Thread-Topic: [Hipsec] New HIP WG charter proposal Thread-Index: AcrscCn+m/JNWtaOT1SWw+D7YzjcbAKPWepg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE9716193@XCH-NW-10V.nw.nos.boeing.com> References: <4BDBD41E.5030107@ericsson.com> <4BDFE5B7.3020500@oracle.com><4BE02580.8060808@htt-consult.com> <5E24EE17-E367-4CA9-9453-EF3DFF264DFD@nomadiclab.com> In-Reply-To: <5E24EE17-E367-4CA9-9453-EF3DFF264DFD@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] New HIP WG charter proposal 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 May 2010 17:22:52 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Jan Melen > Sent: Wednesday, May 05, 2010 9:29 AM > To: Robert Moskowitz > Cc: HIP > Subject: Re: [Hipsec] New HIP WG charter proposal > > Hi, > > To me the new charter looks good. For referrals I don't see > any big problems as mentioned already by Miika and Bob we > have gained quite a bit experience on how much of an problem > the referrals are and according to that experience there is > only very few cases where they cannot be made to work, in all > other cases the referrals can be resolved through mechanisms > described by Bob. > > Of course these are issues that need to be documented in > architecture and DNS documents > > Regards, > Jan I'd also like to support the new charter proposal, and also mention that th= ere is some documentation about referrals in RFC 5338. Tom From thomas.r.henderson@boeing.com Tue May 18 10:36:17 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E0F28C1C1; Tue, 18 May 2010 10:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.238 X-Spam-Level: X-Spam-Status: No, score=-4.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXGwM8IrV5VM; Tue, 18 May 2010 10:36:16 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B316B28C1EF; Tue, 18 May 2010 10:31:36 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o4IHVRE7013283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 12:31:28 -0500 (CDT) 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 o4IHVR5V005419; Tue, 18 May 2010 10:31:27 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o4IHVR6U005407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 18 May 2010 10:31:27 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 18 May 2010 10:31:27 -0700 From: "Henderson, Thomas R" To: "'Noel Chiappa'" , "hiprg@irtf.org" , "hipsec@ietf.org" Date: Tue, 18 May 2010 10:31:26 -0700 Thread-Topic: [hiprg] Putting HIP on a Diet Thread-Index: Acr16GiXDQ8FsTjNSDemomAua/o4iQAxf0rA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> References: <20100517173256.798446BE575@mercury.lcs.mit.edu> In-Reply-To: <20100517173256.798446BE575@mercury.lcs.mit.edu> 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] [hiprg] Putting HIP on a Diet 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 May 2010 17:36:17 -0000 > -----Original Message----- > From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org] > On Behalf Of Noel Chiappa > Sent: Monday, May 17, 2010 10:33 AM > To: hiprg@irtf.org; hipsec@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [hiprg] Putting HIP on a Diet > > > From: Robert Moskowitz > > > What is HIP? Is HIP the exchange we have now have and > only that? Or is > > HIP a class of protocols built on a Host Identity, each bring a > > slightly different set of security claims and risks and > a slightly > > different domain of use? > > Well, those are some key (and excellent) questions - and I > would think you > need to answer them all fairly fully, and fairly early in the > design process. > I agree, and while it would be fine to work the protocol specifics in the r= esearch group (since the proposed WG charter doesn't include this for now),= I think that the basic question above should be covered in RFC4423bis. I = would support the latter interpretation (that HIP is (potentially) a protoc= ol family built around the concept of a namespace for IP stacks). - Tom From rgm@htt-consult.com Tue May 18 10:54:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B273A6858 for ; Tue, 18 May 2010 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYTlBji9oFn6 for ; Tue, 18 May 2010 10:54:22 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id B60A33A690F for ; Tue, 18 May 2010 10:54:21 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 779DD68B46; Tue, 18 May 2010 17:47:40 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6r0AkG8SW-r; Tue, 18 May 2010 13:47:31 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 402DC68B99; Tue, 18 May 2010 13:47:23 -0400 (EDT) Message-ID: <4BF2D433.6050206@htt-consult.com> Date: Tue, 18 May 2010 13:53:55 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <20100517173256.798446BE575@mercury.lcs.mit.edu> <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" , "hiprg@irtf.org" , 'Noel Chiappa' Subject: Re: [Hipsec] [hiprg] Putting HIP on a Diet 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 May 2010 17:54:22 -0000 On 05/18/2010 01:31 PM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: hiprg-bounces@irtf.org [mailto:hiprg-bounces@irtf.org] >> On Behalf Of Noel Chiappa >> Sent: Monday, May 17, 2010 10:33 AM >> To: hiprg@irtf.org; hipsec@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: Re: [hiprg] Putting HIP on a Diet >> >> > From: Robert Moskowitz >> >> > What is HIP? Is HIP the exchange we have now have and >> only that? Or is >> > HIP a class of protocols built on a Host Identity, each bring a >> > slightly different set of security claims and risks and >> a slightly >> > different domain of use? >> >> Well, those are some key (and excellent) questions - and I >> would think you >> need to answer them all fairly fully, and fairly early in the >> design process. >> >> > I agree, and while it would be fine to work the protocol specifics in the research group (since the proposed WG charter doesn't include this for now), I think that the basic question above should be covered in RFC4423bis. I would support the latter interpretation (that HIP is (potentially) a protocol family built around the concept of a namespace for IP stacks). I will move HIP DEX discussions over to HIP-RG. Drat it :) From rgm@htt-consult.com Tue May 18 10:56:18 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF3E3A6846 for ; Tue, 18 May 2010 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwfAqyfnJkiT for ; Tue, 18 May 2010 10:56:17 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7F7E03A67A3 for ; Tue, 18 May 2010 10:56:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4EC2268B7C; Tue, 18 May 2010 17:49:13 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePFXi1GuPvPJ; Tue, 18 May 2010 13:49:04 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3F46A68B81; Tue, 18 May 2010 13:49:04 -0400 (EDT) Message-ID: <4BF2D498.9050907@htt-consult.com> Date: Tue, 18 May 2010 13:55:36 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <20100517173256.798446BE575@mercury.lcs.mit.edu> <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" , 'Noel Chiappa' Subject: Re: [Hipsec] [hiprg] Putting HIP on a Diet 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 May 2010 17:56:18 -0000 On 05/18/2010 01:31 PM, Henderson, Thomas R wrote: > >> -----Original Message----- >> >> > From: Robert Moskowitz >> >> > What is HIP? Is HIP the exchange we have now have and >> only that? Or is >> > HIP a class of protocols built on a Host Identity, each bring a >> > slightly different set of security claims and risks and >> a slightly >> > different domain of use? >> >> Well, those are some key (and excellent) questions - and I >> would think you >> need to answer them all fairly fully, and fairly early in the >> design process. >> >> > I agree, and while it would be fine to work the protocol specifics in the research group (since the proposed WG charter doesn't include this for now), I think that the basic question above should be covered in RFC4423bis. I would support the latter interpretation (that HIP is (potentially) a protocol family built around the concept of a namespace for IP stacks). I am working on this wording being added to 4423-bis. I really think it captures my thoughts over the past 2 years on work being done with HIP RFID and HIP IOT. And now HIP DEX. From thomas.r.henderson@boeing.com Tue May 18 12:25:39 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3B33A6ABB for ; Tue, 18 May 2010 12:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82BS6E7SjCgQ for ; Tue, 18 May 2010 12:25:35 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C853828C1D1 for ; Tue, 18 May 2010 12:23:37 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o4IJNBg6016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 12:23:19 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o4IJNBtx027793; Tue, 18 May 2010 12:23:11 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o4IJNA0v027783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 18 May 2010 12:23:11 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Tue, 18 May 2010 12:23:11 -0700 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Tue, 18 May 2010 12:23:10 -0700 Thread-Topic: [hiprg] Putting HIP on a Diet Thread-Index: Acr2s2LK5kRS3jacQaGQNlfIovw93wACt3zw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE9716197@XCH-NW-10V.nw.nos.boeing.com> References: <20100517173256.798446BE575@mercury.lcs.mit.edu> <7CC566635CFE364D87DC5803D4712A6C4CE9716194@XCH-NW-10V.nw.nos.boeing.com> <4BF2D498.9050907@htt-consult.com> In-Reply-To: <4BF2D498.9050907@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] [hiprg] Putting HIP on a Diet 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 May 2010 19:25:39 -0000 > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com] > Sent: Tuesday, May 18, 2010 10:56 AM > To: Henderson, Thomas R > Cc: 'Noel Chiappa'; hipsec@ietf.org > Subject: Re: [hiprg] Putting HIP on a Diet > > On 05/18/2010 01:31 PM, Henderson, Thomas R wrote: > > > >> -----Original Message----- > >> > >> > From: Robert Moskowitz > >> > >> > What is HIP? Is HIP the exchange we have now have and > >> only that? Or is > >> > HIP a class of protocols built on a Host Identity, > each bring a > >> > slightly different set of security claims and risks and > >> a slightly > >> > different domain of use? > >> > >> Well, those are some key (and excellent) questions - and I > >> would think you > >> need to answer them all fairly fully, and fairly early in the > >> design process. > >> > >> > > I agree, and while it would be fine to work the protocol > specifics in the research group (since the proposed WG > charter doesn't include this for now), I think that the basic > question above should be covered in RFC4423bis. I would > support the latter interpretation (that HIP is (potentially) > a protocol family built around the concept of a namespace for > IP stacks). > > I am working on this wording being added to 4423-bis. I > really think it > captures my thoughts over the past 2 years on work being done > with HIP > RFID and HIP IOT. And now HIP DEX. > I reread the intro to 4423(bis) just now and found myself thinking that it = is really the discussion about the independent namespace for IP stacks, rat= her than the protocol exchange itself, that captures the essence of HIP. F= or instance, section 4.1 of 4423 (now 3.1 of 4423-bis). What aspects, if a= ny, of this description of the namespace do not generally hold? I might re= lax some text in the very last paragraph such as "Using Host Identities req= uires its own protocol layer, the Host Identity Protocol..." and "The names= are based on public-key cryptography.." to instead read something like "On= e implementation of these ideas is based on the use of public/private key p= airs as names and on a key management protocol called the Host Identity Pro= tocol, but other implementations with the above properties may be possible.= .." - Tom From jan.melen@nomadiclab.com Wed May 19 05:29:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2A63A67AC for ; Wed, 19 May 2010 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mu+OgnrfLZf for ; Wed, 19 May 2010 05:29:01 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 3F61A3A6BB0 for ; Wed, 19 May 2010 05:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id D3C4F4E6DC; Wed, 19 May 2010 15:28:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg6R53m5Lj7a; Wed, 19 May 2010 15:28:17 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 8AFB34E6C8; Wed, 19 May 2010 15:28:17 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id 7FB52107148; Wed, 19 May 2010 15:28:17 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id D85EC10713F; Wed, 19 May 2010 15:28:02 +0300 (EEST) From: Jan Melen Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-9--387888899 Date: Wed, 19 May 2010 15:27:34 +0300 In-Reply-To: <62305098-2EBE-4128-9F8D-A4415B8ABB94@nomadiclab.com> To: Gonzalo Camarillo , HIP References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BF@XCH-NW-10V.nw.nos.boeing.com> <79B9C9FA-E49A-4103-B1DA-741FC0389635@nomadiclab.com> <62305098-2EBE-4128-9F8D-A4415B8ABB94@nomadiclab.com> Message-Id: <24BA4DA5-90C9-4196-8CB4-CB05D8C5B2A3@nomadiclab.com> X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-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 May 2010 12:29:03 -0000 --Apple-Mail-9--387888899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, This document has now been lying around quite sometime. I posted the -02 = version just before last IETF and no one has commented on it anything or = neither has it progressed any further from the WGLC. Are there any = remaining issues or are people happy with latest version? http://www.ietf.org/id/draft-ietf-hip-hiccups-02.txt Regards, Jan On Mar 4, 2010, at 3:25 PM, Jan Melen wrote: > Hi, >=20 > It seems that the term HMAC in the document was misunderstood by = people so I replaced it with term Message Integrity Code (MIC) and it is = explained in the terminology section as follows: > Message Integrity Code (MIC) is a hash sum calculated over the > message which is being integrity protected. MIC does not use > secret keys and thus need be protected otherwise against > tampering. Essentially MIC is same as MAC with the distinction > that MIC does not use secret key. MIC is also often referred as > Integrity Check Value (ICV), fingerprint, or unkeyed MAC. > I Hope this makes it a bit more clear now that there is no key needed = when calculating the hash over the payload. The edited version is in the = same location as previous (not yet submitted): = http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt > Regards, > Jan >=20 > On Mar 3, 2010, at 9:08 PM, Jan Melen wrote: >=20 >> Hi, >>=20 >> Here is link to updated version: >> http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt >>=20 >> On Feb 22, 2010, at 8:46 PM, Henderson, Thomas R wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: hipsec-bounces@ietf.org >>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Tuesday, January 26, 2010 7:19 AM >>>> To: HIP >>>> Subject: [Hipsec] WGLC: HIP-based overlays >>>>=20 >>>> Folks, >>>>=20 >>>> we would like to WGLC the set of specifications that describe how = to >>>> build HIP-based overlays. The documents under WGLC are the = following: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-hip-bone-04 >>>> http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 >>>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 >>>> http://tools.ietf.org/html/draft-ietf-hip-via-00 >>>>=20 >>>> This WGLC will end on February 23rd. Please, send your >>>> comments to this >>>> list. >>>>=20 >>>=20 >>> comments on draft-ietf-hip-hiccups-01: >>>=20 >>> Overall, I think that this document mainly makes sense in the = context of HIP BONE and should be folded into that specification. = However, if kept stand-alone, it would help to clarify in the = introduction that this specifies a data service with the following = semantics: unordered, duplicate free (subject to receiver ACK cache = size and lifetime), reliable (up to a retransmission count), = authenticated, and encrypted message-based delivery service. I would = also recommend stating that APIs to higher-level protocols that might = use this service are outside the scope of this specification. >>>=20 >>=20 >>=20 >> Added the semantics and that APIs are outside the scope. >>=20 >>=20 >>>> 2. Terminology >>>>=20 >>>>=20 >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>>> document are to be interpreted as described in RFC 2119 = [RFC2119]. >>>=20 >>> This section is empty; probably at the very least it should point to = the normative references that define the terminology in use later in the = document. >>>=20 >>=20 >> Yes, added reference to RFC 5201 for terminology. >>=20 >>=20 >>>> 3. Background on HIP >>>>=20 >>>>=20 >>>> The HIP protocol specification [RFC5201] defines a number of = messages >>>> and parameters. The parameters are encoded as TLVs, as shown in >>>> Section 3.1.2. Furthermore, the HIP header carries a Next Header >>>> field, allowing other arbitrary packets to be carried within HIP >>>> packets. >>>=20 >>> Perhaps this section could go away or be refactored if this draft is = merged to hip-bone. >>>=20 >>>> 4.1. Definition of the PAYLOAD_MAC Parameter >>>>=20 >>>> Length length in octets, excluding Type, Length, and >>>> Padding >>>=20 >>> are there any minimum or maximum size limitations for this = parameter? Should the maximum length be tied to the maximum size that = the HMAC can handle? >>=20 >>=20 >> Do you mean that we should be more specific than what we are saying = about the HMAC itself: >> Payload HMAC HMAC computed over the data to which the Next >> Header and Payload Data points to. The size of >> the HMAC is the natural size of the computation >> output depending on the used function. >>=20 >>>=20 >>>> 5.1. Handling of SEQ_DATA and ACK_DATA >>>>=20 >>>>=20 >>>> A HIP DATA packet contains zero or one SEQ_DATA parameter. The >>>> presence of a SEQ_DATA parameter indicates that the receiver MUST = ACK >>>> the HIP DATA packet. A HIP DATA packet that does not contain a >>>> SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet = and >>>> MUST NOT be ACKed. >>>=20 >>> is it legal to have a HIP DATA with zero SEQ_DATA and zero ACK_DATA? = If not, suggest to say that if SEQ_DATA is missing, ACK_DATA must be = present. >>>=20 >>> Can SEQ_DATA be present with no PAYLOAD_MAC parameter? >>=20 >>=20 >> Fixed either SEQ_DATA or ACK_DATA must be present and in case of = SEQ_DATA also PAYLOAD_MAC is required. >>=20 >>=20 >>>=20 >>>> packet. A host MAY choose to hold the HIP DATA packet carrying = ACK >>>> for a short period of time to allow for the possibility of >>>> piggybacking the ACK parameter, in a manner similar to TCP = delayed >>>> acknowledgments. >>>=20 >>> Should the ACK_DATA format allow for multiple sequence numbers, if = so, to avoid carrying a Type and Length field for each one? >>=20 >>=20 >> Yes and now it is defined. >>=20 >>=20 >>>=20 >>>> 1. The host creates a HIP DATA packet that contains a SEQ_DATA >>>> parameter. The host is free to choose any value for the = SEQ_DATA >>>> parameter in the first HIP DATA packet it sends to a = destination. >>>=20 >>> This section would be clearer if you replaced "SEQ_DATA parameter" = and "SEQ_DATA value" with "SEQ_DATA sequence number". >>=20 >> Fixed. >>=20 >>=20 >> Thanks for reviewing the draft >> Jan >>=20 >>=20 >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >=20 --Apple-Mail-9--387888899 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.i= etf.org/id/draft-ietf-hip-hiccups-02.txt

&nbs= p;  Regards,
     = Jan


On Mar 4, 2010, at 3:25 PM, = Jan Melen wrote:

  =
 Message Integrity Code (MIC)  is a hash sum calculated over the
      message which is being integrity protected.  MIC does not use
      secret keys and thus need be protected otherwise against
      tampering.  Essentially MIC is same as MAC with the distinction
      that MIC does not use secret key.  MIC is also often referred as
      Integrity Check Value (ICV), fingerprint, or unkeyed MAC.

I Hope this makes it a bit more clear now that =
there is no key needed when calculating the hash over the =
payload. The edited version is in the same location as previous =
(not yet submitted): http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt=
   = Regards,
     = Jan

On Mar 3, 2010, at 9:08 PM, Jan Melen = wrote:

http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt=

On Feb 22, 2010, at 8:46 PM, = Henderson, Thomas R wrote:



-----Original = Message-----
From: hipsec-bounces@ietf.org
[mailto:hipsec-bounces@ietf.org] On = Behalf Of Gonzalo Camarillo
Sent: Tuesday, January 26, 2010 7:19 = AM
To: = HIP
Subject: [Hipsec] WGLC: = HIP-based overlays

Folks,

we would like = to WGLC the set of specifications that describe how = to
build HIP-based overlays. = The documents under WGLC are the following:

http://tools.ie= tf.org/html/draft-ietf-hip-bone-04
http= ://tools.ietf.org/html/draft-ietf-hip-reload-instance-00
http://tools= .ietf.org/html/draft-ietf-hip-hiccups-01
http://tools.iet= f.org/html/draft-ietf-hip-via-00

This WGLC will = end on February 23rd. Please, send your
comments to this
list.


comments on = draft-ietf-hip-hiccups-01:

Overall, I think that this document = mainly makes sense in the context of HIP BONE and should be folded into = that specification.  However, if kept stand-alone, it would help to = clarify in the introduction that this specifies a data service with the = following semantics:  unordered, duplicate free (subject to = receiver ACK cache size and lifetime), reliable (up to a retransmission = count), authenticated, and encrypted message-based delivery service. =  I would also recommend stating that APIs to higher-level protocols = that might use this service are outside the scope of this = specification.



Added the semantics and that APIs are outside the = scope.


2. Terminology


=   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
=   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in this
  document = are to be interpreted as described in RFC 2119 = [RFC2119].

This section is empty; probably at the = very least it should point to the normative references that define the = terminology in use later in the = document.


Yes, added = reference to RFC 5201 for = terminology.


3. Background on = HIP


=   The HIP protocol specification [RFC5201] defines a number of = messages
  and = parameters.  The parameters are encoded as TLVs, as shown = in
  Section 3.1.2. =  Furthermore, the HIP header carries a Next = Header
  field, = allowing other arbitrary packets to be carried within = HIP
=   packets.

Perhaps this section could go = away or be refactored if this draft is merged to = hip-bone.

4.1. Definition of the = PAYLOAD_MAC Parameter

=     Length =            length = in octets, excluding Type, Length, and
=             &n= bsp;         Padding

are there any minimum or maximum size limitations for this = parameter?  Should the maximum length be tied to the maximum size = that the HMAC can = handle?


Do you = mean that we should be more specific than what we are saying about the = HMAC itself:
  Payload HMAC      HMAC computed over the data =
to which the Next
                     Header and Payload Data points to. The size of
                     the HMAC is the natural size of the computation
                     output depending on the used =
function.


5.1. Handling of = SEQ_DATA and ACK_DATA


  A = HIP DATA packet contains zero or one SEQ_DATA parameter. =  The
=   presence of a SEQ_DATA parameter indicates that the receiver = MUST ACK
  the HIP = DATA packet.  A HIP DATA packet that does not contain = a
  SEQ_DATA = parameter is simply an ACK of a previous HIP DATA packet = and
  MUST NOT be = ACKed.

is it legal to have a HIP DATA with zero = SEQ_DATA and zero ACK_DATA?  If not, suggest to say that if = SEQ_DATA is missing, ACK_DATA must be present.

Can SEQ_DATA be = present with no PAYLOAD_MAC = parameter?


Fixed = either SEQ_DATA or ACK_DATA must be present and in case of SEQ_DATA also = PAYLOAD_MAC is required.



  packet. =  A host MAY choose to hold the HIP DATA packet carrying = ACK
  for a short = period of time to allow for the possibility = of
  piggybacking = the ACK parameter, in a manner similar to TCP = delayed
=   acknowledgments.

Should the ACK_DATA = format allow for multiple sequence numbers, if so, to avoid carrying a = Type and Length field for each = one?


Yes and = now it is defined.



  1. =  The host creates a HIP DATA packet that contains a = SEQ_DATA
=       parameter.  The host is free to = choose any value for the SEQ_DATA
      parameter in the = first HIP DATA packet it sends to a = destination.

This section would be clearer if you = replaced "SEQ_DATA parameter" and "SEQ_DATA value" with "SEQ_DATA = sequence = number".

Fixed.

<= /div>

   Thanks for reviewing the = draft
       = Jan


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

=
= --Apple-Mail-9--387888899-- From jan.melen@nomadiclab.com Wed May 19 05:34:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058023A6987 for ; Wed, 19 May 2010 05:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL0tVGTLiUMZ for ; Wed, 19 May 2010 05:34:17 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2E2963A6980 for ; Wed, 19 May 2010 05:34:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7D5A54E6DC; Wed, 19 May 2010 15:34:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u20tA7XvENo2; Wed, 19 May 2010 15:34:01 +0300 (EEST) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 4C14E4E6C8; Wed, 19 May 2010 15:34:01 +0300 (EEST) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id 40B47107148; Wed, 19 May 2010 15:34:01 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id CC3D510713F; Wed, 19 May 2010 15:34:00 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-10--387499616 From: Jan Melen In-Reply-To: <24BA4DA5-90C9-4196-8CB4-CB05D8C5B2A3@nomadiclab.com> Date: Wed, 19 May 2010 15:34:03 +0300 Message-Id: <806F3396-0689-4F3B-A85D-551EDBBFE3D9@nomadiclab.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BF@XCH-NW-10V.nw.nos.boeing.com> <79B9C9FA-E49A-4103-B1DA-741FC0389635@nomadiclab.com> <62305098-2EBE-4128-9F8D-A4415B8ABB94@nomadiclab.com> <24BA4DA5-90C9-4196-8CB4-CB05D8C5B2A3@nomadiclab.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: ClamAV using ClamSMTP Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-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 May 2010 12:34:19 -0000 --Apple-Mail-10--387499616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Replying to my own email.... I should have pinged Gonzalo before sending = this.... It seems that the publication has already been requested there = was just some delay after last IETF so please ignore the previous mail = ;) Jan On May 19, 2010, at 3:27 PM, Jan Melen wrote: > Hi, >=20 > This document has now been lying around quite sometime. I posted the = -02 version just before last IETF and no one has commented on it = anything or neither has it progressed any further from the WGLC. Are = there any remaining issues or are people happy with latest version? > http://www.ietf.org/id/draft-ietf-hip-hiccups-02.txt >=20 > Regards, > Jan >=20 >=20 > On Mar 4, 2010, at 3:25 PM, Jan Melen wrote: >=20 >> Hi, >>=20 >> It seems that the term HMAC in the document was misunderstood by = people so I replaced it with term Message Integrity Code (MIC) and it is = explained in the terminology section as follows: >> Message Integrity Code (MIC) is a hash sum calculated over the >> message which is being integrity protected. MIC does not use >> secret keys and thus need be protected otherwise against >> tampering. Essentially MIC is same as MAC with the distinction >> that MIC does not use secret key. MIC is also often referred = as >> Integrity Check Value (ICV), fingerprint, or unkeyed MAC. >> I Hope this makes it a bit more clear now that there is no key needed = when calculating the hash over the payload. The edited version is in the = same location as previous (not yet submitted): = http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt >> Regards, >> Jan >>=20 >> On Mar 3, 2010, at 9:08 PM, Jan Melen wrote: >>=20 >>> Hi, >>>=20 >>> Here is link to updated version: >>> http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt >>>=20 >>> On Feb 22, 2010, at 8:46 PM, Henderson, Thomas R wrote: >>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: hipsec-bounces@ietf.org >>>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>>> Sent: Tuesday, January 26, 2010 7:19 AM >>>>> To: HIP >>>>> Subject: [Hipsec] WGLC: HIP-based overlays >>>>>=20 >>>>> Folks, >>>>>=20 >>>>> we would like to WGLC the set of specifications that describe how = to >>>>> build HIP-based overlays. The documents under WGLC are the = following: >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-hip-bone-04 >>>>> http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 >>>>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 >>>>> http://tools.ietf.org/html/draft-ietf-hip-via-00 >>>>>=20 >>>>> This WGLC will end on February 23rd. Please, send your >>>>> comments to this >>>>> list. >>>>>=20 >>>>=20 >>>> comments on draft-ietf-hip-hiccups-01: >>>>=20 >>>> Overall, I think that this document mainly makes sense in the = context of HIP BONE and should be folded into that specification. = However, if kept stand-alone, it would help to clarify in the = introduction that this specifies a data service with the following = semantics: unordered, duplicate free (subject to receiver ACK cache = size and lifetime), reliable (up to a retransmission count), = authenticated, and encrypted message-based delivery service. I would = also recommend stating that APIs to higher-level protocols that might = use this service are outside the scope of this specification. >>>>=20 >>>=20 >>>=20 >>> Added the semantics and that APIs are outside the scope. >>>=20 >>>=20 >>>>> 2. Terminology >>>>>=20 >>>>>=20 >>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>>>> document are to be interpreted as described in RFC 2119 = [RFC2119]. >>>>=20 >>>> This section is empty; probably at the very least it should point = to the normative references that define the terminology in use later in = the document. >>>>=20 >>>=20 >>> Yes, added reference to RFC 5201 for terminology. >>>=20 >>>=20 >>>>> 3. Background on HIP >>>>>=20 >>>>>=20 >>>>> The HIP protocol specification [RFC5201] defines a number of = messages >>>>> and parameters. The parameters are encoded as TLVs, as shown in >>>>> Section 3.1.2. Furthermore, the HIP header carries a Next = Header >>>>> field, allowing other arbitrary packets to be carried within HIP >>>>> packets. >>>>=20 >>>> Perhaps this section could go away or be refactored if this draft = is merged to hip-bone. >>>>=20 >>>>> 4.1. Definition of the PAYLOAD_MAC Parameter >>>>>=20 >>>>> Length length in octets, excluding Type, Length, = and >>>>> Padding >>>>=20 >>>> are there any minimum or maximum size limitations for this = parameter? Should the maximum length be tied to the maximum size that = the HMAC can handle? >>>=20 >>>=20 >>> Do you mean that we should be more specific than what we are saying = about the HMAC itself: >>> Payload HMAC HMAC computed over the data to which the Next >>> Header and Payload Data points to. The size of >>> the HMAC is the natural size of the computation >>> output depending on the used function. >>>=20 >>>>=20 >>>>> 5.1. Handling of SEQ_DATA and ACK_DATA >>>>>=20 >>>>>=20 >>>>> A HIP DATA packet contains zero or one SEQ_DATA parameter. The >>>>> presence of a SEQ_DATA parameter indicates that the receiver = MUST ACK >>>>> the HIP DATA packet. A HIP DATA packet that does not contain a >>>>> SEQ_DATA parameter is simply an ACK of a previous HIP DATA = packet and >>>>> MUST NOT be ACKed. >>>>=20 >>>> is it legal to have a HIP DATA with zero SEQ_DATA and zero = ACK_DATA? If not, suggest to say that if SEQ_DATA is missing, ACK_DATA = must be present. >>>>=20 >>>> Can SEQ_DATA be present with no PAYLOAD_MAC parameter? >>>=20 >>>=20 >>> Fixed either SEQ_DATA or ACK_DATA must be present and in case of = SEQ_DATA also PAYLOAD_MAC is required. >>>=20 >>>=20 >>>>=20 >>>>> packet. A host MAY choose to hold the HIP DATA packet carrying = ACK >>>>> for a short period of time to allow for the possibility of >>>>> piggybacking the ACK parameter, in a manner similar to TCP = delayed >>>>> acknowledgments. >>>>=20 >>>> Should the ACK_DATA format allow for multiple sequence numbers, if = so, to avoid carrying a Type and Length field for each one? >>>=20 >>>=20 >>> Yes and now it is defined. >>>=20 >>>=20 >>>>=20 >>>>> 1. The host creates a HIP DATA packet that contains a SEQ_DATA >>>>> parameter. The host is free to choose any value for the = SEQ_DATA >>>>> parameter in the first HIP DATA packet it sends to a = destination. >>>>=20 >>>> This section would be clearer if you replaced "SEQ_DATA parameter" = and "SEQ_DATA value" with "SEQ_DATA sequence number". >>>=20 >>> Fixed. >>>=20 >>>=20 >>> Thanks for reviewing the draft >>> Jan >>>=20 >>>=20 >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --Apple-Mail-10--387499616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
http://www.i= etf.org/id/draft-ietf-hip-hiccups-02.txt

&nbs= p;  Regards,
     = Jan


On Mar 4, 2010, at 3:25 PM, = Jan Melen wrote:

  =
 Message Integrity Code (MIC)  is a hash sum calculated over the
      message which is being integrity protected.  MIC does not use
      secret keys and thus need be protected otherwise against
      tampering.  Essentially MIC is same as MAC with the distinction
      that MIC does not use secret key.  MIC is also often referred as
      Integrity Check Value (ICV), fingerprint, or unkeyed MAC.

I Hope this makes it a bit more clear now that =
there is no key needed when calculating the hash over the =
payload. The edited version is in the same location as previous =
(not yet submitted): http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt=
   = Regards,
     = Jan

On Mar 3, 2010, at 9:08 PM, Jan Melen = wrote:

http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt=

On Feb 22, 2010, at 8:46 PM, = Henderson, Thomas R wrote:



-----Original = Message-----
From: hipsec-bounces@ietf.org
[mailto:hipsec-bounces@ietf.org] On = Behalf Of Gonzalo Camarillo
Sent: Tuesday, January 26, 2010 7:19 = AM
To: = HIP
Subject: [Hipsec] WGLC: = HIP-based overlays

Folks,

we would like = to WGLC the set of specifications that describe how = to
build HIP-based overlays. = The documents under WGLC are the following:

http://tools.ie= tf.org/html/draft-ietf-hip-bone-04
http= ://tools.ietf.org/html/draft-ietf-hip-reload-instance-00
http://tools= .ietf.org/html/draft-ietf-hip-hiccups-01
http://tools.iet= f.org/html/draft-ietf-hip-via-00

This WGLC will = end on February 23rd. Please, send your
comments to this
list.


comments on = draft-ietf-hip-hiccups-01:

Overall, I think that this document = mainly makes sense in the context of HIP BONE and should be folded into = that specification.  However, if kept stand-alone, it would help to = clarify in the introduction that this specifies a data service with the = following semantics:  unordered, duplicate free (subject to = receiver ACK cache size and lifetime), reliable (up to a retransmission = count), authenticated, and encrypted message-based delivery service. =  I would also recommend stating that APIs to higher-level protocols = that might use this service are outside the scope of this = specification.



Added the semantics and that APIs are outside the = scope.


2. Terminology


=   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
=   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in this
  document = are to be interpreted as described in RFC 2119 = [RFC2119].

This section is empty; probably at the = very least it should point to the normative references that define the = terminology in use later in the = document.


Yes, added = reference to RFC 5201 for = terminology.


3. Background on = HIP


=   The HIP protocol specification [RFC5201] defines a number of = messages
  and = parameters.  The parameters are encoded as TLVs, as shown = in
  Section 3.1.2. =  Furthermore, the HIP header carries a Next = Header
  field, = allowing other arbitrary packets to be carried within = HIP
=   packets.

Perhaps this section could go = away or be refactored if this draft is merged to = hip-bone.

4.1. Definition of the = PAYLOAD_MAC Parameter

=     Length =            length = in octets, excluding Type, Length, and
=             &n= bsp;         Padding

are there any minimum or maximum size limitations for this = parameter?  Should the maximum length be tied to the maximum size = that the HMAC can = handle?


Do you = mean that we should be more specific than what we are saying about the = HMAC itself:
  Payload HMAC      HMAC computed over the data =
to which the Next
                     Header and Payload Data points to. The size of
                     the HMAC is the natural size of the computation
                     output depending on the used =
function.


5.1. Handling of = SEQ_DATA and ACK_DATA


  A = HIP DATA packet contains zero or one SEQ_DATA parameter. =  The
=   presence of a SEQ_DATA parameter indicates that the receiver = MUST ACK
  the HIP = DATA packet.  A HIP DATA packet that does not contain = a
  SEQ_DATA = parameter is simply an ACK of a previous HIP DATA packet = and
  MUST NOT be = ACKed.

is it legal to have a HIP DATA with zero = SEQ_DATA and zero ACK_DATA?  If not, suggest to say that if = SEQ_DATA is missing, ACK_DATA must be present.

Can SEQ_DATA be = present with no PAYLOAD_MAC = parameter?


Fixed = either SEQ_DATA or ACK_DATA must be present and in case of SEQ_DATA also = PAYLOAD_MAC is required.



  packet. =  A host MAY choose to hold the HIP DATA packet carrying = ACK
  for a short = period of time to allow for the possibility = of
  piggybacking = the ACK parameter, in a manner similar to TCP = delayed
=   acknowledgments.

Should the ACK_DATA = format allow for multiple sequence numbers, if so, to avoid carrying a = Type and Length field for each = one?


Yes and = now it is defined.



  1. =  The host creates a HIP DATA packet that contains a = SEQ_DATA
=       parameter.  The host is free to = choose any value for the SEQ_DATA
      parameter in the = first HIP DATA packet it sends to a = destination.

This section would be clearer if you = replaced "SEQ_DATA parameter" and "SEQ_DATA value" with "SEQ_DATA = sequence = number".

Fixed.

<= /div>

   Thanks for reviewing the = draft
       = Jan


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

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

= --Apple-Mail-10--387499616-- From rgm@htt-consult.com Fri May 21 00:34:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7ADE3A72CF for ; Fri, 21 May 2010 00:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxLWglTwm59H for ; Fri, 21 May 2010 00:34:31 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id CCAA73A72D3 for ; Thu, 20 May 2010 22:01:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AAFDA68BE9 for ; Fri, 21 May 2010 04:54:28 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uet7rCDjE9oX for ; Fri, 21 May 2010 00:54:19 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 02C1668C4C for ; Fri, 21 May 2010 00:54:17 -0400 (EDT) Message-ID: <4BF61389.1090509@htt-consult.com> Date: Fri, 21 May 2010 01:00:57 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Improving the resiliency of HIP against packet loss 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 May 2010 07:34:31 -0000 Tobias pointed out to me that currently HIP "is rather slow in cases of packet loss". What might we change to address this? Consider standard Internet packet lose and separately high packet lose over lousy (eg 802.15.4) networks. I should point out that the design for IEEE 11073 is that it will take a number of tries to get the data from a sensor to a controller. This protocol just keeps on polling until it gets a response. From rgm@htt-consult.com Fri May 21 09:50:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1B528C243 for ; Fri, 21 May 2010 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_50=0.001, J_CHICKENPOX_32=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 mhYu7ascgfIO for ; Fri, 21 May 2010 09:50:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 62EB43A8315 for ; Fri, 21 May 2010 07:20:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 949BC68C51 for ; Fri, 21 May 2010 14:13:21 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ4SsAePkhTb for ; Fri, 21 May 2010 10:13:12 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 6E68468B65 for ; Fri, 21 May 2010 10:13:12 -0400 (EDT) Message-ID: <4BF69688.9060002@htt-consult.com> Date: Fri, 21 May 2010 10:19:52 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "hipsec@ietf.org" References: <4BF61389.1090509@htt-consult.com> In-Reply-To: <4BF61389.1090509@htt-consult.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Improving the resiliency of HIP against packet loss 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 May 2010 16:50:06 -0000 On 05/21/2010 01:00 AM, Robert Moskowitz wrote: > Tobias pointed out to me that currently HIP "is rather slow in cases > of packet loss". > > What might we change to address this? I think I have worked out a proposal. I will include it in DEX, but only BEX if there is a humm for it. See below. > > Consider standard Internet packet lose and separately high packet lose > over lousy (eg 802.15.4) networks. > > I should point out that the design for IEEE 11073 is that it will take > a number of tries to get the data from a sensor to a controller. This > protocol just keeps on polling until it gets a response. I sends I1 every n msec until it gets an R1 or ICMP error or some sec incase it is sending out to nothing. R sends R1 every n msec until it gets an I2 or ICMP error or some sec incase it is sending out to nothing. I sends I2 every n msec until it gets an R2 or some sec incase R disappeared. R sends R2 every n msec until it gets an ESP payload using the SA or some sec incase I disappeared.. A very simple send/send/send, oh, ACK received. Now there is an attack here. Malice can send an I1 to R with Q's HIT and IP addr. This then becomes a potential attack on Q's battery. But it is one of a lot of attacks where device M sends packets to sensor Q to wake it up and use up its battery. If M sends an I1 to R with Q's HIT&IP, R will start sending R1's until either Q replies or R times out. Q can reply with an ICMP error (hey, I don't do HIP) or something else. Since Q never sent an I1, what is the state machine at? Does Q already have an SA with R and what does receiving an R1 without ever sending an I1? I think the R1 is ignored in all cases. Eventually R times out and stops sending R1s. Just one more battery draining attack. From gonzalo.camarillo@ericsson.com Mon May 24 13:23:34 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87663A635F for ; Mon, 24 May 2010 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.696 X-Spam-Level: X-Spam-Status: No, score=-104.696 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044, 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 IzE2egUAxRzr for ; Mon, 24 May 2010 13:23:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B9B583A6B0A for ; Mon, 24 May 2010 13:23:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7be7ae000002159-97-4bfae02f1f35 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.6F.08537.F20EAFB4; Mon, 24 May 2010 22:23:11 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 22:23:11 +0200 Received: from [138.85.159.70] ([138.85.159.70]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 May 2010 22:23:11 +0200 Message-ID: <4BFAA6B0.6070806@ericsson.com> Date: Mon, 24 May 2010 19:17:52 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2010 20:23:11.0270 (UTC) FILETIME=[EE1B5460:01CAFB7E] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Face-to-face meeting? 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 May 2010 20:23:34 -0000 Folks, we need to decide whether or not we need face-to-face time during the next IETF. Opinions? Thanks, Gonzalo HIP WG co-chair From rgm@htt-consult.com Mon May 24 13:43:56 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F216A3A6F1F for ; Mon, 24 May 2010 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y78s16QmFPq2 for ; Mon, 24 May 2010 13:43:55 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 2AC8F3A6829 for ; Mon, 24 May 2010 13:43:54 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5917468B27; Mon, 24 May 2010 20:37:00 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUq8i6RX61C6; Mon, 24 May 2010 16:36:51 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 581E568C12; Mon, 24 May 2010 16:36:51 -0400 (EDT) Message-ID: <4BFAE4F6.7090602@htt-consult.com> Date: Mon, 24 May 2010 16:43:34 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4BFAA6B0.6070806@ericsson.com> In-Reply-To: <4BFAA6B0.6070806@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] Face-to-face meeting? 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 May 2010 20:43:56 -0000 On 05/24/2010 12:17 PM, Gonzalo Camarillo wrote: > Folks, > > we need to decide whether or not we need face-to-face time during the > next IETF. Opinions? > It would be 'nice' to have a serious document review at that time. There shouldn't be quite the 'hand waving' we did at Anahiem, but actual documents for people to have read over and be reading to hum on or supply changes. From thomas.r.henderson@boeing.com Mon May 24 20:36:52 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D4C3A68D0 for ; Mon, 24 May 2010 20:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE5JUiUEMwun for ; Mon, 24 May 2010 20:36:49 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 2CB103A696D for ; Mon, 24 May 2010 20:36:49 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o4P3aPu9009475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 May 2010 22:36:28 -0500 (CDT) 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 o4P3aPoj010903; Mon, 24 May 2010 20:36:25 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o4P3aOqZ010900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 24 May 2010 20:36:24 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 24 May 2010 20:36:24 -0700 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" , Gonzalo Camarillo Date: Mon, 24 May 2010 20:36:24 -0700 Thread-Topic: [Hipsec] Face-to-face meeting? Thread-Index: Acr7gdLbRLG5s3/CRXqBbQXSe3bSrgAOXDsw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE97161CD@XCH-NW-10V.nw.nos.boeing.com> References: <4BFAA6B0.6070806@ericsson.com> <4BFAE4F6.7090602@htt-consult.com> In-Reply-To: <4BFAE4F6.7090602@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] Face-to-face meeting? 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 May 2010 03:36:52 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: Monday, May 24, 2010 1:44 PM > To: Gonzalo Camarillo > Cc: HIP > Subject: Re: [Hipsec] Face-to-face meeting? > > On 05/24/2010 12:17 PM, Gonzalo Camarillo wrote: > > Folks, > > > > we need to decide whether or not we need face-to-face time > during the > > next IETF. Opinions? > > > > It would be 'nice' to have a serious document review at that time. > > There shouldn't be quite the 'hand waving' we did at Anahiem, > but actual > documents for people to have read over and be reading to hum on or > supply changes. > I cannot attend but I tend to agree that a review would be helpful to move = things along, if you can form a quorum. - Tom From rgm@htt-consult.com Tue May 25 13:03:44 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E223A6A55 for ; Tue, 25 May 2010 13:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZA6YQVQ9AcT for ; Tue, 25 May 2010 13:03:43 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A45363A6A28 for ; Tue, 25 May 2010 13:03:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0609C68C13 for ; Tue, 25 May 2010 19:56:46 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soe-kj-TswjQ for ; Tue, 25 May 2010 15:56:37 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3193268B42 for ; Tue, 25 May 2010 15:56:37 -0400 (EDT) Message-ID: <4BFC2D0A.3030600@htt-consult.com> Date: Tue, 25 May 2010 16:03:22 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Re-purposing HIP parameters 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 May 2010 20:03:44 -0000 This is primarily about what in 5201 is HIP_HMAC and HMAC2. I have renamed them HIP_MAC in 5201-bis, but HMAC is still the underlying function. But in HIP DEX, I am using CMAC. This is actually not so easy a change, as CMAC requires a uniformly randomly distributed key, unlike HMAC, and DIffie-Hellman keys are NOT uniformly randomly distributed. But I've worked that part out. And I have a HIP_MAC that if you are doing a DEX exchange will be just fine with CMAC. Thing is do implementors want to have they code for HIP_MAC be dependent on knowing this is a BEX or DEX exchange (note the HIT_SUITE will key this key this off very easily)? From rgm@htt-consult.com Tue May 25 13:14:12 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3328D3A6812 for ; Tue, 25 May 2010 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiWTmnozeomD for ; Tue, 25 May 2010 13:14:10 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 999763A6405 for ; Tue, 25 May 2010 13:14:10 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 68B5668BA4 for ; Tue, 25 May 2010 20:07:12 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7sYKp2xcaFR for ; Tue, 25 May 2010 16:07:03 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 543F568C13 for ; Tue, 25 May 2010 16:07:03 -0400 (EDT) Message-ID: <4BFC2F7D.4060903@htt-consult.com> Date: Tue, 25 May 2010 16:13:49 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Small definition error on HIP_HMAC in 5201 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 May 2010 20:14:12 -0000 As I plow through the text on HIP_HMAC and working on having it work with CMAC as well I noticed on pg 36 of 5201: | HMAC | 61505 | variable | HMAC-based message | | | | | authentication code, | | | | | with key material | | | | | from HIP_TRANSFORM | | | | | | | HMAC_2 | 61569 | variable | HMAC based message | | | | | authentication code, | | | | | with key material | | | | | from HIP_TRANSFORM. | | | | | Compared to HMAC, the | No, no, that is key material from KEYMAT, not any particular HIP Parameter. And KEYMAT in BEX comes for the DIFFIE_HELLMAN parameter (in DEX it will come from PK_WRAP). No where else is the definition error propagated. So, I plan on just changing the the text here to: key material from KEYMAT And leave it at that unless someone here has some insight to add. From heer@informatik.rwth-aachen.de Wed May 26 03:37:16 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E8F3A68C1 for ; Wed, 26 May 2010 03:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuViCTFInDc1 for ; Wed, 26 May 2010 03:37:14 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 9BD283A68CE for ; Wed, 26 May 2010 03:37:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L30004KPW5S6830@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 12:37:04 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,303,1272837600"; d="scan'208";a="58966111" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 26 May 2010 12:37:04 +0200 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L3000AR2W5SL050@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 12:37:04 +0200 (CEST) From: Tobias Heer Date: Wed, 26 May 2010 12:37:10 +0200 Message-id: To: HIP WG X-Mailer: Apple Mail (2.1078) Subject: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:37:16 -0000 Hello, I have a question regarding some text in RFC5201 that conflicts with the crypto agility that we envisioned. The new BEX will have to start the negotiations of the DH groups already in I1 to allow the Responder to pick a sensible DH group (there are simple countermeasures against downgrade attacks, too, so don't worry). Therefore, the I1 becomes slightly more important than it was (although it stays unsigned and cheap). In Section 4.1 RFC5201 states: ... 705 The Initiator first sends a trigger packet, I1, to the 706 Responder. The packet contains the HIT of the Initiator 707 and possibly the HIT of the Responder, if it is known. 708 Moreover, it contains a list of Diffie Hellman Group IDs 709 supported by the Initiator. Note 710 that in some cases it may be possible to replace this trigger 711 packet by some other form of a trigger, in which case the 712 protocol starts with the Responder sending the R1 packet. ... With the DH group negotiations already starting in I1 it becomes difficult to omit the I1 (you can do it but you lose DH crypto agility). Moreover, I doubt that omitting the I1 works well even without considering the DH group negotiations because some of the measures to keep the Responder stateless until I2 rely on having information from the I1 (IP address or HIT) for the puzzle/ opaque data field. My questions are: Is anyone using or does anyone intent to use this omission of the I1? Is there any specification on how to do it (at least this is the only place in 5201 where it is mentioned). Do we need this feature because there are cases where you cannot send an I1? And finally: can we live without that note? Of course, even if we skip it there is nothing that will keep someone defining it as an extension to the base specs if it is needed in the future. Thanks for any input. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From samu.varjonen@hiit.fi Wed May 26 03:59:48 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF563A68CE for ; Wed, 26 May 2010 03:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bygPKDrumuDF for ; Wed, 26 May 2010 03:59:47 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 61C3D3A68AE for ; Wed, 26 May 2010 03:59:46 -0700 (PDT) Received: from [128.214.113.196] (sutherland.hiit.fi [128.214.113.196]) by argo.otaverkko.fi (Postfix) with ESMTP id 3EE9825ED0E; Wed, 26 May 2010 13:59:37 +0300 (EEST) Message-ID: <4BFCFF0D.10309@hiit.fi> Date: Wed, 26 May 2010 13:59:25 +0300 From: Samu Varjonen User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Tobias Heer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP WG Subject: Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:59:48 -0000 Tobias Heer wrote: > Hello, > > I have a question regarding some text in RFC5201 that conflicts with the crypto agility that we envisioned. > > The new BEX will have to start the negotiations of the DH groups already in I1 to allow the Responder to pick a sensible DH group (there are simple countermeasures against downgrade attacks, too, so don't worry). > Therefore, the I1 becomes slightly more important than it was (although it stays unsigned and cheap). > > > In Section 4.1 RFC5201 states: > > ... > 705 The Initiator first sends a trigger packet, I1, to the > 706 Responder. The packet contains the HIT of the Initiator > 707 and possibly the HIT of the Responder, if it is known. > 708 Moreover, it contains a list of Diffie Hellman Group IDs > 709 supported by the Initiator. Note > 710 that in some cases it may be possible to replace this trigger > 711 packet by some other form of a trigger, in which case the > 712 protocol starts with the Responder sending the R1 packet. > ... > > With the DH group negotiations already starting in I1 it becomes difficult to omit the I1 (you can do it but you lose DH crypto agility). > Moreover, I doubt that omitting the I1 works well even without considering the DH group negotiations because some of the measures to keep the Responder stateless until I2 rely on having information from the I1 (IP address or HIT) for the puzzle/ opaque data field. > > > My questions are: > Is anyone using or does anyone intent to use this omission of the I1? Check out draft-ietf-hip-hiccups-02 Section 5.3 " A host receiving a HIP DATA packet makes decision whether to process the packet or not. If the host, following its local policy, suspects that this packet could be part of a DoS attack. The host MAY respond with an R1 packet to the HIP DATA packet... " > Is there any specification on how to do it (at least this is the only place in 5201 where it is mentioned). > Do we need this feature because there are cases where you cannot send an I1? > And finally: can we live without that note? > > Of course, even if we skip it there is nothing that will keep someone defining it as an extension to the base specs if it is needed in the future. > > Thanks for any input. > > Tobias > > From rene.hummen@informatik.rwth-aachen.de Wed May 26 06:47:29 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEAD3A68F3 for ; Wed, 26 May 2010 06:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFqTaEbDZcDH for ; Wed, 26 May 2010 06:47:28 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 9976F3A6928 for ; Wed, 26 May 2010 06:47:28 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 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 <0L3100LX84YUZA00@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 15:47:18 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,304,1272837600"; d="scan'208";a="58997762" 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; Wed, 26 May 2010 15:47:19 +0200 Received: from umic-137-226-154-190.nn.rwth-aachen.de ([unknown] [137.226.154.190]) 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 <0L31003WJ4YUGV40@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 15:47:18 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-transfer-encoding: quoted-printable Date: Wed, 26 May 2010 15:47:18 +0200 Message-id: <279FACB2-90A1-465A-951B-7F1FC8214404@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1078) Subject: Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 13:47:30 -0000 On May 26, 2010, at 12:59 PM, Samu Varjonen wrote: > Tobias Heer wrote: >> Hello, I have a question regarding some text in RFC5201 that = conflicts with the crypto agility that we envisioned. >> =09 >> The new BEX will have to start the negotiations of the DH groups = already in I1 to allow the Responder to pick a sensible DH group (there = are simple countermeasures against downgrade attacks, too, so don't = worry). >> Therefore, the I1 becomes slightly more important than it was = (although it stays unsigned and cheap). >> In Section 4.1 RFC5201 states: >> ... >> 705 The Initiator first sends a trigger packet, I1, to the = 706 Responder. The packet contains the HIT of the Initiator = 707 and possibly the HIT of the Responder, if it is known. 708 = Moreover, it contains a list of Diffie Hellman Group IDs 709 = supported by the Initiator. Note 710 that in some = cases it may be possible to replace this trigger 711 packet by = some other form of a trigger, in which case the 712 protocol = starts with the Responder sending the R1 packet. ... >> With the DH group negotiations already starting in I1 it becomes = difficult to omit the I1 (you can do it but you lose DH crypto agility). >> Moreover, I doubt that omitting the I1 works well even without = considering the DH group negotiations because some of the measures to = keep the Responder stateless until I2 rely on having information from = the I1 (IP address or HIT) for the puzzle/ opaque data field. >> My questions are: Is anyone using or does anyone intent to use this = omission of the I1? >=20 > Check out draft-ietf-hip-hiccups-02 Section 5.3 > " > A host receiving a HIP DATA packet makes decision whether to process > the packet or not. If the host, following its local policy, suspects > that this packet could be part of a DoS attack. The host MAY respond > with an R1 packet to the HIP DATA packet... > " You could adapt draft-ietf-hip-hiccups-02 Section 5.3 as follows, in = order to support the crypto agility changes introduced in RFC5201-bis: " ...If the host chooses to respond to the HIP DATA with an R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in [RFC5201] Section 5.3.2. " Add: "The host should thereby choose its preferred DH group for the DH = value." This way, the BEX can continue as supposed by hiccups, if the two hosts = agree on the DH group. Otherwise, the host, that was initially sending = the HIP DATA packet, would advertise the supported DH groups by sending = a corresponding I1. >> Is there any specification on how to do it (at least this is the only = place in 5201 where it is mentioned). >> Do we need this feature because there are cases where you cannot send = an I1? >> And finally: can we live without that note? >> Of course, even if we skip it there is nothing that will keep someone = defining it as an extension to the base specs if it is needed in the = future. >> Thanks for any input. >> Tobias Ciao, Ren=E9 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://ds.rwth-aachen.de/members/hummen From heer@informatik.rwth-aachen.de Wed May 26 07:17:00 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7893A6905 for ; Wed, 26 May 2010 07:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, 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 Bu7qro5a1su0 for ; Wed, 26 May 2010 07:16:59 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 1BF123A691A for ; Wed, 26 May 2010 07:16:59 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 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 <0L31004616C16CA0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 16:16:49 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,304,1272837600"; d="scan'208";a="31251682" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 26 May 2010 16:16:49 +0200 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L3100APT6C1L090@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 26 May 2010 16:16:49 +0200 (CEST) From: Tobias Heer In-reply-to: <279FACB2-90A1-465A-951B-7F1FC8214404@cs.rwth-aachen.de> Date: Wed, 26 May 2010 16:16:54 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <279FACB2-90A1-465A-951B-7F1FC8214404@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1078) Cc: =?iso-8859-1?Q?Ren=E9_Hummen?= Subject: Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 14:17:00 -0000 Hi,=20 Am 26.05.2010 um 15:47 schrieb Ren=E9 Hummen: > On May 26, 2010, at 12:59 PM, Samu Varjonen wrote: >> Tobias Heer wrote: >>> Hello, I have a question regarding some text in RFC5201 that = conflicts with the crypto agility that we envisioned. >>> =09 >>> The new BEX will have to start the negotiations of the DH groups = already in I1 to allow the Responder to pick a sensible DH group (there = are simple countermeasures against downgrade attacks, too, so don't = worry). >>> Therefore, the I1 becomes slightly more important than it was = (although it stays unsigned and cheap). >>> In Section 4.1 RFC5201 states: >>> ... >>> 705 The Initiator first sends a trigger packet, I1, to the = 706 Responder. The packet contains the HIT of the Initiator = 707 and possibly the HIT of the Responder, if it is known. 708 = Moreover, it contains a list of Diffie Hellman Group IDs 709 = supported by the Initiator. Note 710 that in some = cases it may be possible to replace this trigger 711 packet by = some other form of a trigger, in which case the 712 protocol = starts with the Responder sending the R1 packet. ... >>> With the DH group negotiations already starting in I1 it becomes = difficult to omit the I1 (you can do it but you lose DH crypto agility). >>> Moreover, I doubt that omitting the I1 works well even without = considering the DH group negotiations because some of the measures to = keep the Responder stateless until I2 rely on having information from = the I1 (IP address or HIT) for the puzzle/ opaque data field. >>> My questions are: Is anyone using or does anyone intent to use this = omission of the I1? >>=20 >> Check out draft-ietf-hip-hiccups-02 Section 5.3 >> " >> A host receiving a HIP DATA packet makes decision whether to process >> the packet or not. If the host, following its local policy, suspects >> that this packet could be part of a DoS attack. The host MAY respond >> with an R1 packet to the HIP DATA packet... >> " >=20 > You could adapt draft-ietf-hip-hiccups-02 Section 5.3 as follows, in = order to support the crypto agility changes introduced in RFC5201-bis: > " > ...If the host chooses to > respond to the HIP DATA with an R1 packet, it creates a new R1 or > selects a precomputed R1 according to the format described in > [RFC5201] Section 5.3.2. > " > Add: > "The host should thereby choose its preferred DH group for the DH = value." >=20 > This way, the BEX can continue as supposed by hiccups, if the two = hosts agree on the DH group. Otherwise, the host, that was initially = sending the HIP DATA packet, would advertise the supported DH groups by = sending a corresponding I1. >=20 That would work for me - and it could be a general procedure for = extensions that use something else than an I1 as trigger. --=20 Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group=20 RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From heer@informatik.rwth-aachen.de Thu May 27 05:18:30 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE8A3A6AC3 for ; Thu, 27 May 2010 05:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amBUZOdTrwpQ for ; Thu, 27 May 2010 05:18:08 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id EB22D3A6AB7 for ; Thu, 27 May 2010 05:18:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L3200KTHVHUKSG0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 27 May 2010 14:17:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; d="scan'208";a="31340972" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 27 May 2010 14:17:54 +0200 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L3200DJPVHUR180@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 27 May 2010 14:17:54 +0200 (CEST) From: Tobias Heer Date: Thu, 27 May 2010 14:18:00 +0200 Message-id: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> To: HIP WG X-Mailer: Apple Mail (2.1078) Subject: [Hipsec] Memory-bound puzzles in BEX 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 May 2010 12:18:30 -0000 Hi everyone, RFC5201 states that memory bound puzzles should be reconsidered for future versions of the document. The exact text is here: 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. At the time of the decision, the idea of memory-bound functions was relatively new and their IPR status were unknown. Once there is more experience about memory-bound functions and once their IPR status is better known, it may be reasonable to reconsider this decision. I am asking the list if the time for reconsideration has come. Should we delve deeper into non CPU-bound puzzles for RFC5201-bis or should we keep this note for future revisions. Is there anyone with a background on memory-bound puzzles interested in having them in RFC5201-bis? Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From mkomu@cs.hut.fi Thu May 27 08:32:01 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2068A3A6B18 for ; Thu, 27 May 2010 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wooo9j5iTuy5 for ; Thu, 27 May 2010 08:32:00 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id DA5443A6B0F for ; Thu, 27 May 2010 08:31:59 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OHf3k-00056U-IL for hipsec@ietf.org; Thu, 27 May 2010 18:31:48 +0300 Message-ID: <4BFE90B5.7080308@cs.hut.fi> Date: Thu, 27 May 2010 18:33:09 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100525 Shredder/3.0.6pre MIME-Version: 1.0 To: hipsec@ietf.org References: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> In-Reply-To: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Memory-bound puzzles in BEX 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 May 2010 15:32:01 -0000 On 27/05/10 15:18, Tobias Heer wrote: Hi Tobias, I'd be leaning a bit towards CPU-bound puzzles but perhaps just because we've been just using them earlier. Big puzzles of both types can be problematic for e.g. sensor devices with limited memory and CPU capabilities, so in that sense it's a tie. Perhaps it's actually battery life (drained by CPU usage) time that seems to suffer from technological advances, so perhaps that could used to promote either of the types. The current CPU-based puzzles are parallelizable which means that a bot net could be used for solving a puzzle in a distributed way. As an alternative, we could also switch to serialized puzzles. Anyway, I don't think this has big impact - I guess it's ok to distribute the solving in the end. > Hi everyone, > > RFC5201 states that memory bound puzzles should be reconsidered for future versions of the document. The exact text is here: > > 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. At the time of the decision, the > idea of memory-bound functions was relatively new and their > IPR status were unknown. Once there is more experience > about memory-bound functions and once their IPR status is > better known, it may be reasonable to reconsider this > decision. > > I am asking the list if the time for reconsideration has come. Should we delve deeper into non CPU-bound puzzles for RFC5201-bis or should we keep this note for future revisions. > Is there anyone with a background on memory-bound puzzles interested in having them in RFC5201-bis? > > Best regards, > > Tobias > > > > > From rgm@htt-consult.com Thu May 27 08:46:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332543A6AD0 for ; Thu, 27 May 2010 08:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqGTRYyfbpxQ for ; Thu, 27 May 2010 08:46:30 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 76D1E3A6AA3 for ; Thu, 27 May 2010 08:46:29 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id CBBAC68BE8; Thu, 27 May 2010 15:39:06 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4hlfH9Xa03u; Thu, 27 May 2010 11:38:56 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DC00B68B4C; Thu, 27 May 2010 11:38:56 -0400 (EDT) Message-ID: <4BFE93AB.8050309@htt-consult.com> Date: Thu, 27 May 2010 11:45:47 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Miika Komu References: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> <4BFE90B5.7080308@cs.hut.fi> In-Reply-To: <4BFE90B5.7080308@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Memory-bound puzzles in BEX 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 May 2010 15:46:31 -0000 On 05/27/2010 11:33 AM, Miika Komu wrote: > On 27/05/10 15:18, Tobias Heer wrote: > > Hi Tobias, > > I'd be leaning a bit towards CPU-bound puzzles but perhaps just > because we've been just using them earlier. Big puzzles of both types > can be problematic for e.g. sensor devices with limited memory and CPU > capabilities, so in that sense it's a tie. Perhaps it's actually > battery life (drained by CPU usage) time that seems to suffer from > technological advances, so perhaps that could used to promote either > of the types. Some good points. What is memory bound mean to a 8Gb notebook compared to a 64K sensor? How do you design a memory bound puzzle that fits each? Or does BEX have one and DEX have another? Battery drain is a dangerous path to go down. Granted that CPU bound SHOULD be harder on a battery than memory bound. > > The current CPU-based puzzles are parallelizable which means that a > bot net could be used for solving a puzzle in a distributed way. Does this lead to memory bound puzzles as a way to mitigate botnet attacks against a puzzle? > As an alternative, we could also switch to serialized puzzles. I am not getting what a serialized puzzle is. > Anyway, I don't think this has big impact - I guess it's ok to > distribute the solving in the end. > >> Hi everyone, >> >> RFC5201 states that memory bound puzzles should be reconsidered for >> future versions of the document. The exact text is here: >> >> 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. At the time of the decision, the >> idea of memory-bound functions was relatively new and their >> IPR status were unknown. Once there is more experience >> about memory-bound functions and once their IPR status is >> better known, it may be reasonable to reconsider this >> decision. >> >> I am asking the list if the time for reconsideration has come. Should >> we delve deeper into non CPU-bound puzzles for RFC5201-bis or should >> we keep this note for future revisions. >> Is there anyone with a background on memory-bound puzzles interested >> in having them in RFC5201-bis? >> >> Best regards, >> >> Tobias >> >> >> >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From mkomu@cs.hut.fi Thu May 27 23:27:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752353A687E for ; Thu, 27 May 2010 23:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dVqPoFgRg6H for ; Thu, 27 May 2010 23:27:40 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 5FA893A684D for ; Thu, 27 May 2010 23:27:40 -0700 (PDT) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OHt2W-00079Y-HH for hipsec@ietf.org; Fri, 28 May 2010 09:27:28 +0300 Message-ID: <4BFF62A5.7060508@cs.hut.fi> Date: Fri, 28 May 2010 09:28:53 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100525 Shredder/3.0.6pre MIME-Version: 1.0 To: hipsec@ietf.org References: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> <4BFE90B5.7080308@cs.hut.fi> <4BFE93AB.8050309@htt-consult.com> In-Reply-To: <4BFE93AB.8050309@htt-consult.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Hipsec] Memory-bound puzzles in BEX 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 May 2010 06:27:41 -0000 On 27/05/10 18:45, Robert Moskowitz wrote: Hi, > On 05/27/2010 11:33 AM, Miika Komu wrote: >> On 27/05/10 15:18, Tobias Heer wrote: >> >> Hi Tobias, >> >> I'd be leaning a bit towards CPU-bound puzzles but perhaps just >> because we've been just using them earlier. Big puzzles of both types >> can be problematic for e.g. sensor devices with limited memory and CPU >> capabilities, so in that sense it's a tie. Perhaps it's actually >> battery life (drained by CPU usage) time that seems to suffer from >> technological advances, so perhaps that could used to promote either >> of the types. > > Some good points. What is memory bound mean to a 8Gb notebook compared > to a 64K sensor? How do you design a memory bound puzzle that fits each? > Or does BEX have one and DEX have another? I think BEX and DEX should have the same puzzle. Maybe you could artificially limit the puzzle difficulty in DEX and recommend a smaller size (independently of what puzzle technology will be used). > Battery drain is a dangerous path to go down. Granted that CPU bound > SHOULD be harder on a battery than memory bound. > > >> >> The current CPU-based puzzles are parallelizable which means that a >> bot net could be used for solving a puzzle in a distributed way. > > Does this lead to memory bound puzzles as a way to mitigate botnet > attacks against a puzzle? > >> As an alternative, we could also switch to serialized puzzles. > > I am not getting what a serialized puzzle is. Brent Waters, Ari Juels, J. Alex Halderman, and Edward W. Felten. New Client Puzzle Outsourcing Techniques for DoS Resistance. In Pro- ceedings of the 11th ACM conference on Computer and communications security CCS ’04, 2004. R.L. Rivest, A. Shamir, and D. Wagner. Time-lock puzzles and timed- release crypto. Technical Report MIT/LCS/TR-684, MIT, 1996. >> Anyway, I don't think this has big impact - I guess it's ok to >> distribute the solving in the end. >> >>> Hi everyone, >>> >>> RFC5201 states that memory bound puzzles should be reconsidered for >>> future versions of the document. The exact text is here: >>> >>> 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. At the time of the decision, the >>> idea of memory-bound functions was relatively new and their >>> IPR status were unknown. Once there is more experience >>> about memory-bound functions and once their IPR status is >>> better known, it may be reasonable to reconsider this >>> decision. >>> >>> I am asking the list if the time for reconsideration has come. Should >>> we delve deeper into non CPU-bound puzzles for RFC5201-bis or should >>> we keep this note for future revisions. >>> Is there anyone with a background on memory-bound puzzles interested >>> in having them in RFC5201-bis? >>> >>> Best regards, >>> >>> Tobias >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From rgm@htt-consult.com Fri May 28 05:30:56 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF533A6781 for ; Fri, 28 May 2010 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDHCuAKZvHsW for ; Fri, 28 May 2010 05:30:55 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 618343A6822 for ; Fri, 28 May 2010 05:30:55 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9B0E668B94; Fri, 28 May 2010 12:14:20 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flRPBMRadY+I; Fri, 28 May 2010 08:14:09 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A739F68B4C; Fri, 28 May 2010 08:14:09 -0400 (EDT) Message-ID: <4BFFB52E.4030804@htt-consult.com> Date: Fri, 28 May 2010 08:21:02 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Miika Komu References: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de> <4BFE90B5.7080308@cs.hut.fi> <4BFE93AB.8050309@htt-consult.com> <4BFF62A5.7060508@cs.hut.fi> In-Reply-To: <4BFF62A5.7060508@cs.hut.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Memory-bound puzzles in BEX 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 May 2010 12:30:56 -0000 On 05/28/2010 02:28 AM, Miika Komu wrote: > On 27/05/10 18:45, Robert Moskowitz wrote: > > Hi, > >> On 05/27/2010 11:33 AM, Miika Komu wrote: >>> On 27/05/10 15:18, Tobias Heer wrote: >>> >>> Hi Tobias, >>> >>> I'd be leaning a bit towards CPU-bound puzzles but perhaps just >>> because we've been just using them earlier. Big puzzles of both types >>> can be problematic for e.g. sensor devices with limited memory and CPU >>> capabilities, so in that sense it's a tie. Perhaps it's actually >>> battery life (drained by CPU usage) time that seems to suffer from >>> technological advances, so perhaps that could used to promote either >>> of the types. >> >> Some good points. What is memory bound mean to a 8Gb notebook compared >> to a 64K sensor? How do you design a memory bound puzzle that fits each? >> Or does BEX have one and DEX have another? > > I think BEX and DEX should have the same puzzle. Maybe you could > artificially limit the puzzle difficulty in DEX and recommend a > smaller size (independently of what puzzle technology will be used). Can't entirely. DEX does not have a hash primative, nor the HMAC function. Dave McGrew has told me he was looking for a good compress function for HIT generation from a small ECC key, but this will not be good to use for the puzzle as the underlying hash. My plan is to build the puzzle around CMAC. I am not sure about how appropriate CMAC is for this. Another option is to use ECC encrypt function: find a keypair that encrypts a value to generate the puzzle. It would be very short keypairs.... >> Battery drain is a dangerous path to go down. Granted that CPU bound >> SHOULD be harder on a battery than memory bound. >> >> >>> >>> The current CPU-based puzzles are parallelizable which means that a >>> bot net could be used for solving a puzzle in a distributed way. >> >> Does this lead to memory bound puzzles as a way to mitigate botnet >> attacks against a puzzle? >> >>> As an alternative, we could also switch to serialized puzzles. >> >> I am not getting what a serialized puzzle is. > > Brent Waters, Ari Juels, J. Alex Halderman, and Edward W. Felten. > New Client Puzzle Outsourcing Techniques for DoS Resistance. In Pro- > ceedings of the 11th ACM conference on Computer and communications > security CCS ’04, 2004. URL? > > R.L. Rivest, A. Shamir, and D. Wagner. Time-lock puzzles and timed- > release crypto. Technical Report MIT/LCS/TR-684, MIT, 1996. Oh, time based. I THINK I get it. > >>> Anyway, I don't think this has big impact - I guess it's ok to >>> distribute the solving in the end. >>> >>>> Hi everyone, >>>> >>>> RFC5201 states that memory bound puzzles should be reconsidered for >>>> future versions of the document. The exact text is here: >>>> >>>> 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. At the time of the decision, the >>>> idea of memory-bound functions was relatively new and their >>>> IPR status were unknown. Once there is more experience >>>> about memory-bound functions and once their IPR status is >>>> better known, it may be reasonable to reconsider this >>>> decision. >>>> >>>> I am asking the list if the time for reconsideration has come. Should >>>> we delve deeper into non CPU-bound puzzles for RFC5201-bis or should >>>> we keep this note for future revisions. >>>> Is there anyone with a background on memory-bound puzzles interested >>>> in having them in RFC5201-bis? >>>> >>>> Best regards, >>>> >>>> Tobias >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From zfhu2001@163.com Sun May 30 01:43:59 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436603A67E2 for ; Sun, 30 May 2010 01:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.754 X-Spam-Level: **** X-Spam-Status: No, score=4.754 tagged_above=-999 required=5 tests=[BAYES_95=3, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 C+w9SUN+7nD4 for ; Sun, 30 May 2010 01:43:58 -0700 (PDT) Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by core3.amsl.com (Postfix) with ESMTP id CA1B83A67D1 for ; Sun, 30 May 2010 01:43:56 -0700 (PDT) Received: from zfhu (unknown [123.119.252.69]) by smtp4 (Coremail) with SMTP id DtGowLCL5AI7JQJM8nlKAA--.24594S2; Sun, 30 May 2010 16:43:39 +0800 (CST) Date: Sun, 30 May 2010 16:43:38 +0800 From: "HU Zhangfeng" To: "hipsec" References: <5E1C2F4F-6527-4FDC-9ED6-BC5358F7716A@cs.rwth-aachen.de>, <4BFE90B5.7080308@cs.hut.fi>, <4BFE93AB.8050309@htt-consult.com>, <4BFF62A5.7060508@cs.hut.fi> Message-ID: <201005301643379532972@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon477460204146_=====" X-CM-TRANSID: DtGowLCL5AI7JQJM8nlKAA--.24594S2 X-Coremail-Antispam: 1Uf129KBjvdXoWrtF1rCw1UtFyxJry7Xw47Arb_yoWfCFb_u3 srGryqq3yIkw1Svw4xA3yUZryxWay3Wr13X3y0va1rGa4ktw4DJrZ0ga9xua4fGa1agrZx Crn8Xw42vry3WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUb66zUUUUUU== X-CM-SenderInfo: p2ik3jqqqrqiywtou0bp/1tbitg-fiUtUjvXiqwABsD Subject: [Hipsec] [hipsec] Simultaneous end-host mobility & High availability for RVS servers(mechanism of backup RVS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 08:43:59 -0000 This is a multi-part message in MIME format. --=====003_Dragon477460204146_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit hi all, As you know, 1) the scenario of simultaneous end-host mobility maybe actually exist in real world, while it still has not been specified in HIP. 2) RVS servers in HIP functioning as HAs in MIP play very important roles for the management of mobile nodes. If a RVS server stops working, then all the mobile nodes managed by it should be lost in the network and cannot be re-managed any more before the mobile nodes re-register to a new RVS server. So I'm considering doing some work on both or either of the two above-mentioned topics, and I'm wondering if some ones have completed some work or got some achievement on both of them. Thank you. 2010-05-30 Zhangfeng HU, phD candidate of Broadband Network Research Center, State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing, China Email:zfhu2001@gmail.com Tel:86+13811892137 --=====003_Dragon477460204146_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4NzAyIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9Mj5oaSBhbGwsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPkFzIHlvdSBrbm93LCZuYnNwOzEpIHRoZSBzY2Vu YXJpbyBvZiANCnNpbXVsdGFuZW91cyZuYnNwO2VuZC1ob3N0Jm5ic3A7bW9iaWxpdHkgbWF5YmUg YWN0dWFsbHkgZXhpc3QgaW4gcmVhbCB3b3JsZCwgDQp3aGlsZSBpdCBzdGlsbCBoYXMgbm90IGJl ZW4gc3BlY2lmaWVkIGluIEhJUC4mbmJzcDsgMikgUlZTIHNlcnZlcnMgaW4gSElQIA0KZnVuY3Rp b25pbmcgYXMgSEFzIGluIE1JUCBwbGF5IHZlcnkgaW1wb3J0YW50IHJvbGVzIGZvciB0aGUgbWFu YWdlbWVudCBvZiBtb2JpbGUgDQpub2Rlcy4gSWYgYSBSVlMgc2VydmVyIHN0b3BzIHdvcmtpbmcs IHRoZW4gYWxsIHRoZSBtb2JpbGUgbm9kZXMgbWFuYWdlZCBieSANCml0Jm5ic3A7c2hvdWxkIGJl IGxvc3QgaW4gdGhlIG5ldHdvcmsgYW5kIGNhbm5vdCBiZSByZS1tYW5hZ2VkIGFueSBtb3JlIGJl Zm9yZSANCnRoZSBtb2JpbGUgbm9kZXMgcmUtcmVnaXN0ZXIgdG8gYSBuZXcgUlZTIHNlcnZlci48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPlNvIEknbSBjb25zaWRlcmluZyBkb2luZyBzb21l IHdvcmsgb24gYm90aCBvciBlaXRoZXIgDQpvZiZuYnNwO3RoZSB0d28gYWJvdmUtbWVudGlvbmVk IHRvcGljcywgYW5kIEknbSB3b25kZXJpbmcgaWYmbmJzcDtzb21lIG9uZXMgaGF2ZSANCmNvbXBs ZXRlZCBzb21lIHdvcmsgb3IgZ290IHNvbWUgYWNoaWV2ZW1lbnQgb24gYm90aCBvZiB0aGVtLiBU aGFuayANCnlvdS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9Mj4yMDEwLTA1 LTMwIDwvRk9OVD48L0RJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIA0Kc2l6ZT0yPg0KPEhSIHN0eWxl PSJXSURUSDogMTAwcHgiIGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+ DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjxTUEFOPg0KPERJVj4NCjxESVY+PEZP TlQgc2l6ZT0xPlpoYW5nZmVuZyBIVSwgcGhEJm5ic3A7Y2FuZGlkYXRlIG9mPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTE+QnJvYWRiYW5kIE5ldHdvcmsgUmVzZWFyY2ggQ2VudGVyLDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPlN0YXRlIEtleSBMYWJvcmF0b3J5IG9mIE5l dHdvcmtpbmcgYW5kIFN3aXRjaGluZyBUZWNobm9sb2d5LCANCjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0xPkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmlj YXRpb25zLCBCZWlqaW5nLCANCkNoaW5hPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+RW1haWw6emZodTIwMDFAZ21h aWwuY29tPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgDQpzaXplPTE+VGVsOjg2KzEz ODExODkyMTM3PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9C T0RZPjwvSFRNTD4NCg== --=====003_Dragon477460204146_=====-- From zfhu2001@163.com Sun May 30 02:06:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B590D3A67B5 for ; Sun, 30 May 2010 02:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.877 X-Spam-Level: *** X-Spam-Status: No, score=3.877 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_95=3, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLMAIq39KDfa for ; Sun, 30 May 2010 02:06:31 -0700 (PDT) Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by core3.amsl.com (Postfix) with ESMTP id DE4213A635F for ; Sun, 30 May 2010 02:06:29 -0700 (PDT) Received: from zfhu (unknown [123.119.252.69]) by smtp4 (Coremail) with SMTP id DtGowLALNpeEKgJMhBtLAA--.11781S2; Sun, 30 May 2010 17:06:13 +0800 (CST) Date: Sun, 30 May 2010 17:06:11 +0800 From: "HU Zhangfeng" To: "hipsec" Message-ID: <201005301706108432645@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon006167416721_=====" X-CM-TRANSID: DtGowLALNpeEKgJMhBtLAA--.11781S2 X-Coremail-Antispam: 1Uf129KBjvdXoWrtF1rCw1UtFyxJry7Xw47Arb_yoWDGrb_u3 srGryjq3yxKw1Svr4xArWUZryxWay7Wr15X3y0v3W5Ga4ktw4DGrZ0gasxua4fJa1a9rZx Crn8Xw42vr13WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUUCeHPUUUUU== X-CM-SenderInfo: p2ik3jqqqrqiywtou0bp/1tbiJhjgiUCpiazT2QABsQ Subject: [Hipsec] Simultaneous end-host mobility & High availability for RVS servers(mechanism of backup RVS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 09:06:31 -0000 This is a multi-part message in MIME format. --=====003_Dragon006167416721_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi all, As you know, 1) the scenario of simultaneous end-host mobility maybe actually exist in real world, while it still has not been specified in HIP. 2) RVS servers in HIP functioning as HAs in MIP play very important roles for the management of mobile nodes. If a RVS server stops working, then all the mobile nodes managed by it should be lost in the network and cannot be re-managed any more before the mobile nodes re-register to a new RVS server. So a mechanism of backup RVS should be proposed to solve this problem. I'm considering doing some work on both or either of the two above-mentioned topics, and I'm wondering if some ones have completed some work or got some achievement on both of them. Thank you. 2010-05-30 Zhangfeng HU, phD candidate of Broadband Network Research Center, State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing, China Email:zfhu2001@gmail.com Tel:86+13811892137 --=====003_Dragon006167416721_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
hi all,
As you know, 1) the scenario of simultaneous end-host mobility maybe actually exist in real world, while it still has not been specified in HIP.  2) RVS servers in HIP functioning as HAs in MIP play very important roles for the management of mobile nodes. If a RVS server stops working, then all the mobile nodes managed by it should be lost in the network and cannot be re-managed any more before the mobile nodes re-register to a new RVS server. So a mechanism of backup RVS should be proposed to solve this problem.
 
I'm considering doing some work on both or either of the two above-mentioned topics, and I'm wondering if some ones have completed some work or got some achievement on both of them. Thank you.
 
2010-05-30
Zhangfeng HU, phD candidate of
Broadband Network Research Center,
State Key Laboratory of Networking and Switching Technology,
Beijing University of Posts and Telecommunications, Beijing, China
 
Email:zfhu2001@gmail.com
Tel:86+13811892137
 
 --=====003_Dragon006167416721_=====-- From fabrice.hobaya@gmail.com Sun May 30 04:12:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09103A683C for ; Sun, 30 May 2010 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 DZjaEYL8EkXw for ; Sun, 30 May 2010 04:12:02 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6F4C23A680A for ; Sun, 30 May 2010 04:12:01 -0700 (PDT) Received: by fxm6 with SMTP id 6so2002693fxm.31 for ; Sun, 30 May 2010 04:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LIYy2gJqBxpRiJFHJ6VHqPMqWJmjqfifWIKiPb2qpCk=; b=RhA8cub9tnTtmVKa33NKU98mQ2bNX112dBmSXX2lBWEfSi9SH/AKNnG5j/bg535Sgy CMA60LczOlILh8JMmO7+luLcfYweg6KgyFxC+7smFX9RlPT4HMDOO1b4ew2N1kIIKFcL IxhQ8XaWxySbJlS6igox+fuNJoZI/Jn+v44ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JNfOGXQqz5VPf2b7eiN7txAh9hZcsaH1pBwDuSYY3jYNM9D/9E24il4LilIgtgApAv wbaN12x1XpSWRtU6nxUK+YGR23GQhMaxAraFBJTGR02wSABdUpYOv9naPyC/9apacUFy twDynzMtfdS9QJ9929h0O1ufjnTSLbnDvgOmY= MIME-Version: 1.0 Received: by 10.102.237.35 with SMTP id k35mr1026525muh.72.1275217906436; Sun, 30 May 2010 04:11:46 -0700 (PDT) Sender: fabrice.hobaya@gmail.com Received: by 10.204.122.130 with HTTP; Sun, 30 May 2010 04:11:46 -0700 (PDT) In-Reply-To: <201005301706108432645@163.com> References: <201005301706108432645@163.com> Date: Sun, 30 May 2010 13:11:46 +0200 X-Google-Sender-Auth: obKjoGBqNBWYfJmnVJ_7kRgBM5A Message-ID: From: Fabrice HOBAYA To: HU Zhangfeng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hipsec , "Eric.ROBERT@fr.thalesgroup.com" , "Vincent.GAY@fr.thalesgroup.com" Subject: Re: [Hipsec] Simultaneous end-host mobility & High availability for RVS servers(mechanism of backup RVS) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 11:12:04 -0000 Hi Zhangfeng, 1) FYI, with some colleagues, we have worked on the end host simultaneous mobility in HIP. Here is our paper on this work where we propose a first solution we have implemented with OpenHIP and performed several preliminary tests. http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=3D&arnumber=3D5279586= &queryText%3D%28Authors%3Ahobaya%29%26openedRefinements%3D*%26matchBoolean%= 3Dtrue%26searchField%3DSearch+All 2) I have not worked on this topic but my colleagues have worked on a home agent redundancy solution for MIP, may be some ideas could be useful for the similar issue in HIP. http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=3D&arnumber=3D4976739= &queryText%3D%28Authors%3Agay%29%26refinements%3D4293762425%26openedRefinem= ents%3D*%26matchBoolean%3Dtrue%26searchField%3DSearch+All We'd be happy to discuss about these issues with you. Feel free to discuss/comment our works. Best Regards, Fabrice & al. On 30 May 2010 11:06, HU Zhangfeng wrote: > hi all, > As you know,=A01) the scenario of simultaneous=A0end-host=A0mobility mayb= e > actually exist in real world, while it still has not been specified in HI= P. > 2) RVS servers in HIP functioning as HAs in MIP play very important roles > for the management of mobile nodes. If a RVS server stops working, then a= ll > the mobile nodes managed by it=A0should be lost in the network and cannot= be > re-managed any more before the mobile nodes re-register to a new RVS serv= er. > So a mechanism=A0of=A0backup=A0RVS should be proposed to solve this probl= em. > > I'm considering doing some work on both or either of=A0the two above-ment= ioned > topics, and I'm wondering if=A0some ones have completed some work or got = some > achievement on both of them. Thank you. > > 2010-05-30 > ________________________________ > Zhangfeng HU, phD=A0candidate of > Broadband Network Research Center, > State Key Laboratory of Networking and Switching Technology, > Beijing University of Posts and Telecommunications, Beijing, China > > Email:zfhu2001@gmail.com > Tel:86+13811892137 > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > --=20 Fabrice HOBAYA -- PhD student CNES / Thales Alenia Space / T=E9SA +335 34 35 41 12 - from monday to wednesday +335 61 24 73 82 - from thursday to friday fabrice.hobaya@tesa.prd.fr From jnc@mercury.lcs.mit.edu Mon May 17 10:33:11 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619263A68A7 for ; Mon, 17 May 2010 10:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vblFQ+4HxOXn for ; Mon, 17 May 2010 10:33:09 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 340CE3A6872 for ; Mon, 17 May 2010 10:33:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 798446BE575; Mon, 17 May 2010 13:32:56 -0400 (EDT) To: hiprg@irtf.org, hipsec@ietf.org Message-Id: <20100517173256.798446BE575@mercury.lcs.mit.edu> Date: Mon, 17 May 2010 13:32:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Mon, 31 May 2010 03:49:34 -0700 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Hipsec] [hiprg] Putting HIP on a Diet 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 May 2010 17:33:12 -0000 > From: Robert Moskowitz > What is HIP? Is HIP the exchange we have now have and only that? Or is > HIP a class of protocols built on a Host Identity, each bring a > slightly different set of security claims and risks and a slightly > different domain of use? Well, those are some key (and excellent) questions - and I would think you need to answer them all fairly fully, and fairly early in the design process. I don't have a problem with an architecture that includes optional extensions that provide richer functionality sets, but... I would be wary of a design that does so _at the expense of interoperability between different groups of nodes_. So I would say that you need to define a basic architecture, at a fairly high semantic level (e.g. 'HIP is an architecture that provides Host Identities based on cryptographic means blah blah blah'). (Sorry, I haven't read the HIP architecture document in a long time, so I don't recall if you all already have such a statement.) It should, in its highest-level form, be a paragraph or so long - longer than that, and it's either i) not high enough level, or ii) too complex. And if it doesn't cover all the versions of HIP without version-specific language, then again there's a problem. Having done that, I think you should try and define some namespace(s) (both in semantics and syntax) which are common across _all_ variants, because it is those namespace(s) which allow interoperation across the variants. (Although the full detailed semantics of all variants might not be totally understood by all participants: much as the full meanings of some human names are only understood by subsets of readers, those who are in the same linguistic pool - others may be able to parse them, and use them for _some_ functions, e.g. to uniquely identify the bearers, but will not extract the full semantic functionality. A good example of this sort of thing would be 'Cohen'.) Then you can define HIP-lite as the 'base' HIP, and the variants which provide different (presumably more complex/expensive) security properties (and thus applicability to different usage domains) would be extensions to that base. Communicating nodes that both implement a particular extension could opt to use that extension _if the application at hand needed the security properties that extension provides_, and they were willing to pay the overhead of using that extension. Sorry if this all sounds either i) obvious, or ii) hand-wavy - this is as best as I can put it. Noel From becky.vandorn@computerforensicshow.com Thu May 27 08:45:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0E23A6359 for ; Thu, 27 May 2010 08:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_99=3.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPqfpmZ8PoXw for ; Thu, 27 May 2010 08:45:39 -0700 (PDT) Received: from computerforensicshow.com (computerforensicshow.com [198.171.167.178]) by core3.amsl.com (Postfix) with ESMTP id E80753A68CB for ; Thu, 27 May 2010 08:45:38 -0700 (PDT) Received: from p2e90gwm (ool-44c631e5.dyn.optonline.net [68.198.49.229]) (authenticated bits=0) by computerforensicshow.com (8.14.4/8.14.4) with ESMTP id o4RF57nB019588; Thu, 27 May 2010 15:05:09 GMT Message-ID: From: "Becky Vandorn" To: "Becky Vandorn" Date: Thu, 27 May 2010 11:03:10 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01CAFD8C.31F578A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailman-Approved-At: Mon, 31 May 2010 03:49:33 -0700 Subject: [Hipsec] Call for Papers/ San Francisco, CA 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 May 2010 15:45:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00FE_01CAFD8C.31F578A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CALL FOR PAPERS: The Computer Forensics ShowCALL FOR PAPERS: The = Computer Forensics Show =20 November 1-2, 2010 . Fort Mason Convention Center . San Francisco, CA =20 IMAGINE THE ABILITY TO VIEW ANYTHING THAT EVER APPEARED ON ALMOST ANY = COMPUTER THE COMPUTER FORENSICS SHOW IS THE "DON'T MISS" EVENT OF THE YEAR FOR = ALL =20 LEGAL, ACCOUNTING, IT SECURITY, RISK MANAGEMENT, AND LAW ENFORCEMENT = PROFESSIONALS =20 Forensic Trade Shows, LLC is proud to announce The Computer Forensics = Show, November 1st and 2nd, 2010 at the Fort Mason Convention Center, = San Francisco, CA. =20 The Computer Forensics Show is geared to meet the needs of industry = professionals by providing detailed information regarding the changes = and advancements in the IT security marketplace. =20 The event will highlight exhibits from some of the leading companies in = the industry, complemented by a comprehensive conference program to = provide attendees with important information about the latest = technological advancement, ideas and practical information available = today. =20 The Computer Forensics Show offers its speakers tremendous opportunities = for exposure and recognition as industry leader. Your session will = attract many technical professionals interested in learning from your = example, expertise and experience. In appreciation of your contributions = as a conference speaker, we provide the following benefits: =20 . Complementary speaker registration to the exhibition and full = conference pass; . Complementary session passes for your colleagues to attend your = session (upon request); . Presenters will receive three promotional conference passes to = promote their session. =20 Please visit our speaker page from this year's show at = http://www.computerforensicshow.com/speakers_panels.htm.=20 =20 There are 6 main tracks in the conference=20 =20 Forensic Accounting - Fraud, Financial Investigations, Compliance, Best = Practices, Litigation. Forensic accounting is the number one growing = field in accounting today. Legal (A) - EDD, including Litigation and Best Practice Issues. Legal (B) - Emerging Technologies/Litigation, Data/Records Management, = Reporting, and Privacy. IT Security - For organizations that are just beginning to encounter = security issues and deals with more broad issues effecting organizations = today. IT Security Advanced Track - Encompasses more complex and in-depth = issues and can highlight the need for additional training. Cyber-crime, Terrorism, and Information Warfare Track - Cyber crime and = terrorism as it relates to Homeland Security, public and corporate = policy, risk management, and the protection of our nation's critical = infrastructures. =20 The first and last sessions of each track on both days will be vendor = only and will be open to all attendees at no charge. =20 The Show's Conference Department is asking industry executives to submit = brief abstracts on some current topics to be presented to attendees in a = solo presentation or as part of a conference panel. If you are = interested, please review the following guidelines and contact = information, and note the submission deadlines for the conference. =20 =20 Guidelines =20 Formatting: . Paper size - letter/8.5" width X 11.0" height. . Margins - top/bottom/left/right - 1". . Font - Times New Roman 11 point. . Paragraph Spacing - single spaced.=20 . The submission should be sent in Microsoft Word. =20 The submission must include: . The Presentation Title . Author Name(s) . Title . Company . Speaker Contact Information: Address . Phone Number . E-mail = Address . Keywords (4-8 words) . ABSTRACT* The presentation abstract should outline your = presentation and what attendees would learn. Please remember that all = the content must be strictly educational and marketing oriented papers = will not be accepted. The presentation has to be oriented for: = Accounting, Legal, IT Security, Risk Management, and Law Enforcement = professionals. . BIOGRAPHY* The speakers biography should be 60 to 100 words in = paragraph form. These may include present position, titles, areas of = professional expertise, experience, research interests, major = publications, degrees, etc. =20 * Abstract and Biography information should not extend more than one = page and will be used for our Show Guide and Website if speaking. =20 Please do not hesitate to include additional material regarding your = presentation(s) for better evaluation. =20 The total presentation length is 75 minutes: speech ~ 50-60min; Q&A ~ = 15-20min. =20 SUBMISSION DEADLINE: July 20th, 2010.=20 =20 Submissions will be evaluated for originality, significance of the work, = technical content, and interest to a wide audience. Speakers may also be = grouped into panels when there are overlapping topics of interest. =20 Submissions should be in Microsoft Word and sent to = nmanley@computerforensicshow.com. Please note that due to the expected = volume of submissions, Forensic Trade Shows, LLC will only contact = speakers who are selected.=20 =20 By agreeing to speak, you grant one-time permission to Forensic Trade = Shows, LLC to retain and publish a copy of your presentation. The = copyright and all other rights to the presentation remain with the = author(s). All rights to and use of The Computer Forensics Show name and = logos are retained exclusively by its respective party. =20 A copy of the presentation materials should be submitted to us no later = than August 20th, 2010. It should be sent in Microsoft PowerPoint (.ppt) = format on the Computer Forensics Show template that will be provided to = you prior to the conference. If you use any animation or active content, = please include that as well. For reliability and security purposes, all = presentations will be preloaded onto the presentation computers at the = conference. =20 Note: Substitutions for speakers are only allowed under emergency = circumstances, and tradeshow management must be immediately notified of = any changes. All participants are selected at the discretion of show = management. =20 Suggested topics include Accountant Malpractice Claims=20 Anonymity and Proxies Authentication and Access Control=20 Civil Litigation=20 Class Action Disputes=20 Computer Crime and Information Warfare Construction Solutions=20 Corporate Governance=20 Corporate Information=20 Corporate Risk and Security=20 Criminal Fraud and Deception Cases=20 Cyber Forensics=20 Damage Assessment=20 Digital Forensic Case Studies=20 Digital Forensic Processes and Workflow Models=20 Digital Forensics and Internet Digital Law=20 =20 Digital Rights Management (DRM) Digital Signatures=20 E-Discovery=20 Employee Internet Abuse=20 Employment and Family Law Cases=20 Encryption and Decryption Environmental Litigation=20 Financial Investigations and Forensic Accounting=20 Forensics Accounting and the Internet Fraud Investigation=20 General Commercial Disputes=20 Identity Theft Industrial Espionage=20 Insurance Claims and Digital Forensics Integrity of Archival Data=20 Intellectual Property Claims=20 International Risk and Investigations Intrusion Detection=20 IT Security and Compliance=20 Legal, Ethical and Policy Issues=20 Mobile Forensics=20 More General Criminal Cases=20 Network Forensics=20 New Firewall Technologies=20 Portable Electronic Device Forensics=20 Post-Acquisition Disputes=20 Privacy and Data Mining=20 Privacy issues in digital forensics Privacy Leakage Case Studies=20 Privacy Policy Enforcement=20 Security Education and Training=20 Smart Card Applications=20 Stealth Data=20 Steganography Stylometrics and Author Attribution Terrorist Use of the Internet=20 Unauthorized Disclosure of Corporate Information =20 Additional classes will also be available to attendees such as:=20 Computer Forensics - CCFE Boot Camp - 5 Days Advanced Computer Forensics - 5 Days Cell Phone Forensics - 2 Days Live Memory Forensics - 2 Days Linux Forensics - 3 Days Mac Forensics - 3 Days Reverse Engineering Malware - CREA Boot Camp - 5 Days Ethical Hacking - CPT/CEH Boot Camp - 5 Days =20 If you have any questions about The Computer Forensics Conferences, = please send us an e-mail to info@computerforensicshow.com.=20 =20 # # # =20 To be removed from the mailing list please send us an e-mail to: = remove@computerforensicshow.com. =20 ------=_NextPart_000_00FE_01CAFD8C.31F578A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CALL FOR = PAPERS: The Computer Forensics Show
CALL=20 FOR PAPERS: The Computer Forensics = Show

 

November=20 1-2, 2010=20 =95 Fort=20 Mason=20 Convention=20 Center=20 =95 San=20 Francisco,=20 CA

 

IMAGINE=20 THE ABILITY TO VIEW ANYTHING THAT EVER APPEARED ON ALMOST ANY=20 COMPUTER

THE=20 COMPUTER FORENSICS SHOW IS THE "DON'T MISS" EVENT OF THE YEAR FOR=20 ALL

 

LEGAL,=20 ACCOUNTING, IT SECURITY, RISK MANAGEMENT, AND LAW ENFORCEMENT=20 PROFESSIONALS

 

Forensic=20 Trade Shows, LLC is proud to announce The Computer Forensics Show,=20 November=20 1st and 2nd, 2010=20 at the Fort=20 Mason=20 Convention=20 Center,=20 San=20 Francisco,=20 CA.

 

The=20 Computer Forensics Show is geared to meet the needs of industry = professionals by=20 providing detailed information regarding the changes and advancements in = the IT=20 security marketplace.

 

The=20 event will highlight exhibits from some of the leading companies in the=20 industry, complemented by a comprehensive conference program to provide=20 attendees with important information about the latest technological = advancement,=20 ideas and practical information available = today.

 

The=20 Computer Forensics Show offers its speakers tremendous opportunities for = exposure and recognition as industry leader. Your session will attract = many=20 technical professionals interested in learning from your example, = expertise and=20 experience. In appreciation of your contributions as a conference = speaker, we=20 provide the following benefits:

 

   =95 Complementary = speaker=20 registration to the exhibition and full conference=20 pass;

   =95 Complementary = session passes for=20 your colleagues to attend your session (upon=20 request);

   =95 Presenters will = receive three=20 promotional conference passes to promote their=20 session.

 

Please=20 visit our speaker page from this year's show at http://w= ww.computerforensicshow.com/speakers_panels.htm.=20

 

There=20 are 6 main tracks in the conference =

 

Forensic=20 Accounting =96=20 Fraud, Financial Investigations, Compliance, Best Practices, Litigation. = Forensic accounting is the number one growing field in accounting=20 today.

Legal=20 (A) =96=20 EDD, including Litigation and Best Practice = Issues.

Legal=20 (B) =96=20 Emerging Technologies/Litigation, Data/Records Management, Reporting, = and=20 Privacy.

IT=20 Security =96=20 For organizations that are just beginning to encounter security issues = and deals=20 with more broad issues effecting organizations=20 today.

IT=20 Security Advanced Track=20 =96=20 Encompasses more complex and in-depth issues and can highlight the need = for=20 additional training.

Cyber-crime,=20 Terrorism, and Information Warfare Track =96=20 Cyber crime and terrorism as it relates to Homeland Security, public and = corporate policy, risk management, and the protection of our nation=92s = critical=20 infrastructures.

 

The=20 first and last sessions of each track on both days will be vendor = only=20 and will be open to all attendees at no = charge.

 

The=20 Show=92s Conference Department is asking industry executives to submit = brief=20 abstracts on some current topics to be presented to attendees in a solo=20 presentation or as part of a conference panel. If you are interested, = please=20 review the following guidelines and contact information, and note the = submission=20 deadlines for the conference. 

 

Guidelines

 

Formatting:

  =20 =95 Paper size - letter/8.5" width X 11.0"=20 height.

   =95 Margins - = top/bottom/left/right=20 =96 1".

   =95 Font - Times New = Roman 11=20 point.

   =95 Paragraph Spacing - = single=20 spaced.

   =95 The submission = should be sent in=20 Microsoft Word.

 

The=20 submission must include:

   =95 The Presentation=20 Title

   =95 Author Name(s) =95 = Title =95=20 Company

   =95 Speaker Contact = Information:=20 Address =95 Phone Number =95 E-mail Address

   =95 Keywords (4-8=20 words)

   =95 ABSTRACT* The=20 presentation abstract should outline your presentation and what = attendees would=20 learn. Please    remember=20 that all the content must be strictly educational and marketing oriented = papers=20 will not be accepted. The presentation has to be oriented for: = Accounting,=20 Legal, IT Security, Risk Management, and Law Enforcement=20 professionals.

   =95 BIOGRAPHY*=20 The speakers biography should be 60 to 100 words in paragraph form. = These may=20 include present position, titles, areas of professional expertise, = experience,=20 research interests, major publications, degrees,=20 etc.

 

*=20 Abstract=20 and Biography information should not extend more than one page and will = be used=20 for our Show Guide and Website if = speaking.

 

Please=20 do not hesitate to include additional material regarding your = presentation(s)=20 for better evaluation.

 

The=20 total presentation length is 75 minutes: speech ~ 50-60min; = Q&A ~=20 15-20min.

 

SUBMISSION=20 DEADLINE:=20 July=20 20th, 2010.=20

 

Submissions=20 will be evaluated for originality, significance of the work, technical = content,=20 and interest to a wide audience. Speakers may also be grouped into = panels when=20 there are overlapping topics of interest.

 

Submissions=20 should be in Microsoft Word and sent to nmanley@computerforensic= show.com.  Please note that due to the = expected=20 volume of submissions, Forensic Trade Shows, LLC will only contact = speakers who=20 are selected.

 

By=20 agreeing to speak, you grant one-time permission to Forensic Trade = Shows, LLC to=20 retain and publish a copy of your presentation. The copyright and all = other=20 rights to the presentation remain with the author(s). All rights to and = use of=20 The Computer Forensics Show name and logos are retained exclusively by = its=20 respective party.

 

A=20 copy of the presentation materials should be submitted to us no later = than=20 August=20 20th, 2010.=20 It should be sent in Microsoft PowerPoint (.ppt) format on the Computer=20 Forensics Show template that will be provided to you prior to the = conference. If=20 you use any animation or active content, please include that as well. = For=20 reliability and security purposes, all presentations will be preloaded = onto the=20 presentation computers at the conference.

 

Note:=20 Substitutions=20 for speakers are only allowed under emergency circumstances, and = tradeshow=20 management must be immediately notified of any changes.  All participants are selected = at the=20 discretion of show management.

 

Suggested=20 topics include

Accountant=20 Malpractice Claims

Anonymity=20 and Proxies

Authentication=20 and Access Control

Civil=20 Litigation

Class=20 Action Disputes

Computer=20 Crime and Information Warfare

Construction=20 Solutions

Corporate=20 Governance

Corporate=20 Information

Corporate=20 Risk and Security

Criminal=20 Fraud and Deception Cases

Cyber=20 Forensics

Damage=20 Assessment

Digital=20 Forensic Case Studies

Digital=20 Forensic Processes and Workflow Models =

Digital=20 Forensics and Internet

Digital=20 Law

 

Digital=20 Rights Management (DRM)

Digital=20 Signatures

E-Discovery=20

Employee=20 Internet Abuse

Employment=20 and Family Law Cases

Encryption=20 and Decryption

Environmental=20 Litigation

Financial=20 Investigations and Forensic Accounting =

Forensics=20 Accounting and the Internet

Fraud=20 Investigation

General=20 Commercial Disputes

Identity=20 Theft

Industrial=20 Espionage

Insurance=20 Claims and Digital Forensics

Integrity=20 of Archival Data

Intellectual=20 Property Claims

International=20 Risk and Investigations

Intrusion=20 Detection

IT=20 Security and Compliance

Legal,=20 Ethical and Policy Issues

Mobile=20 Forensics

More=20 General Criminal Cases

Network=20 Forensics

New=20 Firewall Technologies

Portable=20 Electronic Device Forensics

Post-Acquisition=20 Disputes

Privacy=20 and Data Mining

Privacy=20 issues in digital forensics

Privacy=20 Leakage Case Studies

Privacy=20 Policy Enforcement

Security=20 Education and Training

Smart=20 Card Applications

Stealth=20 Data

Steganography

Stylometrics=20 and Author Attribution

Terrorist=20 Use of the Internet

Unauthorized=20 Disclosure of Corporate Information

Additional=20 classes will also be available to attendees such as:=20

Computer=20 Forensics - CCFE Boot Camp - 5 Days

Advanced=20 Computer Forensics - 5 Days

Cell=20 Phone Forensics - 2 Days

Live=20 Memory Forensics - 2 Days

Linux=20 Forensics - 3 Days

Mac=20 Forensics - 3 Days

Reverse=20 Engineering Malware - CREA Boot Camp - 5 = Days

Ethical=20 Hacking - CPT/CEH Boot Camp - 5 Days

 

If=20 you have any questions about The Computer Forensics Conferences, please = send us=20 an e-mail to info@computerforensicshow.c= om.=20

 

#=20 # #

 

To=20 be removed from the mailing list please send us an e-mail to:=20 remove@computerforensicsh= ow.com.

 

------=_NextPart_000_00FE_01CAFD8C.31F578A0-- From wwwrun@core3.amsl.com Fri May 28 08:56:26 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5C4073A6A40; Fri, 28 May 2010 08:56:26 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100528155626.5C4073A6A40@core3.amsl.com> Date: Fri, 28 May 2010 08:56:26 -0700 (PDT) X-Mailman-Approved-At: Mon, 31 May 2010 03:49:33 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-bone (HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is 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 May 2010 15:56:26 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-bone-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17868&rfc_flag=0 From wwwrun@core3.amsl.com Fri May 28 09:02:42 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0C9563A6A3E; Fri, 28 May 2010 09:02:41 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100528160242.0C9563A6A3E@core3.amsl.com> Date: Fri, 28 May 2010 09:02:42 -0700 (PDT) X-Mailman-Approved-At: Mon, 31 May 2010 03:49:33 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-via (Host Identity Protocol (HIP) Multi-hop Routing Extension) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is 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 May 2010 16:02:42 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol (HIP) Multi-hop Routing Extension ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-via-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19355&rfc_flag=0 From wwwrun@core3.amsl.com Fri May 28 09:03:26 2010 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 563523A6A50; Fri, 28 May 2010 09:03:26 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100528160326.563523A6A50@core3.amsl.com> Date: Fri, 28 May 2010 09:03:26 -0700 (PDT) X-Mailman-Approved-At: Mon, 31 May 2010 03:49:33 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-hiccups (HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is 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 May 2010 16:03:26 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-hiccups-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19354&rfc_flag=0 From gonzalo.camarillo@ericsson.com Mon May 31 07:11:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8453A6A43 for ; Mon, 31 May 2010 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.459 X-Spam-Level: X-Spam-Status: No, score=-100.459 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_50=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 YAsToeXEusho for ; Mon, 31 May 2010 07:11:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 868923A69E9 for ; Mon, 31 May 2010 07:11:39 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-e6-4c03c38ea088 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.89.06817.E83C30C4; Mon, 31 May 2010 16:11:27 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 16:11:26 +0200 Received: from [131.160.126.212] ([131.160.126.212]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 16:11:26 +0200 Message-ID: <4C03C38D.3000408@ericsson.com> Date: Mon, 31 May 2010 17:11:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4BFAA6B0.6070806@ericsson.com> <4BFAE4F6.7090602@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4CE97161CD@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE97161CD@XCH-NW-10V.nw.nos.boeing.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2010 14:11:26.0292 (UTC) FILETIME=[28320940:01CB00CB] X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] Face-to-face meeting? 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, 31 May 2010 14:11:41 -0000 Hi, it is clear we need to have the documents reviewed. However, do you expect the reviewers to find issues that will require face-to-face discussions? If we need face-to-face time, I am happy to request a slot. However, I would not like to request a slot just to show a few slides without discussions. Thanks, Gonzalo On 25/05/2010 6:36 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org >> [mailto:hipsec-bounces@ietf.org] On Behalf Of Robert Moskowitz >> Sent: Monday, May 24, 2010 1:44 PM >> To: Gonzalo Camarillo >> Cc: HIP >> Subject: Re: [Hipsec] Face-to-face meeting? >> >> On 05/24/2010 12:17 PM, Gonzalo Camarillo wrote: >>> Folks, >>> >>> we need to decide whether or not we need face-to-face time >> during the >>> next IETF. Opinions? >>> >> >> It would be 'nice' to have a serious document review at that time. >> >> There shouldn't be quite the 'hand waving' we did at Anahiem, >> but actual >> documents for people to have read over and be reading to hum on or >> supply changes. >> > > I cannot attend but I tend to agree that a review would be helpful to move things along, if you can form a quorum. > > - Tom From gonzalo.camarillo@ericsson.com Mon May 31 09:17:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722743A685C for ; Mon, 31 May 2010 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.344 X-Spam-Level: X-Spam-Status: No, score=-100.344 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_50=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 pB1eKWeLS76G for ; Mon, 31 May 2010 09:17:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 935A13A68C7 for ; Mon, 31 May 2010 09:17:33 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-a3-4c03e1103a20 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.E2.06817.011E30C4; Mon, 31 May 2010 18:17:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 18:17:19 +0200 Received: from [131.160.126.212] ([131.160.126.212]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 18:17:19 +0200 Message-ID: <4C03E10F.4080508@ericsson.com> Date: Mon, 31 May 2010 19:17:19 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: HIP References: <4BCDA1BC.1020701@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4CE8C27305@XCH-NW-10V.nw.nos.boeing.com> <2D4CC47B-D38B-41EE-8D39-AF3B76986CDE@cs.rwth-aachen.de> <4BDE9BC7.5090201@ericsson.com> In-Reply-To: <4BDE9BC7.5090201@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2010 16:17:19.0755 (UTC) FILETIME=[BE6905B0:01CB00DC] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] NAT traversal and the standards track work X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 16:17:35 -0000 Hi, it seems we also have consensus on going native. Cheers, Gonzalo On 03/05/2010 12:47 PM, Gonzalo Camarillo wrote: > Folks, > > it seems we have consensus on including the mobility and multihoming > extensions in the scope of our new to-be-chartered NAT traversal effort. > > With respect to whether we want to go native or still use the STUN-based > connectivity checks, it would be good to have more discussions on the list. > > Thanks, > > Gonzalo > > > On 26/04/2010 1:06 PM, Tobias Heer wrote: >> >> Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R: >> >>> >>> >>>> -----Original Message----- >>>> From: hipsec-bounces@ietf.org >>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >>>> Sent: Tuesday, April 20, 2010 5:45 AM >>>> To: HIP >>>> Subject: [Hipsec] NAT traversal and the standards track work >>>> >>>> Hi, >>>> >>>> we need to decide what to do with NAT traversal when moving to the >>>> standards track. We have the following drafts: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/ >>>> >>>> The draft above will soon become an Experimental RFC. >>>> >>>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat- >>>> traversal/ >>>> >>>> The draft above proposes implementing HIP-based connectivity checks >>>> instead of STUN-based ones. >>>> >>>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt >>>> >>>> The draft above, which needs to be revised, describes the mobility and >>>> multihoming extensions for NAT traversal. >>>> >>>> I would like to hear people's views on what to do here. >>>> >>> >>> Gonzalo, I would like to see both topics (NAT traversal, and mobility management aspects of NAT traversal) on the revised charter, as the second phase of standards-track work, as we discussed in Anaheim. I am neutral on the questions of which one of the two drafts to adopt (if a choice needs to be made now) and on whether the nat-mm draft should remain separate or should be combined into one NAT traversal draft. >>> >> I share Tom's opinion here. I would like to see both progress (provided there is enough manpower to support both). However, I think it might be useful to address mobility in the actual NAT documents since it poses special challenges that are special to NATs. >> >> Tobias >> >>> - Tom >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> >> >> >> -- >> >> Dipl.-Inform. Tobias Heer, Ph.D. Student >> Distributed Systems Group >> RWTH Aachen University, Germany >> tel: +49 241 80 207 76 >> web: http://ds.cs.rwth-aachen.de/members/heer >> >> >> >> >> >> >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >