From oleg.ponomarev@hiit.fi Fri Mar 6 04:55:34 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C223A685E for ; Fri, 6 Mar 2009 04:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXW11Wjd5FvY for ; Fri, 6 Mar 2009 04:55:34 -0800 (PST) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 115A53A67D2 for ; Fri, 6 Mar 2009 04:55:32 -0800 (PST) Received: from stargazer.pc.infrahip.net (stargazer.pc.infrahip.net [IPv6:2001:708:140:220:215:60ff:fe9f:60c4]) by felwood.infrahip.net (8.14.2/8.14.2) with ESMTP id n26Ctugw002544; Fri, 6 Mar 2009 14:55:57 +0200 Date: Fri, 6 Mar 2009 14:55:56 +0200 (EET) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer.pc.infrahip.net To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BCD6@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D07B0BCD6@XCH-NW-5V1.nw.nos.boeing.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) X-GPG-FINGRPRINT: E94D 632A 70E4 3F92 9A7E B04E 20BF FC6B 983B CA5E X-GPG-PUBLIC_KEY: http://ponomarev.ru/oleg.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIT to IP in DNS X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 12:55:34 -0000 Hi! On Wed, 21 Jan 2009, Henderson, Thomas R wrote: Apologies for the late reply, I did not have time to update the draft before, but now submitted its new version that is available at http://www.ietf.org/internet-drafts/draft-ponomarev-hip-hit2ip-02.txt This version has much longer discussion about the usage and deployment. > You are really talking about defining domain names based on HITs and > storing them in a well known domain. Maybe the title could be > simplified to "Storing HITs as domain names in the DNS". Right, I changed it to "Embedding Host Identity Tags Data in DNS" > What if the target end system uses an RVS? This is just an interface to HIT->IP database, a rendezvous server may update the mapping with its own interface, but it is not covered in the draft. > 2.1. Preconfigured Domain > The systems using this method MUST have the same domain pre- > configured, for example hit-to-ip.example.net. > > It seems like this could be slightly relaxed to state that systems MUST > share at least one top-level domain storing the HITs, since it is > conceivable that more than one server (name service provider) could be > used, and records could be looked up at multiple places. Ok, I added a usage scenario with multiple independent mapping services. > 2.4 Managing the Records > The system MAY send DNS UPDATE[RFC2136] to the server provided by SOA > MNAME field of the domain. The system MUST use HIT as the source > address in this case. > > Can you clarify what "source address" you are talking about above? Sure, I changed to "The system MAY add or delete A,AAAA,PTR,CNAME records for its own HIT representation.The update MUST then originate from the corresponding HIT". > The system MAY add or delete A/AAAA or CNAME > records for its own HIT representation. The domain provided in SOA > MNAME field of the preconfigured domain MUST have Host Identity of > the server stored in DNS, the IP addresses MUST be listed in that > domain using suggested method and the server MUST accept DNS UPDATE > messages, which add or delete A/AAAA or CNAME records for the HIT > representation of the client after successfull HIP base exchange. > > It might be helpful to clarify that the HIP base exchange here serves to > authenticate the origin of the DNS UPDATE, from the server's > perspective. Added. > Also, DHTs are an alternative lookup mechanism that can be used in this > scenario; it would be helpful to reference that draft: > http://tools.ietf.org/html/draft-ahrenholz-hiprg-dht-03 Thanks for you feedback and for this tip, I wanted to mention DHT, but could not find this ID in the archive of hip-related drafts. Would it make sense to show "*-hiprg-*" on the HIP WG page as well? AFAIK extended mapping of Internet Drafts (by name) to WG was implemented recently. -- Regards, Oleg. From root@core3.amsl.com Mon Mar 9 10:15:02 2009 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1C8723A6C37; Mon, 9 Mar 2009 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309171502.1C8723A6C37@core3.amsl.com> Date: Mon, 9 Mar 2009 10:15:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-nat-traversal-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Basic HIP Extensions for Traversal of Network Address Translators Author(s) : M. Komu, et al. Filename : draft-ietf-hip-nat-traversal-06.txt Pages : 31 Date : 2009-03-09 This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-nat-traversal-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09100431.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 12:30:01 2009 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 98FAA3A685B; Mon, 9 Mar 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309193001.98FAA3A685B@core3.amsl.com> Date: Mon, 9 Mar 2009 12:30:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-bone-01.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment Author(s) : G. Camarillo, et al. Filename : draft-ietf-hip-bone-01.txt Pages : 18 Date : 2009-03-09 This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-bone-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-bone-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09121617.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Wed Mar 11 02:26:18 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA603A6A74 for ; Wed, 11 Mar 2009 02:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 469S9OR7i1hd for ; Wed, 11 Mar 2009 02:26:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5922E3A68D2 for ; Wed, 11 Mar 2009 02:26:17 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13E572060E for ; Wed, 11 Mar 2009 10:26:52 +0100 (CET) X-AuditID: c1b4fb3c-ad80abb000001b43-69-49b783dcfa6c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0A9A2203F1 for ; Wed, 11 Mar 2009 10:26:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 10:26:50 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 10:26:49 +0100 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C0825244E for ; Wed, 11 Mar 2009 11:26:49 +0200 (EET) Message-ID: <49B783D9.3070505@nomadiclab.com> Date: Wed, 11 Mar 2009 11:26:49 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: hipsec@ietf.org References: <20090309171502.1C8723A6C37@core3.amsl.com> In-Reply-To: <20090309171502.1C8723A6C37@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2009 09:26:49.0624 (UTC) FILETIME=[8178C980:01C9A22B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-nat-traversal-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 09:26:18 -0000 Hi all, 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 : Basic HIP Extensions for Traversal of Network Address Translators > Author(s) : M. Komu, et al. > Filename : draft-ietf-hip-nat-traversal-06.txt > Pages : 31 > Date : 2009-03-09 This new version of the draft has only fairly small technical changes (new STUN username encoding and change of the packets where pacing is negotiated) and some clarifications. Based on our implementation experience the draft seems reasonable and we are currently starting interoperability tests between two implementations. We think the draft is getting mature enough to move forward. If you have any concerns on this, please comment on the list. Of course other comments are welcome too. Cheers, Ari From mglt.ietf@gmail.com Mon Mar 23 14:42:28 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291DC3A6A82 for ; Mon, 23 Mar 2009 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkvWqcrD5kgC for ; Mon, 23 Mar 2009 14:42:27 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 285AF3A67F5 for ; Mon, 23 Mar 2009 14:42:26 -0700 (PDT) Received: by bwz17 with SMTP id 17so1964092bwz.37 for ; Mon, 23 Mar 2009 14:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ci6Mj6TB9aeaJaCWwcBzEQG7mQgYG8yub6XDPnQky5M=; b=Z5agltS/YBRizM0RUW7F9cOtFMU7r2A7Y80ZXB40LXmoHjXt7NXJ0D/LArRT7PdOYr DnL3ffb3DiHgUH/GAl5AZ/MRw77vJNmdQslBKrWjo2/PefXDC20CmgzAsn/gg2qH6fPM AYF+ia7zJfscCFIyVM5Tu62gM4mzzxQypzwBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nCx4acmrQLTfSO2rxtZluKcVUfSNmXuyf+3e2y/V8nERGE4oE/46+gXFo0fIc9rAmr geUsek/cLvT1C9Y2MfryIRbcMF9P5tWD/fUWchcJJCNF3o9tUDu8ScjuAvyK/3i1A+vq /q788QHs0u62RVNBQ0jNTjAPQ+eE3mz0x2Tyc= MIME-Version: 1.0 Received: by 10.223.107.199 with SMTP id c7mr6454785fap.31.1237844596389; Mon, 23 Mar 2009 14:43:16 -0700 (PDT) Date: Mon, 23 Mar 2009 22:43:16 +0100 Message-ID: <51eafbcb0903231443m55c330cevd8b2a6d2bf47db85@mail.gmail.com> From: Daniel Migault To: hipsec@ietf.org Content-Type: multipart/alternative; boundary=001636c5b84d7478e30465d02721 Subject: [Hipsec] SRP and IPR X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:42:28 -0000 --001636c5b84d7478e30465d02721 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here is a link on SRP and patterns http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08027.html It can be found on the from the wikipedia SRP page. http://en.wikipedia.org/wiki/Secure_remote_password_protocol -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001636c5b84d7478e30465d02721 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Here is a link on SRP and patterns
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08027.html

It can be found on the from the wikipedia SRP page.
http://en.wikipedia.org/wiki/Secure_remote_password_protocol

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--001636c5b84d7478e30465d02721-- From miika.komu@hiit.fi Fri Mar 27 05:24:43 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA503A6A83 for ; Fri, 27 Mar 2009 05:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAZXPZjsMl10 for ; Fri, 27 Mar 2009 05:24:42 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id E96DE3A6850 for ; Fri, 27 Mar 2009 05:24:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 9A8EC21AF5C for ; Fri, 27 Mar 2009 14:25:35 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31026-09; Fri, 27 Mar 2009 14:25:30 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 073CA21AF57 for ; Fri, 27 Mar 2009 14:25:30 +0200 (EET) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 015A625ED06 for ; Fri, 27 Mar 2009 14:25:30 +0200 (EET) Message-ID: <49CCC5B9.9000002@hiit.fi> Date: Fri, 27 Mar 2009 14:25:29 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Subject: [Hipsec] allocation of LSI address space X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:24:43 -0000 Hi, we have been talking about reserving address space for non-routable address in draft-iana-rfc3330bis-06. After some discussion with Robert Moskowitz and Antti Louko, I wrote down some straw-man text. Before you start reading the text, you should notice that it is not HIP specific. Also, the "site-local context" is an attempt to extend a little bit beyond of current standards for HIP. Perhaps HIP folks can think about leasing an LSI from DHCP if you have trouble in picturing an use case for the site-local addresses. Looking forward for comments. Better yet, please rewrite the text if you're not happy with it!) Address Space for Non-routable IPv4 Addresses --------------------------------------------- Address space 1.0.0.0/8 is reserved for experimental use with flat, non-routable IPv4 addresses. An example of such addresses are Local Scope Identifiers (LSIs) in Host Identity Protocol [RFC4423, section 5.4], but the namespace can be used by any other protocol. The address space is not managed by IANA except for 1.255.255.255 which reserved for protocol-specific broadcast. As the namespace is unmanaged, the namespace is not collision free and the addresses are valid only within a local context. Local context refers either to a host or site context as explained below. Selection of the context depends on the underlying protocol making use of the 1.0.0.0/8 address space and, hence, it is out of scope of this document. In host-local context, an address valid only within the local host. The local and peer address assignment is managed by the local system. In site-local context, an address is valid within an administrative domain consisting of a number of hosts. The addresses are distributed for the hosts using a centralized (or distributed) mechanism by the site. When an address from host-local or site-local context leaks to another context, it MUST be considered invalid. Detection of context leaks are protocol specific and therefore not specified herein. The address allocation policy in both host-local and site-local context has to follow two rules. First, the policy MUST NOT partition the address space into subprefixes. Second, the policy MUST be based on random allocation of new addresses. The reason for this address allocation policy is to avoid namespace collision upon the event when namespaces of two or more sites are joined together. The address space reserves a relatively large namespace for non-routable IPv4 addresses. A large namespace is necessary for two reasons. First, the same address space is used by multiple protocols and each protocol may want to separate addresses from each other. Second, the large namespace lowers collision probabilities when sites with large number of routable addresses are joined together. From jeffrey.m.ahrenholz@boeing.com Fri Mar 27 11:51:43 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0DC28C16F for ; Fri, 27 Mar 2009 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPQy-Av6AJeN for ; Fri, 27 Mar 2009 11:51:43 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 1E52A28C106 for ; Fri, 27 Mar 2009 11:51:43 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2RIqYbp006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Mar 2009 11:52:35 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2RIqYXg012477 for ; Fri, 27 Mar 2009 13:52:34 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2RIqMUQ012166 for ; Fri, 27 Mar 2009 13:52:34 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 11:52:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 11:52:32 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7A74@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: incorrect examples in RFC 5202 Thread-Index: AcmvDS/mcTRHPY5CRX+ePXEcdouBZA== From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 27 Mar 2009 18:52:33.0859 (UTC) FILETIME=[306C0130:01C9AF0D] Subject: [Hipsec] incorrect examples in RFC 5202 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:51:43 -0000 The examples in sections 5.2.1.1 and 5.2.1.2 of RFC 5202 seem incorrect. Here is the "Modifications in R1" example: IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, HOST_ID, [ ECHO_REQUEST, ] HIP_SIGNATURE_2 ) [, ECHO_REQUEST ]) The ESP_TRANSFORM (4095) belongs after the HOST_ID (705) (and any ECHO_REQUEST) and before HIP_SIGNATURE_2 (61633) so it should look like this: IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID, [ ECHO_REQUEST, ] ESP_TRANSFORM, HIP_SIGNATURE_2 ) [, ECHO_REQUEST ]) A similar change is needed for the "Modifications in I2" example with the I2 packet. Note that RFC 5201 does contain this text: " Parameters using type values from 2048 up to 4095 are transport formats. Currently, one transport format is defined: the ESP transport format [RFC5202]. The order of these parameters does not follow the order of their type value, but they are put in the packet in order of preference. The first of the transport formats it the most preferred, and so on." ...but that TLV parameter ordering seems to apply only to types 2048 through 4095, the order of preference of any transport formats; it is not saying that types 2048-4095 can go anywhere in the packet. This came up with some interop tests performed by Oleg Ponomarev. -Jeff From rgm@htt-consult.com Mon Mar 30 14:45:29 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B8928C133 for ; Mon, 30 Mar 2009 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgiZcPCA8OAF for ; Mon, 30 Mar 2009 14:45:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id A10F13A6D54 for ; Mon, 30 Mar 2009 14:45:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2ULkLTF003535 for ; Mon, 30 Mar 2009 17:46:21 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Mon, 30 Mar 2009 17:45:49 -0400 (EDT) Date: Mon, 30 Mar 2009 17:45:48 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49D13D8C.6070403@htt-consult.com> In-Reply-To: <49CCC5B9.9000002@hiit.fi> References: <49CCC5B9.9000002@hiit.fi> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Subject: Re: [Hipsec] allocation of LSI address space X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:45:29 -0000 Miika Komu wrote: > Hi, > > we have been talking about reserving address space for non-routable > address in draft-iana-rfc3330bis-06. After some discussion with Robert > Moskowitz and Antti Louko, I wrote down some straw-man text. I am going to put on an IANA hat, for discuss purposes. > > Before you start reading the text, you should notice that it is not > HIP specific. Also, the "site-local context" is an attempt to extend a > little bit beyond of current standards for HIP. Perhaps HIP folks can > think about leasing an LSI from DHCP if you have trouble in picturing > an use case for the site-local addresses. > > Looking forward for comments. Better yet, please rewrite the text if > you're not happy with it!) > > Address Space for Non-routable IPv4 Addresses > --------------------------------------------- > > Address space 1.0.0.0/8 is reserved for experimental use with flat, > non-routable IPv4 addresses. ICANN is hurting. They are under pressure to move 1.0.0.0/8 from reserved to unassigned. That is they are going to have IANA allocate Net1 to RIRs and let any 25+ year old problems surface and be dealt with. > An example of such addresses are Local Scope Identifiers (LSIs) in > Host Identity Protocol [RFC4423, section 5.4], but the namespace can > be used by any other protocol. > > The address space is not managed by IANA except for 1.255.255.255 > which reserved for protocol-specific broadcast. As the namespace is > unmanaged, the namespace is not collision free and the addresses are > valid only within a local context. Local context refers either to a > host or site context as explained below. Selection of the context > depends on the underlying protocol making use of the 1.0.0.0/8 address > space and, hence, it is out of scope of this document. > > In host-local context, an address valid only within the local host. > The local and peer address assignment is managed by the local system. This is what 127.0.0.0/8 is for use it. > > In site-local context, an address is valid within an administrative > domain consisting of a number of hosts. The addresses are distributed > for the hosts using a centralized (or distributed) mechanism by the site. This is what RFC1918 allocated addresses are for, use them. > > When an address from host-local or site-local context leaks to another > context, it MUST be considered invalid. Detection of context leaks are > protocol specific and therefore not specified herein. > > The address allocation policy in both host-local and site-local > context has to follow two rules. First, the policy MUST NOT partition > the address space into subprefixes. Second, the policy MUST be based > on random allocation of new addresses. The reason for this address > allocation policy is to avoid namespace collision upon the event when > namespaces of two or more sites are joined together. > > The address space reserves a relatively large namespace for > non-routable IPv4 addresses. A large namespace is necessary for two > reasons. First, the same address space is used by multiple protocols > and each protocol may want to separate addresses from each other. > Second, the large namespace lowers collision probabilities when sites > with large number of routable addresses are joined together. For our purposes, we need to look real hard if 127.255.0.0/16 will work for us and various apps won't hickup with this new use of Net127. If we need more space consider 127.192.0.0/14 or even 127.128.0.0/12. We need to have the data on hand as to why Net127 does not work before we ask for space in Net1. If Net127 DOES meet our needs, we still need to educate IANA on this so that it can be recorded in 3330bis for posperity. And given the timing for 3330bis, we need to act fast. In fact can our chairs inform IANA that we have this concern, to actually posting a last-call comment on ietf mailing list? From rgm@htt-consult.com Mon Mar 30 14:55:59 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57543A68D1 for ; Mon, 30 Mar 2009 14:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLlNist2Abhg for ; Mon, 30 Mar 2009 14:55:59 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id E34CE3A6846 for ; Mon, 30 Mar 2009 14:55:58 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2ULuoOu004724 for ; Mon, 30 Mar 2009 17:56:50 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Mon, 30 Mar 2009 17:55:54 -0400 (EDT) Date: Mon, 30 Mar 2009 17:55:53 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49D13FE9.7020206@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Developing a todo list for getting HIP on the standards track X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:56:00 -0000 THE HIP EXPERIMENT IS A SUCCESS. Or at least that is my position and I will hold to it. Yes there are pieces that still need more work and more business cases are needed but it is time for the work to move to standards track which means work for many and time commitments. Myself included. So first which RFCs are impacted? All the HIP RFCs? For example, 5207 is informational; does it need changes even while staying informational? IMO ALL the other HIP RFCs (4423 included) will need to be reved. So we have to look at them all to see what needs to be thought out (like the LSI discussion that I started to a small group and Miika has brought to the list) and what else is impacted. For example, ORCHIDs (RFC4843) will either need to go to Standards as well or we will need to NOT reference ORCHIDs. There is also the BEET draft that has timed out yet again. I have already started working with Tim Polk on this an I spoke with Sheila Frankel about it thursday. Tim has asked Sheila to give it an expert review. Sheila wanted to know if all BEET is is tunnel without tunneling, and if so is it really worth saving those handful or 2 of bytes per packet. Off the cuff, I responded that BEET is a header compression in the classical mode of header compressions. That those that implemented HIP figured out that my original intent to run HIP over Transport mode had issues, and that Tunnel was better, but that the whole Tunnel header could be compressed out. That there are use cases for HIP where that overhead IS an issue and so we should be allowed a tunnel compression mode. Further we have actual experience with the Linux 2.6.27 kernel that IPsec and HIP can coexist. That the presence of BEET mode support in the kernel is not a problem with IPsec implementations. But it is clear at least to me that text is needed in draft 10 of BEET. Anyway, I will begin to post areas of discussion on items we need to address in each of our documents and hope that editors will step forward (myself included) that will make the needed changes and shepard through the revised documents over the next year. One other thing is will we need a charter revision? If so, what political energy will be needed to accomplish this? IMO, those that have invested time and money will want to see HIP through to Standards and will lend the effort to get this in place. I am putting in my request to go to Stockholm. At this point, though, I will not be attending Hiroshima (I have avoided asia venues because of Shabbos challenges, and for 2 years now Verizon has canceled all Q4 non-sales travel, it took quite a bit for me to attend Minneapolis last year; Japan would never have gotten approved). Kudos to all HIP authors, developers, testers, implmentors, and most importantly, chairs. From rgm@htt-consult.com Mon Mar 30 14:56:06 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C17E3A6B68 for ; Mon, 30 Mar 2009 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIz+wdvQJzXm for ; Mon, 30 Mar 2009 14:56:05 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 88CAE3A6A36 for ; Mon, 30 Mar 2009 14:56:05 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2ULut5d004748 for ; Mon, 30 Mar 2009 17:56:57 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Mon, 30 Mar 2009 17:56:05 -0400 (EDT) Date: Mon, 30 Mar 2009 17:56:04 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49D13FF4.7060700@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] HIP needs hash agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:56:06 -0000 One item that is a MUST to address in HIP is adding hash agility. This is specifically called out in the IESG comments in RFC5201. I doubt if there is anyone here that feels otherwise, but we need to work out some requirements. Hash agility SHOULD include HIT generation. Even if analysis shows that today's class of attacks on SHA-1 do not affect HIT generation does not mean this will always be the case. Hash agility MUST NOT added to that HIP base exchange. That is, in dealing with say downgrade attacks, the HIP exchange MUST NOT be increased from its current 4 packets. It is ALLOWed to change the state machine as needed in adding Hash agility. The hash used to generate the HIT SHOULD be used to protect the HIP base exchange. KISS. HITs in ACLs SHOULD be considered in adding Hash agility (should you be able to tell by looking at an ACL that a HIT uses a hash that you no longer support). Adding Hash agility MAY result in reving the version number in HIP. What else is needed for a design for hash agility? ============================================= Here is my 1st serious thought on Hash agility: We alter the content of the HI to be not just the PK pair and the algorithm (plus parameters) used, but also the Hash for HIT/Base exchange. The only question would be is it always just ONE hash, or can it be a set? From rgm@htt-consult.com Mon Mar 30 15:38:22 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2073A698F for ; Mon, 30 Mar 2009 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RZjQHlZz0E7 for ; Mon, 30 Mar 2009 15:38:21 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 52AD63A68DF for ; Mon, 30 Mar 2009 15:38:20 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2RLTA3b012195 for ; Fri, 27 Mar 2009 17:29:10 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Fri, 27 Mar 2009 17:29:08 -0400 (EDT) Date: Fri, 27 Mar 2009 17:29:07 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49CD4523.50202@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] HIP needs hash agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:38:22 -0000 One item that is a MUST to address in HIP is adding hash agility. This is specifically called out in the IESG comments in RFC5201. I doubt if there is anyone here that feels otherwise, but we need to work out some requirements. Hash agility SHOULD include HIT generation. Even if analysis shows that today's class of attacks on SHA-1 do not affect HIT generation does not mean this will always be the case. Hash agility MUST NOT added to that HIP base exchange. That is, in dealing with say downgrade attacks, the HIP exchange MUST NOT be increased from its current 4 packets. It is ALLOWed to change the state machine as needed in adding Hash agility. The hash used to generate the HIT SHOULD be used to protect the HIP base exchange. KISS. HITs in ACLs SHOULD be considered in adding Hash agility (should you be able to tell by looking at an ACL that a HIT uses a hash that you no longer support). Adding Hash agility MAY result in reving the version number in HIP. What else is needed for a design for hash agility? ============================================= Here is my 1st serious thought on Hash agility: We alter the content of the HI to be not just the PK pair and the algorithm (plus parameters) used, but also the Hash for HIT/Base exchange. The only question would be is it always just ONE hash, or can it be a set? From rgm@htt-consult.com Mon Mar 30 15:40:27 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4993A6832 for ; Mon, 30 Mar 2009 15:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWOAFTz6j+40 for ; Mon, 30 Mar 2009 15:40:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id E25D03A68DF for ; Mon, 30 Mar 2009 15:40:25 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2RL2Zqu009934 for ; Fri, 27 Mar 2009 17:02:35 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Fri, 27 Mar 2009 17:01:39 -0400 (EDT) Date: Fri, 27 Mar 2009 17:01:38 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49CD3EB2.30303@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Developing a todo list for getting HIP on the standards track X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:40:27 -0000 THE HIP EXPERIMENT IS A SUCCESS. Or at least that is my position and I will hold to it. Yes there are pieces that still need more work and more business cases are needed but it is time for the work to move to standards track which means work for many and time commitments. Myself included. So first which RFCs are impacted? All the HIP RFCs? For example, 5207 is informational; does it need changes even while staying informational? IMO ALL the other HIP RFCs (4423 included) will need to be reved. So we have to look at them all to see what needs to be thought out (like the LSI discussion that I started to a small group and Miika has brought to the list) and what else is impacted. For example, ORCHIDs (RFC4843) will either need to go to Standards as well or we will need to NOT reference ORCHIDs. There is also the BEET draft that has timed out yet again. I have already started working with Tim Polk on this an I spoke with Sheila Frankel about it thursday. Tim has asked Sheila to give it an expert review. Sheila wanted to know if all BEET is is tunnel without tunneling, and if so is it really worth saving those handful or 2 of bytes per packet. Off the cuff, I responded that BEET is a header compression in the classical mode of header compressions. That those that implemented HIP figured out that my original intent to run HIP over Transport mode had issues, and that Tunnel was better, but that the whole Tunnel header could be compressed out. That there are use cases for HIP where that overhead IS an issue and so we should be allowed a tunnel compression mode. Further we have actual experience with the Linux 2.6.27 kernel that IPsec and HIP can coexist. That the presence of BEET mode support in the kernel is not a problem with IPsec implementations. But it is clear at least to me that text is needed in draft 10 of BEET. Anyway, I will begin to post areas of discussion on items we need to address in each of our documents and hope that editors will step forward (myself included) that will make the needed changes and shepard through the revised documents over the next year. One other thing is will we need a charter revision? If so, what political energy will be needed to accomplish this? IMO, those that have invested time and money will want to see HIP through to Standards and will lend the effort to get this in place. I am putting in my request to go to Stockholm. At this point, though, I will not be attending Hiroshima (I have avoided asia venues because of Shabbos challenges, and for 2 years now Verizon has canceled all Q4 non-sales travel, it took quite a bit for me to attend Minneapolis last year; Japan would never have gotten approved). Kudos to all HIP authors, developers, testers, implmentors, and most importantly, chairs. From rgm@htt-consult.com Mon Mar 30 15:40:28 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4D03A6832 for ; Mon, 30 Mar 2009 15:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-n0qKyTNLSK for ; Mon, 30 Mar 2009 15:40:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 8A3FB3A6B04 for ; Mon, 30 Mar 2009 15:40:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2RKfZYZ008551 for ; Fri, 27 Mar 2009 16:41:35 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Fri, 27 Mar 2009 16:40:57 -0400 (EDT) Date: Fri, 27 Mar 2009 16:40:51 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49CD39D3.9070401@htt-consult.com> In-Reply-To: <49CCC5B9.9000002@hiit.fi> References: <49CCC5B9.9000002@hiit.fi> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Subject: Re: [Hipsec] allocation of LSI address space X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:40:28 -0000 Miika Komu wrote: > Hi, > > we have been talking about reserving address space for non-routable > address in draft-iana-rfc3330bis-06. After some discussion with Robert > Moskowitz and Antti Louko, I wrote down some straw-man text. I am going to put on an IANA hat, for discuss purposes. > > Before you start reading the text, you should notice that it is not > HIP specific. Also, the "site-local context" is an attempt to extend a > little bit beyond of current standards for HIP. Perhaps HIP folks can > think about leasing an LSI from DHCP if you have trouble in picturing > an use case for the site-local addresses. > > Looking forward for comments. Better yet, please rewrite the text if > you're not happy with it!) > > Address Space for Non-routable IPv4 Addresses > --------------------------------------------- > > Address space 1.0.0.0/8 is reserved for experimental use with flat, > non-routable IPv4 addresses. ICANN is hurting. They are under pressure to move 1.0.0.0/8 from reserved to unassigned. That is they are going to have IANA allocate Net1 to RIRs and let any 25+ year old problems surface and be dealt with. > An example of such addresses are Local Scope Identifiers (LSIs) in > Host Identity Protocol [RFC4423, section 5.4], but the namespace can > be used by any other protocol. > > The address space is not managed by IANA except for 1.255.255.255 > which reserved for protocol-specific broadcast. As the namespace is > unmanaged, the namespace is not collision free and the addresses are > valid only within a local context. Local context refers either to a > host or site context as explained below. Selection of the context > depends on the underlying protocol making use of the 1.0.0.0/8 address > space and, hence, it is out of scope of this document. > > In host-local context, an address valid only within the local host. > The local and peer address assignment is managed by the local system. This is what 127.0.0.0/8 is for use it. > > In site-local context, an address is valid within an administrative > domain consisting of a number of hosts. The addresses are distributed > for the hosts using a centralized (or distributed) mechanism by the site. This is what RFC1918 allocated addresses are for, use them. > > When an address from host-local or site-local context leaks to another > context, it MUST be considered invalid. Detection of context leaks are > protocol specific and therefore not specified herein. > > The address allocation policy in both host-local and site-local > context has to follow two rules. First, the policy MUST NOT partition > the address space into subprefixes. Second, the policy MUST be based > on random allocation of new addresses. The reason for this address > allocation policy is to avoid namespace collision upon the event when > namespaces of two or more sites are joined together. > > The address space reserves a relatively large namespace for > non-routable IPv4 addresses. A large namespace is necessary for two > reasons. First, the same address space is used by multiple protocols > and each protocol may want to separate addresses from each other. > Second, the large namespace lowers collision probabilities when sites > with large number of routable addresses are joined together. For our purposes, we need to look real hard if 127.255.0.0/16 will work for us and various apps won't hickup with this new use of Net127. If we need more space consider 127.192.0.0/14 or even 127.128.0.0/12. We need to have the data on hand as to why Net127 does not work before we ask for space in Net1. If Net127 DOES meet our needs, we still need to educate IANA on this so that it can be recorded in 3330bis for posperity. And given the timing for 3330bis, we need to act fast. In fact can our chairs inform IANA that we have this concern, to actually posting a last-call comment on ietf mailing list? From rgm@htt-consult.com Mon Mar 30 15:55:28 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F1D3A6A3C for ; Mon, 30 Mar 2009 15:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zNpmyqaN9DO for ; Mon, 30 Mar 2009 15:55:27 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 3C6A23A67B1 for ; Mon, 30 Mar 2009 15:55:26 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2UMuLq3008497 for ; Mon, 30 Mar 2009 18:56:21 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Mon, 30 Mar 2009 18:56:20 -0400 (EDT) Date: Mon, 30 Mar 2009 18:56:19 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49D14E13.3080208@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Sorry for the double posting X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:55:28 -0000 My mailserver had developed problems mailing to ietf.org lists. So after fixing it, I resent the messages. Then the queued messages finally came through... From thomas.r.henderson@boeing.com Mon Mar 30 22:03:16 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E204D3A682A for ; Mon, 30 Mar 2009 22:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgQL0td3YNML for ; Mon, 30 Mar 2009 22:03:15 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 6E65D3A69CF for ; Mon, 30 Mar 2009 22:02:59 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2V53je4000454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 22:03:50 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2V53jer005881; Mon, 30 Mar 2009 22:03:45 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2V53jwk005874; Mon, 30 Mar 2009 22:03:45 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 22:03:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 22:03:44 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BFBB@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <49CCC5B9.9000002@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] allocation of LSI address space Thread-Index: Acmu1yTU8+cMzcIJS0iOyPmSxkW+TAC5Tz8g References: <49CCC5B9.9000002@hiit.fi> From: "Henderson, Thomas R" To: , X-OriginalArrivalTime: 31 Mar 2009 05:03:45.0117 (UTC) FILETIME=[116F28D0:01C9B1BE] Subject: Re: [Hipsec] allocation of LSI address space X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:03:17 -0000 Hi, I had a few comments also on this proposal (inline below). I would also be fine with Robert's suggestion for 127.255/16, or for RFC1918 addresses in some HIP proxy situations. >=20 > Address Space for Non-routable IPv4 Addresses > --------------------------------------------- Many people use the term non-routable for RFC1918 addresses, which is not what I think you meant (but would be fine with me-- see above). >=20 > Address space 1.0.0.0/8 is reserved for experimental use with flat,=20 > non-routable IPv4 addresses. An example of such addresses are Local=20 > Scope Identifiers (LSIs) in Host Identity Protocol [RFC4423, section=20 > 5.4], but the namespace can be used by any other protocol. >=20 > The address space is not managed by IANA except for=20 > 1.255.255.255 which=20 > reserved for protocol-specific broadcast. As the namespace is=20 > unmanaged,=20 > the namespace is not collision free and the addresses are valid only=20 > within a local context. Local context refers either to a host or site=20 > context as explained below. Selection of the context depends on the=20 > underlying protocol making use of the 1.0.0.0/8 address space and,=20 > hence, it is out of scope of this document. >=20 > In host-local context, an address valid only within the local=20 > host. The=20 > local and peer address assignment is managed by the local system. >=20 > In site-local context, an address is valid within an administrative=20 > domain consisting of a number of hosts. The addresses are distributed=20 > for the hosts using a centralized (or distributed) mechanism=20 > by the site. >=20 > When an address from host-local or site-local context leaks=20 > to another=20 > context, it MUST be considered invalid. Detection of context=20 > leaks are=20 > protocol specific and therefore not specified herein. I do not see the point of the above paragraph, plus if you are arguing for generating them randomly, and that they must be flat, how is a context leak detected? >=20 > The address allocation policy in both host-local and=20 > site-local context=20 > has to follow two rules. First, the policy MUST NOT partition the=20 > address space into subprefixes. Second, the policy MUST be based on=20 > random allocation of new addresses. The reason for this address=20 > allocation policy is to avoid namespace collision upon the event when=20 > namespaces of two or more sites are joined together. I don't see the point for restricting the above. We found it convenient to use non random LSIs in some of our experiments, such as 1.0.0.1, 1.0.0.2, etc. I would rather just say that random allocation is one technique to reduce collisions and leave it at that. - Tom From miika.komu@hiit.fi Mon Mar 30 22:16:21 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD083A6859 for ; Mon, 30 Mar 2009 22:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s96YwT6Bj9VU for ; Mon, 30 Mar 2009 22:16:20 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 37BC23A6A9C for ; Mon, 30 Mar 2009 22:16:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 8DAF421AF3B; Tue, 31 Mar 2009 08:17:18 +0300 (EEST) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03506-01; Tue, 31 Mar 2009 08:17:12 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id E7F1921AF27; Tue, 31 Mar 2009 08:17:12 +0300 (EEST) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id E0D9625ED06; Tue, 31 Mar 2009 08:17:12 +0300 (EEST) Message-ID: <49D1A758.9000800@hiit.fi> Date: Tue, 31 Mar 2009 08:17:12 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <49CCC5B9.9000002@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D07B0BFBB@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BFBB@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: hipsec@ietf.org Subject: Re: [Hipsec] allocation of LSI address space X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:16:21 -0000 Henderson, Thomas R wrote: Hi, > Hi, I had a few comments also on this proposal (inline below). I would > also be fine with Robert's suggestion for 127.255/16, or for RFC1918 > addresses in some HIP proxy situations. no strong objections on /16 either (it is better than nothing). I tried to argument why /8 would be more useful in the text. >> Address Space for Non-routable IPv4 Addresses >> --------------------------------------------- > > Many people use the term non-routable for RFC1918 addresses, which is > not what I think you meant (but would be fine with me-- see above). > >> Address space 1.0.0.0/8 is reserved for experimental use with flat, >> non-routable IPv4 addresses. An example of such addresses are Local >> Scope Identifiers (LSIs) in Host Identity Protocol [RFC4423, section >> 5.4], but the namespace can be used by any other protocol. >> >> The address space is not managed by IANA except for >> 1.255.255.255 which >> reserved for protocol-specific broadcast. As the namespace is >> unmanaged, >> the namespace is not collision free and the addresses are valid only >> within a local context. Local context refers either to a host or site >> context as explained below. Selection of the context depends on the >> underlying protocol making use of the 1.0.0.0/8 address space and, >> hence, it is out of scope of this document. >> >> In host-local context, an address valid only within the local >> host. The >> local and peer address assignment is managed by the local system. >> >> In site-local context, an address is valid within an administrative >> domain consisting of a number of hosts. The addresses are distributed >> for the hosts using a centralized (or distributed) mechanism >> by the site. >> >> When an address from host-local or site-local context leaks >> to another >> context, it MUST be considered invalid. Detection of context >> leaks are >> protocol specific and therefore not specified herein. > > I do not see the point of the above paragraph, plus if you are arguing > for generating them randomly, and that they must be flat, how is a > context leak detected? The above paragraph was not very important. Detecting leaks is a hard problem and shouldn't be discussed in the text. >> The address allocation policy in both host-local and >> site-local context >> has to follow two rules. First, the policy MUST NOT partition the >> address space into subprefixes. Second, the policy MUST be based on >> random allocation of new addresses. The reason for this address >> allocation policy is to avoid namespace collision upon the event when >> namespaces of two or more sites are joined together. > > I don't see the point for restricting the above. We found it convenient > to use non random LSIs in some of our experiments, such as 1.0.0.1, > 1.0.0.2, etc. I would rather just say that random allocation is one > technique to reduce collisions and leave it at that. Right. From thomas.r.henderson@boeing.com Mon Mar 30 22:17:04 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8533A3A67BD for ; Mon, 30 Mar 2009 22:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKJmby8ehukN for ; Mon, 30 Mar 2009 22:17:03 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id CEC7F3A68A6 for ; Mon, 30 Mar 2009 22:17:03 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2V5Hqsp003124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Mar 2009 22:17:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2V5Hq6I017259; Tue, 31 Mar 2009 00:17:52 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2V5Ho0O017227; Tue, 31 Mar 2009 00:17:52 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 22:17:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 22:17:50 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BFBC@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <49D13FE9.7020206@htt-consult.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Developing a todo list for getting HIP on the standardstrack Thread-Index: AcmxgnQp2ZRvsPapRU2Wu7ZxzfPd2wAPM6Tg References: <49D13FE9.7020206@htt-consult.com> From: "Henderson, Thomas R" To: "Robert Moskowitz" , X-OriginalArrivalTime: 31 Mar 2009 05:17:51.0149 (UTC) FILETIME=[09B565D0:01C9B1C0] Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standardstrack X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:17:04 -0000 > There is also the BEET draft that has timed out yet again. I have > already started working with Tim Polk on this an I spoke with Sheila > Frankel about it thursday. Tim has asked Sheila to give it an expert > review. Sheila wanted to know if all BEET is is tunnel without > tunneling, and if so is it really worth saving those handful or 2 of > bytes per packet. Off the cuff, I responded that BEET is a header > compression in the classical mode of header compressions. That those > that implemented HIP figured out that my original intent to=20 > run HIP over > Transport mode had issues, and that Tunnel was better, but that the > whole Tunnel header could be compressed out. That there are use cases > for HIP where that overhead IS an issue and so we should be allowed a > tunnel compression mode. Note that BEET mode allows sessions to roam across address families, which makes it possibly a transition mechanism. But, I agree that it is probably just an optimization in many cases. Tom From thomas.r.henderson@boeing.com Mon Mar 30 22:18:31 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CAF3A69CF for ; Mon, 30 Mar 2009 22:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eDJQa57YP-p for ; Mon, 30 Mar 2009 22:18:31 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 333D83A68A6 for ; Mon, 30 Mar 2009 22:18:31 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2V5JODx003324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 22:19:25 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n2V5JOdA026065; Mon, 30 Mar 2009 22:19:24 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n2V5JO4B026062; Mon, 30 Mar 2009 22:19:24 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 22:19:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 22:19:23 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BFBD@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <49D13FE9.7020206@htt-consult.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Developing a todo list for getting HIP on the standardstrack Thread-Index: AcmxgnQp2ZRvsPapRU2Wu7ZxzfPd2wAPZv8Q References: <49D13FE9.7020206@htt-consult.com> From: "Henderson, Thomas R" To: "Robert Moskowitz" , X-OriginalArrivalTime: 31 Mar 2009 05:19:24.0229 (UTC) FILETIME=[41304750:01C9B1C0] Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standardstrack X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:18:31 -0000 =20 > So first which RFCs are impacted? All the HIP RFCs? For=20 > example, 5207 > is informational; does it need changes even while staying=20 > informational? What about NAT traversal? I think it should not be left behind, although it is not an RFC yet. Tom From miika.komu@hiit.fi Tue Mar 31 00:58:15 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3DE3A69CC for ; Tue, 31 Mar 2009 00:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDuAJoXmAkUb for ; Tue, 31 Mar 2009 00:58:14 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 9B7E03A693B for ; Tue, 31 Mar 2009 00:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id CFCFA21AF56 for ; Tue, 31 Mar 2009 10:59:10 +0300 (EEST) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12396-08; Tue, 31 Mar 2009 10:59:07 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 1FCE521AF3C for ; Tue, 31 Mar 2009 10:59:07 +0300 (EEST) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 10B1525ED06 for ; Tue, 31 Mar 2009 10:59:07 +0300 (EEST) Message-ID: <49D1CD4A.3060307@hiit.fi> Date: Tue, 31 Mar 2009 10:59:06 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Subject: Re: [Hipsec] HIP needs hash agility X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 07:58:15 -0000 Robert Moskowitz wrote: Hi, > One item that is a MUST to address in HIP is adding hash agility. This > is specifically called out in the IESG comments in RFC5201. I doubt if > there is anyone here that feels otherwise, but we need to work out some > requirements. > > Hash agility SHOULD include HIT generation. Even if analysis shows that > today's class of attacks on SHA-1 do not affect HIT generation does not > mean this will always be the case. > > Hash agility MUST NOT added to that HIP base exchange. That is, in > dealing with say downgrade attacks, the HIP exchange MUST NOT be > increased from its current 4 packets. It is ALLOWed to change the state > machine as needed in adding Hash agility. > > The hash used to generate the HIT SHOULD be used to protect the HIP base > exchange. KISS. > > HITs in ACLs SHOULD be considered in adding Hash agility (should you be > able to tell by looking at an ACL that a HIT uses a hash that you no > longer support). > > Adding Hash agility MAY result in reving the version number in HIP. > > What else is needed for a design for hash agility? I think we are going to need a new version of ORCHID that tells the hash version? Below are some comments from Ken Rimey. We have also asked Julien about the exact reason why the context id is incorporated in the hash input (security?), but no response yet. -------- Original Message -------- Subject: ORCHIDs Date: Tue, 10 Mar 2009 21:07:33 +0200 From: Ken Rimey To: ext Pekka Nikander CC: samu.varjonen@hiit.fi, miika.komu@hiit.fi Pekka, After talking it over with Samu and Miika, I'd like to offer some feedback on ORCHIDs. Instead of using Hash_function(Context ID | Input) as the input to Encode_100(), it would be better to use Hash_function(Context ID) XOR Hash_function(Input) I'll explain. I am running an administratively decentralized lookup service (not a DHT) that stores limited-size byte strings (up to 8K) with a limited time-to-live (up to a week), indexed by principal-label pair. (See http://openlookup.net/.) The arguments to a lookup are the public key fingerprint and the label or its hash. I also support querying with a prefix of the public key fingerprint instead of the full fingerprint. Samu would like to use this service to look up information about a host identity (current address, public key, etc.) using a HIT instead of my public key fingerprint. The problem is that this would require me to maintain an additional database index. More generally, if people are going to want to be able to look up information using ORCHIDs, it would seem that I will need to maintain an additional database index for each context identifier of interest. A lookup would involve providing a context identifier, an ORCHID, and a label. The intent of my proposed change is to enable the client to factor the context identifier out of the ORCHID and provide the context-independent public key hash instead -- 100 bits of it, that is. (The purpose of XORing with the hash of the context identifier instead of the context identifier itself is to prevent the party selecting the context identifier from trivially arranging for an inter-context collision to occur.) I want to encourage clients to provide the full public key fingerprint and not just 100 bits of it, but I can handle both cases with just one database B-tree index by adding a rotation by 30 bits to the hash function so as to bring the middle 100 bits to the front. That's not pretty, however, so if there is no strong reason to use the middle 100 bits, I think it would be appropriate to additionally change the ORCHID scheme to straightforwardly use the first 100 bits. (I don't know the original rationale for that choice.) Comments? Ken From rgm@htt-consult.com Tue Mar 31 03:56:53 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3FD3A6A62 for ; Tue, 31 Mar 2009 03:56:53 -0700 (PDT) X-Quarantine-ID: <9Y6s4mskPPzx> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y6s4mskPPzx for ; Tue, 31 Mar 2009 03:56:52 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 97C6D3A6A9D for ; Tue, 31 Mar 2009 03:56:51 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n2VAvi8W014138 for ; Tue, 31 Mar 2009 06:57:44 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 31 Mar 2009 06:57:24 -0400 (EDT) Date: Tue, 31 Mar 2009 06:57:23 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <49D1F713.4000508@htt-consult.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D07B0BFBD@XCH-NW-5V1.nw.nos.boeing.com> References: <49D13FE9.7020206@htt-consult.com> References: <77F357662F8BFA4CA7074B0410171B6D07B0BFBD@XCH-NW-5V1.nw.nos.boeing.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standardstrack X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 10:56:53 -0000 Henderson, Thomas R wrote: > > >> So first which RFCs are impacted? All the HIP RFCs? For >> example, 5207 >> is informational; does it need changes even while staying >> informational? >> > > What about NAT traversal? I think it should not be left behind, > although it is not an RFC yet. Oh course, it gets added to the list....