From thomas.r.henderson@boeing.com Mon Dec 10 22:00:16 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2D421F8707 for ; Mon, 10 Dec 2012 22:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q74WE-XVFl93 for ; Mon, 10 Dec 2012 22:00:13 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3521F870C for ; Mon, 10 Dec 2012 22:00:08 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qBB607Bw028244 for ; Mon, 10 Dec 2012 22:00:07 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qBB607ii028240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 10 Dec 2012 22:00:07 -0800 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 10 Dec 2012 22:00:07 -0800 From: "Henderson, Thomas R" To: "hipsec@ietf.org" Date: Mon, 10 Dec 2012 22:00:06 -0800 Thread-Topic: LSI prefix testing results Thread-Index: Ac3DlGfgZRU760GRSj6RdXeFQC6HSwBvTorAAZNUneAC8IQsIA== Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4D5DDE9A@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA2E4D5DDDB0@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4D5DDDB0@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [Hipsec] LSI prefix testing results X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 06:00:16 -0000 > 3) LSI prefix range in Class E or 127/8 range >=20 > We would like to recommend a suitable range for assignment of LSIs. A > range in the 127/8 or class E IPv4 address space is being considered. >=20 > This is now issue 41 in the tracker: > http://trac.tools.ietf.org/wg/hip/trac/ticket/41 Jeff Ahrenholz and I have been testing the use of OpenHIP with different LS= I prefixes: - a relatively unused class A prefix (25/8), for control purposes - a loopback prefix (127/8) - a class E prefix (250/8) on different platforms. I initially tested with a recent Ubuntu Linux distribution and was able to = get it to work using 250/8. However, Jeff tested on an older Linux system = (2.6.18 kernel) and found that attempting to either ping or ssh to the LSI = resulted in 'invalid argument'. On Windows (XP and 7), Jeff was not able to successfully use either 127/8 o= r the representative class E prefix (250/8) that we have been testing. Whe= n the Windows XP host is the responder, the base exchange completes but the= Windows XP host cannot use the socket (ping.exe fails with "Destination sp= ecified is invalid" and ssh.exe fails with "Cannot assign requested address= "). On Windows 7 and XP, upon trying to set an interface address to one within = a Class E prefix, the following error is displayed: " is not a vali= d entry. Please specify a value between 1 and 223." An address in 127/8 i= s also disallowed. I did not test OS X since the above problems manifested themselves. In summary, it seems that we need to use prefixes that are outside of 127/8= , class D, and class E prefixes for IPv4 LSIs if we want to have a portable= solution. - Tom From ari.keranen@nomadiclab.com Fri Dec 14 04:43:07 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37A21F841F for ; Fri, 14 Dec 2012 04:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywD7o1bPgjfa for ; Fri, 14 Dec 2012 04:43:06 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35C21F8231 for ; Fri, 14 Dec 2012 04:43:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E5F184E6EF; Fri, 14 Dec 2012 14:43:03 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz9d84W00wiW; Fri, 14 Dec 2012 14:43:02 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 7D6404E6EC; Fri, 14 Dec 2012 14:43:02 +0200 (EET) Message-ID: <50CB1ED5.2040103@nomadiclab.com> Date: Fri, 14 Dec 2012 14:43:01 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tobias Heer , Samu Varjonen References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> In-Reply-To: <505C213F.6050701@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , "hipsec@ietf.org" Subject: Re: [Hipsec] Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:43:08 -0000 So, what's blocking the progress on this is the lack of STD track CERT draft. Samu and Tobi, would you have cycles to move your experimental track CERT RFC into STD track draft? I guess not much (or anything except the category?) need to be changed from the current RFC doc. Cheers, Ari On 9/21/12 11:11 AM, Gonzalo Camarillo wrote: > Hi Julien, > > my take on this is that we need to produce a standards-track document > specifying exactly that. This is what our charter says about it: > > https://datatracker.ietf.org/wg/hip/charter/ > >> o Specify in a standards track RFC how to carry certificates in the >> base exchange. This was removed from the base HIP spec so that the >> mechanism is specified in a stand-alone spec. > > Cheers, > > Gonzalo > > On 21/09/2012 2:49 AM, Julien Laganier wrote: >> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >>> Hi Julien, >>> >>> >>> On 7/6/12 3:37 AM, Julien Laganier wrote: >>>> >>>> - 5203bis (registration) can IMHO be republished as is as I haven't >>>> seen any issue with the original version. If people agree I could >>>> republish it and we could WGLC it... >>> >>> >>> I posted some comments about 5203bis earlier this year but back then there >>> was no discussion regarding them. So, here goes again. >>> >>> Some of these have been discussed also earlier on this list (these relate to >>> requirements discovered with the native NAT traversal draft [1]), but I'll >>> have them all here for easier reference. >>> >>> Currently, the registrar has no way of indicating that it would otherwise >>> accept the registration, but it's currently running low on resources. For >>> this purpose, a failure type "Insufficient resources" could be added to the >>> "registration failure types". >>> >>> Registration using authentication with certificates could be part of the >>> registration RFC. Currently, only authentication with HI is defined, but >>> knowing all HIs beforehand is not practical in many cases. >>> >>> Text in section 3.2. of [1] could be used as a basis for this (just replace >>> "HIP' data relay" with "registrar"). Also, if this authentication mode is >>> added to the draft, failure type "Invalid certificate" should be added for >>> the failure case. >>> >>> Should we have these in the registration draft? >>> >>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >> >> I was going to shamelessly copy/paste section 3.2 of [1] in the >> registration draft but I noticed that [1] actually has a normative >> dependency on RFC 6253 "Host Identity Protocol Certificates" which is >> Experimental. Thus adding the support for certificates to a standard >> track HIP registration would cause a so-called downref which could be >> problematic... >> >> Gonzalo - what is your take on this? >> >> --julien >> > From internet-drafts@ietf.org Fri Dec 14 04:46:09 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA19021F865D; Fri, 14 Dec 2012 04:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCx-cs00a3Fr; Fri, 14 Dec 2012 04:46:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B921F8651; Fri, 14 Dec 2012 04:46:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121214124609.27482.12268.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 04:46:09 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:46:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group of t= he IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Author(s) : Ari Keranen Jan Melen Filename : draft-ietf-hip-native-nat-traversal-04.txt Pages : 15 Date : 2012-12-14 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ari.keranen@nomadiclab.com Fri Dec 14 04:48:20 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3690521F84CD for ; Fri, 14 Dec 2012 04:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZDH6Xi9PRoG for ; Fri, 14 Dec 2012 04:48:19 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 678C821F8479 for ; Fri, 14 Dec 2012 04:48:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A998F4E6EF for ; Fri, 14 Dec 2012 14:48:17 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0uaEuctBznv for ; Fri, 14 Dec 2012 14:48:16 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 0D29B4E6EC for ; Fri, 14 Dec 2012 14:48:16 +0200 (EET) Message-ID: <50CB200F.7030600@nomadiclab.com> Date: Fri, 14 Dec 2012 14:48:15 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <20121214124609.27482.12268.idtracker@ietfa.amsl.com> In-Reply-To: <20121214124609.27482.12268.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:48:20 -0000 Just a keep-alive update while waiting for the main docs to move forward. Cheers, Ari On 12/14/12 2:46 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Native NAT Traversal Mode for the Host Identity Protocol > Author(s) : Ari Keranen > Jan Melen > Filename : draft-ietf-hip-native-nat-traversal-04.txt > Pages : 15 > Date : 2012-12-14 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode is > based on the Interactive Connectivity Establishment (ICE) methodology > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From ari.keranen@nomadiclab.com Fri Dec 14 05:14:56 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB021F873C for ; Fri, 14 Dec 2012 05:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2pfTrafnjP2 for ; Fri, 14 Dec 2012 05:14:56 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E46B121F86C3 for ; Fri, 14 Dec 2012 05:14:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 3C6744E6EF; Fri, 14 Dec 2012 15:14:55 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61kqdg3slSOM; Fri, 14 Dec 2012 15:14:51 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 2B2D24E6EC; Fri, 14 Dec 2012 15:14:51 +0200 (EET) Message-ID: <50CB264A.7030403@nomadiclab.com> Date: Fri, 14 Dec 2012 15:14:50 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> <5080010B.7030605@cs.hut.fi> In-Reply-To: <5080010B.7030605@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:14:57 -0000 Or we can do this. However, I would not be too concerned for the CERT draft blocking the reg draft given that the CERT draft should not require much (any?) changes for STD track. Of course that would need someone driving that work too. If there's not enough interest for that work (I think it's important but don't have the cycles to do it myself), it makes sense to go forward as proposed below. Cheers, Ari On 10/18/12 4:15 PM, Miika Komu wrote: > Hi Julien, > > your suggestion sounds fine. > > On 09/25/2012 10:26 AM, Gonzalo Camarillo wrote: >> Hi, >> >> if we have the appropriate hooks in the main specs, we could do as you >> suggest. I would be interested in hearing more opinions, though. >> >> Cheers, >> >> Gonzalo >> >> On 24/09/2012 5:48 PM, Julien Laganier wrote: >>> Hi Gonzalo, all, >>> >>> So if we include in the registration a dependency towards the standard >>> tracks HIP certificates draft (that doesn't exist yet) we would be >>> tying the two together such that the registration can't be published >>> before the HIP certificate RFC is. >>> >>> An alternative would be to move ahead with the current registration >>> draft without specific dependency on HIP certificates but leaving the >>> door open for these to be used once they are defined in standard >>> track; the current draft and RFC already have hooks for authentication >>> means beyond HIT authentication: >>> >>> >>> In particular, >>> REG_FAILED with a failure type of zero indicates the service(s) >>> type(s) that require further credentials for registration. >>> >>> If the registrar requires further authorization and the requester >>> has >>> additional credentials available, the requester SHOULD try to >>> register again with the service after the HIP association has been >>> established. The precise means of establishing and verifying >>> credentials are beyond the scope of this document and are >>> expected to >>> be defined in other documents. >>> >>> Would that be an appropriate way forward? >>> >>> --julien >>> >>> On Fri, Sep 21, 2012 at 1:11 AM, Gonzalo Camarillo >>> wrote: >>>> Hi Julien, >>>> >>>> my take on this is that we need to produce a standards-track document >>>> specifying exactly that. This is what our charter says about it: >>>> >>>> https://datatracker.ietf.org/wg/hip/charter/ >>>> >>>>> o Specify in a standards track RFC how to carry certificates in the >>>>> base exchange. This was removed from the base HIP spec so that the >>>>> mechanism is specified in a stand-alone spec. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 21/09/2012 2:49 AM, Julien Laganier wrote: >>>>> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen >>>>> wrote: >>>>>> Hi Julien, >>>>>> >>>>>> >>>>>> On 7/6/12 3:37 AM, Julien Laganier wrote: >>>>>>> >>>>>>> - 5203bis (registration) can IMHO be republished as is as I haven't >>>>>>> seen any issue with the original version. If people agree I could >>>>>>> republish it and we could WGLC it... >>>>>> >>>>>> >>>>>> I posted some comments about 5203bis earlier this year but back >>>>>> then there >>>>>> was no discussion regarding them. So, here goes again. >>>>>> >>>>>> Some of these have been discussed also earlier on this list (these >>>>>> relate to >>>>>> requirements discovered with the native NAT traversal draft [1]), >>>>>> but I'll >>>>>> have them all here for easier reference. >>>>>> >>>>>> Currently, the registrar has no way of indicating that it would >>>>>> otherwise >>>>>> accept the registration, but it's currently running low on >>>>>> resources. For >>>>>> this purpose, a failure type "Insufficient resources" could be >>>>>> added to the >>>>>> "registration failure types". >>>>>> >>>>>> Registration using authentication with certificates could be part >>>>>> of the >>>>>> registration RFC. Currently, only authentication with HI is >>>>>> defined, but >>>>>> knowing all HIs beforehand is not practical in many cases. >>>>>> >>>>>> Text in section 3.2. of [1] could be used as a basis for this >>>>>> (just replace >>>>>> "HIP' data relay" with "registrar"). Also, if this authentication >>>>>> mode is >>>>>> added to the draft, failure type "Invalid certificate" should be >>>>>> added for >>>>>> the failure case. >>>>>> >>>>>> Should we have these in the registration draft? >>>>>> >>>>>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >>>>> >>>>> I was going to shamelessly copy/paste section 3.2 of [1] in the >>>>> registration draft but I noticed that [1] actually has a normative >>>>> dependency on RFC 6253 "Host Identity Protocol Certificates" which is >>>>> Experimental. Thus adding the support for certificates to a standard >>>>> track HIP registration would cause a so-called downref which could be >>>>> problematic... >>>>> >>>>> Gonzalo - what is your take on this? >>>>> >>>>> --julien >>>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 thomas.r.henderson@boeing.com Fri Dec 14 23:41:01 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8860821F8A28 for ; Fri, 14 Dec 2012 23:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw7xtTYUiBxI for ; Fri, 14 Dec 2012 23:41:00 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id E061F21F8A21 for ; Fri, 14 Dec 2012 23:41:00 -0800 (PST) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qBF7f006008660 for ; Fri, 14 Dec 2012 23:41:00 -0800 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qBF7ewgP008652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 14 Dec 2012 23:40:59 -0800 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 14 Dec 2012 23:40:58 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" , "hipsec@ietf.org" Date: Fri, 14 Dec 2012 23:40:58 -0800 Thread-Topic: [Hipsec] Fwd: Status of WG items Thread-Index: Ac3Z/QZr4bJf9PfER26auLR1uD7uvQAmiOEg Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4D5DDEE7@XCH-NW-16V.nw.nos.boeing.com> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> <5080010B.7030605@cs.hut.fi> <50CB264A.7030403@nomadiclab.com> In-Reply-To: <50CB264A.7030403@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 X-TM-AS-MML: No Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:41:01 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Ari Keranen > Sent: Friday, December 14, 2012 5:15 AM > To: hipsec@ietf.org > Subject: Re: [Hipsec] Fwd: Status of WG items >=20 > Or we can do this. >=20 > However, I would not be too concerned for the CERT draft blocking the > reg draft given that the CERT draft should not require much (any?) > changes for STD track. Of course that would need someone driving that > work too. >=20 > If there's not enough interest for that work (I think it's important > but don't have the cycles to do it myself), it makes sense to go > forward as proposed below. I agree with the above. I would support carrying them forward as is and tr= ying to publish together, but if the authors prefer to decouple, I would be= fine with that approach. - Tom From mkomu@cs.hut.fi Fri Dec 14 23:51:10 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7480321F8945 for ; Fri, 14 Dec 2012 23:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10TdsMgmmlW9 for ; Fri, 14 Dec 2012 23:51:10 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3021F88C8 for ; Fri, 14 Dec 2012 23:51:09 -0800 (PST) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 4AB993087D6; Sat, 15 Dec 2012 09:51:08 +0200 (EET) Message-ID: <50CC2BEB.1030709@cs.hut.fi> Date: Sat, 15 Dec 2012 09:51:07 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: hipsec@ietf.org, Varjonen Samu References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> <5080010B.7030605@cs.hut.fi> <50CB264A.7030403@nomadiclab.com> <758141CC3D829043A8C3164DD3D593EA2E4D5DDEE7@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4D5DDEE7@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:51:10 -0000 Hi, On 12/15/2012 09:40 AM, Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >> Behalf Of Ari Keranen >> Sent: Friday, December 14, 2012 5:15 AM >> To: hipsec@ietf.org >> Subject: Re: [Hipsec] Fwd: Status of WG items >> >> Or we can do this. >> >> However, I would not be too concerned for the CERT draft blocking the >> reg draft given that the CERT draft should not require much (any?) >> changes for STD track. Of course that would need someone driving that >> work too. >> >> If there's not enough interest for that work (I think it's important >> but don't have the cycles to do it myself), it makes sense to go >> forward as proposed below. > > I agree with the above. I would support carrying them forward as is and trying to publish together, but if the authors prefer to decouple, I would be fine with that approach. I would also suggest pushing CERT draft to the standards track if the authors can contribute some cycles. From samu.varjonen@hiit.fi Sat Dec 15 02:40:33 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC121F8839 for ; Sat, 15 Dec 2012 02:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 709mXTLGM1oz for ; Sat, 15 Dec 2012 02:40:33 -0800 (PST) Received: from argo.otaverkko.fi (argo.ipv6.otaverkko.fi [IPv6:2a02:4880:10:1000::2:25]) by ietfa.amsl.com (Postfix) with ESMTP id 39FF621F8838 for ; Sat, 15 Dec 2012 02:40:32 -0800 (PST) Received: from [192.168.0.10] (cs181123160.pp.htv.fi [82.181.123.160]) by argo.otaverkko.fi (Postfix) with ESMTPSA id 220192181F for ; Sat, 15 Dec 2012 12:40:30 +0200 (EET) Message-ID: <50CC5390.40707@hiit.fi> Date: Sat, 15 Dec 2012 12:40:16 +0200 From: Samu Varjonen User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: hipsec@ietf.org References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> <5080010B.7030605@cs.hut.fi> <50CB264A.7030403@nomadiclab.com> <758141CC3D829043A8C3164DD3D593EA2E4D5DDEE7@XCH-NW-16V.nw.nos.boeing.com> <50CC2BEB.1030709@cs.hut.fi> In-Reply-To: <50CC2BEB.1030709@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 10:40:33 -0000 15.12.2012 9:51, Miika Komu kirjoitti: > Hi, > > On 12/15/2012 09:40 AM, Henderson, Thomas R wrote: >> >> >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >>> Behalf Of Ari Keranen >>> Sent: Friday, December 14, 2012 5:15 AM >>> To: hipsec@ietf.org >>> Subject: Re: [Hipsec] Fwd: Status of WG items >>> >>> Or we can do this. >>> >>> However, I would not be too concerned for the CERT draft blocking the >>> reg draft given that the CERT draft should not require much (any?) >>> changes for STD track. Of course that would need someone driving that >>> work too. >>> >>> If there's not enough interest for that work (I think it's important >>> but don't have the cycles to do it myself), it makes sense to go >>> forward as proposed below. >> >> I agree with the above. I would support carrying them forward as is >> and trying to publish together, but if the authors prefer to decouple, >> I would be fine with that approach. > > I would also suggest pushing CERT draft to the standards track if the > authors can contribute some cycles. I can contribute some cycles. BR, Samu > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From ari.keranen@nomadiclab.com Mon Dec 17 00:41:24 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918ED21F8A46 for ; Mon, 17 Dec 2012 00:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq1DCjsec4vv for ; Mon, 17 Dec 2012 00:41:24 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id F114F21F89B6 for ; Mon, 17 Dec 2012 00:41:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 089644E6F7; Mon, 17 Dec 2012 10:41:19 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT5AdhI-MX6H; Mon, 17 Dec 2012 10:41:14 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id A45184E6ED; Mon, 17 Dec 2012 10:41:14 +0200 (EET) Message-ID: <50CEDAAA.1000401@nomadiclab.com> Date: Mon, 17 Dec 2012 10:41:14 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Samu Varjonen , Julien Laganier References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> <5080010B.7030605@cs.hut.fi> <50CB264A.7030403@nomadiclab.com> <758141CC3D829043A8C3164DD3D593EA2E4D5DDEE7@XCH-NW-16V.nw.nos.boeing.com> <50CC2BEB.1030709@cs.hut.fi> <50CC5390.40707@hiit.fi> In-Reply-To: <50CC5390.40707@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 08:41:24 -0000 On 12/15/12 12:40 PM, Samu Varjonen wrote: > 15.12.2012 9:51, Miika Komu kirjoitti: >> Hi, >> >> On 12/15/2012 09:40 AM, Henderson, Thomas R wrote: >>> >>> >>>> -----Original Message----- >>>> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >>>> Behalf Of Ari Keranen >>>> Sent: Friday, December 14, 2012 5:15 AM >>>> To: hipsec@ietf.org >>>> Subject: Re: [Hipsec] Fwd: Status of WG items >>>> >>>> Or we can do this. >>>> >>>> However, I would not be too concerned for the CERT draft blocking the >>>> reg draft given that the CERT draft should not require much (any?) >>>> changes for STD track. Of course that would need someone driving that >>>> work too. >>>> >>>> If there's not enough interest for that work (I think it's important >>>> but don't have the cycles to do it myself), it makes sense to go >>>> forward as proposed below. >>> >>> I agree with the above. I would support carrying them forward as is >>> and trying to publish together, but if the authors prefer to decouple, >>> I would be fine with that approach. >> >> I would also suggest pushing CERT draft to the standards track if the >> authors can contribute some cycles. > > I can contribute some cycles. Excellent, thanks Samu! Julien, if we can get CERT moving, do you agree that this way forward makes sense? Cheers, Ari From thierry.moreau@connotech.com Wed Dec 19 10:49:59 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91B21F87B2 for ; Wed, 19 Dec 2012 10:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc-BCp5KZFLg for ; Wed, 19 Dec 2012 10:49:59 -0800 (PST) Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0521F87B1 for ; Wed, 19 Dec 2012 10:49:58 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id 90C8130ACE for ; Wed, 19 Dec 2012 18:20:15 -0500 (EST) Message-ID: <50D20FCA.60602@connotech.com> Date: Wed, 19 Dec 2012 14:04:42 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Hipsec@ietf.org References: <50B449B1.5010205@connotech.com> In-Reply-To: <50B449B1.5010205@connotech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Network-bound puzzles for HIP? X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:49:59 -0000 Hi! An update ... no clear solution benefit for HIP denial-of-service mitigation. The main point being that artificial latency introduced by network-bound puzzles may be hard to control given the kind of "acceptable" delays for a legitimate HIP connection. (in case someone wants to investigate further, I advanced these ideas for a different problem statement: http://www.connotech.com/time_ticket_sub_prot.html title "Internet Public Service Abuse Mitigation with a Time Ticket Sub-Protocol") Regards, - Thierry Thierry Moreau wrote: > Hi, > > I find quite interesting the active development of HIPv2 drafts. From an > applied cryptography perspective, I appreciate this state-of-the-art > secure protocol development. > > Nonetheless, I am very novice in the design of puzzles for DOS attack > mitigation. But I have this idea of network-bound puzzle so that the > battery life of sensor devices is preserved. > > Very roughly ... > > The network-bound puzzle is a pair > If time0>=time1 the solution is zero > Otherwise, the solution is obtained from the "URI server" (using an > plain UDP query) at a time no earlier than time1 (which the HIP > initiator may guesstimate as now+(time1-time0) > (I use absolute times such that the URI server need not be synchronized > with the responder). > > UDP queries to the URI server simply carry some value timeX (discrete > resolution) > The URI server simply answers UDP queries with either > a) solutX (for timeX>=now), else > b) delayed UDP response solutX (if timeX in near future and the URI > server is not currently under heavy load), or else > c) some "REQUEST TOO EARLY" negative response. > > In practice, some secret pseudo-random sequence defines the successive > solutions. I would guess a timeX resolution of 0.1 second would allow > DOS attacks mitigation in low to medium throughput HIP responder hosts, > but this is only from intuition. > > The HIP responder may need a special arrangement with the URI server to > learn the responses in advance (or on a priority basis during a DOS > attack). I guess the two could be the same system (the URI server needs > not be "trusted"). > > ... end of rough idea. > > Was this ever envisioned? Were the practicalities ever looked at? > > Anyway, just my little suggestion. > > > Yes, I did look at > http://www.ietf.org/mail-archive/web/hipsec/current/msg03122.html > (Memory-bound puzzles in BEX) > and the reference by Rivest et al. (which does not address the DOS > mitigation as it is understood nowadays but has something along the URI > server idea for "timed-released crypto"). > > and > http://www.ietf.org/mail-archive/web/hipsec/current/msg03565.html > (New Version Notification for draft-hummen-hip-middle-puzzle-00.txt) > > > Regards, >