From goodzi@gmail.com Tue Feb 2 03:19:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE5328C1C5 for ; Tue, 2 Feb 2010 03:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzNWhFvPLRqy for ; Tue, 2 Feb 2010 03:19:48 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 378C128C1B0 for ; Tue, 2 Feb 2010 03:19:48 -0800 (PST) Received: by ewy28 with SMTP id 28so3699381ewy.28 for ; Tue, 02 Feb 2010 03:20:20 -0800 (PST) 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:content-transfer-encoding; bh=oJ5kNegW+5QzX59b0dQJYddHPWd0J/tCtcfmZZwoZKM=; b=eDmptOG7OSJIY52B48dLr5tcqn/3t0fcK9UuPGtv9pP79OAIXZTSpUjvIfCpGtjeru JPunuFhb0FnTsR9e59SFzhgzndEGJaqDj2JlppIscfYNA6Lf+uNHsOWzIJu8XrKe+LKO s+myb1vesOKee0hxual55r06hubpg6vufHpms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=f/qli+GVFmko7Xs0hbMpoZ2OD08D/UdNzulF+c8XqAOn9U/K8qYJx5hu1fa4KZoKmr prKiYRNbszGwAlBRbXE6WX3Uo9XXHUdEYo8EOgwcdTrtqZkZ/ZwtZkiycSI2mRZYUsT8 ZeGvenr5LdYiMedxhXoEbmstthiZLcCITfEYw= MIME-Version: 1.0 Received: by 10.216.89.205 with SMTP id c55mr2865330wef.186.1265109618419; Tue, 02 Feb 2010 03:20:18 -0800 (PST) Date: Tue, 2 Feb 2010 12:20:18 +0100 Message-ID: <47d91b9d1002020320r4a7c47dcmb882852a71c096a7@mail.gmail.com> From: Bokor Laszlo To: hipsec@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Hipsec] Host Identity Protocol simulation framework for INET/OMNeT++ 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, 02 Feb 2010 11:19:50 -0000 Dear All, I am happy to announce the first public release of HIPSim++ which is a Host Identity Protocol simulation framework for INET/OMNeT++ 4.x developed to provide a flexible toolset for testing and validation of HIP and its extensions. HIPSim++ has been implemented with conformance to the IETF=92s HIP specifications and has been validated against a real-life HIP testbed applying the InfraHIP implementation. For download and further information please visit our website: http://www.ict-optimix.eu/index.php/HIPSim I hope that you will find interesting stuff on the page and also that you will find the model useful in cost-effective, simulation-based HIP experiments. Best regards, goodzi -- Laszlo BOKOR / BME - Department of Telecommunications ----------------------- / Tel: +36-1-463-3420, Fax: +36-1-463-3307 Research fellow /------------------------------------------- From heer@informatik.rwth-aachen.de Tue Feb 2 05:51:10 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFFA3A68A6 for ; Tue, 2 Feb 2010 05:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDL6yEa4ZCEw for ; Tue, 2 Feb 2010 05:51:08 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 992CC3A6868 for ; Tue, 2 Feb 2010 05:51:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KX700CPNVU96PG0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 02 Feb 2010 14:51:45 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,390,1262559600"; d="scan'208";a="43370990" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 02 Feb 2010 14:51:45 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KX700KVEVU92250@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 02 Feb 2010 14:51:45 +0100 (CET) From: Tobias Heer Date: Tue, 02 Feb 2010 14:51:45 +0100 Message-id: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> To: "hipsec@ietf.org WG" X-Mailer: Apple Mail (2.1077) Subject: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Tue, 02 Feb 2010 13:51:10 -0000 Hello, we have been discussing about different options to include the HIH (host identity hash) index in HIP packet or in the HIT. The most compelling option (at least to me and Bob) is encoding the HIH in the HIT directly. Advantages of this procedure are: a) No need to supply additional parameters with the HIT to convey the HIH. This simplifies things like referrals and DNS (you just transfer an IPv6-comatible address instead of an address plus the HIH index). b) A host can immediately determine if it can use a HIT. There won't be any chance of receiving a HIT without knowing the type. However, encoding the HIH in the HIT means that we have to sacrifice bits that could have been used for crypto / collision resistance. The first question is how many bits we would have to sacrifice. I remember Tom asking if we could work with 4 bits for the HIH. I think one could work with four additional bits. This means that 16 different hash functions could be encoded at the same time. Of course we have to use crypto agility carefully then (i.e., we only introduce new HIH algorithms when the previous becomes insufficient). With 16 possible hash functions, this should give us plenty of time to completely phase out HIH #0 before #15 becomes insecure. If we look at the life-cycle of popular hash functions (MD5, SHA-1) 16 replacements represent a huge time frame. We could start over with #0 when #15 becomes insecure. Tom also asked whether 100 bits are enough or if we need more. From Julien's reply I take that it's not likely to get anything else than a /28 ORCHID prefix. So now the question is if fewer than 100 bits would do. Using 4 bits for crypto agility leaves us with 96 bits for the actual hash of the HI. Where will that put us in terms of collision resistance and security? I did some calculations based on the birthday paradox to give some examples and to get a feeling for the strength of 96 bits. However, I am not an expert on this, so please tell me if you have deeper insight into the required strength. The following table gives the number of hashes you have to compute for a given output hash length until you reach a certain collision probability (CP). I put 128 bit there as a reference. 100 bit is the status quo with a 28 bit ORCHID prefix. 96 bit is with 28 bit ORCHID prefix and 4 bit HIH index. +---------+---------+---------+---------+---------+---------+ | Bits/CP | 0.5 | 0.25 | 0.01 | 0.001 | 0.0001 | +---------+---------+---------+---------+---------+---------+ | 128 bit | 2.2E+19 | 1.4E+19 | 2.6E+18 | 8.3E+17 | 2.6E+17 | | 100 bit | 1.3E+15 | 8.5E+14 | 1.6E+14 | 5.0E+13 | 1.6E+13 | | 96 bit | 3.3E+14 | 2.1E+14 | 4.0E+13 | 1.3E+13 | 4.0E+12 | +---------+---------+---------+---------+---------+---------+ I pushed the collision probability down to 0.0001. For 96 bits you need a hash population of 4.0E+12 (4.000.000.000.000 / 4 trillion) to reach a collision with a probability of 0.0001. 100 bits will allow a population of 16 trillion before you reach the same probability. Some closer-to-real-world-examples that Bob asked me to do take a given population (e.g., entries in an ACL). Given an ACL size of 10.000.000 (10 M) the chance of a collision is about 0,0000000000000007 (7E-16) for 96 bits. Assuming an ACL of 680 billion (current world population x 100), the collision probability is 0,00000000000292 (2.92E-12) for 96 bits. For 100 bits the probability of a collision is 0,000000000000183 (1.83E-13) These numbers are for benign collisions. For an attacker, it is important to compute a HIT (including public key) that matches another HIT. From the numbers above it seems to me that creating a collision for a determined HIT is out of scope. Creating any HIT collision (e.g. by creating a large number of HITs) will probably not be dangerous either, because the chance that the HIT for which you find the collision is in use is rather small (the address space will be very sparsely populated). What remains is to find a collision for a set of HITs (the HITs that are in use). I found some work on how to compute the probability for sets of random variables but I was unable to come up with useful results because of the very large (and very small) numbers involved. Even Scheme with its good math support was unable to handle the numbers. Maybe someone with matlab skills can help. What I would like to know from the group: Do you think that a 28 + 4 + 96 bit HIT is a good choice? Do you think the cryptographic strength is sufficient? Do you have other preferences/alternatives? BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Tue Feb 2 07:14:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A962A3A688C for ; Tue, 2 Feb 2010 07:14: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6d8fRx5FqZi for ; Tue, 2 Feb 2010 07:14:00 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 16A783A693D for ; Tue, 2 Feb 2010 07:13:56 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8F59368B81 for ; Tue, 2 Feb 2010 16:11:22 +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 pCK0Q6eV-t2c for ; Tue, 2 Feb 2010 11:11:13 -0500 (EST) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 62CE068B4D for ; Tue, 2 Feb 2010 11:11:13 -0500 (EST) Message-ID: <4B68414D.9040402@htt-consult.com> Date: Tue, 02 Feb 2010 10:14:21 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.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] HIP usage in a large SmartGrid/SCADA environment 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, 02 Feb 2010 15:14:03 -0000 I really don't know if this is the way such a scenario would be implemented, but talking to the Power Engineering people, they SEEM to think so... Situation: 10 Million or so meters all controlled from a single server. Now I don't believe it would be a single server, I suspect that the meters will be regionally grouped by location on the grid. But still and all, lets work with the PES people on this one. It still could be 100K meters per server.... Meters do a HIP BEX at setup, and may never do another, as the key entropy will well handle the low volume of data. So the MK is stored in protected memory in the meter and a secure store on the server (that would survive server reboot, imagine forcing 10M meters to rekey becuase the server rebooted). Can HIP, will actually ESP SAs, scale to this large in a reasonable implementation? For now don't add in mobility (RVS server) and meter server redundancy (HIP/ESP SA fate sharing through some backend protocol?). Hopefully the meter app will be implemented over UDP, so a single packet comes in on an ESP SPI and that has to be looked up, processed and tossed up to the app. Then perhaps there will be a response back to the meter. The round trip needs to be in 100ms. How many SAs can we expect a single server to be able to support? Then there is the downstream alerts. Say a rate change notice taking affect in 5 min to 50K customers. That data packet with the rate information will have to be sent to each meter (this customer's meter is currently at IP address (HIT) n) with ACKs coming back that the rate information was accepted. Round trip for this is in seconds. Anyone want to tackle a scaling modeling challenge? Would HIP scale better than other security tools or about the same? From thomas.r.henderson@boeing.com Tue Feb 2 08:35:08 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9770F28C101 for ; Tue, 2 Feb 2010 08:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 OC0dIa9lneiw for ; Tue, 2 Feb 2010 08:35:07 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id B34913A6856 for ; Tue, 2 Feb 2010 08:35:07 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o12GZdFq002187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2010 08:35:40 -0800 (PST) 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 o12GZdxm004191; Tue, 2 Feb 2010 10:35:39 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o12GZchb004177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 2 Feb 2010 10:35:38 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 2 Feb 2010 08:35:38 -0800 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Tue, 2 Feb 2010 08:35:37 -0800 Thread-Topic: [Hipsec] 28 + 4 + 96 bit HIT crypto agility Thread-Index: AcqkDt+ByAo5sZotSmyJwGVqHUbLqgAE6iXw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> In-Reply-To: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hip WG Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Tue, 02 Feb 2010 16:35:08 -0000 Hi Tobias, thanks for continuing this thread. > > These numbers are for benign collisions. For an attacker, it > is important to compute a HIT (including public key) that > matches another HIT. From the numbers above it seems to me > that creating a collision for a determined HIT is out of > scope. I think you mean "not practical" rather than "out of scope", right? And by= not practical, this means that the cost of mounting a second preimage atta= ck by brute force (which includes the cost to create the key and hash it to= test that it matches the target HIT) is likely to be 2^96 work for 96 bits= if we continue to deprecate cracked hash functions over time, and that 2^9= 6 (10^28) work is not likely to be feasible even for an attacker with large= computing resources? > Creating any HIT collision (e.g. by creating a large > number of HITs) will probably not be dangerous either, > because the chance that the HIT for which you find the > collision is in use is rather small (the address space will > be very sparsely populated). What remains is to find a > collision for a set of HITs (the HITs that are in use). I > found some work on how to compute the probability for sets of > random variables but I was unable to come up with useful > results because of the very large (and very small) numbers > involved. Even Scheme with its good math support was unable > to handle the numbers. Maybe someone with matlab skills can help. > Doesn't this question devolve into "if you are using N HITs, your attack su= rface to brute force attack goes up by a factor of N"? > What I would like to know from the group: Do you think that a > 28 + 4 + 96 bit HIT is a good choice? Do you think the > cryptographic strength is sufficient? Do you have other > preferences/alternatives? Outside of the crypto issues, I think that encoding the HIH explicitly with= some number of bits (your proposal seems adequate to me) is going to be pr= eferable for ease of use considerations. I think there are broader system and use case issues that would need to be = considered in the analysis of whether 96 bits are enough. For example, wit= h 96 bits, might this mean that other vulnerabilities (lack of entropy in k= ey generation, potential for users to mishandle keys) trump the brute force= resistance? Plus, it may be that we do not need to be bullet proof at th= is layer. For an application that wants extra security, another independen= t security layer could be layered on top of HIP, rather than rely on HIP fo= r channel bindings. In such a case, attacks on HIP may just be of the DoS = (packet redirection) variety, which again might be defused by robust system= design and considering HIP to be a possible, albeit unlikely, point of fai= lure. By the way, can someone who was involved in the ORCHID deliberations chime = in about the process for renewing the /28, and what are the issues to make = this a permanent allocation? Tom From julienl@qualcomm.com Tue Feb 2 10:42:14 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8BE3A697B for ; Tue, 2 Feb 2010 10:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.67 X-Spam-Level: X-Spam-Status: No, score=-106.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBGWp1DqN3fd for ; Tue, 2 Feb 2010 10:42:13 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 698633A6947 for ; Tue, 2 Feb 2010 10:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1265136172; x=1296672172; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Henderson,=20Thomas=20R"=20,=0D=0A=20=20=20=20=20=20=20=20"'Tobias=20Heer'" =0D=0A=09|CC:=20hip=20WG=20|Date:=20Tue,=202=20Feb=202010=2010:42:45=20-0 800|Subject:=20[Hipsec]=20ORCHID=20IANA=20allocation=20(w as:=2028=20+=204=20+=2096=20bit=20HIT=20=20crypto=0D=0A =20agility)|Thread-Topic:=20[Hipsec]=20ORCHID=20IANA=20al location=20(was:=2028=20+=204=20+=2096=20bit=20HIT=0D=0A =20=20crypto=20agility)|Thread-Index:=20AcqkDt+ByAo5sZotS myJwGVqHUbLqgAE6iXwAAUD8IA=3D|Message-ID:=20|References:=20<00E85481-5745-4093-B165-887058ED719B@cs .rwth-aachen.de>=0D=0A=20<7CC566635CFE364D87DC5803D4712A6 C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com>|In-Reply-To:=20 <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw .nos.boeing.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=APwq6yLuV/+XuVddhTUw2jJRZ064G5hjlj/S8fjAOh8=; b=LALlCJpSL2vL/aqX6SC8JVmbOadaTFyEpHmNhFjOntC7S/EJ0u8mKyoR 3uHxkusUOjstD/lqeWbxnhCa1T7/h2KnDdZ8Rwdxb2QcZFBop5NfZWnJf XVyX7/yt7KGKE4riEW4wgGn+QCB5CB0pJmuwX1Pw/NcSjRcgprsH5aQlw Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5880"; a="33319983" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 02 Feb 2010 10:42:51 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o12IgqxT020470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Feb 2010 10:42:52 -0800 X-IronPort-AV: E=Sophos;i="4.49,392,1262592000"; d="scan'208";a="37765456" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 02 Feb 2010 10:42:51 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 2 Feb 2010 10:42:51 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 2 Feb 2010 10:42:51 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 2 Feb 2010 10:42:48 -0800 From: "Laganier, Julien" To: "Henderson, Thomas R" , "'Tobias Heer'" Date: Tue, 2 Feb 2010 10:42:45 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation (was: 28 + 4 + 96 bit HIT crypto agility) Thread-Index: AcqkDt+ByAo5sZotSmyJwGVqHUbLqgAE6iXwAAUD8IA= Message-ID: References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hip WG Subject: [Hipsec] ORCHID IANA allocation (was: 28 + 4 + 96 bit HIT crypto 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: Tue, 02 Feb 2010 18:42:14 -0000 Hello Tom, Henderson, Thomas R wrote: > [...] >=20 > By the way, can someone who was involved in the ORCHID deliberations > chime in about the process for renewing the /28, and what are the > issues to make this a permanent allocation? The current assignment for ORCHID terminates on 21 Mar 2014. The registrati= on procedure for the IANA IPv6 Special Purpose Address Registry is IETF Con= sensus, see: http://www.iana.org/assignments/iana-ipv6-special-registry/ Since we're now discussing a HIT/ORCHID design that differs from the one or= iginally documented in RFC 4843, updating RFC 4843 could 1) update the ORCH= ID design with hash agility, and 2) establish IETF consensus for a never en= ding ORCHID assignment in the relevant IANA registry. --julien From rgm@htt-consult.com Tue Feb 2 11:30:00 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395EA3A68C3 for ; Tue, 2 Feb 2010 11:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpxQgHJfEPUF for ; Tue, 2 Feb 2010 11:29:59 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 1475F3A68B9 for ; Tue, 2 Feb 2010 11:29:59 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id CAF4A68B4D; Tue, 2 Feb 2010 20:27:22 +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 4ENhDRd8OgWZ; Tue, 2 Feb 2010 15:27:13 -0500 (EST) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1755768B25; Tue, 2 Feb 2010 15:27:13 -0500 (EST) Message-ID: <4B687D4E.6000501@htt-consult.com> Date: Tue, 02 Feb 2010 14:30:22 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Tue, 02 Feb 2010 19:30:00 -0000 On 02/02/2010 11:35 AM, Henderson, Thomas R wrote: > Hi Tobias, thanks for continuing this thread. > >> These numbers are for benign collisions. For an attacker, it >> is important to compute a HIT (including public key) that >> matches another HIT. From the numbers above it seems to me >> that creating a collision for a determined HIT is out of >> scope. >> > I think you mean "not practical" rather than "out of scope", right? And by not practical, this means that the cost of mounting a second preimage attack by brute force (which includes the cost to create the key and hash it to test that it matches the target HIT) is likely to be 2^96 work for 96 bits if we continue to deprecate cracked hash functions over time, and that 2^96 (10^28) work is not likely to be feasible even for an attacker with large computing resources? > > >> Creating any HIT collision (e.g. by creating a large >> number of HITs) will probably not be dangerous either, >> because the chance that the HIT for which you find the >> collision is in use is rather small (the address space will >> be very sparsely populated). What remains is to find a >> collision for a set of HITs (the HITs that are in use). I >> found some work on how to compute the probability for sets of >> random variables but I was unable to come up with useful >> results because of the very large (and very small) numbers >> involved. Even Scheme with its good math support was unable >> to handle the numbers. Maybe someone with matlab skills can help. >> >> > Doesn't this question devolve into "if you are using N HITs, your attack surface to brute force attack goes up by a factor of N"? > > > >> What I would like to know from the group: Do you think that a >> 28 + 4 + 96 bit HIT is a good choice? Do you think the >> cryptographic strength is sufficient? Do you have other >> preferences/alternatives? >> > Outside of the crypto issues, I think that encoding the HIH explicitly with some number of bits (your proposal seems adequate to me) is going to be preferable for ease of use considerations. > > I think there are broader system and use case issues that would need to be considered in the analysis of whether 96 bits are enough. For example, with 96 bits, might this mean that other vulnerabilities (lack of entropy in key generation, potential for users to mishandle keys) trump the brute force resistance? How is the size of the truncation of the hash of the HI of any import to the strength of the key obtained? They seem to be orthogonal to me. > Plus, it may be that we do not need to be bullet proof at this layer. For an application that wants extra security, another independent security layer could be layered on top of HIP, rather than rely on HIP for channel bindings. In such a case, attacks on HIP may just be of the DoS (packet redirection) variety, which again might be defused by robust system design and considering HIP to be a possible, albeit unlikely, point of failure. > > By the way, can someone who was involved in the ORCHID deliberations chime in about the process for renewing the /28, and what are the issues to make this a permanent allocation? > > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > From thomas.r.henderson@boeing.com Tue Feb 2 12:14:31 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445703A68C7 for ; Tue, 2 Feb 2010 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 TjeH6GmxY4fe for ; Tue, 2 Feb 2010 12:14:27 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A182B3A6995 for ; Tue, 2 Feb 2010 12:14:25 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o12KEkWd018431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2010 14:14:53 -0600 (CST) 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 o12KEkEL028414; Tue, 2 Feb 2010 14:14:46 -0600 (CST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o12KE0ou026963 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 2 Feb 2010 14:14:46 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 2 Feb 2010 12:14:22 -0800 From: "Henderson, Thomas R" To: "'Robert Moskowitz'" Date: Tue, 2 Feb 2010 12:14:22 -0800 Thread-Topic: [Hipsec] 28 + 4 + 96 bit HIT crypto agility Thread-Index: AcqkPkhgCXKLVdaEQJ6acZq5uwQhwAAA65Ug Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6DB@XCH-NW-10V.nw.nos.boeing.com> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> <4B687D4E.6000501@htt-consult.com> In-Reply-To: <4B687D4E.6000501@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hip WG Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Tue, 02 Feb 2010 20:14:31 -0000 > > I think there are broader system and use case issues that > would need to be considered in the analysis of whether 96 > bits are enough. For example, with 96 bits, might this mean > that other vulnerabilities (lack of entropy in key > generation, potential for users to mishandle keys) trump the > brute force resistance? > > How is the size of the truncation of the hash of the HI of > any import to > the strength of the key obtained? They seem to be orthogonal to me. > I don't think it is related. My point was that we ought to have the big pi= cture security threat analysis in mind when we make a decision about how mu= ch security is enough for one aspect of the overall design. I recall that you said once that the point of HIP security was to prevent t= he network layer mechanisms (packet forwarding and redirection) from being = attacked (apologies if I misquote you or remember this imperfectly). Is ma= king the attacker do 96 bits worth of work just so he/she can disrupt netwo= rk layer mechanisms enough in this case? If however, the user stakes all e= nd-to-end security on HIP (i.e. channel bindings), then maybe the stakes ar= e higher. Tom From oleg.ponomarev@hiit.fi Tue Feb 2 13:05:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5ED3A6B44 for ; Tue, 2 Feb 2010 13:05:03 -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_32=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 kNT6mZvladiZ for ; Tue, 2 Feb 2010 13:05:02 -0800 (PST) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id B52F93A69A5 for ; Tue, 2 Feb 2010 13:05:01 -0800 (PST) Received: from stargazer.pc.infrahip.net (stargazer.pc.infrahip.net [IPv6:2001:708:140:220:21e:4fff:fe92:4522]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id o12L4WdN030643; Tue, 2 Feb 2010 23:04:32 +0200 Date: Tue, 2 Feb 2010 23:04:30 +0200 (EET) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer.pc.infrahip.net To: Robert Moskowitz In-Reply-To: <4B68414D.9040402@htt-consult.com> Message-ID: References: <4B68414D.9040402@htt-consult.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; charset=US-ASCII; format=flowed Cc: hipsec@ietf.org Subject: Re: [Hipsec] HIP usage in a large SmartGrid/SCADA environment 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, 02 Feb 2010 21:05:03 -0000 Hi! On Tue, 2 Feb 2010, Robert Moskowitz wrote: There are the following bottlenecks: 1) number of ESP SAs in RAM 2) number of packets per second 3) bandwidth Let us take a look at them: 1) We have to store in RAM 2 * 128 bit - remote HIT, remote IP addr 2 * 128 bit + 2 * 32 bit - incoming enc and auth key, SPI, sec # 2 * 128 bit + 2 * 32 bit - outgoing -//- total about 112 bytes per meter, if we round to it 128 bytes (sorted tree structure etc), we need 10*10^6*128/2^30 ~= 1.2 GB of RAM It should fit multiple times to a modern server 2) one core of Intel Xeon E5440 CPU using OpenSSL-1.0.0-beta2 can perform 91,142 encryptions per second of 1024-byte blocks with 128-bit AES key 157,053 sha256 per second of 1024-byte blocks Assuming decryption and verification takes about the same time, it should send (or receive) up to 57,672 1024-byte packets per second So it should take 2*10*10^6/57672 ~= 347 seconds to "ping" every meter 3) This data exchange should generate about 57672*1500*8/2^20 =~ 660 Mbps in/out traffic and ~120 kPPS through the router. So the task should be viable using modern server with multicore CPU(s) and good network connection. Of course the initial BEX'es with all meters would take 10*10^6/145/4/3600 ~= 5 hours using quad-core Xeon with RSA1024/DH1536 (10*10^6/639/4/3600 ~= 1 hour with ECDSA160/ECDH192). This estimations are quite optimistic, the reality might be much worse. I guess, the scalability should be about the same with other solutions, but it may be more/less convenient to setup such meters from various vendors using other tools. > 10 Million or so meters all controlled from a single server. Now I don't > believe it would be a single server, I suspect that the meters will be > regionally grouped by location on the grid. But still and all, lets work > with the PES people on this one. It still could be 100K meters per > server.... > > Meters do a HIP BEX at setup, and may never do another, as the key entropy > will well handle the low volume of data. So the MK is stored in protected > memory in the meter and a secure store on the server (that would survive > server reboot, imagine forcing 10M meters to rekey becuase the server > rebooted). > > Can HIP, will actually ESP SAs, scale to this large in a reasonable > implementation? For now don't add in mobility (RVS server) and meter server > redundancy (HIP/ESP SA fate sharing through some backend protocol?). > Hopefully the meter app will be implemented over UDP, so a single packet > comes in on an ESP SPI and that has to be looked up, processed and tossed up > to the app. Then perhaps there will be a response back to the meter. The > round trip needs to be in 100ms. How many SAs can we expect a single server > to be able to support? > > Then there is the downstream alerts. Say a rate change notice taking affect > in 5 min to 50K customers. That data packet with the rate information will > have to be sent to each meter (this customer's meter is currently at IP > address (HIT) n) with ACKs coming back that the rate information was > accepted. Round trip for this is in seconds. > > Anyone want to tackle a scaling modeling challenge? Would HIP scale better > than other security tools or about the same? -- Regards, Oleg. From miika.komu@hiit.fi Wed Feb 3 02:38:39 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650FF3A6BF6 for ; Wed, 3 Feb 2010 02:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbuNqeLgoM4y for ; Wed, 3 Feb 2010 02:38:38 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 4AB043A6BF3 for ; Wed, 3 Feb 2010 02:38:37 -0800 (PST) Received: from [130.233.194.249] (vbwin.cs.hut.fi [130.233.194.249]) by argo.otaverkko.fi (Postfix) with ESMTP id 43A4225ED10 for ; Wed, 3 Feb 2010 12:39:18 +0200 (EET) Message-ID: <4B695255.7010500@hiit.fi> Date: Wed, 03 Feb 2010 12:39:17 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8pre) Gecko/20100131 Shredder/3.0.2pre MIME-Version: 1.0 To: hipsec@ietf.org References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Wed, 03 Feb 2010 10:38:39 -0000 On 02/02/2010 06:35 PM, Henderson, Thomas R wrote: Hi, >> What I would like to know from the group: Do you think that a 28 + >> 4 + 96 bit HIT is a good choice? Do you think the cryptographic >> strength is sufficient? Do you have other >> preferences/alternatives? I believe the 28 + 4 + 96 scheme is a good idea, assuming that we really won't get a larger prefix from IANA. However, I have a question on the four bits that perhaps needs to be asked aloud even though the answer is probably "no". Currently, the four bits for the algo are just "hints", i.e., they are not securely bound to the HIT calculation. Should they be included in the HIT calculation? > Outside of the crypto issues, I think that encoding the HIH > explicitly with some number of bits (your proposal seems adequate to > me) is going to be preferable for ease of use considerations. > > I think there are broader system and use case issues that would need > to be considered in the analysis of whether 96 bits are enough. For > example, with 96 bits, might this mean that other vulnerabilities > (lack of entropy in key generation, potential for users to mishandle > keys) trump the brute force resistance? Plus, it may be that we do > not need to be bullet proof at this layer. For an application that > wants extra security, another independent security layer could be > layered on top of HIP, rather than rely on HIP for channel bindings. > In such a case, attacks on HIP may just be of the DoS (packet > redirection) variety, which again might be defused by robust system > design and considering HIP to be a possible, albeit unlikely, point > of failure. I think it would be useful to add some text on this e.g. in RFC5201-bis. From laser.ru@gmail.com Wed Feb 3 03:18:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCDB3A6BE7 for ; Wed, 3 Feb 2010 03:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk0rNJWxnIdi for ; Wed, 3 Feb 2010 03:18:39 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 4E7E03A6C05 for ; Wed, 3 Feb 2010 03:18:39 -0800 (PST) Received: by ewy28 with SMTP id 28so1236508ewy.28 for ; Wed, 03 Feb 2010 03:19:17 -0800 (PST) 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:cc:content-type; bh=cRP+cDQz10iLvUbYdAe6cxWPrZVE6hR9D9ZdGcfwMZ0=; b=qGbf4ZMpeNAhyMDYtXFBgbUXH1ldk07xVHqPJK/egdU+ODlttj7OCX7kojU09GJJh3 2Ctwid6bt1YXhEfg9FBBpbgOflLrsWuiHJfXvnj4A18U65AQuyq7xKYGsoAoKOSqiXDC J8wKmejLNpY6Sf2EDel5/aB2+keBzMT3UeYMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=pjMYW70qOZC9KzrQvl8hIEbA6v5afkWTkfVqz4buB4Se/UKQW/U42McV2Fx5Bnjfxv 2HLPLmFXUD12S1I6KywWMSiaqhsKzMqQnGLeqC3sJ/+sZDynaGlntf06QGVgYpIdOYBF QBbEfg5DJr6C1AaBc3IV5CcuX85ayTDJDJ43M= MIME-Version: 1.0 Received: by 10.213.96.198 with SMTP id i6mr2036910ebn.10.1265195957137; Wed, 03 Feb 2010 03:19:17 -0800 (PST) Date: Wed, 3 Feb 2010 13:19:17 +0200 Message-ID: From: Andrey Lukyanenko To: Tobias Heer Content-Type: text/plain; charset=UTF-8 Cc: hipsec@ietf.org Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Wed, 03 Feb 2010 11:18:41 -0000 Hello Tobias, > What remains is to find a collision for a set of HITs (the HITs that are in use). I found > some work on how to compute the probability for sets of random variables but I was > unable to come up with useful results because of the very large (and very small) > numbers involved. Even Scheme with its good math support was unable to handle > the numbers. Maybe someone with matlab skills can help. I am not sure whether I understood the model correctly, but to me it seems like a problem of random allocations. We with Andrei Gurtov have a small paper about its application http://www.cs.helsinki.fi/u/gurtov/papers/scgame.pdf. Take a look on the model (does it correspond to yours?). The exact probability is hard to find as it is computed using binomial coefficients with large numbers involved, but the expectation can be found quite easily. -- Best regards, Andrey Lukyanenko. From heer@informatik.rwth-aachen.de Wed Feb 3 04:55:25 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B77C3A6813 for ; Wed, 3 Feb 2010 04:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m41Ihhq+9M7K for ; Wed, 3 Feb 2010 04:55:24 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 180413A67EA for ; Wed, 3 Feb 2010 04:55:23 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KX900CJRNXGRUA0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 03 Feb 2010 13:56:04 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,397,1262559600"; d="scan'208";a="43524997" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 03 Feb 2010 13:56:04 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KX900LIQNXG4P50@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 03 Feb 2010 13:56:04 +0100 (CET) From: Tobias Heer Date: Wed, 03 Feb 2010 13:56:03 +0100 References: <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> To: "hipsec@ietf.org WG" Message-id: X-Mailer: Apple Mail (2.1077) Subject: [Hipsec] Fwd: 28 + 4 + 96 bit HIT crypto 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: Wed, 03 Feb 2010 12:55:25 -0000 Hello Tom. > > Hi Tobias, thanks for continuing this thread. >> >> These numbers are for benign collisions. For an attacker, it >> is important to compute a HIT (including public key) that >> matches another HIT. From the numbers above it seems to me >> that creating a collision for a determined HIT is out of >> scope. > > I think you mean "not practical" rather than "out of scope", right? And by not practical, this means that the cost of mounting a second preimage attack by brute force (which includes the cost to create the key and hash it to test that it matches the target HIT) is likely to be 2^96 work for 96 bits if we continue to deprecate cracked hash functions over time, and that 2^96 (10^28) work is not likely to be feasible even for an attacker with large computing resources? Right. Yes, that's the assumption. Moreover, finding a second preimage only is not enough. The second preimage needs to be a public key that the attacker has to generate. Right now, generating an asymmetric key pair causes considerable overhead (at least for RSA and DSA). However, I can imagine that we might encounter public-key schemes for which key generation is relatively cheap, so I would not like to base the security of the scheme on the assumption that key generation is expensive. > >> Creating any HIT collision (e.g. by creating a large >> number of HITs) will probably not be dangerous either, >> because the chance that the HIT for which you find the >> collision is in use is rather small (the address space will >> be very sparsely populated). What remains is to find a >> collision for a set of HITs (the HITs that are in use). I >> found some work on how to compute the probability for sets of >> random variables but I was unable to come up with useful >> results because of the very large (and very small) numbers >> involved. Even Scheme with its good math support was unable >> to handle the numbers. Maybe someone with matlab skills can help. >> > > Doesn't this question devolve into "if you are using N HITs, your attack surface to brute force attack goes up by a factor of N"? >From what I have read [3], its not that easy. It's a tough combinatorial problem... but I may have misunderstood it. The problem is to compute the collision probability of two sets of random values. Both sets are of different size. The first set is the set of HITs in use, the second set is the set of HIs and HITs that an attacker generates in order to find a collision. > >> What I would like to know from the group: Do you think that a >> 28 + 4 + 96 bit HIT is a good choice? Do you think the >> cryptographic strength is sufficient? Do you have other >> preferences/alternatives? > > Outside of the crypto issues, I think that encoding the HIH explicitly with some number of bits (your proposal seems adequate to me) is going to be preferable for ease of use considerations. > > I think there are broader system and use case issues that would need to be considered in the analysis of whether 96 bits are enough. For example, with 96 bits, might this mean that other vulnerabilities (lack of entropy in key generation, potential for users to mishandle keys) trump the brute force resistance? You are right here. I guess an important question is also if the HIT is easier to crack than the HI itself. An example: when using a 1024 bit RSA HI, its strength is routhly equivalent to a 80-bit symmetric cipher [1]. This might be easier to crack than the 96 bit in the HIT. I am not sure if the bit lengths can be compared directly but *iff* this is the case, 96 bits would be somewhere between RSA with 1553 and 1926 bit keys[2]. 100 bits is equivalent to RSA 1926. Iff this assumption holds, 96 bit HITs would only be a weak spot for RSA keys above that length. > Plus, it may be that we do not need to be bullet proof at this layer. For an application that wants extra security, another independent security layer could be layered on top of HIP, rather than rely on HIP for channel bindings. In such a case, attacks on HIP may just be of the DoS (packet redirection) variety, which again might be defused by robust system design and considering HIP to be a possible, albeit unlikely, point of failure. Another option would be to put more emphasis on the HI itself. Even if the application only sees the HI, the HIP stack will see the HI itself. By managing lists of known identities (just like SSH does), the HIP layer could figure out that a collision occurred (and issue a warning or deny the communication). However, this will only help if the peer has had the chance to see both hits. If we neglect accidental (benign) collisions, one could also considering methods to make HIT or HI generation more costly in terms of computations. Such artificial hardening (similar to what CGA does) could be adjusted over time to compensate advances in cryptography and Moore's law. I guess we can come up with a sensible method if this is the desired direction for HIP. Tobias References: [1] http://www.rsa.com/rsalabs/node.asp?id=2088 [2] RFC 3766 [3] Michael C. Wendl, Collision probability between sets of random variables, Statistics & Probability Letters, Volume 64, Issue 3, 15 September 2003, Pages 249-254 -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Wed Feb 3 06:28:51 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78FCE28C162 for ; Wed, 3 Feb 2010 06:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.301 X-Spam-Level: X-Spam-Status: No, score=-5.301 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYPEuxqpIff9 for ; Wed, 3 Feb 2010 06:28:50 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 2F6833A6A0E for ; Wed, 3 Feb 2010 06:28:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KX900KEES96MF10@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 03 Feb 2010 15:29:30 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,398,1262559600"; d="scan'208";a="23458357" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 03 Feb 2010 15:29:31 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KX900L7MS964P70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 03 Feb 2010 15:29:30 +0100 (CET) From: Tobias Heer In-reply-to: <4B695255.7010500@hiit.fi> Date: Wed, 03 Feb 2010 15:29:30 +0100 Message-id: References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> <4B695255.7010500@hiit.fi> To: Miika Komu X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] 28 + 4 + 96 bit HIT crypto 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: Wed, 03 Feb 2010 14:28:51 -0000 Hello Miika, Am 03.02.2010 um 11:39 schrieb Miika Komu: > On 02/02/2010 06:35 PM, Henderson, Thomas R wrote: > > Hi, > >>> What I would like to know from the group: Do you think that a 28 + >>> 4 + 96 bit HIT is a good choice? Do you think the cryptographic >>> strength is sufficient? Do you have other >>> preferences/alternatives? > > I believe the 28 + 4 + 96 scheme is a good idea, assuming that we really > won't get a larger prefix from IANA. However, I have a question on the four bits that perhaps needs to be asked aloud even though the answer is > probably "no". Currently, the four bits for the algo are just "hints", > i.e., they are not securely bound to the HIT calculation. Should they be > included in the HIT calculation? Since the HIH bits are a pointer to a specific hash function and that specific hash function was used to generate the HI hash bits the binding is already there. Changing the HIH bits would cause the HIT verification to fail. Hence, IMHO, tampering with these bits is rather ineffective. However, thanks for asking the question anyway. Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From heer@informatik.rwth-aachen.de Thu Feb 4 06:46:27 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B4A28C181 for ; Thu, 4 Feb 2010 06:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT-Hdm7gn5T9 for ; Thu, 4 Feb 2010 06:46:26 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 8065928C189 for ; Thu, 4 Feb 2010 06:46:26 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KXB009HNNQNEW80@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 04 Feb 2010 15:47:11 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,404,1262559600"; d="scan'208";a="43718914" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 04 Feb 2010 15:47:12 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KXB00611NQN8R80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 04 Feb 2010 15:47:11 +0100 (CET) From: Tobias Heer In-reply-to: Date: Thu, 04 Feb 2010 15:47:11 +0100 Message-id: <02529DFE-B2AF-4DC2-9DE8-83951BE0D0B2@cs.rwth-aachen.de> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> To: Pekka Nikander X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: [Hipsec] ORCHID RFC 4843 (was: 28 + 4 + 96 bit HIT crypto 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: Thu, 04 Feb 2010 14:46:27 -0000 Hello Pekka, On 02.02.2010, at 15:02, Pekka Nikander wrote: > Tobias and Bob, > > I think you should talk to Sam Hartman about how Orchids were designed. Initially Orchids had the same feature: a few bits reserved to denote the crypto algorithm. But then Sam (IIRC) came with the present Orchid way, where those bits are not needed. I don't remember the details and rationale any more, and since I'm not working with HIP anymore, I wouldn't have the time to check. Thanks for the reply. RFC 4843 is quite clear why these bits are not needed. ORCHIDs don't offer support for multiple hash functions within one context ID. Different hash functions require different context IDs. In addition, the context ID is not encoded in the ORCHID directly because of the underlying assumption that the application will know its context ID. This works fine as long as every application uses only few different context IDs (as long as trying out which context id matches is sufficient). However, this assumes that the context ID and the preimage of the hash are known. This is not the case for the current attempts to add crypto agility for HIT. Hence, adding crypto agility to ORCHIDs in the way we are currently discussing it would probably lead to a redesign of the ORCHID. RFC 4942 is also quite clear that future versions of the ORCHID work should think about hash extension mechanisms (like in CGA). This might be a way out of the 96 vs 100 bit trap. Tobias [removed trailing text] -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From rgm@htt-consult.com Fri Feb 5 06:21:17 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DFA28C159 for ; Fri, 5 Feb 2010 06:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Rrcq5VPVja for ; Fri, 5 Feb 2010 06:21:14 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A829C28C115 for ; Fri, 5 Feb 2010 06:21:13 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 85F8768B44 for ; Fri, 5 Feb 2010 15:18:43 +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 WOW4aRgg5RK3 for ; Fri, 5 Feb 2010 10:18:34 -0500 (EST) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8936568B27 for ; Fri, 5 Feb 2010 10:18:34 -0500 (EST) Message-ID: <4B6C297F.6030600@htt-consult.com> Date: Fri, 05 Feb 2010 09:21:51 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] IETF outrcomes WIKI 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, 05 Feb 2010 14:21:17 -0000 We should add content there for HIP. Any takers to prepare it? From rgm@htt-consult.com Fri Feb 5 06:22:10 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD5028C183 for ; Fri, 5 Feb 2010 06:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQTlKqPLyA9F for ; Fri, 5 Feb 2010 06:22:10 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 2AC3428C17C for ; Fri, 5 Feb 2010 06:22:10 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 300A668BC7 for ; Fri, 5 Feb 2010 15:19:43 +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 FlMCpxS9KXcO for ; Fri, 5 Feb 2010 10:19:34 -0500 (EST) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8247568B23 for ; Fri, 5 Feb 2010 10:19:34 -0500 (EST) Message-ID: <4B6C29BB.3030107@htt-consult.com> Date: Fri, 05 Feb 2010 09:22:51 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Charter update 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, 05 Feb 2010 14:22:11 -0000 Can we get a new charter in for this session? I see other charter change reviews coming up on the IETF list. Now seems to be the time to move officially on this and not wait until the meeting slot again? From gonzalo.camarillo@ericsson.com Tue Feb 9 03:16:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC923A7339 for ; Tue, 9 Feb 2010 03:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+3oJprlbXaV for ; Tue, 9 Feb 2010 03:15:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9EFEE3A702D for ; Tue, 9 Feb 2010 03:15:57 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-88-4b71442e6324 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DA.74.31641.E24417B4; Tue, 9 Feb 2010 12:17:02 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 12:17:01 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 12:17:01 +0100 Message-ID: <4B71442D.3000204@ericsson.com> Date: Tue, 09 Feb 2010 13:17:01 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Moskowitz References: <4B6C29BB.3030107@htt-consult.com> In-Reply-To: <4B6C29BB.3030107@htt-consult.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2010 11:17:01.0549 (UTC) FILETIME=[66DEB9D0:01CAA979] X-Brightmail-Tracker: AAAAAA== Cc: hip WG Subject: Re: [Hipsec] Charter update 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, 09 Feb 2010 11:16:03 -0000 Hi Bob, I already shared Ralph's questions on the rechartering process a while ago. As soon as we feel we are ready to provide him with answers, we can get back to him and resume the discussions. Do you think we are at that point yet? Work wise, as soon as we request the publication of the overlay-related specs (whose WGLC ends on February 23rd), we will only have the certificate draft left in our current charter. Thanks, Gonzalo Robert Moskowitz wrote: > Can we get a new charter in for this session? I see other charter > change reviews coming up on the IETF list. Now seems to be the time to > move officially on this and not wait until the meeting slot again? > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From thomas.r.henderson@boeing.com Tue Feb 9 09:07:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5CB3A7428 for ; Tue, 9 Feb 2010 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 LBK55BnqxWQN for ; Tue, 9 Feb 2010 09:07:40 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7F63C3A744A for ; Tue, 9 Feb 2010 09:07:40 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o19H8bDa022214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 09:08:40 -0800 (PST) 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 o19H8b8Z025824; Tue, 9 Feb 2010 09:08:37 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o19H8VOx025669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 9 Feb 2010 09:08:37 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 9 Feb 2010 09:08:31 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" , HIP Date: Tue, 9 Feb 2010 09:08:31 -0800 Thread-Topic: draft-keranen-hip-over-hip-00 Thread-Index: AcqelWS/wqHzZmpkS4O/VN4f5FmG7wLD86og Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> References: <4B5EFEA2.6020205@nomadiclab.com> In-Reply-To: <4B5EFEA2.6020205@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Hipsec] draft-keranen-hip-over-hip-00 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, 09 Feb 2010 17:07:41 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > Sent: Tuesday, January 26, 2010 6:40 AM > To: HIP > Subject: [Hipsec] [Fwd: New Version Notification > fordraft-keranen-hip-over-hip-00] > > Hi all, > > In addition to updating the HIP BONE drafts, we wrote a new draft [1] > about conveying HIP messages over the ESP tunnels. This is something > that is especially useful in overlay scenarios, and has actually been > already discussed in multiple places before, but never really > specified. > Comments are welcome. > > > Cheers, > Ari > > [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt Hi Ari, I had a few questions on the above draft. 1) I wonder about a dependency in requiring HIP to use ESP (the "MUST" in s= ection 3.2) if HIP is also responsible for setting up or repairing ESP itse= lf. Should there be a possibility of falling back to HIP outside of the ES= P envelope in failure cases? Another failure case is that the initiator or= responder fails to set up the TCP sockets as described. 2) previously in RFC5201, we adopted the convention that the roles of Initi= ator and Responder are abandoned once the base exchange completes, so this = would require implementations to keep that state around (might require some= comment here or in 5201bis). 3) (Linux question) regarding HIP over ESP, will XFRM process the packet en= tering/leaving on a raw socket (both for IPv4 and IPv6)? Am wondering how = easy it will be to implement this option on current systems, using kernel E= SP implementations. Should HIP over UDP over ESP (possibly over UDP again)= be an option, for ease of programming? 4) Have you thought about SCTP instead of TCP for this use case? - Tom From zhangdacheng@huawei.com Tue Feb 9 23:38:10 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798F33A7675 for ; Tue, 9 Feb 2010 23:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.361 X-Spam-Level: **** X-Spam-Status: No, score=4.361 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 xgPzAxJ7kKuz for ; Tue, 9 Feb 2010 23:38:09 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CBF943A761D for ; Tue, 9 Feb 2010 23:38:08 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXM005IR7WAVN@szxga04-in.huawei.com> for hipsec@ietf.org; Wed, 10 Feb 2010 15:38:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXM00MKR7W9WQ@szxga04-in.huawei.com> for hipsec@ietf.org; Wed, 10 Feb 2010 15:38:33 +0800 (CST) Received: from z00133208 ([10.111.13.7]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXM005U37W9A0@szxml06-in.huawei.com> for hipsec@ietf.org; Wed, 10 Feb 2010 15:38:33 +0800 (CST) Date: Wed, 10 Feb 2010 15:38:33 +0800 From: Dacheng Zhang To: hipsec@ietf.org Message-id: <017501caaa24$0c4280f0$070d6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YeDkFUdg09VVDmJDZFXHzA)" Thread-index: AcqqJAvxepnREE7mTgCoScjfMyOnQg== Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 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, 10 Feb 2010 07:38:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YeDkFUdg09VVDmJDZFXHzA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Ari: I have a superficial question here. A HIP host needs to use Update a packet to inform its partner that its IP address has been changed. However, if the update packet is transported using ESP, will it be difficult for the partner to find out the proper IPsec AS to decrpt the packet and get the update information? ^_^ > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen > Sent: Tuesday, January 26, 2010 6:40 AM > To: HIP > Subject: [Hipsec] [Fwd: New Version Notification > fordraft-keranen-hip-over-hip-00] > > Hi all, > > In addition to updating the HIP BONE drafts, we wrote a new draft [1] > about conveying HIP messages over the ESP tunnels. This is something > that is especially useful in overlay scenarios, and has actually been > already discussed in multiple places before, but never really > specified. > Comments are welcome. > > > Cheers, > Ari > > [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt Hi Ari, I had a few questions on the above draft. 1) I wonder about a dependency in requiring HIP to use ESP (the "MUST" in section 3.2) if HIP is also responsible for setting up or repairing ESP itself. Should there be a possibility of falling back to HIP outside of the ESP envelope in failure cases? Another failure case is that the initiator or responder fails to set up the TCP sockets as described. 2) previously in RFC5201, we adopted the convention that the roles of Initiator and Responder are abandoned once the base exchange completes, so this would require implementations to keep that state around (might require some comment here or in 5201bis). 3) (Linux question) regarding HIP over ESP, will XFRM process the packet entering/leaving on a raw socket (both for IPv4 and IPv6)? Am wondering how easy it will be to implement this option on current systems, using kernel ESP implementations. Should HIP over UDP over ESP (possibly over UDP again) be an option, for ease of programming? 4) Have you thought about SCTP instead of TCP for this use case? - Tom _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec --Boundary_(ID_YeDkFUdg09VVDmJDZFXHzA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, = Ari:

 <= /span>

I have a superficial question here. A HIP host needs to use Update a packet to = inform its partner that its IP address has been changed. However, if the update = packet is transported using ESP, will it be difficult for the partner to find = out the proper IPsec = AS to decrpt the packet and get the = update information?

 <= /span>

 ^_^

 

 

> -----Original Message-----

> From: hipsec-bounces@ietf.org

> [mailto:hipsec-bounces@ietf.org] On Behalf Of Ari Keranen

> Sent: Tuesday, January 26, 2010 6:40 AM

> To: HIP

> Subject: [Hipsec] [Fwd: New Version Notification =

> fordraft-keranen-hip-over-hip-00]

> <= /font>

> Hi all,

> <= /font>

> In addition to updating the HIP BONE drafts, we wrote a new draft [1] =

> about conveying HIP messages over the ESP tunnels. This is something =

> that is especially useful in overlay scenarios, and has actually been =

> already discussed in multiple places before, but never really =

> specified.

> Comments are welcome.

> <= /font>

> <= /font>

> Cheers,

> Ari

> <= /font>

> [1] http://= www.ietf.org/id/draft-keranen-hip-over-hip-00.txt

 

Hi Ari,

 

I had a few questions on the above draft.

 

1) I wonder about a dependency in requiring HIP to use ESP (the = "MUST" in section 3.2) if HIP is also responsible for setting up or repairing = ESP itself.  Should there be a possibility of falling back to HIP = outside of the ESP envelope in failure cases?  Another failure case is that = the initiator or responder fails to set up the TCP sockets as = described.

 

2) previously in RFC5201, we adopted the convention that the roles of = Initiator and Responder are abandoned once the base exchange completes, so this = would require implementations to keep that state around (might require some = comment here or in 5201bis).

 

3) (Linux question) regarding HIP over ESP, will XFRM process the packet entering/leaving on a raw socket (both for IPv4 and IPv6)?  Am = wondering how easy it will be to implement this option on current systems, using = kernel ESP implementations.  Should HIP over UDP over ESP (possibly over = UDP again) be an option, for ease of = programming?

 

4) Have you thought about SCTP instead of TCP for this use = case?

 

- Tom

_____________________________= __________________

Hipsec mailing list

Hipsec@ietf.org

https://www.ietf.or= g/mailman/listinfo/hipsec

 

--Boundary_(ID_YeDkFUdg09VVDmJDZFXHzA)-- From ari.keranen@nomadiclab.com Wed Feb 10 04:09:47 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8513A704B for ; Wed, 10 Feb 2010 04:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LP7zI5zMSca for ; Wed, 10 Feb 2010 04:09:46 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id DB0913A7353 for ; Wed, 10 Feb 2010 04:09:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B36384E6D8; Wed, 10 Feb 2010 14:10:50 +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 wbQc0eizd8WI; Wed, 10 Feb 2010 14:10:49 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 015854E6CC; Wed, 10 Feb 2010 14:10:48 +0200 (EET) Message-ID: <4B72A248.9090901@nomadiclab.com> Date: Wed, 10 Feb 2010 14:10:48 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 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, 10 Feb 2010 12:09:47 -0000 Hi Tom, Thanks for the comments! Responses inline. Henderson, Thomas R wrote: >> -----Original Message----- [...] >> [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt > > Hi Ari, > > I had a few questions on the above draft. > > 1) I wonder about a dependency in requiring HIP to use ESP (the > "MUST" in section 3.2) if HIP is also responsible for setting up or > repairing ESP itself. Should there be a possibility of falling back > to HIP outside of the ESP envelope in failure cases? Another failure > case is that the initiator or responder fails to set up the TCP > sockets as described. Good point. Failure and mobility scenarios are not yet specified in this initial version, but I'll add text about them to the next revision. AFAIK, unless one of the hosts dies and we need a new BEX anyway, the ESP tunnel should break only in case of break-before-make mobility or failed re-keying. In these cases one could send the required UPDATE outside of the ESP tunnel. > 2) previously in RFC5201, we adopted the convention that the roles of > Initiator and Responder are abandoned once the base exchange > completes, so this would require implementations to keep that state > around (might require some comment here or in 5201bis). With the ESP mode you don't need this information, so I assume you are referring to the ESP-TCP mode where the Initiator initiates also the TCP connection, right? Although even in this case the information is needed only right after the BEX. If you think it would be beneficial to not require keeping this information (even for such a short period of time), we could define that the host with lower HIT value starts the TCP connection. Actually, if we want to support negotiation of the transport mode after the BEX using UPDATEs, this would be a good idea. > 3) (Linux question) regarding HIP over ESP, will XFRM process the > packet entering/leaving on a raw socket (both for IPv4 and IPv6)? Am > wondering how easy it will be to implement this option on current > systems, using kernel ESP implementations. Should HIP over UDP over > ESP (possibly over UDP again) be an option, for ease of programming? At least on Linux and IPv4 this seems to work if you don't use the IP_HDRINCL option and specify some protocol (say, 139) when creating the socket and give the same protocol to the IPsec policy. Haven't tested this with IPv6 yet. Does anyone have any experience on other platforms with raw sockets and ESP? A UDP mode would make the protocol stack look a bit funny, but surely that's not a show stopper if it's needed on some platforms. And I guess one could use the TCP mode in these cases too. > 4) Have you thought about SCTP instead of TCP for this use case? Not really, but I don't see much benefit of using SCTP instead of TCP in this scenario (e.g., we have already framing thanks to HIP header, HOL blocking doesn't sound like a probable scenario, DoS protection is provided by HIP). And since TCP is still much more widely supported, using that for fragmentation handling seems like a good idea. Or am I missing something? That said, having SCTP as one extra mode would fit well into the specification. Cheers, Ari From ari.keranen@nomadiclab.com Wed Feb 10 04:42:38 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0A63A7371 for ; Wed, 10 Feb 2010 04:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3mEGkzHYqAi for ; Wed, 10 Feb 2010 04:42:37 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 723243A6B88 for ; Wed, 10 Feb 2010 04:42:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 808C34E6D8; Wed, 10 Feb 2010 14:43:45 +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 XV6Os6XovyCU; Wed, 10 Feb 2010 14:43:45 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 147274E6CC; Wed, 10 Feb 2010 14:43:45 +0200 (EET) Message-ID: <4B72AA00.7020607@nomadiclab.com> Date: Wed, 10 Feb 2010 14:43:44 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dacheng Zhang References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <017401caaa01$9665e5b0$070d6f0a@china.huawei.com> In-Reply-To: <017401caaa01$9665e5b0$070d6f0a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: 'HIP' Subject: Re: [Hipsec] =?windows-1252?q?=3F=3F=3A__draft-keranen-hip-over-hip-0?= =?windows-1252?q?0?= 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, 10 Feb 2010 12:42:38 -0000 Hi, Dacheng Zhang wrote: > I have a superficial question here. A HIP host needs to use Update a packet > to inform its partner that its IP address has been changed. However, if the > update packet is transported using ESP, will it be difficult for the partner > to find out the proper IPsec AS to decrpt the packet and get the update > information? This should not be a problem. The ESP packet with the UPDATE still contains the same SPI value which the peer can use for finding the correct IPsec SA (only destination address and SPI value are needed for making the match). However, if both hosts move at the same time, one would need to fall back to using HIP without ESP. I'll add text about this to the next revision of the draft. Cheers, Ari From miika.komu@hiit.fi Wed Feb 10 04:49:20 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C36E3A7349 for ; Wed, 10 Feb 2010 04:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAW0ss7gNt8X for ; Wed, 10 Feb 2010 04:49:19 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id D7E793A7371 for ; Wed, 10 Feb 2010 04:49:18 -0800 (PST) Received: from [130.233.194.200] (tko-add-200.cs.hut.fi [130.233.194.200]) by argo.otaverkko.fi (Postfix) with ESMTP id 8981925ED1E for ; Wed, 10 Feb 2010 14:50:28 +0200 (EET) Message-ID: <4B72AB94.8030408@hiit.fi> Date: Wed, 10 Feb 2010 14:50:28 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100206 Shredder/3.0.2pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <4B72A248.9090901@nomadiclab.com> In-Reply-To: <4B72A248.9090901@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 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: Wed, 10 Feb 2010 12:49:20 -0000 On 02/10/2010 02:10 PM, Ari Keranen wrote: Hi, > Hi Tom, > > Thanks for the comments! Responses inline. > > Henderson, Thomas R wrote: >>> -----Original Message----- > [...] >>> [1] http://www.ietf.org/id/draft-keranen-hip-over-hip-00.txt >> >> Hi Ari, >> >> I had a few questions on the above draft. >> >> 1) I wonder about a dependency in requiring HIP to use ESP (the >> "MUST" in section 3.2) if HIP is also responsible for setting up or >> repairing ESP itself. Should there be a possibility of falling back >> to HIP outside of the ESP envelope in failure cases? Another failure >> case is that the initiator or responder fails to set up the TCP >> sockets as described. > > Good point. Failure and mobility scenarios are not yet specified in this > initial version, but I'll add text about them to the next revision. > > AFAIK, unless one of the hosts dies and we need a new BEX anyway, the > ESP tunnel should break only in case of break-before-make mobility or > failed re-keying. In these cases one could send the required UPDATE > outside of the ESP tunnel. agree. >> 2) previously in RFC5201, we adopted the convention that the roles of >> Initiator and Responder are abandoned once the base exchange >> completes, so this would require implementations to keep that state >> around (might require some comment here or in 5201bis). > > With the ESP mode you don't need this information, so I assume you are > referring to the ESP-TCP mode where the Initiator initiates also the TCP > connection, right? Although even in this case the information is needed > only right after the BEX. > > If you think it would be beneficial to not require keeping this > information (even for such a short period of time), we could define that > the host with lower HIT value starts the TCP connection. Actually, if we > want to support negotiation of the transport mode after the BEX using > UPDATEs, this would be a good idea. Bigger HIT would align well with the NAT traversal draft. >> 3) (Linux question) regarding HIP over ESP, will XFRM process the >> packet entering/leaving on a raw socket (both for IPv4 and IPv6)? Am >> wondering how easy it will be to implement this option on current >> systems, using kernel ESP implementations. Should HIP over UDP over >> ESP (possibly over UDP again) be an option, for ease of programming? > > At least on Linux and IPv4 this seems to work if you don't use the > IP_HDRINCL option and specify some protocol (say, 139) when creating the > socket and give the same protocol to the IPsec policy. Haven't tested > this with IPv6 yet. > > Does anyone have any experience on other platforms with raw sockets and > ESP? A UDP mode would make the protocol stack look a bit funny, but > surely that's not a show stopper if it's needed on some platforms. And I > guess one could use the TCP mode in these cases too. No experience. The ESP-over-UDP case has to work for deployment scenarios with legacy NATs and somebody should really try this. >> 4) Have you thought about SCTP instead of TCP for this use case? > > Not really, but I don't see much benefit of using SCTP instead of TCP in > this scenario (e.g., we have already framing thanks to HIP header, HOL > blocking doesn't sound like a probable scenario, DoS protection is > provided by HIP). And since TCP is still much more widely supported, > using that for fragmentation handling seems like a good idea. Or am I > missing something? > > That said, having SCTP as one extra mode would fit well into the > specification. SCTP can be added later if needed. Btw, the multihoming support from SCTP inside the ESP tunnel seems unnecessary. Few other questions that came into my mind: * One potential use case for HIP inside TCP are the certificates which can fragment. Perhaps this could be mentioned in the draft and you could cite Samu's cert draft. * The draft has a dependency to ESP transform. One must be negotiated or otherwise the extensions in the draft do not apply. I think Initiator MUST not send HIP_TRANSPORT_MODE with mode 1/2 transform when the Responder has excluded ESP transform in R1. From ari.keranen@nomadiclab.com Wed Feb 10 08:33:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0983A7762 for ; Wed, 10 Feb 2010 08:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2hSHxdrDJRm for ; Wed, 10 Feb 2010 08:33:49 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 243493A774F for ; Wed, 10 Feb 2010 08:33:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 1B6884E6DD; Wed, 10 Feb 2010 18:34:59 +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 DTpXuK-KKw1X; Wed, 10 Feb 2010 18:34:58 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9FA874E6CC; Wed, 10 Feb 2010 18:34:58 +0200 (EET) Message-ID: <4B72E032.5000009@nomadiclab.com> Date: Wed, 10 Feb 2010 18:34:58 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: miika.komu@hiit.fi References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <4B72A248.9090901@nomadiclab.com> <4B72AB94.8030408@hiit.fi> In-Reply-To: <4B72AB94.8030408@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 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, 10 Feb 2010 16:33:50 -0000 Hi, Miika Komu wrote: > On 02/10/2010 02:10 PM, Ari Keranen wrote: >> Henderson, Thomas R wrote: >>> 2) previously in RFC5201, we adopted the convention that the roles of >>> Initiator and Responder are abandoned once the base exchange >>> completes, so this would require implementations to keep that state >>> around (might require some comment here or in 5201bis). >> >> With the ESP mode you don't need this information, so I assume you are >> referring to the ESP-TCP mode where the Initiator initiates also the TCP >> connection, right? Although even in this case the information is needed >> only right after the BEX. >> >> If you think it would be beneficial to not require keeping this >> information (even for such a short period of time), we could define that >> the host with lower HIT value starts the TCP connection. Actually, if we >> want to support negotiation of the transport mode after the BEX using >> UPDATEs, this would be a good idea. > > Bigger HIT would align well with the NAT traversal draft. True. I changed this so that the one with the larger HIT is the "Responder" (i.e., the one waiting for the connection). Also, I added the possibility to negotiate new mode after BEX using UPDATEs and a mode (called DEFAULT) for changing back to what ever was used during the BEX. >>> 4) Have you thought about SCTP instead of TCP for this use case? >> >> Not really, but I don't see much benefit of using SCTP instead of TCP in >> this scenario (e.g., we have already framing thanks to HIP header, HOL >> blocking doesn't sound like a probable scenario, DoS protection is >> provided by HIP). And since TCP is still much more widely supported, >> using that for fragmentation handling seems like a good idea. Or am I >> missing something? >> >> That said, having SCTP as one extra mode would fit well into the >> specification. > > SCTP can be added later if needed. Btw, the multihoming support from > SCTP inside the ESP tunnel seems unnecessary. Agree. > Few other questions that came into my mind: > > * One potential use case for HIP inside TCP are the certificates which > can fragment. Perhaps this could be mentioned in the draft and you could > cite Samu's cert draft. True, I'll add this and some text on when to choose each mode. Also the HICCUPS DATA messages are a potential candidate for the TCP mode. > * The draft has a dependency to ESP transform. One must be negotiated or > otherwise the extensions in the draft do not apply. I think Initiator > MUST not send HIP_TRANSPORT_MODE with mode 1/2 transform when the > Responder has excluded ESP transform in R1. Good point; I'll fix this too. Thanks, Ari From thomas.r.henderson@boeing.com Thu Feb 11 08:50:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C407228C1FC for ; Thu, 11 Feb 2010 08:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 WT2yzuaj0OhE for ; Thu, 11 Feb 2010 08:50:34 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E241428C1D2 for ; Thu, 11 Feb 2010 08:50:34 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o1BGpjqf008874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 08:51:45 -0800 (PST) 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 o1BGpi3P011201; Thu, 11 Feb 2010 08:51:44 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o1BGpikW011198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Feb 2010 08:51:44 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 11 Feb 2010 08:51:44 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Thu, 11 Feb 2010 08:51:44 -0800 Thread-Topic: draft-keranen-hip-over-hip-00 Thread-Index: AcqqShlEOH+AzkOaQfOniCESll/DsAA75RGg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A762@XCH-NW-10V.nw.nos.boeing.com> References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <4B72A248.9090901@nomadiclab.com> In-Reply-To: <4B72A248.9090901@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:50:35 -0000 > > 2) previously in RFC5201, we adopted the convention that > the roles of > > Initiator and Responder are abandoned once the base exchange > > completes, so this would require implementations to keep that state > > around (might require some comment here or in 5201bis). > > With the ESP mode you don't need this information, so I > assume you are > referring to the ESP-TCP mode where the Initiator initiates > also the TCP > connection, right? Although even in this case the information > is needed > only right after the BEX. > > If you think it would be beneficial to not require keeping this > information (even for such a short period of time), we could > define that > the host with lower HIT value starts the TCP connection. > Actually, if we > want to support negotiation of the transport mode after the BEX using > UPDATEs, this would be a good idea. Yes, I was referring to ESP-TCP mode. Your suggestion about the lower HIT = value seems fine to me. > > > 4) Have you thought about SCTP instead of TCP for this use case? > > Not really, but I don't see much benefit of using SCTP > instead of TCP in > this scenario (e.g., we have already framing thanks to HIP > header, HOL > blocking doesn't sound like a probable scenario, DoS protection is > provided by HIP). And since TCP is still much more widely supported, > using that for fragmentation handling seems like a good idea. Or am I > missing something? > > That said, having SCTP as one extra mode would fit well into the > specification. > I was thinking initially that SEQPACKET might offer slightly better semanti= cs than STREAM to this application, but having read the sctp API draft just= now, I'm not sure that the work to deconflict the SCTP multihoming from HI= P multihoming is worth it (i.e. you would have to provide some explicit gui= delines on how to use the SCTP API, where TCP is pretty clear cut to develo= pers). - Tom From ari.keranen@nomadiclab.com Fri Feb 12 04:27:43 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A003A78B4 for ; Fri, 12 Feb 2010 04:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRIeSB-hgE-r for ; Fri, 12 Feb 2010 04:27:42 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2A77A3A78B3 for ; Fri, 12 Feb 2010 04:27:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0F52C4E6C8; Fri, 12 Feb 2010 14:28:58 +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 Xtlv9W+bdQtB; Fri, 12 Feb 2010 14:28:57 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9BE1F4E6C4; Fri, 12 Feb 2010 14:28:57 +0200 (EET) Message-ID: <4B754989.5090209@nomadiclab.com> Date: Fri, 12 Feb 2010 14:28:57 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5EFEA2.6020205@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A73B@XCH-NW-10V.nw.nos.boeing.com> <4B72A248.9090901@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A762@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A762@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] draft-keranen-hip-over-hip-00 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, 12 Feb 2010 12:27:43 -0000 Henderson, Thomas R wrote: >>> 2) previously in RFC5201, we adopted the convention that >> the roles of >>> Initiator and Responder are abandoned once the base exchange >>> completes, so this would require implementations to keep that >>> state around (might require some comment here or in 5201bis). >> With the ESP mode you don't need this information, so I assume you >> are referring to the ESP-TCP mode where the Initiator initiates >> also the TCP connection, right? Although even in this case the >> information is needed only right after the BEX. >> >> If you think it would be beneficial to not require keeping this >> information (even for such a short period of time), we could define >> that the host with lower HIT value starts the TCP connection. >> Actually, if we want to support negotiation of the transport mode >> after the BEX using UPDATEs, this would be a good idea. > > Yes, I was referring to ESP-TCP mode. Your suggestion about the > lower HIT value seems fine to me. OK, great. This will be included in the next revision. >>> 4) Have you thought about SCTP instead of TCP for this use case? >> Not really, but I don't see much benefit of using SCTP instead of >> TCP in this scenario (e.g., we have already framing thanks to HIP >> header, HOL blocking doesn't sound like a probable scenario, DoS >> protection is provided by HIP). And since TCP is still much more >> widely supported, using that for fragmentation handling seems like >> a good idea. Or am I missing something? >> >> That said, having SCTP as one extra mode would fit well into the >> specification. >> > > I was thinking initially that SEQPACKET might offer slightly better > semantics than STREAM to this application, but having read the sctp > API draft just now, I'm not sure that the work to deconflict the SCTP > multihoming from HIP multihoming is worth it (i.e. you would have to > provide some explicit guidelines on how to use the SCTP API, where > TCP is pretty clear cut to developers). OK. Then I think it makes sense to leave SCTP out of the draft, at least for the time being. Thanks for the analysis! Cheers, Ari From thomas.r.henderson@boeing.com Mon Feb 22 10:43:34 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18E828C374 for ; Mon, 22 Feb 2010 10:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 eqmciVAv2Uvn for ; Mon, 22 Feb 2010 10:43:33 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id AF16128C164 for ; Mon, 22 Feb 2010 10:43:30 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1MIjJ62028156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2010 12:45:20 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1MIjHjd007717; Mon, 22 Feb 2010 10:45:17 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1MIjGwh007679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Feb 2010 10:45:16 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 22 Feb 2010 10:45:16 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Mon, 22 Feb 2010 10:45:15 -0800 Thread-Topic: [Hipsec] WGLC: HIP-based overlays Thread-Index: Acqem2t7RDuopi1YTBisaKUsTpcP6AVOTsEw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BD@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> In-Reply-To: <4B5F07F6.7080800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] WGLC: HIP-based overlays 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, 22 Feb 2010 18:43:34 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 26, 2010 7:19 AM > To: HIP > Subject: [Hipsec] WGLC: HIP-based overlays > > Folks, > > we would like to WGLC the set of specifications that describe how to > build HIP-based overlays. The documents under WGLC are the following: > > http://tools.ietf.org/html/draft-ietf-hip-bone-04 > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 > http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 > http://tools.ietf.org/html/draft-ietf-hip-via-00 > > This WGLC will end on February 23rd. Please, send your > comments to this > list. > Gonzalo, Below are my WGLC comments on this set of drafts. I will send some detaile= d comments on each draft in subsequent messages. Overall, my opinion is that this set of drafts is not yet ready to publish,= because there are some missing elements in each draft (see the detailed co= mments) and also because I think the overall clarity of the specifications = could be improved. In particular, I found several instances where I had a = question of how something worked in one draft, and later found the answer s= omewhere else in another draft. These types of things could be probably ad= dressed by some reorganization. Also, I did not have a clear big picture of this type of overlay until I re= ad all of the details of all drafts. Some type of "Protocol overview" sect= ion in the framework draft, with particular attention to interface definiti= ons or modular decomposition, would help. For example, when I read the REL= OAD draft, I found a nice overview section including architectural diagrams= in Section 1 of the draft. Maybe Section 7 of the hip-bone draft could be= moved forward to Section 1 and expanded. I would suggest: 1) merge draft-ietf-hip-bone, draft-ietf-hip-via, and draft-ietf-hip-hiccup= s into one draft. Keep the reload instance as a separate draft. Keep the = certificate draft as a separate draft. 2) write a protocol (or framework) overview section in the draft-ietf-hip-b= one-04 and place it in Section 1, like was done for RELOAD. Note that I did not review these drafts from the perspective of whether all= of the new crypto defined is correct and consistent with the rest of HIP. Regards, Tom From thomas.r.henderson@boeing.com Mon Feb 22 10:44:03 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC05228C371 for ; Mon, 22 Feb 2010 10:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 wjtAPADYWv-y for ; Mon, 22 Feb 2010 10:44:02 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9590B28C164 for ; Mon, 22 Feb 2010 10:44:02 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1MIk0cF028583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2010 12:46:00 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1MIjx62027699; Mon, 22 Feb 2010 12:45:59 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1MIjx6t027682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Feb 2010 12:45:59 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 22 Feb 2010 10:45:59 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Mon, 22 Feb 2010 10:45:58 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-via-00 Thread-Index: Acqem2t7RDuopi1YTBisaKUsTpcP6AVOjB2w Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BE@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> In-Reply-To: <4B5F07F6.7080800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00 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, 22 Feb 2010 18:44:03 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 26, 2010 7:19 AM > To: HIP > Subject: [Hipsec] WGLC: HIP-based overlays > > Folks, > > we would like to WGLC the set of specifications that describe how to > build HIP-based overlays. The documents under WGLC are the following: > > http://tools.ietf.org/html/draft-ietf-hip-bone-04 > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 > http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 > http://tools.ietf.org/html/draft-ietf-hip-via-00 > > This WGLC will end on February 23rd. Please, send your > comments to this > list. > Comments on draft-ietf-hip-via-00: I recommended in another message that this draft could be merged with the H= IP BONE draft, but below are some more specific comments. > These two extensions enable multi-hop routing in HIP. Before these > extensions were specified, HIP only supported a single intermediate > host (i.e., a rendezvous server [RFC5204]) between the source of a > HIP packet and its destination. I don't see why these extensions are required to perform multi-hop routing = in all cases. I agree that one of them is needed to provide multi-hop sour= ce routing, but perhaps not multi-hop destination-based routing. > 2.2. Definitions > > > Destination list: A list of HITs of the hosts that a HIP packet > should traverse. > > Via list: A list of HITs of the hosts that a HIP packet has > traversed. > > Symmetric routing: A response to a message is routed back using the > same set of intermediary nodes as the original message used, > except in reversed order. It may help to note that the terminology is borrowed from RELOAD. > 3.1. Creating and Processing Via Lists > > > When a host sending a HIP packet needs to record the hosts that are > on the path that the HIP packet traverses, it includes an empty > ROUTE_VIA parameter to the packet. Can you clarify the means whereby a HIP host originating a packet knows tha= t it needs to include a ROUTE_VIA? Especially, the distinction between set= ting the SYMMETRIC flag or not. This is an example where I found the rules for setting these flags and para= meters in the instance specification (section 7 of the instance draft). Ma= ybe this draft should clarify that this is discussed in an instance specifi= cation. > 3.3. Processing Destination Lists > > > When a host receives a HIP packet that contains a ROUTE_DST > parameter, it first looks up its own HIT from the route list. If > host's own HIT is not in the list and the host is not the receiver of > the packet, the packet was incorrectly forwarded and MUST be dropped. > Next hop for the packet is the HIT after host's own HIT in the list. The above sentence should be expanded and clarified. Can the forwarding ho= st ignore the specified next hop in any cases (i.e., is this a SHOULD or MU= ST next hop)? For instance, the host may "look ahead" in the destination l= ist and find that it already has an active association to a later host-- ca= n it just use that? Another possibility to discuss is a situation in which= the requested next hop is not reachable for some reason. Or, you may delegate the exact behavior to the instance specification (such= as you do in section 7 of hip-reload-instance), in which case this draft s= hould more clearly state that forwarding behavior may be specified elsewher= e. Perhaps the protocol needs a loose source and strict source routing flag of= some sort, to control this behavior. > If the host's HIT was the last HIT in the list, the next hop is the > receiver's HIT in the HIP header. It seems to me that the above sentence would be clearer if it just stated t= hat there is no next hop in this case. > 6.1. Forwarding Loops > > > A malicious host could craft a destination route list that contains > the same HIT more than once and thus create a forwarding loop. Since > the IP layer TTL is decremented on each hop, the loop will be > eventually broken, but hosts may additionally protect themselves > against this attack by checking that their own HIT is in the > destination list only once and drop invalid packets. I don't think that IP layer TTL can provide protection here; it is regenera= ted at every HIP hop, right? However, you do introduce an OVERLAY_TTL para= meter elsewhere in HIP BONE; can you use that? > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Why is this a normative reference? Other comments: - Should there be a NOTIFY parameter for a route failure situation (for ROU= TE_DST)? See for instance Section 5.3.3.1 of RELOAD From thomas.r.henderson@boeing.com Mon Feb 22 10:44:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D638C28C37B for ; Mon, 22 Feb 2010 10:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 c9jW41xrJyBL for ; Mon, 22 Feb 2010 10:44:50 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id CE3BB28C379 for ; Mon, 22 Feb 2010 10:44:49 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1MIkkji029007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2010 12:46:47 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1MIkkoo011115; Mon, 22 Feb 2010 10:46:46 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1MIkkqv011095 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Feb 2010 10:46:46 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 22 Feb 2010 10:46:45 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Mon, 22 Feb 2010 10:46:45 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 Thread-Index: Acqem2t7RDuopi1YTBisaKUsTpcP6AVS/lww Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BF@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> In-Reply-To: <4B5F07F6.7080800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] WGLC: draft-ietf-hip-hiccups-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:44:50 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 26, 2010 7:19 AM > To: HIP > Subject: [Hipsec] WGLC: HIP-based overlays > > Folks, > > we would like to WGLC the set of specifications that describe how to > build HIP-based overlays. The documents under WGLC are the following: > > http://tools.ietf.org/html/draft-ietf-hip-bone-04 > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 > http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 > http://tools.ietf.org/html/draft-ietf-hip-via-00 > > This WGLC will end on February 23rd. Please, send your > comments to this > list. > comments on draft-ietf-hip-hiccups-01: Overall, I think that this document mainly makes sense in the context of HI= P BONE and should be folded into that specification. However, if kept stan= d-alone, it would help to clarify in the introduction that this specifies a= data service with the following semantics: unordered, duplicate free (sub= ject to receiver ACK cache size and lifetime), reliable (up to a retransmis= sion count), authenticated, and encrypted message-based delivery service. = I would also recommend stating that APIs to higher-level protocols that mig= ht use this service are outside the scope of this specification. > 2. Terminology > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. This section is empty; probably at the very least it should point to the no= rmative references that define the terminology in use later in the document= . > 3. Background on HIP > > > The HIP protocol specification [RFC5201] defines a number of messages > and parameters. The parameters are encoded as TLVs, as shown in > Section 3.1.2. Furthermore, the HIP header carries a Next Header > field, allowing other arbitrary packets to be carried within HIP > packets. Perhaps this section could go away or be refactored if this draft is merged= to hip-bone. > 4.1. Definition of the PAYLOAD_MAC Parameter > > Length length in octets, excluding Type, Length, and > Padding are there any minimum or maximum size limitations for this parameter? Shou= ld the maximum length be tied to the maximum size that the HMAC can handle? > 5.1. Handling of SEQ_DATA and ACK_DATA > > > A HIP DATA packet contains zero or one SEQ_DATA parameter. The > presence of a SEQ_DATA parameter indicates that the receiver MUST ACK > the HIP DATA packet. A HIP DATA packet that does not contain a > SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and > MUST NOT be ACKed. is it legal to have a HIP DATA with zero SEQ_DATA and zero ACK_DATA? If no= t, suggest to say that if SEQ_DATA is missing, ACK_DATA must be present. Can SEQ_DATA be present with no PAYLOAD_MAC parameter? > packet. A host MAY choose to hold the HIP DATA packet carrying ACK > for a short period of time to allow for the possibility of > piggybacking the ACK parameter, in a manner similar to TCP delayed > acknowledgments. Should the ACK_DATA format allow for multiple sequence numbers, if so, to a= void carrying a Type and Length field for each one? > 1. The host creates a HIP DATA packet that contains a SEQ_DATA > parameter. The host is free to choose any value for the SEQ_DATA > parameter in the first HIP DATA packet it sends to a destination. This section would be clearer if you replaced "SEQ_DATA parameter" and "SEQ= _DATA value" with "SEQ_DATA sequence number". From thomas.r.henderson@boeing.com Mon Feb 22 10:45:49 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197283A7D67 for ; Mon, 22 Feb 2010 10:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 XScrCctPgRs3 for ; Mon, 22 Feb 2010 10:45:48 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0520F3A7ADF for ; Mon, 22 Feb 2010 10:45:23 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1MIlH66000786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2010 10:47:18 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1MIlHeK000206; Mon, 22 Feb 2010 12:47:17 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1MIlBJl000043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Feb 2010 12:47:17 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 22 Feb 2010 10:47:15 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Mon, 22 Feb 2010 10:47:14 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 Thread-Index: Acqem2t7RDuopi1YTBisaKUsTpcP6AVRSIWg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> In-Reply-To: <4B5F07F6.7080800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 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, 22 Feb 2010 18:45:49 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 26, 2010 7:19 AM > To: HIP > Subject: [Hipsec] WGLC: HIP-based overlays > > Folks, > > we would like to WGLC the set of specifications that describe how to > build HIP-based overlays. The documents under WGLC are the following: > > http://tools.ietf.org/html/draft-ietf-hip-bone-04 > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 > http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 > http://tools.ietf.org/html/draft-ietf-hip-via-00 > > This WGLC will end on February 23rd. Please, send your > comments to this > list. > comments on draft-ietf-hip-reload-instance-00: > 2. Terminology > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. This section is empty; probably at the very least it should point to the no= rmative references that define the terminology in use later in the document= . > 3. Peer Protocol > > The peer protocol to be used is RELOAD, which is specified in > [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the > RELOAD's Forwarding and Link Management Layer (described in Section > 5.5. of [I-D.ietf-p2psip-base]. RELOAD also has a Topology Plugin module that is responsible for maintainin= g the routing tables; from the RELOAD draft: " The Topology Plugin is responsible for maintaining the overlay algorithm Routing Table, which is consulted by the Forwarding and Link Management Layer before routing a message." can you define how this relates to the HIP-specific implementation? Does a= n interface exist between a HIP forwarding process and the topology plugin = of RELOAD? > 4. Peer ID Generation > > In the other Peer ID mode, namely "RELOAD", all 128 bits are > generated as defined in [I-D.ietf-p2psip-base] resulting in a larger > usable address space. If the RELOAD node IDs are not HITs (ORCHIDs), then a mapping between the n= ode id and the HITs is necessary. Section 5.6.1 of RELOAD suggests that ce= rtificates are to be used in this case; I expected that this draft would di= scuss the HIP certificate model for this binding. > 5. Mapping between Protocol Primitives and HIP Messages > > ...Block are replaced with HIP header, HIP VIA lists [I-D.ietf-hip-via= ], > and CERT [I-D.ietf-hip-cert], TRANSACTION_ID, OVERLAY_ID and > OVERLAY_TTL [I-D.ietf-hip-bone] parameters. TRANSACTION_ID is specified in hiccups, not hip-bone. > 8. Enrollment and Bootstrapping > > The RELOAD HIP BONE instance uses the enrollment and bootstrap > procedure defined by RELOAD [I-D.ietf-p2psip-base] with the > exceptions listed below. It was not clear to me how initial bootstrapping occurred, or whether HIP R= elay/Rendezvous servers can be used in the absence of HIP routes being in t= he node's Topology plugin table. I am assuming that upon first join, HIP n= odes must either use the "well known public IP address" technique of bootst= rap nodes to join, and then subsequently they will forward all of their HIP= messages over the overlay-- is that correct? Does the AttachReq have a s= et of suggested locators for initial contact? > 9. NAT Traversal > > > RELOAD relies on the Forwarding and Link Management Layer providing > NAT traversal capabilities. Thus, the RELOAD HIP BONE instance > implementations MUST implement some reliable NAT traversal mechanism. > To maximize interoperability, all implementations SHOULD implement at > least [I-D.ietf-hip-nat-traversal]. RELOAD specifies that nodes MUST implement full ICE. (Section 5.5.1.3). C= an you clarify whether that MUST should be avoided in this instance (i.e. h= ow to avoid RELOAD ICE layered on top of HIP ICE-like NAT traversal)? From thomas.r.henderson@boeing.com Mon Feb 22 10:47:23 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0BF3A7D67 for ; Mon, 22 Feb 2010 10:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 Folw4QclZyAi for ; Mon, 22 Feb 2010 10:47:22 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 35B153A76B1 for ; Mon, 22 Feb 2010 10:47:22 -0800 (PST) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1MInIE1001992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2010 10:49:19 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1MInIAP018863; Mon, 22 Feb 2010 10:49:18 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1MImuje017933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 22 Feb 2010 10:49:18 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 22 Feb 2010 10:49:03 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" , HIP Date: Mon, 22 Feb 2010 10:49:02 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-bone-04 Thread-Index: Acqem2t7RDuopi1YTBisaKUsTpcP6AVT8wWA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C1@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> In-Reply-To: <4B5F07F6.7080800@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] WGLC: draft-ietf-hip-bone-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:47:23 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Tuesday, January 26, 2010 7:19 AM > To: HIP > Subject: [Hipsec] WGLC: HIP-based overlays > > Folks, > > we would like to WGLC the set of specifications that describe how to > build HIP-based overlays. The documents under WGLC are the following: > > http://tools.ietf.org/html/draft-ietf-hip-bone-04 > http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00 > http://tools.ietf.org/html/draft-ietf-hip-hiccups-01 > http://tools.ietf.org/html/draft-ietf-hip-via-00 > > This WGLC will end on February 23rd. Please, send your > comments to this > list. > comments on draft-ietf-hip-bone-04: (please see my other post suggesting that this draft include the via and hi= ccups drafts and that it add a better protocol overview section). > 2. Terminology > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. This section is empty; I think that since this is intended as a framework d= ocument, a good terminology section is needed. > 3. Background on HIP > I previously commented (earlier version of this draft) that it might be eas= ier to refer readers to the HIP arch or base RFCs, but if you want to keep = it here, suggest to move it to an appendix since it is not normative materi= al. > 4. The HIP BONE Framework > > > An overlay typically requires three types of operations: > > o overlay maintenance. > o data storage and retrieval. > o connection management. Not all overlays (e.g. pure routing overlays) require data storage and retr= ieval. Suggest to say that "Many overlays typically require..." > 4.1. Peer ID Assignment and Bootstrap > > Nodes in an overlay are primarily identified by their Peer IDs. This terminology "Peer ID" seems very RELOAD-centric. How about the more g= eneral "Node ID", or talk about the distinction between peers and clients, = such as in RELOAD? > If the overlay network or peer protocol has more specific > requirements for the Peer ID value that prevent using HITs derived > from public keys, each host will need a certificate (e.g., in their > HIP base exchanges) provided by the enrollment server to prove that > they are authorized to use a particular identifier in the overlay. Note: this is what I thought was missing in the instance specification. > Bootstrap issues such as how to locate an enrollment or a bootstrap > server belong to the peer protocol. This seems to be a placeholder sentence for future text. At the very least= , this framework draft should deal with the bootstrap issue of how to forwa= rd I1s along the HIP BONE when a node first joins the overlay. > Note that the border between HIP BONE instance specification and a > peer protocol specifications is blurry. I agree with this observation; the current drafts are basically written fro= m the standpoint of RELOAD and details about e.g. interaction between HIP a= nd topology plugin are fuzzy. However, it seems to me that to be useful as= a general purpose framework for arbitrary peer protocols, crisper APIs wou= ld need to be specified. > 5. Advantages of Using HIP BONE > > Using HIP BONE, as opposed to a peer protocol, to perform connection > management in an overlay has a set of advantages. HIP BONE can be > used by any peer protocol. This keeps each peer protocol from > defining primitives needed for connection management (e.g., > primitives to establish connections and to tunnel messages through > the overlay) and NAT traversal. Having this functionality at a lower > layer allows multiple upper-layer protocols to take advantage of it. This section probably could be moved to an introduction, explaining why we = are going through all of the trouble to support these overlays. > 7. Architectural Considerations Note, Section 7 is probably more important as a first section, not the last= in the draft. > Architecturally, routing tables are located between the peer protocol > and HIP, as shown in Figure 7. This is important architectural discussion. I had a few questions here: 1) can a HIP packet from one overlay consult the routing table built in ano= ther overlay? 2) if HIP receives a locally originated packet with no OVERLAY_ID, and it h= as one or more peer protocols running, how does it decide where to route th= e packet? I assume that all locally originated packets will somehow have t= heir overlay identifier specified, but it would be helpful to state this so= mewhere. For example, if it were RELOAD, RELOAD may have special APIs allo= wing it to identify the overlay ID that all locally originated packets from= the RELOAD instance should use. In addition, if HIP on that node was prov= iding traditional HIP services to legacy applications, such (legacy applica= tions) outbound packets would use rendezvous/relay servers as usual. From gonzalo.camarillo@ericsson.com Tue Feb 23 03:13:39 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C823028C275 for ; Tue, 23 Feb 2010 03:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdcXbvXLW9uY for ; Tue, 23 Feb 2010 03:13:38 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4E08C28C186 for ; Tue, 23 Feb 2010 03:13:37 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-ce-4b83b8dad723 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0B.86.31641.AD8B38B4; Tue, 23 Feb 2010 12:15:39 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 12:15:38 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 12:15:38 +0100 Message-ID: <4B83B8DA.5000108@ericsson.com> Date: Tue, 23 Feb 2010 13:15:38 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BD@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BD@XCH-NW-10V.nw.nos.boeing.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2010 11:15:38.0453 (UTC) FILETIME=[871FC850:01CAB479] X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: HIP-based overlays 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, 23 Feb 2010 11:13:40 -0000 Hi Tom, my answers inline: > Gonzalo, Below are my WGLC comments on this set of drafts. I will > send some detailed comments on each draft in subsequent messages. thanks for taking the time to comment on all these drafts. > Overall, my opinion is that this set of drafts is not yet ready to > publish, because there are some missing elements in each draft (see > the detailed comments) and also because I think the overall clarity > of the specifications could be improved. You have made a number of good comments. They will absolutely need to be addressed before we request their publication. In any case, while we could request the publication of the framework, via, and hiccups drafts when your comments have been incorporated, we will most likely delay the publication request of the RELOAD instance draft for a while. The reason is that the new revision of the main RELOAD spec (draft-ietf-p2psip-base-07), which was submitted last week, includes a few changes (some of them fruit of reviews by "HIP people") that require modifications in the instance spec. Obviously, ee will not request the publication of the instance spec as long as the main RELOAD spec is a moving target. > In particular, I found > several instances where I had a question of how something worked in > one draft, and later found the answer somewhere else in another > draft. These types of things could be probably addressed by some > reorganization. Yes, your comments about reorganizing some sections and introducing more elaborate overview sections in the drafts make sense to me. > Also, I did not have a clear big picture of this type of overlay > until I read all of the details of all drafts. Some type of > "Protocol overview" section in the framework draft, with particular > attention to interface definitions or modular decomposition, would > help. For example, when I read the RELOAD draft, I found a nice > overview section including architectural diagrams in Section 1 of the > draft. Maybe Section 7 of the hip-bone draft could be moved forward > to Section 1 and expanded. Agreed. > I would suggest: > > 1) merge draft-ietf-hip-bone, draft-ietf-hip-via, and > draft-ietf-hip-hiccups into one draft. The reason why these drafts are kept separate is that while the via and hiccups mechanisms are needed to build overlays, they are not specific to overlays and can be used in other contexts. Therefore, from a documentation perspective, it makes sense to have them in separate drafts. That much said, I agree that we need to make sure readers get the complete picture as soon as possible when they start reading the specifications. Let's work on reorganizing the sections and adding overview material so that the drafts explain up front what they are about. > Keep the reload instance as a > separate draft. Keep the certificate draft as a separate draft. > > 2) write a protocol (or framework) overview section in the > draft-ietf-hip-bone-04 and place it in Section 1, like was done for > RELOAD. I agree. Thanks, Gonzalo From ari.keranen@nomadiclab.com Tue Feb 23 06:06:15 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296283A837B for ; Tue, 23 Feb 2010 06:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0j1SRmgAvC4 for ; Tue, 23 Feb 2010 06:06:13 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 6B8E33A68ED for ; Tue, 23 Feb 2010 06:06:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 481114E6CF; Tue, 23 Feb 2010 16:08:14 +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 wdOginRWsX8S; Tue, 23 Feb 2010 16:08:13 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 545164E67D; Tue, 23 Feb 2010 16:08:13 +0200 (EET) Message-ID: <4B83E14D.3000401@nomadiclab.com> Date: Tue, 23 Feb 2010 16:08:13 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BE@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BE@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00 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, 23 Feb 2010 14:06:15 -0000 Hi Tom, Thanks for the review and comments; responses inline. Henderson, Thomas R wrote: >> These two extensions enable multi-hop routing in HIP. Before these >> extensions were specified, HIP only supported a single >> intermediate host (i.e., a rendezvous server [RFC5204]) between the >> source of a HIP packet and its destination. > > I don't see why these extensions are required to perform multi-hop > routing in all cases. I agree that one of them is needed to provide > multi-hop source routing, but perhaps not multi-hop destination-based > routing. Yes, you could have other ways to do that, but since this is, AFAIK, so far the only (to-be) standardized way to do this, I think it's fair to say that only single intermediary hop is currently supported. And we don't rule out other ways to do that either. But perhaps we could say something like: Before these extensions were specified, there were standardized ways for supporting only a single intermediate host (e.g., a rendezvous server [RFC5204]) between the source of a HIP packet and its destination. >> 2.2. Definitions >> >> >> Destination list: A list of HITs of the hosts that a HIP packet >> should traverse. >> >> Via list: A list of HITs of the hosts that a HIP packet has >> traversed. >> >> Symmetric routing: A response to a message is routed back using >> the same set of intermediary nodes as the original message used, >> except in reversed order. > > It may help to note that the terminology is borrowed from RELOAD. Actually, originally it wasn't, but you're right that it ended up being quite similar. Anyway, since this draft is not RELOAD (or even overlay) specific, I think having a RELOAD reference here would rather confuse the reader than clarify the terminology. >> 3.1. Creating and Processing Via Lists >> >> >> When a host sending a HIP packet needs to record the hosts that are >> on the path that the HIP packet traverses, it includes an empty >> ROUTE_VIA parameter to the packet. > > Can you clarify the means whereby a HIP host originating a packet > knows that it needs to include a ROUTE_VIA? Especially, the > distinction between setting the SYMMETRIC flag or not. It's intentional that we don't mandate when to use the VIA parameter or the symmetric flag; it's up to implementation, local policy, or another protocol taking advantage of this extension to decide that. For example, in the RELOAD instance spec we define the MUSTs and SHOULDs in that context. Some other usage may have different requirements, so we don't want to rule out those possibilities here. > This is an example where I found the rules for setting these flags > and parameters in the instance specification (section 7 of the > instance draft). Maybe this draft should clarify that this is > discussed in an instance specification. As mentioned above, instance specs are only one possible place where this could be defined. I'll add an additional paragraph to the beginning of the "Protocol Definitions" section clarifying this: The multi-hop routing extensions may be used in different contexts and whether a new HIP packet should, for example, include a Via list or have different options enabled, can depend on the particular use case, local policies, and different protocols using the extension. This section defines how the new parameters are handled, but when to use these extensions is out of scope for this document. >> 3.3. Processing Destination Lists >> >> >> When a host receives a HIP packet that contains a ROUTE_DST >> parameter, it first looks up its own HIT from the route list. If >> host's own HIT is not in the list and the host is not the receiver >> of the packet, the packet was incorrectly forwarded and MUST be >> dropped. Next hop for the packet is the HIT after host's own HIT in >> the list. > > The above sentence should be expanded and clarified. Can the > forwarding host ignore the specified next hop in any cases (i.e., is > this a SHOULD or MUST next hop)? For instance, the host may "look > ahead" in the destination list and find that it already has an active > association to a later host-- can it just use that? Another > possibility to discuss is a situation in which the requested next hop > is not reachable for some reason. Next hops should not be ignored, so that should be a MUST. I added to the end of the paragraph the following: If the host has a valid locator for the next hop, it MUST forward the HIP packet to the next hop host. (there's also new text after this paragraph about what to do if there is no valid locator; see the last comment) If you think that there are relevant use cases for the "look ahead optimization", we could have one flag that signals whether it's OK to do that (and have that as a "MAY"). > Or, you may delegate the exact behavior to the instance specification > (such as you do in section 7 of hip-reload-instance), in which case > this draft should more clearly state that forwarding behavior may be > specified elsewhere. > > Perhaps the protocol needs a loose source and strict source routing > flag of some sort, to control this behavior. Actually, this loose source routing flag was in one of the early pre-release versions of the draft, but it was removed since we didn't find really good use cases for it and it is a bit problematic with signed ROUTE_DST list. The problem is that with loose source routing either the VIA list would need to be modified (removing the hops that are already used; breaking the signature) or one would need a pointer (new parameter in the unsigned part) to the "next hop in the list" since you don't necessarily anymore implicitly know where in the list you're going. Moving the ROUTE_DST to the unsigned part would solve the issue, but we felt that protecting the list with signature is more important. Of course we could have both signed and unsigned versions if there are compelling use cases for the loose source routing. >> If the host's HIT was the last HIT in the list, the next hop is the >> receiver's HIT in the HIP header. > > It seems to me that the above sentence would be clearer if it just > stated that there is no next hop in this case. But there is the "next hop" from the last forwarding host to the receiver, right? And it's actually easier to refer to "next hop" in both cases in the following text. Or can you propose some other wording that would make this clearer? >> 6.1. Forwarding Loops >> >> >> A malicious host could craft a destination route list that contains >> the same HIT more than once and thus create a forwarding loop. >> Since the IP layer TTL is decremented on each hop, the loop will be >> eventually broken, but hosts may additionally protect themselves >> against this attack by checking that their own HIT is in the >> destination list only once and drop invalid packets. > > I don't think that IP layer TTL can provide protection here; it is > regenerated at every HIP hop, right? However, you do introduce an > OVERLAY_TTL parameter elsewhere in HIP BONE; can you use that? Good point; I was under the impression that the IP layer TTL is preserved by what is defined in the current RFCs, but after having a closer look at them it turned out they don't require this. I would not require using the OVERLAY_TTL parameter if not really necessary and rather make the checking-your-own HIT a MUST. >> [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an >> > IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. > > Why is this a normative reference? Good catch. Moved it to informative. > Other comments: > > - Should there be a NOTIFY parameter for a route failure situation > (for ROUTE_DST)? See for instance Section 5.3.3.1 of RELOAD That could be useful, I'll add it to the draft. Now it says at the end of Section 3.3: If the host does not have a valid locator for the next hop host, it SHOULD drop the packet and SHOULD send back a NOTIFY error packet with type UNKNOWN_NEXT_HOP (value [TBD by IANA; 90]). The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet and the ROUTE_DST parameter. Cheers, Ari From ari.keranen@nomadiclab.com Tue Feb 23 07:18:41 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6CA3A848B for ; Tue, 23 Feb 2010 07:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXK09ZOxQ-yq for ; Tue, 23 Feb 2010 07:18:40 -0800 (PST) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E29063A8490 for ; Tue, 23 Feb 2010 07:18:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0D4004E6D4; Tue, 23 Feb 2010 17:20:37 +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 wPhxCdPZ7Af8; Tue, 23 Feb 2010 17:20:36 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 05D0F4E67D; Tue, 23 Feb 2010 17:20:36 +0200 (EET) Message-ID: <4B83F243.6070208@nomadiclab.com> Date: Tue, 23 Feb 2010 17:20:35 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 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, 23 Feb 2010 15:18:41 -0000 Hi Tom, Once again, thanks for the comments; responses inline. Henderson, Thomas R wrote: >> 2. Terminology >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this document are to be interpreted as described in RFC 2119 >> [RFC2119]. > > This section is empty; probably at the very least it should point to > the normative references that define the terminology in use later in > the document. Makes sense; added pointers to 5201, HIP BONE and RELOAD. >> 3. Peer Protocol >> >> The peer protocol to be used is RELOAD, which is specified in >> [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the >> RELOAD's Forwarding and Link Management Layer (described in Section >> 5.5. of [I-D.ietf-p2psip-base]. > > RELOAD also has a Topology Plugin module that is responsible for > maintaining the routing tables; from the RELOAD draft: " The > Topology Plugin is responsible for maintaining the overlay algorithm > Routing Table, which is consulted by the Forwarding and Link > Management Layer before routing a message." > > can you define how this relates to the HIP-specific implementation? HIP replaces the Forwarding layer, so it consults the Topology plugin module as the Forwarding layer would have done. > Does an interface exist between a HIP forwarding process and the > topology plugin of RELOAD? The details about the interface (if any) between HIP and RELOAD modules are left up to implementations. Our goal was not to define APIs in this document, but such APIs can be later defined in, e.g., advanced HIP native API document. >> 4. Peer ID Generation >> >> In the other Peer ID mode, namely "RELOAD", all 128 bits are >> generated as defined in [I-D.ietf-p2psip-base] resulting in a >> larger usable address space. > > If the RELOAD node IDs are not HITs (ORCHIDs), then a mapping between > the node id and the HITs is necessary. Section 5.6.1 of RELOAD > suggests that certificates are to be used in this case; I expected > that this draft would discuss the HIP certificate model for this > binding. In this case the 128-bit ID would be your "HIT" so there is no need for mapping (and in that sense the assumptions in Section 5.6.1.1 of RELOAD draft are not really correct). >> 5. Mapping between Protocol Primitives and HIP Messages >> >> ...Block are replaced with HIP header, HIP VIA lists >> [I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID, >> OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-bone] parameters. > > TRANSACTION_ID is specified in hiccups, not hip-bone. Good catch; fixed. >> 8. Enrollment and Bootstrapping >> >> The RELOAD HIP BONE instance uses the enrollment and bootstrap >> procedure defined by RELOAD [I-D.ietf-p2psip-base] with the >> exceptions listed below. > > It was not clear to me how initial bootstrapping occurred, or whether > HIP Relay/Rendezvous servers can be used in the absence of HIP routes > being in the node's Topology plugin table. I am assuming that upon > first join, HIP nodes must either use the "well known public IP > address" technique of bootstrap nodes to join, and then subsequently > they will forward all of their HIP messages over the overlay-- is > that correct? Does the AttachReq have a set of suggested locators > for initial contact? The idea is to re-use the bootsrapping possibilities defined in the RELOAD spec; including downloading the config file using HTTP from a server discovered using DNS. But perhaps this would need some clarification. I'll see what I can do. AttachReqs are not used with the instance spec. >> 9. NAT Traversal >> >> >> RELOAD relies on the Forwarding and Link Management Layer providing >> NAT traversal capabilities. Thus, the RELOAD HIP BONE instance >> implementations MUST implement some reliable NAT traversal >> mechanism. To maximize interoperability, all implementations SHOULD >> implement at least [I-D.ietf-hip-nat-traversal]. > > RELOAD specifies that nodes MUST implement full ICE. (Section > 5.5.1.3). Can you clarify whether that MUST should be avoided in > this instance (i.e. how to avoid RELOAD ICE layered on top of HIP > ICE-like NAT traversal)? Yes, the whole 5.5. section of RELOAD is replaced by what is defined in 5 of the instance spec. I'll clarify in that section that this also includes all the ICE stuff. Now the section 5 starts with: RELOAD HIP BONE replaces the RELOAD protocol primitives taking care of connection establishment with the HIP base exchange, where as the rest of the RELOAD messages are conveyed within HIP messages. The Forwarding and Link Management Layer functionality of RELOAD defined in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT traversal functionality, is replaced by HIP and the extensions defined in this document. Cheers, Ari From thomas.r.henderson@boeing.com Tue Feb 23 09:46:11 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646AA28C15D for ; Tue, 23 Feb 2010 09:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 jYuyjfE70xqA for ; Tue, 23 Feb 2010 09:46:10 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id CA20328C17A for ; Tue, 23 Feb 2010 09:45:54 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1NHlpSl017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2010 09:47:52 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1NHlp5C013557; Tue, 23 Feb 2010 11:47:51 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1NHlooC013550 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Feb 2010 11:47:51 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 23 Feb 2010 09:47:50 -0800 From: "Henderson, Thomas R" To: "'Gonzalo Camarillo'" Date: Tue, 23 Feb 2010 09:47:49 -0800 Thread-Topic: [Hipsec] WGLC: HIP-based overlays Thread-Index: Acq0eYoJ3xCkYRvqRSyCzyt99twdUwANik8A Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7CE@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BD@XCH-NW-10V.nw.nos.boeing.com> <4B83B8DA.5000108@ericsson.com> In-Reply-To: <4B83B8DA.5000108@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: HIP-based overlays 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, 23 Feb 2010 17:46:11 -0000 > > > I would suggest: > > > > 1) merge draft-ietf-hip-bone, draft-ietf-hip-via, and > > draft-ietf-hip-hiccups into one draft. > > The reason why these drafts are kept separate is that while > the via and > hiccups mechanisms are needed to build overlays, they are not specific > to overlays and can be used in other contexts. Therefore, from a > documentation perspective, it makes sense to have them in separate > drafts. That much said, I agree that we need to make sure readers get > the complete picture as soon as possible when they start reading the > specifications. Let's work on reorganizing the sections and adding > overview material so that the drafts explain up front what > they are about. I agree that the HIP DATA could be used in other contexts; I had another co= mment against that draft that if you decide to keep this as a separate draf= t, you could clarify some things in the beginning of the draft regarding th= e scope of the specification. Regarding the via draft, it seems to me to be much more coupled with overla= y forwarding, so I would suggest that either you describe the other non-ove= rlay use case(s) for these parameters, or else merge it with HIP BONE. Any= way, if you still feel that it is important to keep the via draft separate,= I will not raise this point again. Regards, Tom From thomas.r.henderson@boeing.com Tue Feb 23 10:10:00 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A72E3A8497 for ; Tue, 23 Feb 2010 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 op44D7ZW6Kfr for ; Tue, 23 Feb 2010 10:09:56 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 512F33A848E for ; Tue, 23 Feb 2010 10:09:56 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1NIBhGL022919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2010 10:11:43 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1NIBgiX000949; Tue, 23 Feb 2010 12:11:42 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1NIBgrY000927 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Feb 2010 12:11:42 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Tue, 23 Feb 2010 10:11:41 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Tue, 23 Feb 2010 10:11:41 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-via-00 Thread-Index: Acq0kaz4/L8Cxqh7Rpq/WuKHVBtGBgAHqfuw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D0@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BE@XCH-NW-10V.nw.nos.boeing.com> <4B83E14D.3000401@nomadiclab.com> In-Reply-To: <4B83E14D.3000401@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00 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, 23 Feb 2010 18:10:00 -0000 Hi Ari, some responses to your responses below: > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Tuesday, February 23, 2010 6:08 AM > To: Henderson, Thomas R > Cc: 'Gonzalo Camarillo'; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00 > > Hi Tom, > > Thanks for the review and comments; responses inline. > > Henderson, Thomas R wrote: > >> These two extensions enable multi-hop routing in HIP. Before these > >> extensions were specified, HIP only supported a single > >> intermediate host (i.e., a rendezvous server [RFC5204]) between the > >> source of a HIP packet and its destination. > > > > I don't see why these extensions are required to perform multi-hop > > routing in all cases. I agree that one of them is needed to provide > > multi-hop source routing, but perhaps not multi-hop > destination-based > > routing. > > Yes, you could have other ways to do that, but since this is, > AFAIK, so > far the only (to-be) standardized way to do this, I think > it's fair to > say that only single intermediary hop is currently supported. And we > don't rule out other ways to do that either. > > But perhaps we could say something like: > > Before these > extensions were specified, there were standardized ways for > supporting only a single intermediate host (e.g., a > rendezvous server > [RFC5204]) between the source of a HIP packet and its destination. OK > > >> 2.2. Definitions > >> > >> > >> Destination list: A list of HITs of the hosts that a HIP packet > >> should traverse. > >> > >> Via list: A list of HITs of the hosts that a HIP packet has > >> traversed. > >> > >> Symmetric routing: A response to a message is routed back using > >> the same set of intermediary nodes as the original message used, > >> except in reversed order. > > > > It may help to note that the terminology is borrowed from RELOAD. > > Actually, originally it wasn't, but you're right that it > ended up being > quite similar. Anyway, since this draft is not RELOAD (or > even overlay) > specific, I think having a RELOAD reference here would rather confuse > the reader than clarify the terminology. If you end up with the same terms as RELOAD but slightly different meanings= , I would recommend that you try to clarify the distinction, so that reader= s familiar with RELOAD are not confused. If they end up being the same ter= ms and definitions as in RELOAD, I don't think that it would be confusing t= o state this, but I'll leave it up to you. > > >> 3.1. Creating and Processing Via Lists > >> > >> > >> When a host sending a HIP packet needs to record the hosts that are > >> on the path that the HIP packet traverses, it includes an empty > >> ROUTE_VIA parameter to the packet. > > > > Can you clarify the means whereby a HIP host originating a packet > > knows that it needs to include a ROUTE_VIA? Especially, the > > distinction between setting the SYMMETRIC flag or not. > > It's intentional that we don't mandate when to use the VIA > parameter or > the symmetric flag; it's up to implementation, local policy, > or another > protocol taking advantage of this extension to decide that. > For example, > in the RELOAD instance spec we define the MUSTs and SHOULDs in that > context. Some other usage may have different requirements, so > we don't > want to rule out those possibilities here. > > > This is an example where I found the rules for setting these flags > > and parameters in the instance specification (section 7 of the > > instance draft). Maybe this draft should clarify that this is > > discussed in an instance specification. > > As mentioned above, instance specs are only one possible place where > this could be defined. I'll add an additional paragraph to > the beginning > of the "Protocol Definitions" section clarifying this: > > The multi-hop routing extensions may be used in different contexts > and whether a new HIP packet should, for example, include > a Via list > or have different options enabled, can depend on the > particular use > case, local policies, and different protocols using the extension. > This section defines how the new parameters are handled, > but when to > use these extensions is out of scope for this document. OK > > >> 3.3. Processing Destination Lists > >> > >> > >> When a host receives a HIP packet that contains a ROUTE_DST > >> parameter, it first looks up its own HIT from the route list. If > >> host's own HIT is not in the list and the host is not the receiver > >> of the packet, the packet was incorrectly forwarded and MUST be > >> dropped. Next hop for the packet is the HIT after host's own HIT in > >> the list. > > > > The above sentence should be expanded and clarified. Can the > > forwarding host ignore the specified next hop in any cases (i.e., is > > this a SHOULD or MUST next hop)? For instance, the host may "look > > ahead" in the destination list and find that it already has > an active > > association to a later host-- can it just use that? Another > > possibility to discuss is a situation in which the > requested next hop > > is not reachable for some reason. > > Next hops should not be ignored, so that should be a MUST. I added to > the end of the paragraph the following: > > If the host has a valid locator > for the next hop, it MUST forward the HIP packet to the next hop > host. > > (there's also new text after this paragraph about what to do > if there is > no valid locator; see the last comment) > > If you think that there are relevant use cases for the "look ahead > optimization", we could have one flag that signals whether > it's OK to do > that (and have that as a "MAY"). If I process a destination list, and I have an active HIP association to th= e destination HIT, why MUST I send it to another host on the destination li= st? It seems that MAY should be the default and MUST should be a mode of o= peration when there is a specific use case that requires that intermediate = nodes handle the packet. > > > Or, you may delegate the exact behavior to the instance > specification > > (such as you do in section 7 of hip-reload-instance), in which case > > this draft should more clearly state that forwarding behavior may be > > specified elsewhere. > > > > Perhaps the protocol needs a loose source and strict source routing > > flag of some sort, to control this behavior. > > Actually, this loose source routing flag was in one of the early > pre-release versions of the draft, but it was removed since we didn't > find really good use cases for it and it is a bit problematic with > signed ROUTE_DST list. > > The problem is that with loose source routing either the VIA > list would > need to be modified (removing the hops that are already used; > breaking > the signature) or one would need a pointer (new parameter in the > unsigned part) to the "next hop in the list" since you don't > necessarily > anymore implicitly know where in the list you're going. I'm sorry, I do not see the issue. The via list is not associated with loo= se source routing; it is just a "Record Route" option that can be turned ar= ound and made into a destination list at the receiver (if symmetric flag is= set). The destination list can be signed; it does not have to be modified regardl= ess of whether loose or strict source routing is chosen. By loose source, = I mean that any later HIT or the destination HIT can be chosen instead of t= he next HIT in the list; this would allow the packet to always make progres= s to the destination without confusion about where you are at in the list, = right? > > Moving the ROUTE_DST to the unsigned part would solve the > issue, but we > felt that protecting the list with signature is more important. Of > course we could have both signed and unsigned versions if there are > compelling use cases for the loose source routing. > > >> If the host's HIT was the last HIT in the list, the next hop is the > >> receiver's HIT in the HIP header. > > > > It seems to me that the above sentence would be clearer if it just > > stated that there is no next hop in this case. > > But there is the "next hop" from the last forwarding host to the > receiver, right? And it's actually easier to refer to "next > hop" in both > cases in the following text. Or can you propose some other > wording that > would make this clearer? I think I misread this yesterday, and am not sure it needs to be clarified;= sorry. > > >> 6.1. Forwarding Loops > >> > >> > >> A malicious host could craft a destination route list that contains > >> the same HIT more than once and thus create a forwarding loop. > >> Since the IP layer TTL is decremented on each hop, the loop will be > >> eventually broken, but hosts may additionally protect themselves > >> against this attack by checking that their own HIT is in the > >> destination list only once and drop invalid packets. > > > > I don't think that IP layer TTL can provide protection here; it is > > regenerated at every HIP hop, right? However, you do introduce an > > OVERLAY_TTL parameter elsewhere in HIP BONE; can you use that? > > Good point; I was under the impression that the IP layer TTL is > preserved by what is defined in the current RFCs, but after having a > closer look at them it turned out they don't require this. > > I would not require using the OVERLAY_TTL parameter if not really > necessary and rather make the checking-your-own HIT a MUST. Perhaps checking-your-own-HIT(s) is MUST and OVERLAY_TTL a MAY? > > >> [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > >> > > IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. > > > > Why is this a normative reference? > > Good catch. Moved it to informative. > > > Other comments: > > > > - Should there be a NOTIFY parameter for a route failure situation > > (for ROUTE_DST)? See for instance Section 5.3.3.1 of RELOAD > > That could be useful, I'll add it to the draft. Now it says > at the end > of Section 3.3: > > If the host does not have a valid locator for the next > hop host, it > SHOULD drop the packet and SHOULD send back a NOTIFY error packet > with type UNKNOWN_NEXT_HOP (value [TBD by IANA; 90]). The > Notification Data field for the error notifications SHOULD contain > the HIP header of the rejected packet and the ROUTE_DST parameter. > Should you say "host cannot determine a valid locator" instead of "host doe= s not have"? That would give more flexibility to perhaps find this locator= on demand if needed. Regards, Tom > > Cheers, > Ari > From thomas.r.henderson@boeing.com Tue Feb 23 10:20:04 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39AF28C160 for ; Tue, 23 Feb 2010 10:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkcXXj52BY8f for ; Tue, 23 Feb 2010 10:20:03 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E5F323A8182 for ; Tue, 23 Feb 2010 10:20:02 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1NIM2MY029491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2010 10:22:03 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1NIM2hR003569; Tue, 23 Feb 2010 10:22:02 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1NIM2T2003556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Feb 2010 10:22:02 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 23 Feb 2010 10:22:02 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Tue, 23 Feb 2010 10:22:01 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 Thread-Index: Acq0m8psUmMMlj7ySieabZ/YHac9pwAF/Qxw Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> In-Reply-To: <4B83F243.6070208@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 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, 23 Feb 2010 18:20:05 -0000 > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Tuesday, February 23, 2010 7:21 AM > To: Henderson, Thomas R > Cc: 'Gonzalo Camarillo'; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 > > Hi Tom, > > Once again, thanks for the comments; responses inline. > > Henderson, Thomas R wrote: > >> 2. Terminology > >> > >> > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > >> this document are to be interpreted as described in RFC 2119 > >> [RFC2119]. > > > > This section is empty; probably at the very least it should point to > > the normative references that define the terminology in use later in > > the document. > > Makes sense; added pointers to 5201, HIP BONE and RELOAD. > > >> 3. Peer Protocol > >> > >> The peer protocol to be used is RELOAD, which is specified in > >> [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the > >> RELOAD's Forwarding and Link Management Layer (described in Section > >> 5.5. of [I-D.ietf-p2psip-base]. > > > > RELOAD also has a Topology Plugin module that is responsible for > > maintaining the routing tables; from the RELOAD draft: " The > > Topology Plugin is responsible for maintaining the overlay algorithm > > Routing Table, which is consulted by the Forwarding and Link > > Management Layer before routing a message." > > > > can you define how this relates to the HIP-specific implementation? > > HIP replaces the Forwarding layer, so it consults the Topology plugin > module as the Forwarding layer would have done. > > > Does an interface exist between a HIP forwarding process and the > > topology plugin of RELOAD? > > The details about the interface (if any) between HIP and > RELOAD modules > are left up to implementations. Our goal was not to define > APIs in this > document, but such APIs can be later defined in, e.g., advanced HIP > native API document. OK, I suggest to add this clarification to the draft. > > >> 4. Peer ID Generation > >> > >> In the other Peer ID mode, namely "RELOAD", all 128 bits are > >> generated as defined in [I-D.ietf-p2psip-base] resulting in a > >> larger usable address space. > > > > If the RELOAD node IDs are not HITs (ORCHIDs), then a > mapping between > > the node id and the HITs is necessary. Section 5.6.1 of RELOAD > > suggests that certificates are to be used in this case; I expected > > that this draft would discuss the HIP certificate model for this > > binding. > > In this case the 128-bit ID would be your "HIT" so there is > no need for > mapping (and in that sense the assumptions in Section 5.6.1.1 > of RELOAD > draft are not really correct). My understanding is that there are two main modes of Node ID generation in = (non-HIP-based) RELOAD: 1) centralized 2) self-generated, self-signed When you say "In the other Peer ID mode, namely "RELOAD",..." which case do= you mean? Just the self-generated case? If it is the centralized case, t= he Node IDs can't be used as HITs, and then the Node IDs and the HITs are n= ot related to one another and need to be bound by some kind of certificate = framework. This is what I think section 5.6.1.1 of the base draft refers t= o. Or am I misunderstanding something? > > >> 5. Mapping between Protocol Primitives and HIP Messages > >> > >> ...Block are replaced with HIP header, HIP VIA lists > >> [I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID, > >> OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-bone] parameters. > > > > TRANSACTION_ID is specified in hiccups, not hip-bone. > > Good catch; fixed. > > >> 8. Enrollment and Bootstrapping > >> > >> The RELOAD HIP BONE instance uses the enrollment and bootstrap > >> procedure defined by RELOAD [I-D.ietf-p2psip-base] with the > >> exceptions listed below. > > > > It was not clear to me how initial bootstrapping occurred, > or whether > > HIP Relay/Rendezvous servers can be used in the absence of > HIP routes > > being in the node's Topology plugin table. I am assuming that upon > > first join, HIP nodes must either use the "well known public IP > > address" technique of bootstrap nodes to join, and then subsequently > > they will forward all of their HIP messages over the overlay-- is > > that correct? Does the AttachReq have a set of suggested locators > > for initial contact? > > The idea is to re-use the bootsrapping possibilities defined in the > RELOAD spec; including downloading the config file using HTTP from a > server discovered using DNS. But perhaps this would need some > clarification. I'll see what I can do. AttachReqs are not > used with the > instance spec. > > >> 9. NAT Traversal > >> > >> > >> RELOAD relies on the Forwarding and Link Management Layer providing > >> NAT traversal capabilities. Thus, the RELOAD HIP BONE instance > >> implementations MUST implement some reliable NAT traversal > >> mechanism. To maximize interoperability, all implementations SHOULD > >> implement at least [I-D.ietf-hip-nat-traversal]. > > > > RELOAD specifies that nodes MUST implement full ICE. (Section > > 5.5.1.3). Can you clarify whether that MUST should be avoided in > > this instance (i.e. how to avoid RELOAD ICE layered on top of HIP > > ICE-like NAT traversal)? > > Yes, the whole 5.5. section of RELOAD is replaced by what is > defined in > 5 of the instance spec. I'll clarify in that section that this also > includes all the ICE stuff. Now the section 5 starts with: > > RELOAD HIP BONE replaces the RELOAD protocol primitives > taking care > of connection establishment with the HIP base exchange, > where as the > rest of the RELOAD messages are conveyed within HIP messages. The > Forwarding and Link Management Layer functionality of > RELOAD defined > in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT > traversal functionality, is replaced by HIP and the extensions > defined in this document. > OK, I'll have a look at the revisions when they are published. Regards, Tom From heer@informatik.rwth-aachen.de Wed Feb 24 03:31:27 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFC83A7C40 for ; Wed, 24 Feb 2010 03:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.051 X-Spam-Level: X-Spam-Status: No, score=-5.051 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvTfMCyyW77w for ; Wed, 24 Feb 2010 03:31:25 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 552483A82DF for ; Wed, 24 Feb 2010 03:31:25 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KYC005D7G3TZ070@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 24 Feb 2010 12:33:29 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,531,1262559600"; d="scan'208";a="24845053" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 24 Feb 2010 12:33:29 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KYC00H7NG3TJH40@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 24 Feb 2010 12:33:29 +0100 (CET) From: Tobias Heer In-reply-to: Date: Wed, 24 Feb 2010 12:33:30 +0100 Message-id: <461A6C4B-08E3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> To: "hipsec@ietf.org WG" X-Mailer: Apple Mail (2.1077) Cc: Julien Laganier Subject: Re: [Hipsec] ORCHID IANA allocation (was: 28 + 4 + 96 bit HIT crypto 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: Wed, 24 Feb 2010 11:31:27 -0000 Hello Julien, Tom, and everyone else on the list, since the HIH/HIT/ORCHID discussion died, I'd like to revive it to come to a conclusion. I'll sum up some of the previous mails to make the information a bit more accessible. Laganier, Julien wrote: > Hello Tom, > > Henderson, Thomas R wrote: >> [...] >> >> By the way, can someone who was involved in the ORCHID deliberations >> chime in about the process for renewing the /28, and what are the >> issues to make this a permanent allocation? > [...] > Since we're now discussing a HIT/ORCHID design that differs from the one originally documented in RFC 4843, updating RFC 4843 could 1) update the ORCHID design with hash agility, and 2) establish IETF consensus for a never ending ORCHID assignment in the relevant IANA registry. I am still in favor of changing the ORCHID format to support hash agility instead of transmitting auxiliary information in the HIP headers or HIP parameters. Advantages are: a) You'll never get a HIT for which you can't tell which algorithm was used (even if the auxiliary information is missing). This makes it more usable for referrals and legacy applications (also for non-legacy applications that still use the (legacy) socket interface) because these can continue to handle HITs like IPv6 addresses without special treatment. b) It's far less complex than having an additional parameter in HIP for which you need rules when to transmit it (packet types) and where to put it (parameter number). c) It's slightly more space efficient than having another field in the HIP header since there isn't terribly much space left in the header. Just adding 4 or 8 bits to the header would screw the alignment. Hence, even more bits would be needed as padding. There are 3 reserved bits but I guess one should try to keep them for future use - I think right now we are agile enough to actually make changes that break compatibility with older versions. The main disadvantages are: a) We'd have to change the way ORCHIDs are created because RFC 4843 is quite strict on the procedure. b) We'd sacrifice some bits and would weaken the HIT against attacks. Disadvantage b) can be mitigated by using a hash extension mechanism similar to the one in CGA (artificially making HIT generation more CPU intensive). RFC 4843 explicitly states that such mechanism should be considered for future versions of the ORCHID, so I guess there is no fundamental problem here. The only issue might be the IPR questions that were open at the time RFC 4843 was written (it was published in April 2007). I don't have any insight into this but I can investigate if people feel that this is the way to go. I would like to ask for the opinion of the group regarding the redefinition/extension of the way ORCHIDS are created. Should this be done or should we try to live with one of the workarounds in order to add crypto agility to the HIT. What would be the right procedure to get this going? Write a draft? If yes: who should/would do it? BR, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From gonzalo.camarillo@ericsson.com Wed Feb 24 05:46:00 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49A928C124 for ; Wed, 24 Feb 2010 05:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAv-xvO0luzv for ; Wed, 24 Feb 2010 05:46:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EECAB28C10D for ; Wed, 24 Feb 2010 05:45:59 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-ee-4b852e150714 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 5E.62.01038.51E258B4; Wed, 24 Feb 2010 14:48:05 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 14:48:04 +0100 Received: from [131.160.126.196] ([131.160.126.196]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 14:48:05 +0100 Message-ID: <4B852E14.9080809@ericsson.com> Date: Wed, 24 Feb 2010 15:48:04 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BD@XCH-NW-10V.nw.nos.boeing.com> <4B83B8DA.5000108@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7CE@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7CE@XCH-NW-10V.nw.nos.boeing.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2010 13:48:05.0252 (UTC) FILETIME=[FD744C40:01CAB557] X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: HIP-based overlays 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, 24 Feb 2010 13:46:01 -0000 Hi Tom, > I agree that the HIP DATA could be used in other contexts; I had > another comment against that draft that if you decide to keep this as > a separate draft, you could clarify some things in the beginning of > the draft regarding the scope of the specification. sure, that will needs to be clarified in that draft. > Regarding the via draft, it seems to me to be much more coupled with > overlay forwarding, so I would suggest that either you describe the > other non-overlay use case(s) for these parameters, or else merge it > with HIP BONE. Anyway, if you still feel that it is important to > keep the via draft separate, I will not raise this point again. Ari will take care of describing the non-overlay case in the Via draft. Thanks, Gonzalo From mkomu@cs.hut.fi Wed Feb 24 04:27:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45D83A83A7 for ; Wed, 24 Feb 2010 04:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOv0QI6Xn9eU for ; Wed, 24 Feb 2010 04:27:34 -0800 (PST) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id B60B33A8489 for ; Wed, 24 Feb 2010 04:27:34 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1NkGN0-0006Nd-0l; Wed, 24 Feb 2010 14:29:38 +0200 Message-ID: <4B851BB1.7060502@cs.hut.fi> Date: Wed, 24 Feb 2010 14:29:37 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: Thomas Henderson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 24 Feb 2010 07:08:33 -0800 Cc: hip WG Subject: [Hipsec] RFC5206 and LOCATOR parameter 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, 24 Feb 2010 12:30:59 -0000 Hi Tom, there was some discussion about the nat-mm draft which brought another somewhat related thought into my mind. Tom, Have you thought about fixing the format or position the locators in RFC5206? The fact that we now have three different types of locators makes things unnecessarily complicated. IMHO we could just settle to type 2 locators which are the superset of the other locators. The position of the LOCATORs varies at the Responder. RFC5206 place it R1 whereas the NAT traversal extension places it in R2. While both of the positions can be argumented, they introduce complexity for the implementation. I would suggest simplifying this and just place the LOCATOR parameter always to R2. This would exclude the "load balancing" feature achieved by the LOCATOR parameter in the R1 packet, but this is nothing that couldn't already be achieved with DNS-based schemes. From miika.komu@hiit.fi Wed Feb 24 07:30:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95D13A851A for ; Wed, 24 Feb 2010 07:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1eWRKzJOy6g for ; Wed, 24 Feb 2010 07:30:48 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 04D523A8514 for ; Wed, 24 Feb 2010 07:30:48 -0800 (PST) Received: from [192.168.0.2] (cs27089185.pp.htv.fi [89.27.89.185]) by argo.otaverkko.fi (Postfix) with ESMTP id 4F96B25ED13 for ; Wed, 24 Feb 2010 17:32:54 +0200 (EET) Message-ID: <4B8546B5.3010708@hiit.fi> Date: Wed, 24 Feb 2010 17:33:09 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: hipsec@ietf.org References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> <461A6C4B-08E3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de> In-Reply-To: <461A6C4B-08E3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] ORCHID IANA allocation 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: Wed, 24 Feb 2010 15:30:50 -0000 On 24/02/10 13:33, Tobias Heer wrote: Hi, > I would like to ask for the opinion of the group regarding the > redefinition/extension of the way ORCHIDS are created. Should this be > done or should we try to live with one of the workarounds in order to > add crypto agility to the HIT. I am still in favor of some extra bits for the algorithm. Let's do it right and no workarounds please. > What would be the right procedure to get this going? Write a draft? > If yes: who should/would do it? Shouldn't this go to RFC5201-bis? From julienl@qualcomm.com Wed Feb 24 08:46:06 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F2A28C1D0 for ; Wed, 24 Feb 2010 08:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.662 X-Spam-Level: X-Spam-Status: No, score=-106.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwtXE8SjRotv for ; Wed, 24 Feb 2010 08:46:05 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 998B028C16F for ; Wed, 24 Feb 2010 08:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1267030093; x=1298566093; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"miika.komu@hiit.fi"=20,=0D=0A =20=20=20=20=20=20=20=20"hipsec@ietf.org"=0D=0A=09|Date:=20Wed,=2024=20Feb=202010=2008:34:32=20-0 800|Subject:=20RE:=20[Hipsec]=20ORCHID=20IANA=20allocatio n|Thread-Topic:=20[Hipsec]=20ORCHID=20IANA=20allocation |Thread-Index:=20Acq1ZtKeSiHr7IV4SzOK42lzkJ8faQABauLQ |Message-ID:=20|References:=20<00E85481-57 45-4093-B165-887058ED719B@cs.rwth-aachen.de>=0D=0A=09<7CC 566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos .boeing.com>=0D=0A=09=0D=0A=09<461A6C4B-08 E3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de>=0D=0A=20<4B8 546B5.3010708@hiit.fi>|In-Reply-To:=20<4B8546B5.3010708@h iit.fi>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=EzYBECA7ka6LOngA+0cQ9GNJV2g79rY1aHgrYLs6AKA=; b=T3I4gRSdUjaXivaEX6tWGwMXMsvYePIZeFaj/t09nZjiz5BlM4iKQLFB BiSQErfRvOr0v0Ka6BZc3jWDf+sVlk+Jl1C68f6nvdGBFIKQ7zYoOSAAO c7KgI32v37ePfNLTwwhvhRjdfpxAHvmAbBNV0+RPWteVOJt7kuJU9WdUw U=; X-IronPort-AV: E=McAfee;i="5400,1158,5902"; a="34829773" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Feb 2010 08:48:12 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o1OGmCjR028577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Feb 2010 08:48:12 -0800 X-IronPort-AV: E=Sophos;i="4.49,532,1262592000"; d="scan'208";a="46580688" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 Feb 2010 08:34:35 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 24 Feb 2010 08:34:34 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 24 Feb 2010 08:34:34 -0800 From: "Laganier, Julien" To: "miika.komu@hiit.fi" , "hipsec@ietf.org" Date: Wed, 24 Feb 2010 08:34:32 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation Thread-Index: Acq1ZtKeSiHr7IV4SzOK42lzkJ8faQABauLQ Message-ID: References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <7CC566635CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com> <461A6C4B-08E3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de> <4B8546B5.3010708@hiit.fi> In-Reply-To: <4B8546B5.3010708@hiit.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] ORCHID IANA allocation 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, 24 Feb 2010 16:46:06 -0000 Miika Komu wrote: >=20 > On 24/02/10 13:33, Tobias Heer wrote: >=20 > Hi, >=20 > > I would like to ask for the opinion of the group regarding the > > redefinition/extension of the way ORCHIDS are created. Should this be > > done or should we try to live with one of the workarounds in order to > > add crypto agility to the HIT. >=20 > I am still in favor of some extra bits for the algorithm. Let's do it > right and no workarounds please. I concur. I am not very concerned about incompatibilities outlined by Tobias: we can = let the current temporary prefix allocation for ORCHID expire (in 2014) and= request permanent allocation of another prefix for ORCHIDv2. That should b= e enough to handle the transition period. > > What would be the right procedure to get this going? Write a draft? > > If yes: who should/would do it? >=20 > Shouldn't this go to RFC5201-bis? Hmm... During the discussion that led to the allocation of a special purpose IPv6 = prefix for ORCHIDs, a major concern was that this could open the pandora bo= x of having every organization request an IPv6 prefix to number their favor= ite things, e.g., cellular phones, vehicles, . One of the reason we were successful in getting an IPv6 prefix special allo= cation for ORCHIDs is because ORCHIDs are generic IPv6-adddress-formatted c= ryptographic identifier, and not just HITs, specific to one protocol, HIP. So I think we should stick to that as it has worked well for us in the past= , and thus keep ORCHID definition in a standalone document. Revising 4843 l= ooks reasonably easy. I can work on an update if we can agree on a high lev= el design. Would there be consensus to update ORCHIDs to v2 as follows: - ORCHIDv2 structured as 28 + 4 + 96 bits - 28 bits are new prefix for ORCHIDv2 - 4 bits encodes hash - 96 bits are hashed string Note that CGA's hash extension techniques (with Sec parameter) have been up= dated with some hash agility support in [RFC4982]; do we want to do somethi= ng similar? Or do we want to use standalone hash extension in the 96 bits, = as in the original CGA design [RFC3972]? --julien [RFC3972] tools.ietf.org/html/rfc3972 [RFC4982] tools.ietf.org/html/rfc4982 From thomas.r.henderson@boeing.com Wed Feb 24 10:55:14 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6908D28C285 for ; Wed, 24 Feb 2010 10:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 6z+OncO4vzkp for ; Wed, 24 Feb 2010 10:55:13 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7D7AD28C279 for ; Wed, 24 Feb 2010 10:55:13 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1OIv3qF017993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2010 10:57:03 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1OIv3xd029170; Wed, 24 Feb 2010 12:57:03 -0600 (CST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1OIv2MC029071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 24 Feb 2010 12:57:02 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 24 Feb 2010 10:57:02 -0800 From: "Henderson, Thomas R" To: "'Laganier, Julien'" , "miika.komu@hiit.fi" , "hipsec@ietf.org" Date: Wed, 24 Feb 2010 10:57:01 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation Thread-Index: Acq1ZtKeSiHr7IV4SzOK42lzkJ8faQABauLQAAMro8A= Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de><7CC5666 35CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com><461A6C4B-08E 3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de><4B8546B5.3010708@hiit.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-6.000.1038-17212.005 x-tm-as-result: No--38.908000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] ORCHID IANA allocation 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, 24 Feb 2010 18:55:14 -0000 > > > > I am still in favor of some extra bits for the algorithm. > Let's do it > > right and no workarounds please. > > I concur. +1 > > Would there be consensus to update ORCHIDs to v2 as follows: > > - ORCHIDv2 structured as 28 + 4 + 96 bits > - 28 bits are new prefix for ORCHIDv2 > - 4 bits encodes hash > - 96 bits are hashed string > > Note that CGA's hash extension techniques (with Sec > parameter) have been updated with some hash agility support > in [RFC4982]; do we want to do something similar? Or do we > want to use standalone hash extension in the 96 bits, as in > the original CGA design [RFC3972]? > I support the above. Regarding your question, I would recommend that we sa= y for now that "4 bits encodes the hash string generation algorithm" becaus= e it may not simply be a hash algorithm but something like hash extension o= f CGA. Note that if we make ORCHIDs generic, the 4 bits must be shared among all t= he possible users in the future. I don't think it is a big concern because= the current use outside of HIP seems to be limited. It would be nice to discuss and then state in one of the drafts (4843-bis, = 4423-bis, or 5201-bis) what the consensus or options are for the following: - future allocations of new ORCHID prefixes? Are there any conditions that= would lead to asking for additional ORCHID prefixes, or do we expect only = one such prefix? - what happens if the four bits runs out (do we deprecate old values such a= s in RFC4982?) - some discussion of the relationship between HITs, LSIs, ORCHIDs, and othe= r quantities. ** future extension of HIT size (256 bits has been raised in the past)-- = is this possible or are we closing the door on such a future extension?. M= ore generally, does HIP allow for HITs that are not ORCHIDs? (e.g. the old= type-2 HITs, or more recent proposals for hierarchical HITs) Do we use th= e bits in the HIP control field to identify HIT type? ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari have f= loated this idea in the past) ** LSI prefix for IPv4 (recall we discussed a /16 in the 127/8 space-- d= o we also want to resolve this issue while we are resolving ORCHIDs?) ** are LSIs possible for IPv6? When would they be used instead of ORCHID= s? Tom From jeffrey.m.ahrenholz@boeing.com Wed Feb 24 14:21:53 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E4C3A84A2 for ; Wed, 24 Feb 2010 14:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq0b-teeE7YU for ; Wed, 24 Feb 2010 14:21:52 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B8D1F3A85E2 for ; Wed, 24 Feb 2010 14:21:52 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1OMNfnc019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2010 16:23:46 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1OMNf9C000632; Wed, 24 Feb 2010 14:23:41 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1OMNf0L000629 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 24 Feb 2010 14:23:41 -0800 (PST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 24 Feb 2010 14:23:41 -0800 From: "Ahrenholz, Jeffrey M" To: Miika Komu , "Henderson, Thomas R" Date: Wed, 24 Feb 2010 14:23:40 -0800 Thread-Topic: [Hipsec] RFC5206 and LOCATOR parameter Thread-Index: Acq1Y5vYl6DvXUvKRda6Qq9qPBwlMQAO609g Message-ID: References: <4B851BB1.7060502@cs.hut.fi> In-Reply-To: <4B851BB1.7060502@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hip WG Subject: Re: [Hipsec] RFC5206 and LOCATOR parameter 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, 24 Feb 2010 22:21:53 -0000 > The position of the LOCATORs varies at the Responder. RFC5206 > place it R1 whereas the NAT traversal extension places it in R2. > While both of > the positions can be argumented, they introduce complexity for the > implementation. I would suggest simplifying this and just place the > LOCATOR parameter always to R2. This would exclude the "load > balancing" > feature achieved by the LOCATOR parameter in the R1 packet, > but this is > nothing that couldn't already be achieved with DNS-based schemes. I'd agree with this... one of the complexities that I dislike about placing= LOCATORs in the R1 is that every time your locator set changes (if includi= ng all addresses) or every time your preferred locator changes, you need to= invalidate your entire R1 cache and recompute it. This would occur at a ti= me when you are already (possibly) busy generating and processing UPDATEs f= or the locator change. -Jeff From jeffrey.m.ahrenholz@boeing.com Wed Feb 24 14:21:57 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A172C28C16B for ; Wed, 24 Feb 2010 14:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5NPjP+OekaE for ; Wed, 24 Feb 2010 14:21:56 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id C3F3D28C0FF for ; Wed, 24 Feb 2010 14:21:56 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1OMNowT017845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2010 14:23:51 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1OMNo3H005884; Wed, 24 Feb 2010 14:23:50 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1OMNome005865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 24 Feb 2010 14:23:50 -0800 (PST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 24 Feb 2010 14:23:50 -0800 From: "Ahrenholz, Jeffrey M" To: "Henderson, Thomas R" , "'Laganier, Julien'" , "miika.komu@hiit.fi" , "hipsec@ietf.org" Date: Wed, 24 Feb 2010 14:23:48 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation Thread-Index: Acq1ZtKeSiHr7IV4SzOK42lzkJ8faQABauLQAAMro8AACVIC4A== Message-ID: References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de><7CC5666 35CFE364D87DC5803D4712A6C4C1F48A6D9@XCH-NW-10V.nw.nos.boeing.com><461A6C4B-08E 3-4D77-8292-BD4CCC7A375B@cs.rwth-aachen.de><4B8546B5.3010708@hiit.fi> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] ORCHID IANA allocation 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, 24 Feb 2010 22:21:57 -0000 > > > I am still in favor of some extra bits for the algorithm. > > Let's do it > > > right and no workarounds please. > > > > I concur. > > +1 +1 here too. The HIT with algorithm bits will make life much easier. -Jeff From thomas.r.henderson@boeing.com Wed Feb 24 21:06:05 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE0B28C253 for ; Wed, 24 Feb 2010 21:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 F+F6vo-z+cuu for ; Wed, 24 Feb 2010 21:06:04 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4A13D3A6A19 for ; Wed, 24 Feb 2010 21:06:04 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1P57p0J024356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2010 23:07:56 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1P57pwD017562; Wed, 24 Feb 2010 23:07:51 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1P57oB3017557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 24 Feb 2010 23:07:51 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 24 Feb 2010 21:07:51 -0800 From: "Henderson, Thomas R" To: "'Miika Komu'" Date: Wed, 24 Feb 2010 21:07:50 -0800 Thread-Topic: RFC5206 and LOCATOR parameter Thread-Index: Acq1TQq3S5YBrW+dQMSuUlnveIlDOAAiaXog Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FB@XCH-NW-10V.nw.nos.boeing.com> References: <4B851BB1.7060502@cs.hut.fi> In-Reply-To: <4B851BB1.7060502@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hip WG Subject: Re: [Hipsec] RFC5206 and LOCATOR parameter X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 05:06:05 -0000 > -----Original Message----- > From: Miika Komu [mailto:mkomu@cs.hut.fi] > Sent: Wednesday, February 24, 2010 4:30 AM > To: Henderson, Thomas R > Cc: hip WG > Subject: RFC5206 and LOCATOR parameter > > Hi Tom, > > there was some discussion about the nat-mm draft which > brought another > somewhat related thought into my mind. Tom, Have you thought about > fixing the format or position the locators in RFC5206? No, not yet. I thought that RFC5206bis had to at least account for the R2 = locators, but wasn't thinking about reducing the other use cases. > > The fact that we now have three different types of locators > makes things > unnecessarily complicated. IMHO we could just settle to type > 2 locators > which are the superset of the other locators. Are you asking about having only one type code and parameter format, or one= parameter format, with different type codes possible (the types can govern= whether certain fields are valid)? > > The position of the LOCATORs varies at the Responder. RFC5206 > place it > R1 whereas the NAT traversal extension places it in R2. While both of > the positions can be argumented, they introduce complexity for the > implementation. I would suggest simplifying this and just place the > LOCATOR parameter always to R2. This would exclude the "load > balancing" > feature achieved by the LOCATOR parameter in the R1 packet, > but this is > nothing that couldn't already be achieved with DNS-based schemes. > I am not sure yet; we should probably study some use cases to decide. Many= hosts can't control their DNS records (if present) as you suggest. - Tom From mkomu@cs.hut.fi Wed Feb 24 23:03:24 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6398A3A8439 for ; Wed, 24 Feb 2010 23:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdZgI+XjX9kL for ; Wed, 24 Feb 2010 23:03:23 -0800 (PST) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 75AE03A7FE0 for ; Wed, 24 Feb 2010 23:03:23 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1NkXmr-0005sM-Jb; Thu, 25 Feb 2010 09:05:29 +0200 Message-ID: <4B86214D.8010500@cs.hut.fi> Date: Thu, 25 Feb 2010 09:05:49 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B851BB1.7060502@cs.hut.fi> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FB@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FB@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] RFC5206 and LOCATOR parameter X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 07:03:24 -0000 On 25/02/10 07:07, Henderson, Thomas R wrote: Hi, >> The fact that we now have three different types of locators makes >> things unnecessarily complicated. IMHO we could just settle to >> type 2 locators which are the superset of the other locators. > > Are you asking about having only one type code and parameter format, > or one parameter format, with different type codes possible (the > types can govern whether certain fields are valid)? I was asking to invalidate type 0 and type 1 locators and start using type 2 locators so that locator size would be fixed, at least for the time being. We could use zeroed fields e.g. when a host does not want UDP encapsulation. From miika.komu@hiit.fi Wed Feb 24 23:10:26 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEA73A80B2 for ; Wed, 24 Feb 2010 23:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C8P3nuplwCt for ; Wed, 24 Feb 2010 23:10:20 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 0E6653A852A for ; Wed, 24 Feb 2010 23:10:16 -0800 (PST) Received: from [192.168.0.2] (cs27089185.pp.htv.fi [89.27.89.185]) by argo.otaverkko.fi (Postfix) with ESMTP id 058EB25ED06 for ; Thu, 25 Feb 2010 09:12:24 +0200 (EET) Message-ID: <4B8622EC.3050702@hiit.fi> Date: Thu, 25 Feb 2010 09:12:44 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: hipsec@ietf.org References: <4B851BB1.7060502@cs.hut.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] RFC5206 and LOCATOR parameter 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: Thu, 25 Feb 2010 07:10:26 -0000 On 25/02/10 00:23, Ahrenholz, Jeffrey M wrote: Hi, >> The position of the LOCATORs varies at the Responder. RFC5206 place >> it R1 whereas the NAT traversal extension places it in R2. While >> both of the positions can be argumented, they introduce complexity >> for the implementation. I would suggest simplifying this and just >> place the LOCATOR parameter always to R2. This would exclude the >> "load balancing" feature achieved by the LOCATOR parameter in the >> R1 packet, but this is nothing that couldn't already be achieved >> with DNS-based schemes. > > I'd agree with this... one of the complexities that I dislike about > placing LOCATORs in the R1 is that every time your locator set > changes (if including all addresses) or every time your preferred > locator changes, you need to invalidate your entire R1 cache and > recompute it. This would occur at a time when you are already > (possibly) busy generating and processing UPDATEs for the locator > change. we had to implement this "workaround" as well. From ari.keranen@nomadiclab.com Thu Feb 25 04:10:19 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B6628C11F for ; Thu, 25 Feb 2010 04:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLHZNdxP6a96 for ; Thu, 25 Feb 2010 04:10:18 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 2E54028C0F9 for ; Thu, 25 Feb 2010 04:10:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B1FD54E6CD; Thu, 25 Feb 2010 14:12:21 +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 NaF059Y0mMQ8; Thu, 25 Feb 2010 14:12:21 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0AC6B4E67D; Thu, 25 Feb 2010 14:12:21 +0200 (EET) Message-ID: <4B866924.6010507@nomadiclab.com> Date: Thu, 25 Feb 2010 14:12:20 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7BE@XCH-NW-10V.nw.nos.boeing.com> <4B83E14D.3000401@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D0@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D0@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 12:10:19 -0000 Hi Tom, Responses to remaining open issues below. Henderson, Thomas R wrote: >> -----Original Message----- From: Ari Keranen >> Henderson, Thomas R wrote: >>>> 3.3. Processing Destination Lists >>>> >>>> >>>> When a host receives a HIP packet that contains a ROUTE_DST >>>> parameter, it first looks up its own HIT from the route list. >>>> If host's own HIT is not in the list and the host is not the >>>> receiver of the packet, the packet was incorrectly forwarded >>>> and MUST be dropped. Next hop for the packet is the HIT after >>>> host's own HIT in the list. >>> The above sentence should be expanded and clarified. Can the >>> forwarding host ignore the specified next hop in any cases (i.e., >>> is this a SHOULD or MUST next hop)? For instance, the host may >>> "look ahead" in the destination list and find that it already has >>> >> an active >>> association to a later host-- can it just use that? Another >>> possibility to discuss is a situation in which the >> requested next hop >>> is not reachable for some reason. >> Next hops should not be ignored, so that should be a MUST. I added >> to the end of the paragraph the following: >> >> If the host has a valid locator for the next hop, it MUST forward >> the HIP packet to the next hop host. >> >> (there's also new text after this paragraph about what to do if >> there is no valid locator; see the last comment) >> >> If you think that there are relevant use cases for the "look ahead >> optimization", we could have one flag that signals whether it's OK >> to do that (and have that as a "MAY"). > > If I process a destination list, and I have an active HIP association > to the destination HIT, why MUST I send it to another host on the > destination list? It seems that MAY should be the default and MUST > should be a mode of operation when there is a specific use case that > requires that intermediate nodes handle the packet. One reason for requiring the message pass all hosts in the list is that you could want to keep some HIP host(s) informed about all the signaling that is happening between the two hosts (similar to what you can accomplish with preloaded route header in SIP). In that case one should not skip any of the hosts even if it would be possible. But this kind of "loose source routing" option does make sense and would be easy to implement, so I'll add a flag for it ("MUST_FOLLOW" that says one MUST NOT skip any hosts on path). >>> Or, you may delegate the exact behavior to the instance >> specification >>> (such as you do in section 7 of hip-reload-instance), in which >>> case this draft should more clearly state that forwarding >>> behavior may be specified elsewhere. >>> >>> Perhaps the protocol needs a loose source and strict source >>> routing flag of some sort, to control this behavior. >> Actually, this loose source routing flag was in one of the early >> pre-release versions of the draft, but it was removed since we >> didn't find really good use cases for it and it is a bit >> problematic with signed ROUTE_DST list. >> >> The problem is that with loose source routing either the VIA list >> would need to be modified (removing the hops that are already used; >> breaking the signature) or one would need a pointer (new parameter >> in the unsigned part) to the "next hop in the list" since you don't >> necessarily anymore implicitly know where in the list you're >> going. > > I'm sorry, I do not see the issue. The via list is not associated > with loose source routing; it is just a "Record Route" option that > can be turned around and made into a destination list at the receiver > (if symmetric flag is set). Sorry, I meant ROUTE_DST list. > The destination list can be signed; it does not have to be modified > regardless of whether loose or strict source routing is chosen. By > loose source, I mean that any later HIT or the destination HIT can be > chosen instead of the next HIT in the list; this would allow the > packet to always make progress to the destination without confusion > about where you are at in the list, right? OK, I was talking about different kind of loose source routing where there could be HIP hosts in between which are not part of the list. The kind of LSR you propose sounds reasonable and I added the MUST_FOLLOW flag for this. >>>> 6.1. Forwarding Loops >>>> >>>> >>>> A malicious host could craft a destination route list that >>>> contains the same HIT more than once and thus create a >>>> forwarding loop. Since the IP layer TTL is decremented on each >>>> hop, the loop will be eventually broken, but hosts may >>>> additionally protect themselves against this attack by checking >>>> that their own HIT is in the destination list only once and >>>> drop invalid packets. >>> I don't think that IP layer TTL can provide protection here; it >>> is regenerated at every HIP hop, right? However, you do >>> introduce an OVERLAY_TTL parameter elsewhere in HIP BONE; can you >>> use that? >> Good point; I was under the impression that the IP layer TTL is >> preserved by what is defined in the current RFCs, but after having >> a closer look at them it turned out they don't require this. >> >> I would not require using the OVERLAY_TTL parameter if not really >> necessary and rather make the checking-your-own HIT a MUST. > > Perhaps checking-your-own-HIT(s) is MUST and OVERLAY_TTL a MAY? Yeah, makes sense. But for this to work, the OVERLAY_TTL must be made critical; and this in turn requires that the parameter is removed before forwarding a HIP packet from an overlay to a host that does not understand the parameter (in case you have a "gateway host" to/from the overlay). I made increase the OVERLAY_TTL parameter's type value by one and added the following text to HIP-BONE draft: Type [ TBD by IANA; 64011 ] [...] The type of the OVERLAY_TTL parameter is critical (as defined in Section 5.2.1 of [RFC5201]) and therefore the final recipient of the packet, and all HIP hosts on the path, MUST support it. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient. >>> Other comments: >>> >>> - Should there be a NOTIFY parameter for a route failure >>> situation (for ROUTE_DST)? See for instance Section 5.3.3.1 of >>> RELOAD >> That could be useful, I'll add it to the draft. Now it says at the >> end of Section 3.3: >> >> If the host does not have a valid locator for the next hop host, it >> SHOULD drop the packet and SHOULD send back a NOTIFY error packet >> with type UNKNOWN_NEXT_HOP (value [TBD by IANA; 90]). The >> Notification Data field for the error notifications SHOULD contain >> the HIP header of the rejected packet and the ROUTE_DST parameter. >> > > Should you say "host cannot determine a valid locator" instead of > "host does not have"? That would give more flexibility to perhaps > find this locator on demand if needed. Makes sense; fixed this too. Cheers, Ari From ari.keranen@nomadiclab.com Thu Feb 25 06:29:09 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCD828C333 for ; Thu, 25 Feb 2010 06:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiknSh3d5UMj for ; Thu, 25 Feb 2010 06:29:08 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4D51B28C141 for ; Thu, 25 Feb 2010 06:29:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8A3ED4E6CD; Thu, 25 Feb 2010 16:31:13 +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 CdyxuZNpnVO2; Thu, 25 Feb 2010 16:31:12 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id EAF5A4E67D; Thu, 25 Feb 2010 16:31:12 +0200 (EET) Message-ID: <4B8689B0.50704@nomadiclab.com> Date: Thu, 25 Feb 2010 16:31:12 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 14:29:09 -0000 Henderson, Thomas R wrote: >> -----Original Message----- From: Ari Keranen >> [mailto:ari.keranen@nomadiclab.com] >>>> 3. Peer Protocol >>>> >>>> The peer protocol to be used is RELOAD, which is specified in >>>> [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces >>>> the RELOAD's Forwarding and Link Management Layer (described in >>>> Section 5.5. of [I-D.ietf-p2psip-base]. >>> RELOAD also has a Topology Plugin module that is responsible for >>> maintaining the routing tables; from the RELOAD draft: " The >>> Topology Plugin is responsible for maintaining the overlay >>> algorithm Routing Table, which is consulted by the Forwarding and >>> Link Management Layer before routing a message." >>> >>> can you define how this relates to the HIP-specific >>> implementation? >> HIP replaces the Forwarding layer, so it consults the Topology >> plugin module as the Forwarding layer would have done. >> >>> Does an interface exist between a HIP forwarding process and the >>> topology plugin of RELOAD? >> The details about the interface (if any) between HIP and RELOAD >> modules are left up to implementations. Our goal was not to define >> APIs in this document, but such APIs can be later defined in, e.g., >> advanced HIP native API document. > > OK, I suggest to add this clarification to the draft. OK. I thought that would be implicitly clear. But I can add the following to the end of the intro section: [...] The details on how different RELOAD modules would be integrated to a HIP implementation and what kind of APIs are used between them are left as implementation details or to be defined by other documents. >>>> 4. Peer ID Generation >>>> >>>> In the other Peer ID mode, namely "RELOAD", all 128 bits are >>>> generated as defined in [I-D.ietf-p2psip-base] resulting in a >>>> larger usable address space. >>> If the RELOAD node IDs are not HITs (ORCHIDs), then a >> mapping between >>> the node id and the HITs is necessary. Section 5.6.1 of RELOAD >>> suggests that certificates are to be used in this case; I >>> expected that this draft would discuss the HIP certificate model >>> for this binding. >> In this case the 128-bit ID would be your "HIT" so there is no need >> for mapping (and in that sense the assumptions in Section 5.6.1.1 >> of RELOAD draft are not really correct). > > My understanding is that there are two main modes of Node ID > generation in (non-HIP-based) RELOAD: 1) centralized 2) > self-generated, self-signed > > When you say "In the other Peer ID mode, namely "RELOAD",..." which > case do you mean? Just the self-generated case? If it is the > centralized case, the Node IDs can't be used as HITs, and then the > Node IDs and the HITs are not related to one another and need to be > bound by some kind of certificate framework. This is what I think > section 5.6.1.1 of the base draft refers to. Or am I > misunderstanding something? We mean both cases. I'm sorry but I don't follow why couldn't the non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA lists and certificates) in the centralized case? The CERT parameter used to prove that a host can use certain Node ID contains the hosts real HIT (i.e., hash of the host ID) which binds the Host ID to the Node ID. But I guess this needs some further clarification in the draft; I'll add some text about this. >>>> 8. Enrollment and Bootstrapping >>>> >>>> The RELOAD HIP BONE instance uses the enrollment and bootstrap >>>> procedure defined by RELOAD [I-D.ietf-p2psip-base] with the >>>> exceptions listed below. >>> It was not clear to me how initial bootstrapping occurred, >> or whether >>> HIP Relay/Rendezvous servers can be used in the absence of >> HIP routes >>> being in the node's Topology plugin table. I am assuming that >>> upon first join, HIP nodes must either use the "well known public >>> IP address" technique of bootstrap nodes to join, and then >>> subsequently they will forward all of their HIP messages over the >>> overlay-- is that correct? Does the AttachReq have a set of >>> suggested locators for initial contact? >> The idea is to re-use the bootsrapping possibilities defined in the >> RELOAD spec; including downloading the config file using HTTP from >> a server discovered using DNS. But perhaps this would need some >> clarification. I'll see what I can do. AttachReqs are not used with >> the instance spec. >> >>>> 9. NAT Traversal >>>> >>>> >>>> RELOAD relies on the Forwarding and Link Management Layer >>>> providing NAT traversal capabilities. Thus, the RELOAD HIP >>>> BONE instance implementations MUST implement some reliable NAT >>>> traversal mechanism. To maximize interoperability, all >>>> implementations SHOULD implement at least >>>> [I-D.ietf-hip-nat-traversal]. >>> RELOAD specifies that nodes MUST implement full ICE. (Section >>> 5.5.1.3). Can you clarify whether that MUST should be avoided in >>> this instance (i.e. how to avoid RELOAD ICE layered on top of >>> HIP ICE-like NAT traversal)? >> Yes, the whole 5.5. section of RELOAD is replaced by what is >> defined in 5 of the instance spec. I'll clarify in that section >> that this also includes all the ICE stuff. Now the section 5 starts >> with: >> >> RELOAD HIP BONE replaces the RELOAD protocol primitives taking care >> of connection establishment with the HIP base exchange, where as >> the rest of the RELOAD messages are conveyed within HIP messages. >> The Forwarding and Link Management Layer functionality of RELOAD >> defined in Section 5.5. of [I-D.ietf-p2psip-base], including all >> the NAT traversal functionality, is replaced by HIP and the >> extensions defined in this document. >> > > OK, I'll have a look at the revisions when they are published. > OK, thanks. We'll make a new revision before the cut-off date. Cheers, Ari From thomas.r.henderson@boeing.com Thu Feb 25 08:46:18 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE6928C36A for ; Thu, 25 Feb 2010 08:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 xm9t2MlNJjgH for ; Thu, 25 Feb 2010 08:46:17 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 23D683A7EA2 for ; Thu, 25 Feb 2010 08:46:17 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1PGmH70013512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2010 08:48:17 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1PGmGdB015286; Thu, 25 Feb 2010 10:48:16 -0600 (CST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1PGmGXj015238 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 25 Feb 2010 10:48:16 -0600 (CST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 25 Feb 2010 08:48:16 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Thu, 25 Feb 2010 08:48:16 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 Thread-Index: Acq2JzLhh6/Txc2jQwOtpqdKeIgPsQADz5wg Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FF@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> <4B8689B0.50704@nomadiclab.com> In-Reply-To: <4B8689B0.50704@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 16:46:18 -0000 > > > > When you say "In the other Peer ID mode, namely "RELOAD",..." which > > case do you mean? Just the self-generated case? If it is the > > centralized case, the Node IDs can't be used as HITs, and then the > > Node IDs and the HITs are not related to one another and need to be > > bound by some kind of certificate framework. This is what I think > > section 5.6.1.1 of the base draft refers to. Or am I > > misunderstanding something? > > We mean both cases. I'm sorry but I don't follow why couldn't the > non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA > lists and certificates) in the centralized case? > Let's say that the enrollment server allocates the first node the Node ID o= f "0", the second node a Node ID of "1" etc. Are you suggesting that these= values are used as HITs? I raised this issue in another thread yesterday, but it seems to me that a = central idea in the HIP architecture is that the HIT is the hash of the pub= lic key of a public/private key pair and that the host holds the private ke= y. I don't believe we've talked before about the possibility that the HI a= nd HIT are not related cryptographically. - Tom From ari.keranen@nomadiclab.com Thu Feb 25 22:57:26 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE3928C518 for ; Thu, 25 Feb 2010 22:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM6rlhMRqZTL for ; Thu, 25 Feb 2010 22:57:25 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1F28628C517 for ; Thu, 25 Feb 2010 22:57:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 802364E6D7; Fri, 26 Feb 2010 08:59:32 +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 j3QfBooiuCNh; Fri, 26 Feb 2010 08:59:32 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 05C794E6D4; Fri, 26 Feb 2010 08:59:32 +0200 (EET) Message-ID: <4B877153.10908@nomadiclab.com> Date: Fri, 26 Feb 2010 08:59:31 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> <4B8689B0.50704@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FF@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FF@XCH-NW-10V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 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, 26 Feb 2010 06:57:26 -0000 Henderson, Thomas R wrote: >>> When you say "In the other Peer ID mode, namely "RELOAD",..." >>> which case do you mean? Just the self-generated case? If it is >>> the centralized case, the Node IDs can't be used as HITs, and >>> then the Node IDs and the HITs are not related to one another and >>> need to be bound by some kind of certificate framework. This is >>> what I think section 5.6.1.1 of the base draft refers to. Or am >>> I misunderstanding something? >> We mean both cases. I'm sorry but I don't follow why couldn't the >> non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA >> lists and certificates) in the centralized case? >> > > Let's say that the enrollment server allocates the first node the > Node ID of "0", the second node a Node ID of "1" etc. Are you > suggesting that these values are used as HITs? Yes. Although the enrollment server would not really give IDs like that but rather make them cryptographically random, but the point remains the same: the IDs in the RELOAD mode are not (necessarily) hashes of public keys. > I raised this issue in another thread yesterday, but it seems to me > that a central idea in the HIP architecture is that the HIT is the > hash of the public key of a public/private key pair and that the host > holds the private key. I don't believe we've talked before about the > possibility that the HI and HIT are not related cryptographically. Yeah, we had a thread on the HIP list about this some half a year ago but it died away. I admit that the HIT being a hash of a public key is somewhat central idea in HIP, but is it really necessary if you have a certificate that can provide the same binding between the non-HIT-ID and Host ID? AFAIK, you only lose the property that for someone else it's really hard to generate the same identity, but with an enrollment server that would not be a problem thanks to the certificates. Without an enrollment server one could fake the ID in the RELOAD mode, but then you can still use the ORCHID mode and real HITs or generate IDs as digests (SHA-1 or SHA-256) of the public key as the RELOAD draft proposes. Cheers, Ari From heer@informatik.rwth-aachen.de Fri Feb 26 05:17:13 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF34A3A879A for ; Fri, 26 Feb 2010 05:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALVgcSMN3AN5 for ; Fri, 26 Feb 2010 05:17:12 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 8690E3A8795 for ; Fri, 26 Feb 2010 05:17:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KYG008R6ACD2F90@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 26 Feb 2010 14:19:25 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,546,1262559600"; d="scan'208";a="46661774" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 26 Feb 2010 14:19:26 +0100 Received: from umic-137-226-154-185.nn.rwth-aachen.de ([unknown] [137.226.154.185]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KYG00DIPACDBC70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 26 Feb 2010 14:19:25 +0100 (CET) From: Tobias Heer In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> Date: Fri, 26 Feb 2010 14:19:26 +0100 Message-id: <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <"7CC5666 35CFE364D87DC5803D4712A6C4C1F48A6D9"@XCH-NW-10V.nw.nos.boeing.com> <"BF345F630 74F8040B58C00A186FCA57F1C692DBE6B"@NALASEXMB04.na.qualcomm.com> <"461A6C4B-08E 3-4D77-8292-BD4CCC7A375B"@cs.rwth-aachen.de> <4B8546B5.3010708@hiit.fi> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] ORCHID IANA allocation 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, 26 Feb 2010 13:17:14 -0000 Hi Tom, Am 24.02.2010 um 19:57 schrieb Henderson, Thomas R: [...] >> Would there be consensus to update ORCHIDs to v2 as follows: >> >> - ORCHIDv2 structured as 28 + 4 + 96 bits >> - 28 bits are new prefix for ORCHIDv2 >> - 4 bits encodes hash >> - 96 bits are hashed string >> >> Note that CGA's hash extension techniques (with Sec >> parameter) have been updated with some hash agility support >> in [RFC4982]; do we want to do something similar? Or do we >> want to use standalone hash extension in the 96 bits, as in >> the original CGA design [RFC3972]? >> > > I support the above. Regarding your question, I would recommend that we say for now that "4 bits encodes the hash string generation algorithm" because it may not simply be a hash algorithm but something like hash extension of CGA. > You got a very good point here. I agree. > Note that if we make ORCHIDs generic, the 4 bits must be shared among all the possible users in the future. I don't think it is a big concern because the current use outside of HIP seems to be limited. > I don't think that is a big concern. The ORCHID is designed in a way that the context ID is not visible from the ORCHID. Hence, all protocols that use ORCHIDS need checks whether a given ORCHID actually matches the current protocol context. As far as I can tell, this is done by simple trial and error: hash the public key and the context ID and see if it matches. Now, with the 4 additional bits, for a new (4+96 bit) ORCHID, the protocols that use the old ORCHID format check for the context ID again and the test would fail. In that case, the protocol would figure that it is an ORCHID of another protocol - no harm done... and no need to "share" the four bits. Am I missing something here? > It would be nice to discuss and then state in one of the drafts (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for the following: I tried to distribute your (good) questions to the three documents. I took the liberty to number the questions below. I think question 3 would fit into 4843-bis nicely. There is already a short part on HITs and LSIs. One could easily extend this to go into ORCHIDS a bit more. RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I think that it should stay like that. Your questions 1 and 2 would be good here. Do you want to discuss the answers to your questions on the list or are these meant as todo for the authors of the respective documents. I can adjust the text in RFC5201-bis to match the new HIT format and the resulting changes in the BEX. Part of it was already done together with Bob anyway. I will post the result on the list. 1.) > - future allocations of new ORCHID prefixes? Are there any conditions that would lead to asking for additional ORCHID prefixes, or do we expect only one such prefix? 2.) > - what happens if the four bits runs out (do we deprecate old values such as in RFC4982?) 3.) > - some discussion of the relationship between HITs, LSIs, ORCHIDs, and other quantities. > ** future extension of HIT size (256 bits has been raised in the past)-- is this possible or are we closing the door on such a future extension?. More generally, does HIP allow for HITs that are not ORCHIDs? (e.g. the old type-2 HITs, or more recent proposals for hierarchical HITs) Do we use the bits in the HIP control field to identify HIT type? > ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari have floated this idea in the past) > ** LSI prefix for IPv4 (recall we discussed a /16 in the 127/8 space-- do we also want to resolve this issue while we are resolving ORCHIDs?) > ** are LSIs possible for IPv6? When would they be used instead of ORCHIDs? > Tobias > Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From julienl@qualcomm.com Fri Feb 26 08:04:35 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5544128C113 for ; Fri, 26 Feb 2010 08:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.655 X-Spam-Level: X-Spam-Status: No, score=-106.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22LvcKpuQV4p for ; Fri, 26 Feb 2010 08:04:33 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BC8793A8695 for ; Fri, 26 Feb 2010 08:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1267200409; x=1298736409; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tobias=20Heer=20,=20"Hende rson,=20Thomas=20R"=0D=0A=09|CC:=20"miika.komu@hiit.fi"=20,=20" hipsec@ietf.org"=0D=0A=09|Date:=20Fri, =2026=20Feb=202010=2008:06:46=20-0800|Subject:=20RE:=20[H ipsec]=20ORCHID=20IANA=20allocation|Thread-Topic:=20[Hips ec]=20ORCHID=20IANA=20allocation|Thread-Index:=20Acq25lPs xOuiLLm3QCuwd+whjJCLngAFxYFw|Message-ID:=20|References:=20<00E85481-5745-4093-B165-887058ED719B@cs. rwth-aachen.de>=0D=0A=20<"7CC5666=2035CFE364D87DC5803D471 2A6C4C1F48A6D9"@XCH-NW-10V.nw.nos.boeing.com>=0D=0A=20<"B F345F630=2074F8040B58C00A186FCA57F1C692DBE6B"@NALASEXMB04 .na.qualcomm.com>=0D=0A=20<"461A6C4B-08E=203-4D77-8292-BD 4CCC7A375B"@cs.rwth-aachen.de>=0D=0A=20<4B8546B5.3010708@ hiit.fi>=0D=0A=20=0D=0A=20<7CC566635CFE364 D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> =0D=0A=20<28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aa chen.de>|In-Reply-To:=20<28B85428-CC28-4DB4-83AC-505CE6B4 E955@cs.rwth-aachen.de>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=jkhOaCdmUu5Uak1lV8oYLAeaURLMDz/2aG1zBQB7yIE=; b=xeOA7qpIeubB16aZDU5IvKP48KpsqP6yxXiBmB1UdX/WSmBPWYr6fPxM jskyPt5kRRlV1wP9tM9Iryfg6wGXfV4jwXOLjqWYxjWQV7x1E0T9ZyveN 1D241TvIkkGEVGY9oP9CuvFYclsovMSYLfCj/iEWwSdOmxVhG5jDuLUaI 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5903"; a="34943929" Received: from ironrogue.qualcomm.com ([129.46.61.164]) by wolverine02.qualcomm.com with ESMTP; 26 Feb 2010 08:06:48 -0800 X-IronPort-AV: E=Sophos;i="4.49,546,1262592000"; d="scan'208";a="46245971" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 26 Feb 2010 08:06:48 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 26 Feb 2010 08:06:48 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Fri, 26 Feb 2010 08:06:48 -0800 From: "Laganier, Julien" To: Tobias Heer , "Henderson, Thomas R" Date: Fri, 26 Feb 2010 08:06:46 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation Thread-Index: Acq25lPsxOuiLLm3QCuwd+whjJCLngAFxYFw Message-ID: References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <"7CC5666 35CFE364D87DC5803D4712A6C4C1F48A6D9"@XCH-NW-10V.nw.nos.boeing.com> <"BF345F630 74F8040B58C00A186FCA57F1C692DBE6B"@NALASEXMB04.na.qualcomm.com> <"461A6C4B-08E 3-4D77-8292-BD4CCC7A375B"@cs.rwth-aachen.de> <4B8546B5.3010708@hiit.fi> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> In-Reply-To: <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] ORCHID IANA allocation 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, 26 Feb 2010 16:04:35 -0000 Tobias, Did you swapped 4423 and 4843 in your note below? I'd expect non-HIP-specif= ic 1 & 2 to be discussed in 4843bis / ORCHIDv2, while HIP-specific 3 clearl= y belongs to 3. --julien Tobias Heer wrote: >=20 > Hi Tom, >=20 > Am 24.02.2010 um 19:57 schrieb Henderson, Thomas R: > [...] >=20 > >> Would there be consensus to update ORCHIDs to v2 as follows: > >> > >> - ORCHIDv2 structured as 28 + 4 + 96 bits > >> - 28 bits are new prefix for ORCHIDv2 > >> - 4 bits encodes hash > >> - 96 bits are hashed string > >> > >> Note that CGA's hash extension techniques (with Sec > >> parameter) have been updated with some hash agility support > >> in [RFC4982]; do we want to do something similar? Or do we > >> want to use standalone hash extension in the 96 bits, as in > >> the original CGA design [RFC3972]? > >> > > > > I support the above. Regarding your question, I would recommend that > we say for now that "4 bits encodes the hash string generation > algorithm" because it may not simply be a hash algorithm but something > like hash extension of CGA. > > > You got a very good point here. I agree. >=20 > > Note that if we make ORCHIDs generic, the 4 bits must be shared among > all the possible users in the future. I don't think it is a big > concern because the current use outside of HIP seems to be limited. > > >=20 > I don't think that is a big concern. The ORCHID is designed in a way > that the context ID is not visible from the ORCHID. Hence, all > protocols that use ORCHIDS need checks whether a given ORCHID actually > matches the current protocol context. As far as I can tell, this is > done by simple trial and error: hash the public key and the context ID > and see if it matches. Now, with the 4 additional bits, for a new (4+96 > bit) ORCHID, the protocols that use the old ORCHID format check for the > context ID again and the test would fail. In that case, the protocol > would figure that it is an ORCHID of another protocol - no harm done... > and no need to "share" the four bits. Am I missing something here? >=20 >=20 > > It would be nice to discuss and then state in one of the drafts > (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for > the following: >=20 >=20 > I tried to distribute your (good) questions to the three documents. I > took the liberty to number the questions below. > I think question 3 would fit into 4843-bis nicely. There is already a > short part on HITs and LSIs. One could easily extend this to go into > ORCHIDS a bit more. > RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I > think that it should stay like that. Your questions 1 and 2 would be > good here. > Do you want to discuss the answers to your questions on the list or are > these meant as todo for the authors of the respective documents. >=20 > I can adjust the text in RFC5201-bis to match the new HIT format and > the resulting changes in the BEX. Part of it was already done together > with Bob anyway. I will post the result on the list. >=20 >=20 > 1.) > > - future allocations of new ORCHID prefixes? Are there any > conditions that would lead to asking for additional ORCHID prefixes, or > do we expect only one such prefix? > 2.) > > - what happens if the four bits runs out (do we deprecate old values > such as in RFC4982?) > 3.) > > - some discussion of the relationship between HITs, LSIs, ORCHIDs, > and other quantities. > > ** future extension of HIT size (256 bits has been raised in the > past)-- is this possible or are we closing the door on such a future > extension?. More generally, does HIP allow for HITs that are not > ORCHIDs? (e.g. the old type-2 HITs, or more recent proposals for > hierarchical HITs) Do we use the bits in the HIP control field to > identify HIT type? > > ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari > have floated this idea in the past) > > ** LSI prefix for IPv4 (recall we discussed a /16 in the 127/8 > space-- do we also want to resolve this issue while we are resolving > ORCHIDs?) > > ** are LSIs possible for IPv6? When would they be used instead of > ORCHIDs? > > >=20 > Tobias >=20 >=20 > > Tom > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec >=20 >=20 >=20 >=20 > -- >=20 > Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer >=20 >=20 >=20 >=20 >=20 >=20 From heer@informatik.rwth-aachen.de Fri Feb 26 09:24:50 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5C93A87ED for ; Fri, 26 Feb 2010 09:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdrkMxo0vxe0 for ; Fri, 26 Feb 2010 09:24:49 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 6EE1D3A86DC for ; Fri, 26 Feb 2010 09:24:49 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KYG008UILT32FH0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 26 Feb 2010 18:27:03 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,547,1262559600"; d="scan'208";a="46718195" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 26 Feb 2010 18:27:03 +0100 Received: from [192.168.3.237] ([unknown] [87.65.13.96]) 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 <0KYG009JLLT25N10@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 26 Feb 2010 18:27:03 +0100 (CET) From: Tobias Heer In-reply-to: Date: Fri, 26 Feb 2010 18:27:03 +0100 Message-id: <4E38C50D-4DB7-48D2-B2CC-C8609EDFF450@cs.rwth-aachen.de> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de> <"7CC5666 35CFE364D87DC5803D4712A6C4C1F48A6D9"@XCH-NW-10V.nw.nos.boeing.com> <"BF345F630 74F8040B58C00A186FCA57F1C692DBE6B"@NALASEXMB04.na.qualcomm.com> <"461A6C4B-08E 3-4D77-8292-BD4CCC7A375B"@cs.rwth-aachen.de> <4B8546B5.3010708@hiit.fi> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1077) Cc: "hipsec@ietf.org WG" Subject: Re: [Hipsec] ORCHID IANA allocation 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, 26 Feb 2010 17:24:51 -0000 Hi Julien, Am 26.02.2010 um 17:06 schrieb Laganier, Julien: > Tobias, > > Did you swapped 4423 and 4843 in your note below? I'd expect non-HIP-specific 1 & 2 to be discussed in 4843bis / ORCHIDv2, while HIP-specific 3 clearly belongs to 3. > you are absolutely right. I mixed the numbers in my reply. Sorry for causing confusion. Tobias > --julien > > Tobias Heer wrote: >> >> Hi Tom, >> >> Am 24.02.2010 um 19:57 schrieb Henderson, Thomas R: >> [...] >> >>>> Would there be consensus to update ORCHIDs to v2 as follows: >>>> >>>> - ORCHIDv2 structured as 28 + 4 + 96 bits >>>> - 28 bits are new prefix for ORCHIDv2 >>>> - 4 bits encodes hash >>>> - 96 bits are hashed string >>>> >>>> Note that CGA's hash extension techniques (with Sec >>>> parameter) have been updated with some hash agility support >>>> in [RFC4982]; do we want to do something similar? Or do we >>>> want to use standalone hash extension in the 96 bits, as in >>>> the original CGA design [RFC3972]? >>>> >>> >>> I support the above. Regarding your question, I would recommend that >> we say for now that "4 bits encodes the hash string generation >> algorithm" because it may not simply be a hash algorithm but something >> like hash extension of CGA. >>> >> You got a very good point here. I agree. >> >>> Note that if we make ORCHIDs generic, the 4 bits must be shared among >> all the possible users in the future. I don't think it is a big >> concern because the current use outside of HIP seems to be limited. >>> >> >> I don't think that is a big concern. The ORCHID is designed in a way >> that the context ID is not visible from the ORCHID. Hence, all >> protocols that use ORCHIDS need checks whether a given ORCHID actually >> matches the current protocol context. As far as I can tell, this is >> done by simple trial and error: hash the public key and the context ID >> and see if it matches. Now, with the 4 additional bits, for a new (4+96 >> bit) ORCHID, the protocols that use the old ORCHID format check for the >> context ID again and the test would fail. In that case, the protocol >> would figure that it is an ORCHID of another protocol - no harm done... >> and no need to "share" the four bits. Am I missing something here? >> >> >>> It would be nice to discuss and then state in one of the drafts >> (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for >> the following: >> >> >> I tried to distribute your (good) questions to the three documents. I >> took the liberty to number the questions below. >> I think question 3 would fit into 4843-bis nicely. There is already a >> short part on HITs and LSIs. One could easily extend this to go into >> ORCHIDS a bit more. >> RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I >> think that it should stay like that. Your questions 1 and 2 would be >> good here. >> Do you want to discuss the answers to your questions on the list or are >> these meant as todo for the authors of the respective documents. >> >> I can adjust the text in RFC5201-bis to match the new HIT format and >> the resulting changes in the BEX. Part of it was already done together >> with Bob anyway. I will post the result on the list. >> >> >> 1.) >>> - future allocations of new ORCHID prefixes? Are there any >> conditions that would lead to asking for additional ORCHID prefixes, or >> do we expect only one such prefix? >> 2.) >>> - what happens if the four bits runs out (do we deprecate old values >> such as in RFC4982?) >> 3.) >>> - some discussion of the relationship between HITs, LSIs, ORCHIDs, >> and other quantities. >>> ** future extension of HIT size (256 bits has been raised in the >> past)-- is this possible or are we closing the door on such a future >> extension?. More generally, does HIP allow for HITs that are not >> ORCHIDs? (e.g. the old type-2 HITs, or more recent proposals for >> hierarchical HITs) Do we use the bits in the HIP control field to >> identify HIT type? >>> ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari >> have floated this idea in the past) >>> ** LSI prefix for IPv4 (recall we discussed a /16 in the 127/8 >> space-- do we also want to resolve this issue while we are resolving >> ORCHIDs?) >>> ** are LSIs possible for IPv6? When would they be used instead of >> ORCHIDs? >>> >> >> Tobias >> >> >>> Tom >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> >> >> >> -- >> >> Dipl.-Inform. Tobias Heer, Ph.D. Student >> Distributed Systems Group >> RWTH Aachen University, Germany >> tel: +49 241 80 207 76 >> web: http://ds.cs.rwth-aachen.de/members/heer >> >> >> >> >> >> > -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://ds.cs.rwth-aachen.de/members/heer From thomas.r.henderson@boeing.com Fri Feb 26 09:27:22 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7853A87FB for ; Fri, 26 Feb 2010 09:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 VUi5xTnidP63 for ; Fri, 26 Feb 2010 09:27:21 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 71D153A86DC for ; Fri, 26 Feb 2010 09:27:21 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1QHTSBH004925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2010 09:29:28 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1QHTSn7019033; Fri, 26 Feb 2010 09:29:28 -0800 (PST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1QHTRVn019017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 26 Feb 2010 09:29:28 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Fri, 26 Feb 2010 09:29:27 -0800 From: "Henderson, Thomas R" To: "'Ari Keranen'" Date: Fri, 26 Feb 2010 09:29:26 -0800 Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 Thread-Index: Acq2sUI2gMolbBcqQn+ISTeEAbfnDQAVk/eA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A81E@XCH-NW-10V.nw.nos.boeing.com> References: <4B5F07F6.7080800@ericsson.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7C0@XCH-NW-10V.nw.nos.boeing.com> <4B83F243.6070208@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7D1@XCH-NW-10V.nw.nos.boeing.com> <4B8689B0.50704@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4C1F48A7FF@XCH-NW-10V.nw.nos.boeing.com> <4B877153.10908@nomadiclab.com> In-Reply-To: <4B877153.10908@nomadiclab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-6.000.1038-17216.005 x-tm-as-result: No--38.908000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 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, 26 Feb 2010 17:27:22 -0000 > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Thursday, February 25, 2010 11:00 PM > To: Henderson, Thomas R > Cc: 'Gonzalo Camarillo'; HIP > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00 > > Henderson, Thomas R wrote: > >>> When you say "In the other Peer ID mode, namely "RELOAD",..." > >>> which case do you mean? Just the self-generated case? If it is > >>> the centralized case, the Node IDs can't be used as HITs, and > >>> then the Node IDs and the HITs are not related to one another and > >>> need to be bound by some kind of certificate framework. This is > >>> what I think section 5.6.1.1 of the base draft refers to. Or am > >>> I misunderstanding something? > >> We mean both cases. I'm sorry but I don't follow why couldn't the > >> non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA > >> lists and certificates) in the centralized case? > >> > > > > Let's say that the enrollment server allocates the first node the > > Node ID of "0", the second node a Node ID of "1" etc. Are you > > suggesting that these values are used as HITs? > > Yes. Although the enrollment server would not really give IDs > like that > but rather make them cryptographically random, but the point > remains the > same: the IDs in the RELOAD mode are not (necessarily) hashes > of public > keys. > > > I raised this issue in another thread yesterday, but it seems to me > > that a central idea in the HIP architecture is that the HIT is the > > hash of the public key of a public/private key pair and > that the host > > holds the private key. I don't believe we've talked before > about the > > possibility that the HI and HIT are not related cryptographically. > > Yeah, we had a thread on the HIP list about this some half a year ago > but it died away. I admit that the HIT being a hash of a > public key is > somewhat central idea in HIP, but is it really necessary if > you have a > certificate that can provide the same binding between the > non-HIT-ID and > Host ID? > > AFAIK, you only lose the property that for someone else it's > really hard > to generate the same identity, but with an enrollment server > that would > not be a problem thanks to the certificates. Without an enrollment > server one could fake the ID in the RELOAD mode, but then you > can still > use the ORCHID mode and real HITs or generate IDs as digests > (SHA-1 or > SHA-256) of the public key as the RELOAD draft proposes. > I think we should really explore this idea more but let's do so in the more= RFC4423bis context as discussed in the other thread. I wasn't objecting t= o the idea per se, but just that we should not slip it into this draft if i= t is not really recognized as a part of HIP today. I see pros and cons to non-ORCHID HITs: - pro: can be designed to be hierarchical or formatted as needed. Can the= y even be IPv6 addresses? - con: HITs are no longer unique. It is really the certificate which is t= he unique identifier. It does seem more flexible and may have deployment advantages. Does it sol= ve the ACL problem with current HITs (that they are non-aggregatable)? It = could lead to aggregatable HITs but then the ACL will need to know the auth= orizing enrollment server for those HITs, and check CERTs. - Tom From thomas.r.henderson@boeing.com Fri Feb 26 09:30:13 2010 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A507228C13D for ; Fri, 26 Feb 2010 09:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 JexyFJorSKo1 for ; Fri, 26 Feb 2010 09:30:12 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3B5033A86DC for ; Fri, 26 Feb 2010 09:30:12 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o1QHWEZ4004250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2010 11:32:15 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o1QHWEOj000548; Fri, 26 Feb 2010 09:32:14 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o1QHWDgK000532 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 26 Feb 2010 09:32:14 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 26 Feb 2010 09:32:13 -0800 From: "Henderson, Thomas R" To: "'Tobias Heer'" Date: Fri, 26 Feb 2010 09:32:12 -0800 Thread-Topic: [Hipsec] ORCHID IANA allocation Thread-Index: Acq25lNkrpnVEAs0QxWqvICSj1vFOgAIvaOQ Message-ID: <7CC566635CFE364D87DC5803D4712A6C4C1F48A81F@XCH-NW-10V.nw.nos.boeing.com> References: <00E85481-5745-4093-B165-887058ED719B@cs.rwth-aachen.de><"7CC566 6 35CFE364D87DC5803D4712A6C4C1F48A6D9"@XCH-NW-10V.nw.nos.boeing.com><"BF345F6 30 74F8040B58C00A186FCA57F1C692DBE6B"@NALASEXMB04.na.qualcomm.com><"461A6C4B-0 8E 3-4D77-8292-BD4CCC7A375B"@cs.rwth-aachen.de><4B8546B5.3010708@hiit.fi><7CC5666 35CFE364D87DC5803D4712A6C4C1F48A7E8@XCH-NW-10V.nw.nos.boeing.com> <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> In-Reply-To: <28B85428-CC28-4DB4-83AC-505CE6B4E955@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] ORCHID IANA allocation 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, 26 Feb 2010 17:30:13 -0000 > -----Original Message----- > From: Tobias Heer [mailto:heer@cs.rwth-aachen.de] > Sent: Friday, February 26, 2010 5:19 AM > To: Henderson, Thomas R > Cc: 'Laganier, Julien'; miika.komu@hiit.fi; hipsec@ietf.org > Subject: Re: [Hipsec] ORCHID IANA allocation > > > I don't think that is a big concern. The ORCHID is designed > in a way that the context ID is not visible from the ORCHID. > Hence, all protocols that use ORCHIDS need checks whether a > given ORCHID actually matches the current protocol context. > As far as I can tell, this is done by simple trial and error: > hash the public key and the context ID and see if it matches. > Now, with the 4 additional bits, for a new (4+96 bit) ORCHID, > the protocols that use the old ORCHID format check for the > context ID again and the test would fail. In that case, the > protocol would figure that it is an ORCHID of another > protocol - no harm done... and no need to "share" the four > bits. Am I missing something here? I think you are right. > Do you want to discuss the answers to your questions on the > list or are these meant as todo for the authors of the > respective documents. I think we should discuss them on the list. For questions 1 and 2, I do no= t care so much about the answer, other than we just document what future pl= ans are envisioned. Question 3 is more interesting and we are already disc= ussing with the RELOAD draft. - Tom > > I can adjust the text in RFC5201-bis to match the new HIT > format and the resulting changes in the BEX. Part of it was > already done together with Bob anyway. I will post the result > on the list. > > > 1.) > > - future allocations of new ORCHID prefixes? Are there any > conditions that would lead to asking for additional ORCHID > prefixes, or do we expect only one such prefix? > 2.) > > - what happens if the four bits runs out (do we deprecate > old values such as in RFC4982?) > 3.) > > - some discussion of the relationship between HITs, LSIs, > ORCHIDs, and other quantities. > > ** future extension of HIT size (256 bits has been raised > in the past)-- is this possible or are we closing the door on > such a future extension?. More generally, does HIP allow for > HITs that are not ORCHIDs? (e.g. the old type-2 HITs, or > more recent proposals for hierarchical HITs) Do we use the > bits in the HIP control field to identify HIT type? > > ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo > and Jari have floated this idea in the past) > > ** LSI prefix for IPv4 (recall we discussed a /16 in the > 127/8 space-- do we also want to resolve this issue while we > are resolving ORCHIDs?) > > ** are LSIs possible for IPv6? When would they be used > instead of ORCHIDs? > > > > Tobias > > > > Tom > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > > > > -- > > Dipl.-Inform. Tobias Heer, Ph.D. Student > Distributed Systems Group > RWTH Aachen University, Germany > tel: +49 241 80 207 76 > web: http://ds.cs.rwth-aachen.de/members/heer > > > > > > > >