From jan.melen@nomadiclab.com Fri Nov 2 07:48:30 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 B688F21F8602 for ; Fri, 2 Nov 2012 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D89u0JYxeATW for ; Fri, 2 Nov 2012 07:48:30 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E755621F85D4 for ; Fri, 2 Nov 2012 07:48:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A75BA4E6F5; Fri, 2 Nov 2012 16:48:27 +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 sQg4_1h2Bhro; Fri, 2 Nov 2012 16:48:26 +0200 (EET) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2a00:1d50:2:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id DC3BA4E6F3; Fri, 2 Nov 2012 16:48:26 +0200 (EET) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id A73F71ADE41; Fri, 2 Nov 2012 16:48:22 +0200 (EET) Received: from [127.0.0.1] (n2.nomadiclab.com [IPv6:2a00:1d50:2:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 64BD31ADE23; Fri, 2 Nov 2012 16:48:22 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_25A32002-8A4B-47FE-9617-4FB9B94CB813" From: Jan Melen In-Reply-To: Date: Fri, 2 Nov 2012 16:48:18 +0200 Message-Id: References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> <5082BD8C.4090205@cs.hut.fi> To: Tobias Heer X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: ClamAV using ClamSMTP Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities 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, 02 Nov 2012 14:48:30 -0000 --Apple-Mail=_25A32002-8A4B-47FE-9617-4FB9B94CB813 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Oct 21, 2012, at 12:21 AM, Tobias Heer wrote: > > Am 20.10.2012 17:04 schrieb "Miika Komu" : > > > > Hi, > > > > > > On 10/20/2012 01:28 AM, Henderson, Thomas R wrote: > >>> > >>> > >>> Since parsing and formatting code for both is pretty much ubiquitous > >>> and the packet space is dominated by the key itself, I see no real > >>> reason to change. That DNSKEY is supposed only to be used for DNSSEC > >>> is a distraction, we have our own RR and reusing the wire format is > >>> merely a convenience. > >> > >> > >> +1 > > > > > > fine by me as well. > > I agree. +1. > A bit slow reply but yes +1 from us as well. Cheers, Jan --Apple-Mail=_25A32002-8A4B-47FE-9617-4FB9B94CB813 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Oct 21, 2012, at 12:21 AM, Tobias Heer wrote:


Am 20.10.2012 17:04 schrieb "Miika Komu" <mkomu@cs.hut.fi>:
>
> Hi,
>
>
> On 10/20/2012 01:28 AM, Henderson, Thomas R wrote:
>>>
>>>
>>> Since parsing and formatting code for both is pretty much ubiquitous
>>> and the packet space is dominated by the key itself, I see no real
>>> reason to change.  That DNSKEY is supposed only to be used for DNSSEC
>>> is a distraction, we have our own RR and reusing the wire format is
>>> merely a convenience.
>>
>>
>> +1
>
>
> fine by me as well.

I agree. +1.


A bit slow reply but yes +1 from us as well.

Cheers,
  Jan

--Apple-Mail=_25A32002-8A4B-47FE-9617-4FB9B94CB813-- From internet-drafts@ietf.org Mon Nov 5 07:50:40 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 2181C21F87AA; Mon, 5 Nov 2012 07:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 vYi2O5Fda8SA; Mon, 5 Nov 2012 07:50:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D455321F8458; Mon, 5 Nov 2012 07:50:37 -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.35 Message-ID: <20121105155037.14973.4012.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:50:37 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-reload-instance-06.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: Mon, 05 Nov 2012 15:50:40 -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 : Host Identity Protocol-Based Overlay Networking Environm= ent (HIP BONE) Instance Specification for REsource LOcation And Discovery (= RELOAD) Author(s) : Ari Keranen Gonzalo Camarillo Jouni Maenpaa Filename : draft-ietf-hip-reload-instance-06.txt Pages : 10 Date : 2012-11-05 Abstract: This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-reload-instance-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-reload-instance-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ari.keranen@nomadiclab.com Mon Nov 5 07:53:02 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 29ADB21F8843 for ; Mon, 5 Nov 2012 07:53:02 -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 0KlNKuodGSKJ for ; Mon, 5 Nov 2012 07:53:01 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E65B21F881D for ; Mon, 5 Nov 2012 07:53:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 22F594E6E6 for ; Mon, 5 Nov 2012 17:53:00 +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 vkfLgsRmOjU2 for ; Mon, 5 Nov 2012 17:52:59 +0200 (EET) Received: from dhcp-4643.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 4C8A44E678 for ; Mon, 5 Nov 2012 17:52:59 +0200 (EET) Message-ID: <5097E0D9.4060804@nomadiclab.com> Date: Mon, 05 Nov 2012 10:52:57 -0500 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <20121105155037.14973.4012.idtracker@ietfa.amsl.com> In-Reply-To: <20121105155037.14973.4012.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-reload-instance-06.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: Mon, 05 Nov 2012 15:53:02 -0000 FYI: just a keep-alive update to the RELOAD instance draft. Cheers, Ari On 11/5/12 10:50 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) > Author(s) : Ari Keranen > Gonzalo Camarillo > Jouni Maenpaa > Filename : draft-ietf-hip-reload-instance-06.txt > Pages : 10 > Date : 2012-11-05 > > Abstract: > This document is the Host Identity Protocol-Based Overlay Networking > Environment (HIP BONE) instance specification for the REsource > LOcation And Discovery (RELOAD) protocol. The document provides the > details needed to build a RELOAD-based overlay that uses HIP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-reload-instance > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-reload-instance-06 > > > 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 rgm@htt-consult.com Mon Nov 5 11:45:48 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 2147321F86C7 for ; Mon, 5 Nov 2012 11:45:48 -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 sefldCdczErL for ; Mon, 5 Nov 2012 11:45:41 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9274321F8457 for ; Mon, 5 Nov 2012 11:45:41 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C093F62A89 for ; Mon, 5 Nov 2012 19:45:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcTVD0bmYqK0 for ; Mon, 5 Nov 2012 14:45:02 -0500 (EST) Received: from lx120e.htt-consult.com (dhcp-174b.meeting.ietf.org [130.129.23.75]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 936CB62A71 for ; Mon, 5 Nov 2012 14:45:02 -0500 (EST) Message-ID: <5098173D.3040908@htt-consult.com> Date: Mon, 05 Nov 2012 14:45:01 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Cjdns anyone? 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, 05 Nov 2012 19:45:48 -0000 http://en.wikipedia.org/wiki/Cjdns I was forwarded an email from a security list where Cjdns was discussed. Looking at it, it sure looks familiar! Is anyone connected to the people behind this? From rgm@htt-consult.com Thu Nov 8 12:00:57 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 3068D21F8B2F for ; Thu, 8 Nov 2012 12:00:57 -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 Ueu7KbEA7KPl for ; Thu, 8 Nov 2012 12:00:56 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 85E2321F8A65 for ; Thu, 8 Nov 2012 12:00:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 76F9962A5E for ; Thu, 8 Nov 2012 20:00:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AerarzSK2Xux for ; Thu, 8 Nov 2012 14:59:58 -0500 (EST) Received: from lx120e.htt-consult.com (dhcp-174b.meeting.ietf.org [130.129.23.75]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id A39B562C32 for ; Thu, 8 Nov 2012 14:59:57 -0500 (EST) Message-ID: <509C0F3B.80107@htt-consult.com> Date: Thu, 08 Nov 2012 14:59:55 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] 5201-bis LSI address allocation 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: Thu, 08 Nov 2012 20:00:57 -0000 In 5201-bis we should specify the LSI address range. Net1 has been allocated to APNIC (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). Alternatives mentioned are: 1) dynamically select from 1918 address space like VMs do (but this does not play well with mobility) 2) Use a /16 (we did discuss this earlier with the opinion that a /16 would be large enough) in 127/8. Say 127.9/16 (it could even be a /10, see below)? 3) Request IANA make an assignment from the class E range. 4) Follow precedence set in RFC 6598 for a /10 allocation, but this requires finding a kind owner of address space that would give it up for this purpose. Let's agree on this, then Tom and I will add a section on it into 5201-bis. From heer@informatik.rwth-aachen.de Fri Nov 9 01:12:14 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 8A67221F84B7 for ; Fri, 9 Nov 2012 01:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] 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 aWNiHEf7ICal for ; Fri, 9 Nov 2012 01:12:12 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0273721F8781 for ; Fri, 9 Nov 2012 01:12:11 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_d8fa6kw42+YG1vmxIOs+1A)" Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) 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 <0MD7000CSQWAZ6K0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 09 Nov 2012 10:12:10 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.80,744,1344204000"; d="scan'208";a="198895276" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-1.rz.rwth-aachen.de with ESMTP; Fri, 09 Nov 2012 10:12:10 +0100 Received: from mail-ie0-f172.google.com ([unknown] [209.85.223.172]) 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 <0MD700AEMQW93V50@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 09 Nov 2012 10:12:10 +0100 (CET) Received: by mail-ie0-f172.google.com with SMTP id 9so6242057iec.31 for ; Fri, 09 Nov 2012 01:12:09 -0800 (PST) Received: by 10.50.157.200 with SMTP id wo8mr835282igb.29.1352452329314; Fri, 09 Nov 2012 01:12:09 -0800 (PST) Received: by 10.50.178.73 with HTTP; Fri, 09 Nov 2012 01:12:09 -0800 (PST) Received: by 10.50.178.73 with HTTP; Fri, 09 Nov 2012 01:12:09 -0800 (PST) In-reply-to: <509C0F3B.80107@htt-consult.com> References: <509C0F3B.80107@htt-consult.com> Date: Fri, 09 Nov 2012 10:12:09 +0100 Message-id: From: Tobias Heer To: Robert Moskowitz Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis LSI address allocation 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, 09 Nov 2012 09:12:14 -0000 --Boundary_(ID_d8fa6kw42+YG1vmxIOs+1A) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hello Robert, the question that I just asked myself is: why is it necessary to define the LSI space? After all, the adresses are only local and should not leave the host. So for interoperability between HIP hosts it should not matter. However... Of course, the address space should not collide with any other address space on the host. So coexistence with different applications DOES matter. For this purpose, wouldn't it be enough to give a solid recommendation for a good address space? I agree that the basis for such a recommendation is a specific allocation. However, I think it should be a "SHOULD use" in the final text. With the goal of coexistence in mind, I would pledge for a HIP-only address space. Using the same space as many VMs do will cause trouble and won't benefit coexistence. Regarding the size of the address space. Using a /16 may not be enough for some server applications that serve different hosts with high frequency. However, in such case, the administrator could locally define a different larger space and rule out collisions with other applications locally (if we use the "SHOULD use" phrase). Therefore, for typical applications, I would support a /16 as recommendation. I hope these thoughts help to make a good decision. BR, Tobias Am 08.11.2012 20:59 schrieb "Robert Moskowitz" : > In 5201-bis we should specify the LSI address range. > > Net1 has been allocated to APNIC (http://www.iana.org/** > assignments/ipv4-address-**space/ipv4-address-space.xml). > Alternatives mentioned are: > > 1) dynamically select from 1918 address space like VMs do (but this does > not play well with mobility) > > 2) Use a /16 (we did discuss this earlier with the opinion that a /16 > would be large enough) in 127/8. Say 127.9/16 (it could even be a /10, see > below)? > > 3) Request IANA make an assignment from the class E range. > > 4) Follow precedence set in RFC 6598 for a /10 allocation, but this > requires finding a kind owner of address space that would give it up for > this purpose. > > Let's agree on this, then Tom and I will add a section on it into 5201-bis. > > > ______________________________**_________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/**listinfo/hipsec > --Boundary_(ID_d8fa6kw42+YG1vmxIOs+1A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable

Hello Robert,

the question that I just asked myself is: why is it necessar= y to define the LSI space? After all, the adresses are only local and shoul= d not leave the host. So for interoperability between HIP=A0 hosts it shoul= d not matter. However...

Of course, the address space should not collide with any oth= er address space on the host. So coexistence=A0 with different applications= DOES matter. For this purpose, wouldn't it be enough to give a solid r= ecommendation for a good address space? I agree that the basis for such a r= ecommendation is a specific allocation. However, I think it should be a &qu= ot;SHOULD use" in the final text.

With the goal of coexistence in mind, I would pledge for a H= IP-only address space. Using the same space as many VMs do will cause troub= le and won't benefit coexistence.

Regarding the size of the address space. Using a /16 may not= be enough for some server applications that serve different hosts with hig= h frequency. However, in such case, the administrator could locally define = a different larger space and rule out collisions with other applications lo= cally (if we use the "SHOULD use" phrase). Therefore,=A0 for typi= cal applications, I would support a /16 as recommendation.

I hope these thoughts help to make a good decision.

BR,

Tobias

Am 08.11.2012 20:59 schrieb "Robert Moskowi= tz" <rgm@htt-consult.com= >:
In 5201-bis we should specify the LSI address range.

Net1 has been allocated to APNIC (http://www.i= ana.org/assignments/ipv4-address-space/ipv4-address-space.xml= ). Alternatives mentioned are:

1) dynamically select from 1918 address space like VMs do (but this does no= t play well with mobility)

2) Use a /16 (we did discuss this earlier with the opinion that a /16 would= be large enough) in 127/8. =A0Say 127.9/16 (it could even be a /10, see be= low)?

3) Request IANA make an assignment from the class E range.

4) Follow precedence set in RFC 6598 for a /10 allocation, but this require= s finding a kind owner of address space that would give it up for this purp= ose.

Let's agree on this, then Tom and I will add a section on it into 5201-= bis.


_______________________________________________
Hipsec mailing list
Hipsec@ietf.org = https://www.ietf.org/mailman/listinfo/hipsec
--Boundary_(ID_d8fa6kw42+YG1vmxIOs+1A)-- From rgm@htt-consult.com Fri Nov 9 06:50: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 43A6A21F86F7 for ; Fri, 9 Nov 2012 06:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgSFBsfx9d-4 for ; Fri, 9 Nov 2012 06:50:08 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0021F8553 for ; Fri, 9 Nov 2012 06:50:08 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B62CA633AD; Fri, 9 Nov 2012 14:49:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49IShF5OBwVm; Fri, 9 Nov 2012 09:49:22 -0500 (EST) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0B58F633B1; Fri, 9 Nov 2012 09:49:16 -0500 (EST) Message-ID: <509D17EB.5080404@htt-consult.com> Date: Fri, 09 Nov 2012 09:49:15 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tobias Heer References: <509C0F3B.80107@htt-consult.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050203030002070501090104" Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis LSI address allocation 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, 09 Nov 2012 14:50:10 -0000 This is a multi-part message in MIME format. --------------050203030002070501090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/09/2012 02:12 AM, Tobias Heer wrote: > > Hello Robert, > > the question that I just asked myself is: why is it necessary to > define the LSI space? After all, the adresses are only local and > should not leave the host. So for interoperability between HIP hosts > it should not matter. However... > > Of course, the address space should not collide with any other address > space on the host. So coexistence with different applications DOES > matter. For this purpose, wouldn't it be enough to give a solid > recommendation for a good address space? I agree that the basis for > such a recommendation is a specific allocation. However, I think it > should be a "SHOULD use" in the final text. > It will definitely be a SHOULD for whatever address space we work out. > With the goal of coexistence in mind, I would pledge for a HIP-only > address space. Using the same space as many VMs do will cause trouble > and won't benefit coexistence. > > Regarding the size of the address space. Using a /16 may not be enough > for some server applications that serve different hosts with high > frequency. However, in such case, the administrator could locally > define a different larger space and rule out collisions with other > applications locally (if we use the "SHOULD use" phrase). Therefore, > for typical applications, I would support a /16 as recommendation. > > I hope these thoughts help to make a good decision. > I spoke with Andrew McGregor, Tim Shepard, and our new ID, Brian Haberman about this. The focus seems to be 127 or Class E. 127.10/10, is one option, but according to Andrew and Tim, kernels tend to turn off TCP congestion control for a 127 address. This would be a challenge. Brian is interested in the Class E space. There ARE problems of packets just being dropped if a Class E address was in the IP source address field, but LSIs only occur in places like the TCB. A bit more research will be needed on using Class E. If Brian comes back that this may be a way forward, we probably should have some real testing over the next couple weeks that it will really work before we put it in 5201-bis (and get the address space marked as 'reserved for local use'. > BR, > > Tobias > > Am 08.11.2012 20:59 schrieb "Robert Moskowitz" >: > > > > In 5201-bis we should specify the LSI address range. > > > > Net1 has been allocated to APNIC > (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). > Alternatives mentioned are: > > > > 1) dynamically select from 1918 address space like VMs do (but this > does not play well with mobility) > > > > 2) Use a /16 (we did discuss this earlier with the opinion that a > /16 would be large enough) in 127/8. Say 127.9/16 (it could even be a > /10, see below)? > > > > 3) Request IANA make an assignment from the class E range. > > > > 4) Follow precedence set in RFC 6598 for a /10 allocation, but this > requires finding a kind owner of address space that would give it up > for this purpose. > > > > Let's agree on this, then Tom and I will add a section on it into > 5201-bis. > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > --------------050203030002070501090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/09/2012 02:12 AM, Tobias Heer wrote:

Hello Robert,

the question that I just asked myself is: why is it necessary to define the LSI space? After all, the adresses are only local and should not leave the host. So for interoperability between HIP  hosts it should not matter. However...

Of course, the address space should not collide with any other address space on the host. So coexistence  with different applications DOES matter. For this purpose, wouldn't it be enough to give a solid recommendation for a good address space? I agree that the basis for such a recommendation is a specific allocation. However, I think it should be a "SHOULD use" in the final text.


It will definitely be a SHOULD for whatever address space we work out.

With the goal of coexistence in mind, I would pledge for a HIP-only address space. Using the same space as many VMs do will cause trouble and won't benefit coexistence.

Regarding the size of the address space. Using a /16 may not be enough for some server applications that serve different hosts with high frequency. However, in such case, the administrator could locally define a different larger space and rule out collisions with other applications locally (if we use the "SHOULD use" phrase). Therefore,  for typical applications, I would support a /16 as recommendation.

I hope these thoughts help to make a good decision.



I spoke with Andrew McGregor, Tim Shepard, and our new ID, Brian Haberman about this.  The focus seems to be 127 or Class E. 

127.10/10, is one option, but according to Andrew and Tim, kernels tend to turn off TCP congestion control for a 127 address.  This would be a challenge.

Brian is interested in the Class E space.  There ARE problems of packets just being dropped if a Class E address was in the IP source address field, but LSIs only occur in places like the TCB.  A bit more research will be needed on using Class E.  If Brian comes back that this may be a way forward, we probably should have some real testing over the next couple weeks that it will really work before we put it in 5201-bis (and get the address space marked as 'reserved for local use'.

BR,

Tobias

Am 08.11.2012 20:59 schrieb "Robert Moskowitz" <rgm@htt-consult.com>:
>
> In 5201-bis we should specify the LSI address range.
>
> Net1 has been allocated to APNIC (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). Alternatives mentioned are:
>
> 1) dynamically select from 1918 address space like VMs do (but this does not play well with mobility)
>
> 2) Use a /16 (we did discuss this earlier with the opinion that a /16 would be large enough) in 127/8.  Say 127.9/16 (it could even be a /10, see below)?
>
> 3) Request IANA make an assignment from the class E range.
>
> 4) Follow precedence set in RFC 6598 for a /10 allocation, but this requires finding a kind owner of address space that would give it up for this purpose.
>
> Let's agree on this, then Tom and I will add a section on it into 5201-bis.
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec


--------------050203030002070501090104-- From thomas.r.henderson@boeing.com Fri Nov 9 08:06:43 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 D32A121F8757 for ; Fri, 9 Nov 2012 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vnO67YnDsbO5 for ; Fri, 9 Nov 2012 08:06:43 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5B07B21F8756 for ; Fri, 9 Nov 2012 08:06:43 -0800 (PST) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qA9G6gLR006963 for ; Fri, 9 Nov 2012 10:06:42 -0600 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qA9G6Qmi006751 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 9 Nov 2012 10:06:42 -0600 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Fri, 9 Nov 2012 08:06:37 -0800 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" , Tobias Heer Date: Fri, 9 Nov 2012 08:06:36 -0800 Thread-Topic: [Hipsec] 5201-bis LSI address allocation Thread-Index: Ac2+iY/hp63AUoqRQG2qCCwaSnSSvwACaq+A Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C29F@XCH-NW-16V.nw.nos.boeing.com> References: <509C0F3B.80107@htt-consult.com> <509D17EB.5080404@htt-consult.com> In-Reply-To: <509D17EB.5080404@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_758141CC3D829043A8C3164DD3D593EA2E4C38C29FXCHNW16Vnwnos_" MIME-Version: 1.0 X-TM-AS-MML: No Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] 5201-bis LSI address allocation 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, 09 Nov 2012 16:06:43 -0000 --_000_758141CC3D829043A8C3164DD3D593EA2E4C38C29FXCHNW16Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We'll test class E with OpenHIP and report back later; that seems preferabl= e to me since 127/8 seems tied to localhost (RFC 3330) and RFC 1918 address= es are private routable addresses and aggressively deployed in some environ= ments. - Tom --_000_758141CC3D829043A8C3164DD3D593EA2E4C38C29FXCHNW16Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= We'll test class E with OpenHIP and report back later; that seems pr= eferable to me since 127/8 seems tied to localhost (RFC 3330) and RFC 1918 = addresses are private routable addresses and aggressively deployed in some = environments.

 <= /o:p>

- Tom

= --_000_758141CC3D829043A8C3164DD3D593EA2E4C38C29FXCHNW16Vnwnos_-- From rgm@htt-consult.com Mon Nov 19 12:39: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 3A4731F0C59 for ; Mon, 19 Nov 2012 12:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_40=-0.185] 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 Cfqyb4O4xsJE for ; Mon, 19 Nov 2012 12:39:09 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id AD7671F0C61 for ; Mon, 19 Nov 2012 12:39:09 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0953F62AAB for ; Mon, 19 Nov 2012 20:38:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdSL01vKdDel for ; Mon, 19 Nov 2012 15:38:37 -0500 (EST) Received: from lx120e2.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id CF82162A8F for ; Mon, 19 Nov 2012 15:38:37 -0500 (EST) Message-ID: <50AA98CD.2000804@htt-consult.com> Date: Mon, 19 Nov 2012 15:38:37 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Just recovered from killed notebook 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, 19 Nov 2012 20:39:10 -0000 There will be a slight delay in my work on the HIP docs; I just recovered from a killed notebook (last wed at IEEE802) with backups ~ 3 weeks old (thus changes to 4243-bis almost lost). It was from a Pepsi DOS attack on the keyboard. I have a new (refurbed) Lenovo and was able to rsync all my files from the old drive to the new. Thing is I am using F17 now and I don't have all the customizations working right and things are still difficult. everything is now backed up to my 2T drive I keep stored in a firebox. Keeping backups in a firebox is nice and safe, but then you have to take the drive out and do the backups..... From internet-drafts@ietf.org Sun Nov 25 22:24:52 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 D48BF21F868A; Sun, 25 Nov 2012 22:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, 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 1NlBOeEdla5g; Sun, 25 Nov 2012 22:24:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96621F85C0; Sun, 25 Nov 2012 22:24:52 -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: <20121126062451.28890.80456.idtracker@ietfa.amsl.com> Date: Sun, 25 Nov 2012 22:24:51 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-10.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: Mon, 26 Nov 2012 06:24:53 -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 : Host Identity Protocol Version 2 (HIPv2) Author(s) : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-10.txt Pages : 124 Date : 2012-11-25 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5201-bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.r.henderson@boeing.com Sun Nov 25 22:53:03 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 DB67D21F8695 for ; Sun, 25 Nov 2012 22:53:03 -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 dzPA0UDWoT-a for ; Sun, 25 Nov 2012 22:53:03 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6415021F868A for ; Sun, 25 Nov 2012 22:53:00 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qAQ6qxLB027840 for ; Sun, 25 Nov 2012 22:52:59 -0800 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qAQ6qwE8027837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Sun, 25 Nov 2012 22:52:59 -0800 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Sun, 25 Nov 2012 22:52:58 -0800 From: "Henderson, Thomas R" To: "hipsec@ietf.org" Date: Sun, 25 Nov 2012 22:52:58 -0800 Thread-Topic: update to RFC5201-bis, and open issues Thread-Index: Ac3DlGfgZRU760GRSj6RdXeFQC6HSwBvTorAAZNUneA= Message-ID: <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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [Hipsec] update to RFC5201-bis, and open issues 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, 26 Nov 2012 06:53:04 -0000 I've just posted an update to RFC5201-bis (mainly to address the editorial = issues that Ren=E9 Hummen found), and made some updates to the tracker for = additional open issues that we have been discussing since the WGLC review. = Below is a brief summary; we can open separate threads for discussing each= issue. 1) R1 counter roll over=20 The original point was made in this review: http://www.ietf.org/mail-archi= ve/web/hipsec/current/msg03608.html Subsequent discussion both on and off list grew to include whether the puzz= le and R1 counter are needed, or whether the implementations could be repla= ced by nonces. This is now issue 39 in the tracker: http://trac.tools.ietf.org/wg/hip/tra= c/ticket/39 2) Decreasing the per-packet overhead The original point was made in this review: http://www.ietf.org/mail-archi= ve/web/hipsec/current/msg03608.html This is now issue 40 in the tracker: http://trac.tools.ietf.org/wg/hip/tra= c/ticket/40 3) LSI prefix range in Class E or 127/8 range 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. This is now issue 41 in the tracker: http://trac.tools.ietf.org/wg/hip/tra= c/ticket/41 4) HOST ID encoding (use of DNSKEY RR) I believe that this issue is now closed based on recent list comments. Ple= ase speak up if you would like to treat this as an open issue. 5) Eliminate HIP checksum coverage of IP pseudoheader The original point was made in this review: http://www.ietf.org/mail-archi= ve/web/hipsec/current/msg03608.html I suggested on the list that I'd prefer to keep as is since I could not fin= d a precedent for dropping checksum coverage for non-tunnel situations. If= not needed for when HIP is operated over non-IP transport, then the draft = for HIP-over-non-IP can specify the change. Are there other differing opin= ions on this? If so, I can add another tracker issue. - Tom From thierry.moreau@connotech.com Mon Nov 26 20:50:36 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 EAE9C21F847F for ; Mon, 26 Nov 2012 20:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 hDuuMHfxdD8P for ; Mon, 26 Nov 2012 20:50:35 -0800 (PST) Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 39D7D21F8479 for ; Mon, 26 Nov 2012 20:50:32 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id 7CC1E30977 for ; Tue, 27 Nov 2012 04:22:39 -0500 (EST) Message-ID: <50B449B1.5010205@connotech.com> Date: Tue, 27 Nov 2012 00:03:45 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Tue, 27 Nov 2012 04:50:36 -0000 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, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From mkomu@cs.hut.fi Tue Nov 27 01:38:36 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 A1E6821F857A for ; Tue, 27 Nov 2012 01:38:36 -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 xkSF6YbthRgd for ; Tue, 27 Nov 2012 01:38:35 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id A94E521F856B for ; Tue, 27 Nov 2012 01:38:35 -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 D552B308A45 for ; Tue, 27 Nov 2012 11:38:33 +0200 (EET) Message-ID: <50B48A1A.1080609@cs.hut.fi> Date: Tue, 27 Nov 2012 11:38:34 +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: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP-based anycast 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, 27 Nov 2012 09:38:36 -0000 Hi, opportunistic mode with the help of a rendezvous server could be used for implementing HIP-based anycast. The current RVS specification does not allow this: http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02 4.3.1. Processing Outgoing I1 Packets An initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address that is known to be a rendezvous server address, unless it wants to establish a HIP association with the rendezvous server itself and does not know its HIT. I think we could specify either a flag in the base exchange or alternatively a special HIT encoding for the "NULL" destination HIT in the I1. What do you think? From mkomu@cs.hut.fi Wed Nov 28 07:56:31 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 04E0121F8825 for ; Wed, 28 Nov 2012 07:56:31 -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 VWsWcVyZW2Ix for ; Wed, 28 Nov 2012 07:56:30 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 13DA721F855A for ; Wed, 28 Nov 2012 07:56:29 -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 50B173089B0; Wed, 28 Nov 2012 17:56:27 +0200 (EET) Message-ID: <50B6342B.6030702@cs.hut.fi> Date: Wed, 28 Nov 2012 17:56:27 +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: Thierry Moreau , hip WG References: <50B449B1.5010205@connotech.com> In-Reply-To: <50B449B1.5010205@connotech.com> Content-Type: text/plain; charset=ISO-8859-1; 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, 28 Nov 2012 15:56:31 -0000 Hi Thierry, how do you register the network puzzle to the URI? Unlike the current HIP puzzle, your solution requires a third party? And it couples HIP control plane with e.g. CoAP (since you're talking about URIs)? A decoupled and more standards-compliant solution with a HIP-specific third party could to assume a rendezvous or relay server, which drops messages until some time period. This "some" could be defined when a host registers to rendezvous or relay server or updates its registration. The drawback here is that the initiator will not receive any time value for waiting (unless the rendezvous sends NOTIFY). I am not an expert, I believe current wireless sensor networks communicate through sink or gateway, so DoS protection is not really necessary for the sensors. However, the IoT vision is to have end-to-end connectivity for the sensors, so this may change in the future. Any thoughts on this? P.S. Are you aware of any patents related to network puzzles? On 11/27/2012 07:03 AM, 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, > From thierry.moreau@connotech.com Wed Nov 28 09:08:37 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 BC3AE21F8840 for ; Wed, 28 Nov 2012 09:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 bdbWvL2nyKyU for ; Wed, 28 Nov 2012 09:08:36 -0800 (PST) Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8799B21F8528 for ; Wed, 28 Nov 2012 09:08:36 -0800 (PST) Received: from [192.168.1.200] (unknown [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id 7113B3057D; Wed, 28 Nov 2012 16:40:36 -0500 (EST) Message-ID: <50B64833.3080905@connotech.com> Date: Wed, 28 Nov 2012 12:21:55 -0500 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Miika Komu References: <50B449B1.5010205@connotech.com> <50B6342B.6030702@cs.hut.fi> In-Reply-To: <50B6342B.6030702@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG 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, 28 Nov 2012 17:08:37 -0000 Miika Komu wrote: > Hi Thierry, > > how do you register the network puzzle to the URI? Unlike the current > HIP puzzle, your solution requires a third party? And it couples HIP > control plane with e.g. CoAP (since you're talking about URIs)? > These are "implementation details" at this point, and anyway someone else contribution is just as relevant as mine. A third party appears not essential. > A decoupled and more standards-compliant solution with a HIP-specific > third party could to assume a rendezvous or relay server, which drops > messages until some time period. This "some" could be defined when a > host registers to rendezvous or relay server or updates its > registration. The drawback here is that the initiator will not receive > any time value for waiting (unless the rendezvous sends NOTIFY). > That may qualify as "someone else contribution" and could be relevant. > I am not an expert, I believe current wireless sensor networks > communicate through sink or gateway, so DoS protection is not really > necessary for the sensors. However, the IoT vision is to have end-to-end > connectivity for the sensors, so this may change in the future. Any > thoughts on this? > As I understand it, the DOS protection benefits the responder, but the CPU energy cost is allocated to the legitimate initiators indiscriminately (hence the sensor end-point concern). > P.S. Are you aware of any patents related to network puzzles? > Not aware of anything from third party in this respect. I disclosed the proposal to the HIP mailing list assuming this would be a public disclosure (through the mail archive) and I did not file any patent application on this proposal. Regards, -- - Thierry Moreau > On 11/27/2012 07:03 AM, 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, >> > >