From gonzalo.camarillo@ericsson.com Sun Aug 2 06:51:20 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409FD3A6C0C for ; Sun, 2 Aug 2009 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHQ2NepY+IqY for ; Sun, 2 Aug 2009 06:51:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4244F3A6C00 for ; Sun, 2 Aug 2009 06:51:18 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-2c-4a7599d76698 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 95.30.20235.7D9957A4; Sun, 2 Aug 2009 15:51:19 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Aug 2009 15:51:19 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Aug 2009 15:51:19 +0200 Received: from [131.160.126.175] (rvi2-126-175.lmf.ericsson.se [131.160.126.175]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 952792450; Sun, 2 Aug 2009 16:51:18 +0300 (EEST) Message-ID: <4A7599D7.7040603@ericsson.com> Date: Sun, 02 Aug 2009 16:51:19 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: David Ward References: <4A72C761.9050301@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2009 13:51:19.0339 (UTC) FILETIME=[500B1FB0:01CA1378] X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] Draft meeting minutes X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 13:51:20 -0000 Hi, this is something we will need to ask our ADs and the IAB. My guess is that as long as they are happy with the reporting of the experiments, the fact that the RFC is published will not be that important. Cheers, Gonzalo David Ward wrote: > Gonzalo - > > Is the publication of the experimentation report as an IRTF RFC required > to make HIP PS? Or just HIP WG LC? > > -DWard > > On Jul 31, 2009, at 5:28 AM, Gonzalo Camarillo wrote: > >> Folks, >> >> you can find the draft minutes of our meeting yesterday under the >> following link: >> >> http://www.ietf.org/proceedings/75/minutes/hip.txt >> >> Cheers, >> >> Gonzalo >> HIP co-chair > From rgm@htt-consult.com Tue Aug 4 00:25:49 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EDF3A67F0 for ; Tue, 4 Aug 2009 00:25:49 -0700 (PDT) X-Quarantine-ID: <5EnJns3bekVh> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5EnJns3bekVh for ; Tue, 4 Aug 2009 00:25:48 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 61C653A6884 for ; Tue, 4 Aug 2009 00:25:48 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n747PhZu002224 for ; Tue, 4 Aug 2009 03:25:43 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 04 Aug 2009 03:25:08 -0400 (EDT) Date: Tue, 4 Aug 2009 10:25:06 +0300 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A77E252.8020206@htt-consult.com> In-Reply-To: <8F346BB1-D5EF-419F-AED7-A0DE8DFEECE0@indranet.co.nz> References: <4A72AF52.90603@htt-consult.com> References: <8F346BB1-D5EF-419F-AED7-A0DE8DFEECE0@indranet.co.nz> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Looking for a list of hashes and MACs X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 07:25:49 -0000 I am looking for a list of hashes and MACs for discussion purposes (ie starting point). Hashes, all I am finding is the SHA varients: SHA-1, 224, 256, 384, & 512. I ASSuME that we are awaiting results of the Hash competition for more... For MACs, I found: http://csrc.nist.gov/groups/STM/cavp/index.html which lists CMAC, CCM. GMAC, & HMAC with MAC depricated. (http://csrc.nist.gov/groups/ST/toolkit/message_auth.html only lists MAC & HMAC). If we add ESP-CCM due to the prevalence of CCM in wireless systems, adding CCM for the MAC seems a 'smart' move. But what about others? What are our hashing alternatives? For example could you run CCM with a key of ZERO for a CCM hash to generate the HIT? From discussions I have had, CCM works well with small packet size like found in 802.15.4 where the maximum datagram is 127 bytes. (or perhaps there is research of a key value that generates a 'good' CCM hash?). Just doing a little headscratching here. From rgm@htt-consult.com Tue Aug 4 00:28:00 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9A03A6A45 for ; Tue, 4 Aug 2009 00:28:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZNmbeZVHV07 for ; Tue, 4 Aug 2009 00:28:00 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id C83603A6884 for ; Tue, 4 Aug 2009 00:27:59 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n747Rvj7002324 for ; Tue, 4 Aug 2009 03:27:57 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 04 Aug 2009 03:27:57 -0400 (EDT) Date: Tue, 4 Aug 2009 10:27:55 +0300 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A77E2FB.9030102@htt-consult.com> In-Reply-To: <8F346BB1-D5EF-419F-AED7-A0DE8DFEECE0@indranet.co.nz> References: <4A72AF52.90603@htt-consult.com> References: <8F346BB1-D5EF-419F-AED7-A0DE8DFEECE0@indranet.co.nz> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Which EC for DH X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 07:28:00 -0000 At least Oakley groups 3 & 4? What else for, say, suite B support? From oleg.ponomarev@hiit.fi Tue Aug 4 09:42:24 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58A43A6403 for ; Tue, 4 Aug 2009 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zTAAZWGqg1HK for ; Tue, 4 Aug 2009 09:42:23 -0700 (PDT) Received: from felwood.infrahip.net (felwood.infrahip.net [IPv6:2001:708:140:220::3]) by core3.amsl.com (Postfix) with ESMTP id 49B143A6452 for ; Tue, 4 Aug 2009 09:42:23 -0700 (PDT) Received: from stargazer.pc.infrahip.net (stargazer.pc.infrahip.net [IPv6:2001:708:140:220:215:60ff:fe9f:60c4]) by felwood.infrahip.net (8.14.3/8.14.3) with ESMTP id n74GgFgJ025893; Tue, 4 Aug 2009 19:42:16 +0300 Date: Tue, 4 Aug 2009 19:42:14 +0300 (EEST) From: Oleg Ponomarev X-X-Sender: ponomare@stargazer.pc.infrahip.net To: Robert Moskowitz In-Reply-To: <4A77E2FB.9030102@htt-consult.com> Message-ID: References: <4A72AF52.90603@htt-consult.com> <4A77E2FB.9030102@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] Which EC for DH X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 16:42:25 -0000 Hi! > Subject: [Hipsec] Which EC for DH > > At least Oakley groups 3 & 4? I guess, we need ECP groups from RFC5114? GROUP | SYMMETRIC | RSA -------------------------------------------+------------+------- 192-bit Random ECP Group | 80 | 1024 224-bit Random ECP Group | 112 | 2048 256-bit Random ECP Group | 128 | 3072 384-bit Random ECP Group | 192 | 7680 521-bit Random ECP Group | 256 | 15360 -- Regards, Oleg. From rgm@htt-consult.com Tue Aug 11 08:39:41 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B851B3A6F28 for ; Tue, 11 Aug 2009 08:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpFZ7wbplNdk for ; Tue, 11 Aug 2009 08:39:40 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 7C2173A6DC8 for ; Tue, 11 Aug 2009 08:39:08 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7BFaYdI029379 for ; Tue, 11 Aug 2009 11:36:34 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 11 Aug 2009 11:36:07 -0400 (EDT) Date: Tue, 11 Aug 2009 11:36:07 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A818FE7.1030705@htt-consult.com> In-Reply-To: References: x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit Content-Disposition: inline Subject: [Hipsec] Thoughts on 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, 11 Aug 2009 15:39:41 -0000 Below is a good writeup of what I hope will lead us to a KISS crypto agile BEX. Tobias Heer wrote: > > Hi, > > this is a summary based on discussions with Robert Moskowitz, Tobias > Heer, Stefan Götz and Miika Komu at HIIT during week 32. We discussed > about the problems associated with HIP algorithm agility and different > alternative solutions. After several design iterations (of which not all > are described in this email), Tobias came up with a solution which we > all agreed on. We'd suggest the working group to adopt it to get HIP on > standards track. All discussion is welcome! > > Problems > ======== > > HIP algorithms are attached quite statically to the HIP protocol and > namespace. We need a better way to deal with deprecating broken > algorithms and inclusion of new ones. Some examples below: > > a) Although SHA1 is not broken yet, there will be a need to replace it > with something stronger (SHA256?) in the future. > b) We may want to support other public key algorithms such as elliptic > curve DSA. > c) We may want to support shared key generation with elliptic curve > Diffie-Hellman instead of the normal D-H. > > This leads us to the following new challenges: > > 1.) We have several signature algos now and it cannot be assumed that > every host supports every algo. > 2.) We have several hash algos for HITs now and it cannot be assumed > that every host supports every algo. > 3.) We have several DH groups now and it we cannot fit all in the > R1 packet. > > In effect, several hash and signature algorithms lead to a multitude of > HITs per each host. Several signature algorithms lead to a multitude of > HIs per host. > > Opportunistic HIP introduces additional challenges with the HIT > algorithm selection. The I1 lacks a Responder HIT, so unless we > encode the PK and Hash of the Initiator into its HIT, we have a > decision problem for the Responder. Even if we do that, why did > the Initiator select THAT combination, perhaps the Responder does not > support it, but supports a different combination used by the > Initiator. > > There is also a referral related issue, where the Initiator learned of a > HIT through some application-layer protocol or just by caching. The > problem arises if we don't encode the algorithm in HIT but rather just > encode this in DNS. When application connects to HIT and the system does > know the related algorithms, the connection can just fail due to > algorithm mismatch. This problem might arise for example in hipbone > environments. > > Negotiation of Diffie-Hellman algorithm must be started already in the > I1 message to avoid overly large R1 packets filled with different D-H > parameters. This introduces the possibility for a man-in-the-middle > attack where the attacker mounts a downgrade attack on the Initiator and > Responder. The attacker can alter the I1 because it is unprotected. Thus, > the attacker can cause the Responder to offer unnecessarily too weak > algorithms or key lengths in R1 and. For some reason, I read that "and." and am looking for some more text... > > Solution 1: application selects algorithms > ========================================== > > The basic problem is that the Initiator and the Responder must select a > combination of algorithms supported by both hosts. Some of these > algorithms can be selected during the BEX (see DH below) but some must > be selected before the BEX since the applications may bind to source and > destination HITs before the system performs the BEX. In particular, the > applications selects the destination HIT (=hash algo + signature algo). > Hence, the application must make a "good" choice here. "Good" means here > that the application selects a combination of hash and signature > algorithms supported by both hosts. > > We can't really shift the selection burden to the applications. It might > work on native HIP applications, but we should be able to use HIP with > legacy applications as well. So shifting the problem to the applications > is not a good solution. > > Solution 2: resolver selects algorithms > ======================================= > > As a first approximation, the Initiator learns of the ciphers > supported by the Responder from DNS or some other service, selects its > HIT that matches the selected Responder's HIT and off it goes. The > local DNS resolver can filter the HITs and only provide locally > HITs supported by both hosts to the application. Hence, the application > can make a "good" choice. This requires the availability of additional > information about HITs in the DNS system. Specifically, the hash > function and signature algorithm must either be provided as additional > information through the DNS system or must be encoded within the HIT > itself (which increases chances for HIT collisions). > > The main 'challenge' is selecting the DH mode, since including the DH > modes in DNS or in the bits of the HIT is not feasible (too many > resulting HITs). > > The suggested solution > ====================== > > We reuse the solution 2 and include hash and public key algorithm > support in the DNS resource records, but also signal algorithms in > the base exchange to support scenarios without name look up > infrastructure. > > I1 packet has to be modified to include the hash, public keys and > diffie-hellman algorithms supported by the Initiator in a new "algo" > parameter. The parameter should indicate which hash and public key > algorithm the Initiator used to generate its HIT. > > The Responder receives the I1 packet and compares the algorithms > contained in the I1 parameter with its supported algorithms. It > sends back an R1 generated using the hash, public-key and diffie- > hellman algorithms supported by both of the hosts. The R1 always > includes two diffie-hellman keys and the signature covers the whole > packet as in the current RFC5201 specification. Not always, I believe the 2nd DH is a "MAY"? If only one DH fits the situation, why send two? But this is a nit over all. > > The R1 also lists also the algorithms supported by the Responder in a > new "algo" parameter. This parameter is in the signed part of the R1. > The parameter also denotes which hash, public-key and diffie-Hellman > algorithms were used to produce the R1. It should be noticed that a > Responder implementing precomputed spools of R1 packets has to maintain > a large selection of R1s to support the various combinations of > algorithms. > > This approach also works with opportunistic I1 packets as well. In such > a case, the Responder can select its source HIT for the R1 based on the > algo parameter in I1. > > Protection against the dowgrade attack > ====================================== > > If the offered DHs in R1 are strong enough for the Initiator, > everything proceeds as the current BEX. In the case of a detected > downgrade attack, the {DHlist} in the R1 supports a better algorithm > than the one chosen in R1. In such a case, the Initiator sends another > I1 in which it limits the choice of the supported algos to the > strongest matching algorithm. > > It the attack case would look like this: > > I1 {DHlist: 1,2,3} (attack) > --------------------------> > R1 {DHlist: 1,2,3} DHparameters-1 > <------------------------- > > (Initiator realizes that there is an attack) > > I1 {DHlist: 3} > --------------------------> > R1 {DHlist: 1,2,3} DHparameters-3 > <------------------------- > I2 > --------------------------> > R2 > <------------------------- > > The MITM attacker could still modify the packets but that would only > lead to a situation in which the BEX would never finish (or would be > aborted after some retries). The attacker could also just drop the > packets which would lead to DoS (which is impossible to protect > against) but the attacker cannot mount an undetected downgrade attack > any more. > > As a drawback, this leads to an 6-way BEX which may seem bad at first. > However, since this only happens in an attack scenario and since the > attack can be handled (so it is not interesting to mount anymore), we > assume the additional messages are not a problem at all. Since Malice > cannot be successful with a downgrade attack against I1, these sorts > of attacks will only occur as 'nuisance' attacks. So, the base > exchange would still be usually just four packets even though > implementations must be prepared to protect themselves against the > downgrade attack. > > Also, a benefit of this approach is that it will only have minimal > impact on the state machines specifications and their implementations > (check the DHlists, restart if necessary). This is important over other options we worked through. It maintains the simplicity of HIP while providing the needed agility. > > HI bindings > =================== > A host may now have a number of HIs (several signature algorithms). > This results in the question how to bind these HIs together. Until now > we have only discussed a DNS-(sec)-based binding but other bindings > are also possible (certificates, etc). However, the question of > signature-algo compatibility remains. If the signature algorithm of > the certificate is not understood, the binding is useless. In general, > it would probably make sense to not use crypto agility as a "comfort > tool" that enables to use of any arbitrary combination of algorithms > but as a tool that enables to increase the security of the system > whenever the currently used algorithms are threatened. Otherwise we > will end up with hosts that have a large number of HIs and even more > HITs. > > BR, > > Miika, Robert & Tobias > > > > -- q > 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 -- The Greatest Oak Was once a little Nut That held its ground. From miika.komu@hiit.fi Tue Aug 11 12:34:48 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19513A6CEA for ; Tue, 11 Aug 2009 12:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmOVVIrV49pa for ; Tue, 11 Aug 2009 12:34:48 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id DFBDE3A67A8 for ; Tue, 11 Aug 2009 12:34:47 -0700 (PDT) Received: from ip104.infrahip.net (80-186-82-16.elisa-mobile.fi [80.186.82.16]) by argo.otaverkko.fi (Postfix) with ESMTP id 7E96325ED12; Tue, 11 Aug 2009 22:33:16 +0300 (EEST) Message-ID: <4A81C778.5020907@hiit.fi> Date: Tue, 11 Aug 2009 22:33:12 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Moskowitz References: <4A818FE7.1030705@htt-consult.com> In-Reply-To: <4A818FE7.1030705@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Thoughts on 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: Tue, 11 Aug 2009 19:34:48 -0000 Robert Moskowitz wrote: >> Negotiation of Diffie-Hellman algorithm must be started already in the >> I1 message to avoid overly large R1 packets filled with different D-H >> parameters. This introduces the possibility for a man-in-the-middle >> attack where the attacker mounts a downgrade attack on the Initiator and >> Responder. The attacker can alter the I1 because it is unprotected. Thus, >> the attacker can cause the Responder to offer unnecessarily too weak >> algorithms or key lengths in R1 and. > > For some reason, I read that "and." and am looking for some more text... ...enforce the parties to use unnecessarily too weak crypto. From andrew@indranet.co.nz Wed Aug 12 03:48:05 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1473A69CC for ; Wed, 12 Aug 2009 03:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 J+okPnu3LjYW for ; Wed, 12 Aug 2009 03:48:04 -0700 (PDT) Received: from mail.indranet.co.nz (unknown [203.97.93.68]) by core3.amsl.com (Postfix) with ESMTP id 38CC03A698C for ; Wed, 12 Aug 2009 03:48:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by XServe-2.services.indranet.co.nz (Postfix) with ESMTP id 590269BAD4E; Sat, 8 Aug 2009 14:44:58 +1200 (NZST) X-Virus-Scanned: amavisd-new at indranet.co.nz Received: from XServe-2.services.indranet.co.nz ([127.0.0.1]) by localhost (XServe-2.acheron.indranet.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmdT1k1XetaT; Sat, 8 Aug 2009 14:44:57 +1200 (NZST) Received: from [192.168.1.98] (203-167-186-239.dsl.clear.net.nz [203.167.186.239]) by XServe-2.services.indranet.co.nz (Postfix) with ESMTP id A90F89BAD46; Sat, 8 Aug 2009 14:44:50 +1200 (NZST) Message-Id: From: Andrew McGregor To: Robert Moskowitz In-Reply-To: <4A72BA81.5050809@htt-consult.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Aug 2009 14:44:45 +1200 References: <4A72AF52.90603@htt-consult.com> <4A72BA81.5050809@htt-consult.com> X-Mailer: Apple Mail (2.936) Cc: hipsec@ietf.org Subject: Re: [Hipsec] Building the first list of to Standards changes X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 10:48:05 -0000 On 31/07/2009, at 9:33 PM, Robert Moskowitz wrote: > Andrew McGregor wrote: >> Whole lot of responses inline... >> >> On 31/07/2009, at 10:46 AM, Robert Moskowitz wrote: >> >>> OK we have met and agreed to go out and succeed. >>> >>> In light of that, lets get our work items in order and someone set >>> up the tracking of who is working on what and what it is its status. >>> >>> Crypto Agility >>> Add HI PK algorithms >> >> We use DNS formats for these, and so far the only RFCs published >> are RSA and DSA. There is a draft for ECC, there may be others. >> Code points are allocated by standards action. So this cannot >> progress until the DNS formats do. >> >>> Add HI hashes >> >> 5201 defines the RHASH which is used for all hash operations in the >> protocol to be the same as the hash used for ORCHIDS, see below. > > I would also want CBC-MAC, as hardware that implements CCM has CBC- > MAC. There is lots of wireless hardware that implements CCM... > > And there are those that will expect SHA-256. For completeness, RIPEMD-160 and WHIRLPOOL? CBC-MAC can't be used as a general hash function. So, we can define a way to use CBC-MAC or CCM+ instead of HMAC, but we'll still need a hash at the same time for HIT generation and cookies. >>> Add ESP cipher suites >> >> Straightforward, do you have a list of candidates? > > CCM, as this is in wireless hardware. GCM as this is in highspeed > wired hardware. Or those are the claims... CCM and CCM+ since it's the latter in 802.15 hardware. >>> Multiple HIs per host >>> Multiple HITs per HI >> >> I think these can be done already. Current implementations may not >> support multiple HIs per host, but I see no reason in the protocol >> why this can not be done. Multiple HITs per HI can happen given >> that hash agility is per context; therefore the ORCHIDS >> corresponding to different hashes are astronomically unlikely to >> collide. Local policy dictates if any particular HIT is acceptable. >> >> However, the IESG note at the beginning of 5201 has this to say: >> >> This document doesn't currently define support for parameterized >> (randomized) hashing in signatures, support for negotiation of a key >> derivation function, or support for combined encryption modes. >> >> The first point will require a lot of thought, although the packet >> formats should be straightforward. > > OK. This is an important one I left off. Would the hash used for > making the HIT be the hash used in the HIP sigs? Or is this YAP to > add to things like HIP options and DNS RR? Actually, I've done some more reading. HIP refers to RFC 4034 (Resource Records for the DNS Security Extensions) for signature formats. Any future DNSSEC formats are similarly applicable. There are no drafts specifying hashed variants for DNSSEC. So, as DNSSEC adds algorithms, so can HIP. >> The second point could be covered by redefining the DIFFIE_HELLMAN >> group id parameter to be an (algorithm, group) suite ID... this >> would even be backward compatible by reusing the existing values >> with the same processing definition. The third is merely more suite- >> ids for those modes. > > So would we have a list of key derivations and this is just one more > parameter? No, it's expanding the definition of an existing codepoint space; all the existing codepoints are regarded as specifying standard DH key negotiation with some group, new ones have to specify a key negotiation algorithm as well as its necessary group (or whatever) parameter. BTW, the combined encryption modes is yet more codepoints, with the minor complication that the HMAC TLV calculation definition should include specifying the use of the encryption algorithm's 'additional data' as an HMAC, rather than using the RHASH. This amounts to replacing 'HIP-gl or HIP-lg integrity key retrieved from KEYMAT' in section 6.4 of RFC 5201 with something like 'HIP-gl or HIP-lg integrity key retrieved from KEYMAT, except that if the encryption algorithm in use is also to be used for message authentication, use the encryption key instead'. Also I guess that HMAC should be renamed MAC everywhere. >>> ESP operation with HIP >>> Explain Binding Transport Mode End to End without creating a new >>> ESP mode >> >> This amounts to a wording change in 5202, all the text is already >> there. BEET is a recommended implementation detail for 5202 ESP >> processing and does not change the wire format or semantics, so >> there should be no problem here. >> >>> AH operation with HIP >>> >>> Compressing Transport checksums >>> New HIP option? >> >> I'm not sure what you're suggesting. Compressing suites could be >> defined for ESP. Or are you suggesting compressing the HIP packets >> themselves? > > If you are going to allow for removal of the TCP and UDP checksums, > both parties would need to agree they are going to do this. So, I suggest using suite-IDs for this; responder indicates prepared to use those suites, initiator can as usual take it or leave it. From rgm@htt-consult.com Wed Aug 19 14:37:38 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B483A6FD7 for ; Wed, 19 Aug 2009 14:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 QWCoG1Lpwdff for ; Wed, 19 Aug 2009 14:37:37 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 213953A6899 for ; Wed, 19 Aug 2009 14:37:34 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7JLbUJl024995 for ; Wed, 19 Aug 2009 17:37:30 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Wed, 19 Aug 2009 17:37:30 -0400 (EDT) Date: Wed, 19 Aug 2009 17:37:17 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A8C708D.4010503@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 21:37:38 -0000 We need to come to a quick determination about what we use for LSIs. I have been asked by IANA for clearification on what HIP has been using 1.0.0.0/8 for. I pointed them to the text from 4423 for now. But note that Net1 has been released to the RIRs. Here is what I have been told: ============================================= Whichever block is selected for HIP LSIs we will need to follow the direction in section 4.1 of RFC 2860: 4.1. The IANA will assign and register Internet protocol parameters only as directed by the criteria and procedures specified in RFCs, including Proposed, Draft and full Internet Standards and Best Current Practice documents, and any other RFC that calls for IANA assignment. If the IESG are willing to direct us to reserve a particular /8 or (or a part of it) for a special purpose then we would do so and make sure not to allocate it to an RIR. However, for the time being, 1.0.0.0/8 is available for allocation to RIRs and could be allocated. ============================================= We have discussed using 127.0.0.0 for LSIs, say 127.100.0.0/16, but will that really work? Will the kernels handle them in a reasonable way? What will protocols like the FTP command channel's use of IPaddresses look like? Or referalls? Can anyone shed light on this or actually do some testing? If we REALLY need routable addresses, we need a serious dialog with IANA now. From jeffrey.m.ahrenholz@boeing.com Wed Aug 19 15:25:53 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3123A6FDB for ; Wed, 19 Aug 2009 15:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ESOWhNoijhC for ; Wed, 19 Aug 2009 15:25:53 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EEB403A6FD2 for ; Wed, 19 Aug 2009 15:25:52 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7JMPVDh024140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 15:25:31 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7JMPVUW008796; Wed, 19 Aug 2009 15:25:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7JMPUYa008780; Wed, 19 Aug 2009 15:25:31 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 15:25:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 15:24:37 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C6A@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4A8C708D.4010503@htt-consult.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Selection of LSI address block Thread-Index: AcohFUvC6kOBKxtZTqO1/4y+KNnMHAABaLLQ References: <4A8C708D.4010503@htt-consult.com> From: "Ahrenholz, Jeffrey M" To: "Robert Moskowitz" , X-OriginalArrivalTime: 19 Aug 2009 22:25:26.0552 (UTC) FILETIME=[F3700980:01CA211B] Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 22:25:53 -0000 =20 > We have discussed using 127.0.0.0 for LSIs, say=20 > 127.100.0.0/16, but will=20 > that really work? in the OpenHIP software we have a macro IN_LOOP() to check if an IPv4 address is equal to=20 (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if the top bits equal 127 (see /usr/include/netinet/in.h on Linux) I wonder if other applications use similar techniques to check for loopback addresses? Using 127.100.0.0/16 would be problematic in that case. -Jeff From rgm@htt-consult.com Wed Aug 19 15:30:46 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA1C3A6B6E for ; Wed, 19 Aug 2009 15:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 LFQZvujNGkK6 for ; Wed, 19 Aug 2009 15:30:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id AD04F3A69DE for ; Wed, 19 Aug 2009 15:30:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7JMUhXE028473 for ; Wed, 19 Aug 2009 18:30:43 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Wed, 19 Aug 2009 18:30:40 -0400 (EDT) Date: Wed, 19 Aug 2009 18:30:37 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A8C7D0D.7010708@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] To tunnel or not X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 22:30:46 -0000 ESP Transport in a bound, end-to-end operation or ESP Tunnel with HITS (or LSI?) explicit. Developers have reported challenges in using what we have been calling BEET mode, and have pointed out that if explicit tunnels were used, then the special HIP "optimization" (? right word) of Transport mode would be avoided. I have at least two technical problems with use of tunnel mode: What is enumerated in the tunnel? HITs always or HITs for IPv6 apps and LSIs for IPv4? (as we have demonstarted that IPv4 apps work well over HIP over IPv6). If HITs how will this work for IPv4? I suspect that someone can explain how this could 'work'? Would there be expectations on tunnel behaviour that would have to be negotiated? My basic philosophy was ESP transport was used as a 'short hand' for the HIP connection between two hosts. That HIP is not a key negotiation for ESP, but that ESP is used operationally to simplify HIP (not to develop YAP) with SPIs being pointers to the underlying HITs (did I remember that right? :) ). I can see where the process between two hosts is a tunneling process and in that HIP is used to secure the tunnel, but here the tunnel is not coupled to HIP but rather the process between two hosts that uses HIP. Does that make enough sense? These are reasonable questions that have been asked of me over the past year, and I would like to get some other's views. From rgm@htt-consult.com Wed Aug 19 15:33:14 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0406C3A6C93 for ; Wed, 19 Aug 2009 15:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 tcf2oVyo5s9o for ; Wed, 19 Aug 2009 15:33:13 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 219083A6C7B for ; Wed, 19 Aug 2009 15:33:12 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7JMXBWK028746 for ; Wed, 19 Aug 2009 18:33:11 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Wed, 19 Aug 2009 18:32:35 -0400 (EDT) Date: Wed, 19 Aug 2009 18:32:30 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A8C7D7E.9010402@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Hipsec] Who has the XML source for 4423 and 5201? X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 22:33:14 -0000 I would like to get the XML source for the final submissions to start looking at it in light of considered changes. Has anyone been able to do 'dev' like changes to ID xml sources? From miika.komu@hiit.fi Wed Aug 19 23:43:46 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF1E3A6AB8 for ; Wed, 19 Aug 2009 23:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II9bxRrIXxoq for ; Wed, 19 Aug 2009 23:43:46 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id CFBA73A6850 for ; Wed, 19 Aug 2009 23:43:45 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 68D4425ED12 for ; Thu, 20 Aug 2009 09:43:48 +0300 (EEST) Message-ID: <4A8CF111.5010901@hiit.fi> Date: Thu, 20 Aug 2009 09:45:37 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: hipsec@ietf.org References: <4A8C708D.4010503@htt-consult.com> <0DF156EE7414494187B087A3C279BDB404AD7C6A@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB404AD7C6A@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Selection of LSI address block 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, 20 Aug 2009 06:43:46 -0000 Ahrenholz, Jeffrey M wrote: Hi, >> We have discussed using 127.0.0.0 for LSIs, say >> 127.100.0.0/16, but will >> that really work? > > in the OpenHIP software we have a macro IN_LOOP() to check if an IPv4 > address is equal to > (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if the top bits equal 127 > (see /usr/include/netinet/in.h on Linux) > > I wonder if other applications use similar techniques to check for > loopback addresses? Using 127.100.0.0/16 would be problematic in that > case. many apps probably (?) just check 127.0.0.0/8 which could be a big problem for HIP. I would prefer getting a slot from 1.0.0.0/x address space to avoid such problems. We have been experimenting with the 1.0.0.0/x address space without any problems. From rgm@htt-consult.com Thu Aug 20 03:29:55 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5870E3A6FDF for ; Thu, 20 Aug 2009 03:29:55 -0700 (PDT) X-Quarantine-ID: <0-hVQNsbej8k> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "References" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 0-hVQNsbej8k for ; Thu, 20 Aug 2009 03:29:54 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id B249D3A6EA9 for ; Thu, 20 Aug 2009 03:29:29 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7KATEA5005227; Thu, 20 Aug 2009 06:29:14 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Thu, 20 Aug 2009 06:28:41 -0400 (EDT) Date: Thu, 20 Aug 2009 06:28:39 -0400 From: Robert Moskowitz To: miika.komu@hiit.fi Message-ID: <4A8D2557.4060705@htt-consult.com> In-Reply-To: <4A8CF111.5010901@hiit.fi> References: <4A8C708D.4010503@htt-consult.com> References: <0DF156EE7414494187B087A3C279BDB404AD7C6A@XCH-NW-6V1.nw.nos.boeing.com> References: <4A8CF111.5010901@hiit.fi> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Cc: hipsec@ietf.org Subject: Re: [Hipsec] Selection of LSI address block 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, 20 Aug 2009 10:29:55 -0000 Miika Komu wrote: > Ahrenholz, Jeffrey M wrote: > > Hi, > >>> We have discussed using 127.0.0.0 for LSIs, say 127.100.0.0/16, but >>> will that really work? >> >> in the OpenHIP software we have a macro IN_LOOP() to check if an IPv4 >> address is equal to (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if >> the top bits equal 127 >> (see /usr/include/netinet/in.h on Linux) >> >> I wonder if other applications use similar techniques to check for >> loopback addresses? Using 127.100.0.0/16 would be problematic in that >> case. > > many apps probably (?) just check 127.0.0.0/8 which could be a big > problem for HIP. I would prefer getting a slot from 1.0.0.0/x address > space to avoid such problems. We have been experimenting with the > 1.0.0.0/x address space without any problems. Then we need to make an official request from IANA. It should come from our chairs. But some text from our developers as to why 127 won't work MAY be of value. From rgm@htt-consult.com Thu Aug 20 08:14:55 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F323A6F24 for ; Thu, 20 Aug 2009 08:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 hIv9oHUN3De9 for ; Thu, 20 Aug 2009 08:14:55 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 808663A6FFC for ; Thu, 20 Aug 2009 08:14:34 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7KFEK9E024377 for ; Thu, 20 Aug 2009 11:14:20 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Thu, 20 Aug 2009 11:13:30 -0400 (EDT) Date: Thu, 20 Aug 2009 11:13:31 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A8D681B.2080901@htt-consult.com> In-Reply-To: <4A8C708D.4010503@htt-consult.com> References: <4A8C708D.4010503@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Subject: Re: [Hipsec] Selection of LSI address block 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, 20 Aug 2009 15:14:56 -0000 Robert Moskowitz wrote: > We need to come to a quick determination about what we use for LSIs. > > I have been asked by IANA for clearification on what HIP has been > using 1.0.0.0/8 for. I pointed them to the text from 4423 for now. But > note that Net1 has been released to the RIRs. Here is what I have been > told: > > ============================================= > > Whichever block is selected for HIP LSIs we will need to follow the > direction in section 4.1 of RFC 2860: Further along this please read: http://www.ietf.org/id/draft-iana-rfc3330bis-11.txt From rgm@htt-consult.com Thu Aug 20 08:15:44 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882553A6CD6 for ; Thu, 20 Aug 2009 08:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 hqcpn+1SOBNd for ; Thu, 20 Aug 2009 08:15:43 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by core3.amsl.com (Postfix) with ESMTP id 9C2A03A6A22 for ; Thu, 20 Aug 2009 08:15:43 -0700 (PDT) Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n7KFFZBH024439 for ; Thu, 20 Aug 2009 11:15:35 -0400 Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Thu, 20 Aug 2009 11:15:35 -0400 (EDT) Date: Thu, 20 Aug 2009 11:15:35 -0400 From: Robert Moskowitz To: hipsec@ietf.org Message-ID: <4A8D6897.6020105@htt-consult.com> In-Reply-To: <4A8C708D.4010503@htt-consult.com> References: <4A8C708D.4010503@htt-consult.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Disposition: inline Subject: [Hipsec] The workgroup rechartering process 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, 20 Aug 2009 15:15:44 -0000 As our chair pointed out, we DO have to get recharted by the IESG to actually get the agreement by the IESG that we are moving HIP from experimental to standards track. Anyone want to take a crack at the charter text? I hope our two chairs will agree to stay on for this next step. From thomas.r.henderson@boeing.com Thu Aug 20 13:49:54 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF7A28C15F for ; Thu, 20 Aug 2009 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 TQPhZZlNtUG5 for ; Thu, 20 Aug 2009 13:49:54 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 60BC028C176 for ; Thu, 20 Aug 2009 13:49:49 -0700 (PDT) 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 n7KKnEtG013696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2009 15:49:19 -0500 (CDT) 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 n7KKnExS028841; Thu, 20 Aug 2009 15:49:14 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7KKn56o028580; Thu, 20 Aug 2009 15:49:14 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:49:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Aug 2009 13:49:11 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4A8D2557.4060705@htt-consult.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Selection of LSI address block Thread-Index: AcohgS95UaY1iJZhRnWDassD525O4wALimiQ References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com> From: "Henderson, Thomas R" To: "Robert Moskowitz" , X-OriginalArrivalTime: 20 Aug 2009 20:49:12.0526 (UTC) FILETIME=[AC4356E0:01CA21D7] Cc: hipsec@ietf.org Subject: Re: [Hipsec] Selection of LSI address block 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, 20 Aug 2009 20:49:55 -0000 =20 > -----Original Message----- > From: Robert Moskowitz [mailto:rgm@htt-consult.com]=20 > Sent: Thursday, August 20, 2009 3:29 AM > To: miika.komu@hiit.fi > Cc: hipsec@ietf.org > Subject: Re: [Hipsec] Selection of LSI address block >=20 > Miika Komu wrote: > > Ahrenholz, Jeffrey M wrote: > > > > Hi, > > > >>> We have discussed using 127.0.0.0 for LSIs, say=20 > 127.100.0.0/16, but=20 > >>> will that really work? > >> > >> in the OpenHIP software we have a macro IN_LOOP() to check=20 > if an IPv4 > >> address is equal to (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if=20 > >> the top bits equal 127 > >> (see /usr/include/netinet/in.h on Linux) > >> > >> I wonder if other applications use similar techniques to check for > >> loopback addresses? Using 127.100.0.0/16 would be=20 > problematic in that > >> case. > > > > many apps probably (?) just check 127.0.0.0/8 which could be a big=20 > > problem for HIP. I would prefer getting a slot from=20 > 1.0.0.0/x address=20 > > space to avoid such problems. We have been experimenting with the=20 > > 1.0.0.0/x address space without any problems.=20 >=20 > Then we need to make an official request from IANA. >=20 >=20 > It should come from our chairs. But some text from our=20 > developers as to=20 > why 127 won't work MAY be of value. >=20 For use within the host only, I think it would be nice to get an allocation for this type of usage, but I don't think it is strictly required. It seems to me that the main requirement for LSIs is to use a range of 32-bit numbers that can be distinguished from destination IP addresses reachable from the host, but that are not in the range of special IP addresses (224/8, 127/8) that might be checked by applications. The other consideration is that some other overlay on the host is not using those same numbers (i.e. they need to be locally deconflicted). Use of private address space or just squatting on some other prefix like within 240/8 should also work and be permitted in the specifications (i.e. should be a matter of local deployments).=20 For use within a larger scope, such as a site, an address range in an existing private address block might be the best choice. If there is a request for special allocation, it might help to note that the need is more general than HIP and that other overlays could use this; i.e. maybe something like an "HID" (host identifier) prefix for IPv4, of which HIP is one use case. Tom From miika.komu@hiit.fi Thu Aug 20 14:07:30 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952073A6B95 for ; Thu, 20 Aug 2009 14:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzdZT3+0bJyC for ; Thu, 20 Aug 2009 14:07:29 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 92DC73A6A0C for ; Thu, 20 Aug 2009 14:07:29 -0700 (PDT) Received: from ip104.infrahip.net (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 811FE25ED16 for ; Fri, 21 Aug 2009 00:07:34 +0300 (EEST) Message-ID: <4A8DBB16.3010705@hiit.fi> Date: Fri, 21 Aug 2009 00:07:34 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: hip WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Hipsec] draft-ietf-hip-native-api-09-pre 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, 20 Aug 2009 21:07:30 -0000 Hi, we got an extra review to the native API from Stefan Götz. The new preversion is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre1.txt The changes are editorial readability changes throughout the document. Especially section 4.1 contains now more clarifications on the fields of sockaddr_hip structure and wildcards We'd like to move on with the document, but we have two questions for the working group: #1 How to future proof HITs in case we need 256 bit HITs? This is important also from the view point of comparison of HITs (currently draft suggests memcmp() in section 4.1. Unless, there's other suggestions, I'd go for alternative (i): * Alternative (i): separate sockaddr_hip structure for larger HITs * Alternative (ii): make larger HIT structure in sockaddr_hip with zero padding for 128 bit HITs #2 How should the socket calls react to only-hip wildcard. Currently section 4.1.1 describes: With the HIP_HIT_ANY address, the underlying system allows only HIP-based data flows with the corresponding socket. For incoming packets, the system transparently discards all other traffic arriving at the socket than HIP related. For outgoing packets, the system returns -1 in the socket call and sets errno to ECOMM when the system failed to deliver the packet over a HIP-based data channel. From miika.komu@hiit.fi Thu Aug 20 14:34:59 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCA43A6FB2 for ; Thu, 20 Aug 2009 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEnXIR3hAck4 for ; Thu, 20 Aug 2009 14:34:58 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id CFF3928C17D for ; Thu, 20 Aug 2009 14:34:41 -0700 (PDT) Received: from ip104.infrahip.net (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 1C2C525ED16 for ; Fri, 21 Aug 2009 00:34:47 +0300 (EEST) Message-ID: <4A8DC176.3000608@hiit.fi> Date: Fri, 21 Aug 2009 00:34:46 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: hip WG References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com> <77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Selection of LSI address block 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, 20 Aug 2009 21:34:59 -0000 Henderson, Thomas R wrote: Hi, >> -----Original Message----- >> From: Robert Moskowitz [mailto:rgm@htt-consult.com] >> Sent: Thursday, August 20, 2009 3:29 AM >> To: miika.komu@hiit.fi >> Cc: hipsec@ietf.org >> Subject: Re: [Hipsec] Selection of LSI address block >> >> Miika Komu wrote: >>> Ahrenholz, Jeffrey M wrote: >>> >>> Hi, >>> >>>>> We have discussed using 127.0.0.0 for LSIs, say >> 127.100.0.0/16, but >>>>> will that really work? >>>> in the OpenHIP software we have a macro IN_LOOP() to check >> if an IPv4 >>>> address is equal to (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if >>>> the top bits equal 127 >>>> (see /usr/include/netinet/in.h on Linux) >>>> >>>> I wonder if other applications use similar techniques to check for >>>> loopback addresses? Using 127.100.0.0/16 would be >> problematic in that >>>> case. >>> many apps probably (?) just check 127.0.0.0/8 which could be a big >>> problem for HIP. I would prefer getting a slot from >> 1.0.0.0/x address >>> space to avoid such problems. We have been experimenting with the >>> 1.0.0.0/x address space without any problems. >> Then we need to make an official request from IANA. >> >> >> It should come from our chairs. But some text from our >> developers as to >> why 127 won't work MAY be of value. >> > > For use within the host only, I think it would be nice to get an > allocation for this type of usage, but I don't think it is strictly > required. It seems to me that the main requirement for LSIs is to use a > range of 32-bit numbers that can be distinguished from destination IP > addresses reachable from the host, but that are not in the range of > special IP addresses (224/8, 127/8) that might be checked by > applications. The other consideration is that some other overlay on the > host is not using those same numbers (i.e. they need to be locally > deconflicted). Use of private address space or just squatting on some > other prefix like within 240/8 should also work and be permitted in the > specifications (i.e. should be a matter of local deployments). > > For use within a larger scope, such as a site, an address range in an > existing private address block might be the best choice. > > If there is a request for special allocation, it might help to note that > the need is more general than HIP and that other overlays could use > this; i.e. maybe something like an "HID" (host identifier) prefix for > IPv4, of which HIP is one use case. sorry, but I'd disagree on using private address realms for LSI. IMHO, the private address space is the worst choice for three reasons: 1) You have to guess which one private address space is unoccupied for NATs. 2) Mobility can cause more conflicts with the selection of the LSI prefix selection. Implementations would have to handle dynamic renumbering of the LSI prefix and it would be a mess! 3) Management for LSIs without a fixed prefix would be more complicated for ACLs in legacy apps. It makes the administrators life more complicated. The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is the second best, IMHO. From julienl@qualcomm.com Thu Aug 20 15:42:42 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8953A68E1 for ; Thu, 20 Aug 2009 15:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.707 X-Spam-Level: X-Spam-Status: No, score=-105.707 tagged_above=-999 required=5 tests=[AWL=0.892, 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 mQ522yIHJOvq for ; Thu, 20 Aug 2009 15:42:38 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 10BFA3A69F0 for ; Thu, 20 Aug 2009 15:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1250808163; x=1282344163; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Robert=20Moskowitz=20,=0D=0A =20=20=20=20=20=20=20=20"hipsec@ietf.org"=0D=0A=09|Date:=20Thu,=2020=20Aug=202009=2015:42:33=20-0 700|Subject:=20RE:=20[Hipsec]=20To=20tunnel=20or=20not |Thread-Topic:=20[Hipsec]=20To=20tunnel=20or=20not |Thread-Index:=20AcohHLh0sx+ps+NMRqydCWv+KMz0IgAxdJNw |Message-ID:=20|References:=20<4A8C7D0D.70 10708@htt-consult.com>|In-Reply-To:=20<4A8C7D0D.7010708@h tt-consult.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|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5715"=3B=20a=3D"22409517"; bh=GsHt9rMA/c5s5zSvX615u4E9SjHWBPmidc3DQcxq8+c=; b=QykU/fhmu1MGmZe2HuwDxvqsafpOg5wkKpjkXx2PjJkggEblnNdO0qqJ +c1DocKsFWrLMKpp40t+gKH96zEBMcCjITf/K82E3D6bfzMSptqFB4m6U YUzy8HZQDWz8GXs4e9Wt+KzYKojUD2C2y/Nz/zyALBsKsojlrYGpcHUf8 U=; X-IronPort-AV: E=McAfee;i="5300,2777,5715"; a="22409517" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2009 15:42:43 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7KMghoe024493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2009 15:42:43 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7KMgYqm022923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Aug 2009 15:42:34 -0700 (PDT) Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 20 Aug 2009 15:42:34 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 20 Aug 2009 15:42:34 -0700 From: "Laganier, Julien" To: Robert Moskowitz , "hipsec@ietf.org" Date: Thu, 20 Aug 2009 15:42:33 -0700 Thread-Topic: [Hipsec] To tunnel or not Thread-Index: AcohHLh0sx+ps+NMRqydCWv+KMz0IgAxdJNw Message-ID: References: <4A8C7D0D.7010708@htt-consult.com> In-Reply-To: <4A8C7D0D.7010708@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 Subject: Re: [Hipsec] To tunnel or not 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, 20 Aug 2009 22:42:42 -0000 Robert Moskowitz wrote: >=20 > ESP Transport in a bound, end-to-end operation >=20 > or >=20 > ESP Tunnel with HITS (or LSI?) explicit. >=20 > Developers have reported challenges in using what we have been calling > BEET mode, and have pointed out that if explicit tunnels were used, > then the special HIP "optimization" (? right word) of Transport mode wou= ld > be avoided. While implementing HIP circa 2002 the only reason I had to start hacking th= e kernel was that "optimization". Other than that I could run the same daem= on on FreeBSD and SunOS, and have the daemon configure IPsec SAs via PF_KEY= .=20 Thus I do agree that BEET is challenging to the extent that is not part of = standards IPsec implementation. Would BEET be a standard part of IPsec the = challenge would disappear. Is it likely? I don't think so... =20 > I have at least two technical problems with use of tunnel mode: >=20 > What is enumerated in the tunnel? HITs always or HITs for IPv6 apps > and LSIs for IPv4? (as we have demonstarted that IPv4 apps work well ove= r > HIP over IPv6). If HITs how will this work for IPv4? I suspect that > someone can explain how this could 'work'? The Security Policy Database I had had entries requiring use of ESP tunnel = mode for any communication between a local HITs or LSIs and any remote one. A given communication from a local HIT or LSI to a remote one would thus tr= igger via PF_KEY the HIP daemon to establish keys. The HIP daemon would in = turn insert a specific SPD entries requiring protection of communication be= tween the specific local and remote HIT/LSI via an ESP tunnel mode SA betwe= en the local and remote IP addresses (v4 or v6). =20 Thus for every association there's one or two SPD entries (keyed by local/r= emote HITs and/or LSIs), and the protection required by these entries is a= fforded by a tunnel mode SA between the local and remote IP addresses of th= e peers. > Would there be expectations on tunnel behaviour that would have to be > negotiated? I'm do not understand what sort of behavioral expectations you're talking a= bout. Can you tell us more.. =20 > My basic philosophy was ESP transport was used as a 'short hand' for > the HIP connection between two hosts. That HIP is not a key negotiation > for ESP, but that ESP is used operationally to simplify HIP (not to devel= op > YAP) with SPIs being pointers to the underlying HITs (did I remember > that right? :) ). I remember that. =20 But I'm not sure this is in contradiction with the use of HIP as a key mana= gement to setup IPsec tunnel mode security association between pair of HITs= (or LSIs.) These are IMHO two views of the same machinery. > I can see where the process between two hosts is a tunneling process > and in that HIP is used to secure the tunnel, but here the tunnel is not > coupled to HIP but rather the process between two hosts that uses HIP. > Does that make enough sense? Not sure I'm following you... --julien From jeffrey.m.ahrenholz@boeing.com Thu Aug 20 16:56:20 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17013A6EEF for ; Thu, 20 Aug 2009 16:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ474BVlwRbh for ; Thu, 20 Aug 2009 16:56:20 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 23AB528C14E for ; Thu, 20 Aug 2009 16:56:17 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7KNuAeI028179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 16:56:13 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7KNuAM3007088; Thu, 20 Aug 2009 16:56:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7KNu8Df007037; Thu, 20 Aug 2009 16:56:10 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 16:56:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Aug 2009 16:56:06 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4A8DBB16.3010705@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: Acoh2kBmoONXwfyIS2WtGKM/8dpOUAAD8TNQ References: <4A8DBB16.3010705@hiit.fi> From: "Ahrenholz, Jeffrey M" To: , "hip WG" X-OriginalArrivalTime: 20 Aug 2009 23:56:09.0991 (UTC) FILETIME=[CA64A970:01CA21F1] Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre 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, 20 Aug 2009 23:56:21 -0000 > we got an extra review to the native API from Stefan G=F6tz. The new=20 > preversion is here: >=20 > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre1.txt >=20 > The changes are editorial readability changes throughout the=20 > document. Especially section 4.1 contains now more clarifications on=20 > the fields of sockaddr_hip structure and wildcards I read the new preversion and it looks pretty good. Only this minor = editorial nits below: Sect 3.1 Interaction with the Resolver s/should be noticed/should be noted/ >=20 > We'd like to move on with the document, but we have two questions for=20 > the working group: >=20 > #1 How to future proof HITs in case we need 256 bit HITs? This is=20 > important also from the view point of comparison of HITs (currently=20 > draft suggests memcmp() in section 4.1. Unless, there's other=20 > suggestions, I'd go for alternative (i): >=20 > * Alternative (i): separate sockaddr_hip structure for=20 > larger HITs > * Alternative (ii): make larger HIT structure in=20 > sockaddr_hip with=20 > zero padding for 128 bit HITs yes I like alternative (i) better than (ii); maybe you could make use of = ship_flags to indicate new ship_hit bit sizes in the future note that in section 4.1.1 you also describe storing IPv6 and = IPv4-mapped addresses in the ship_hit field; (should the ship_flags = indicate these locator types?) in the future you would need to come up = with new mappings, such as IPv4/IPv6-mapped to a 256 bit HIT. why is HIP_HIT_ANY_TMP used for anonymous identifiers? maybe it should = be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB? =20 > #2 How should the socket calls react to only-hip wildcard. Currently=20 > section 4.1.1 describes: >=20 > With the HIP_HIT_ANY address, > the underlying system allows only HIP-based data flows with the > corresponding socket. For incoming packets, the system=20 > transparently > discards all other traffic arriving at the socket than=20 > HIP related. > For outgoing packets, the system returns -1 in the socket call and > sets errno to ECOMM when the system failed to deliver the=20 > packet over > a HIP-based data channel. maybe you are asking if the text is enough? it seems fairly clear to me: - bind() to HIP_HIT_ANY and the socket provides you only with HIP data - connect() to HIP_HIT_ANY and you are required to specify a locator = (sect 4.6) (and I assume it would establish an association w/anonymous = I1) - error under other circumstances -Jeff From thomas.r.henderson@boeing.com Thu Aug 20 21:40:15 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7823A69EE for ; Thu, 20 Aug 2009 21:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 LLD8HKGkDZTX for ; Thu, 20 Aug 2009 21:40:13 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id C0C953A6B40 for ; Thu, 20 Aug 2009 21:40:12 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7L4dwXv023424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2009 21:39:59 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7L4dwWN022739; Thu, 20 Aug 2009 23:39:58 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7L4dvN2022728; Thu, 20 Aug 2009 23:39:58 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 21:39:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Aug 2009 21:39:33 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B7265@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4A8DC176.3000608@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Selection of LSI address block Thread-Index: Acoh3hdouJ/OuY7eSN6HyUyY1ofU0QAOFBkg References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com><77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> <4A8DC176.3000608@hiit.fi> From: "Henderson, Thomas R" To: , "hip WG" X-OriginalArrivalTime: 21 Aug 2009 04:39:57.0685 (UTC) FILETIME=[6FB09250:01CA2219] Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 04:40:15 -0000 =20 > -----Original Message----- > From: Miika Komu [mailto:miika.komu@hiit.fi]=20 > Sent: Thursday, August 20, 2009 2:35 PM > To: hip WG > Subject: Re: [Hipsec] Selection of LSI address block >=20 > Henderson, Thomas R wrote: >=20 > > For use within a larger scope, such as a site, an address=20 > range in an > > existing private address block might be the best choice. > >=20 >=20 > sorry, but I'd disagree on using private address realms for=20 > LSI. IMHO,=20 > the private address space is the worst choice for three reasons: >=20 > 1) You have to guess which one private address space is=20 > unoccupied for NATs. Yes, I agree that if all private addresses are in use in a site, or one cannot determine which addresses are likely to be active, then private space may not be a good choice. However, many sites where HIP may be deployed may not otherwise use private space at all. Also, note that some applications (e.g. virtual machine monitors) already scan networks for unused private subnets and start using them once a vacant one is found. > 2) Mobility can cause more conflicts with the selection of the LSI=20 > prefix selection. Implementations would have to handle dynamic=20 > renumbering of the LSI prefix and it would be a mess! Yes, if you are roaming into unknown networks, this would be a bad choice. > 3) Management for LSIs without a fixed prefix would be more=20 > complicated=20 > for ACLs in legacy apps. It makes the administrators life=20 > more complicated. >=20 What kind of ACLs in applications are you thinking of? > The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is=20 > the second=20 > best, IMHO. I agree that if we can obtain a full /8 for LSIs or host identities, that would be easiest. I'm not sure 127/8 is preferable to private space for the reasons Jeff mentioned, but it probably should be tested. If we were to obtain a smaller prefix such as /16, it probably would still be OK but would reduce the likelihood that LSIs could easily be randomly generated (such as using the low order bits of the HIT) without collisions. I would be willing to amend my previous statement such as: For use within a larger scope, such as a site, an address range in an existing private address block might be the best choice, unless the host may, in the future, move to or obtain an address on a network=20 that uses such private addressing. Anyway, it is not going to affect interoperability if an implementation chooses an unused private address block, an unallocated block, or something like Net1. Tom From miika.komu@hiit.fi Thu Aug 20 21:42:42 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5FC3A6405 for ; Thu, 20 Aug 2009 21:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WamMZLsCZyIp for ; Thu, 20 Aug 2009 21:42:40 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 3835C3A6A0A for ; Thu, 20 Aug 2009 21:42:40 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 23E6225ED16; Fri, 21 Aug 2009 07:42:45 +0300 (EEST) Message-ID: <4A8E25C6.1090100@hiit.fi> Date: Fri, 21 Aug 2009 07:42:46 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 04:42:42 -0000 Ahrenholz, Jeffrey M wrote: Hi Jeff, thanks for feedback! Let's iterate further. >> we got an extra review to the native API from Stefan Götz. The new >> preversion is here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre1.txt >> >> The changes are editorial readability changes throughout the >> document. Especially section 4.1 contains now more clarifications on >> the fields of sockaddr_hip structure and wildcards > > I read the new preversion and it looks pretty good. Only this minor editorial nits below: > Sect 3.1 Interaction with the Resolver > s/should be noticed/should be noted/ thanks. >> We'd like to move on with the document, but we have two questions for >> the working group: >> >> #1 How to future proof HITs in case we need 256 bit HITs? This is >> important also from the view point of comparison of HITs (currently >> draft suggests memcmp() in section 4.1. Unless, there's other >> suggestions, I'd go for alternative (i): >> >> * Alternative (i): separate sockaddr_hip structure for >> larger HITs >> * Alternative (ii): make larger HIT structure in >> sockaddr_hip with >> zero padding for 128 bit HITs > > yes I like alternative (i) better than (ii); Ok. Notice that this option would need also flag in the resolver call to force the resolve to return larger HITs. > maybe you could make use of ship_flags to indicate new ship_hit bit sizes in the future Your comment is related to option ii. There is a 128-bit reserved field after the HIT in the sockaddr_hip structure, so this is possible even now. However, the problem is with existing applications because they will hard-code ACL checks with sizeof(128 bits), so we'd really need an union or something to force the sizeof to be always 256 bits. Otherwise, the application compares only 128 bits of the HIT. Setting HIP_HIT_ANY_* will also become more tricky with the union and we'd need to specify explicitly where to fill them in (since the resolver is not currently specified to fill them in automatically). So, the 128-bit reserved field cannot really be used for extending the size of the HIT and we really need a completely new structure for them? Jeff, what do you think about this? Are the associate problems now more clear? I think it's important to get this right. > note that in section 4.1.1 you also describe storing IPv6 and IPv4-mapped addresses in the ship_hit field; (should the ship_flags indicate these locator types?) in the future you would need to come up with new mappings, such as IPv4/IPv6-mapped to a 256 bit HIT. It's redundant information because the HIT has always a separate prefix. sockaddr_is_srcaddr() can be used to verify local HITs, but not peer. Should we actually have a function/macro called HIP_IS_HIT()? Or just add a flag as you suggested to avoid each application to hard-code their own macros for this? What do you think? > why is HIP_HIT_ANY_TMP used for anonymous identifiers? maybe it should be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB? To align it with RFC5014 constants. Do you think ANON would be more clear? >> #2 How should the socket calls react to only-hip wildcard. Currently >> section 4.1.1 describes: >> >> With the HIP_HIT_ANY address, >> the underlying system allows only HIP-based data flows with the >> corresponding socket. For incoming packets, the system >> transparently >> discards all other traffic arriving at the socket than >> HIP related. >> For outgoing packets, the system returns -1 in the socket call and >> sets errno to ECOMM when the system failed to deliver the >> packet over >> a HIP-based data channel. > > maybe you are asking if the text is enough? Yes and I was asking also what should the actual error value be (pick one from /usr/include/asm-generic/errno.h)? It could be also ETIMEDOUT because the peer failed to respond with an R1. Or in the case of hiccups, there was no response from the transport layer... In comparison, it seems like SCTP API just typically ignores errno issues with "the variable errno is then set appropriately": http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 > it seems fairly clear to me: > - bind() to HIP_HIT_ANY and the socket provides you only with HIP data > - connect() to HIP_HIT_ANY and you are required to specify a locator (sect 4.6) (and I assume it would establish an association w/anonymous I1) > - error under other circumstances There is a separate error message when there is no locator with connect() in section 4.2.1: When the system fails to provide the mapping, it returns -1 in the called sockets API function to the application and sets errno to EADDRNOTAVAIL. From miika.komu@hiit.fi Thu Aug 20 21:50:40 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADDC3A6359 for ; Thu, 20 Aug 2009 21:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8PA0tRuWglm for ; Thu, 20 Aug 2009 21:50:39 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 57A303A6405 for ; Thu, 20 Aug 2009 21:50:39 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 9334225ED16; Fri, 21 Aug 2009 07:50:44 +0300 (EEST) Message-ID: <4A8E27A6.3050504@hiit.fi> Date: Fri, 21 Aug 2009 07:50:46 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com><77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> <4A8DC176.3000608@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D0A8B7265@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0A8B7265@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 04:50:40 -0000 Henderson, Thomas R wrote: Hi, >> -----Original Message----- >> From: Miika Komu [mailto:miika.komu@hiit.fi] >> Sent: Thursday, August 20, 2009 2:35 PM >> To: hip WG >> Subject: Re: [Hipsec] Selection of LSI address block >> >> Henderson, Thomas R wrote: >> >>> For use within a larger scope, such as a site, an address >> range in an >>> existing private address block might be the best choice. >>> >> sorry, but I'd disagree on using private address realms for >> LSI. IMHO, >> the private address space is the worst choice for three reasons: >> >> 1) You have to guess which one private address space is >> unoccupied for NATs. > > Yes, I agree that if all private addresses are in use in a site, or one > cannot determine which addresses are likely to be active, then private > space may not be a good choice. However, many sites where HIP may be > deployed may not otherwise use private space at all. Also, note that > some applications (e.g. virtual machine monitors) already scan networks > for unused private subnets and start using them once a vacant one is > found. there may be also some applications that don't scan networking and assume that all 192.168.0.0 and 10.0.0.0 networks are NATted. Such as p2p software. >> 2) Mobility can cause more conflicts with the selection of the LSI >> prefix selection. Implementations would have to handle dynamic >> renumbering of the LSI prefix and it would be a mess! > > Yes, if you are roaming into unknown networks, this would be a bad > choice. > >> 3) Management for LSIs without a fixed prefix would be more >> complicated >> for ACLs in legacy apps. It makes the administrators life >> more complicated. >> > > What kind of ACLs in applications are you thinking of? The admin can allow only secure and/or authenticated communications with LSI-based ACLs in existing legacy applications. Either the whole LSI prefix or individual LSIs (that are locally statically mapped to HIs). Think about the ACLs in apache, sendmail or /etc/hosts.allow. >> The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is >> the second >> best, IMHO. > > I agree that if we can obtain a full /8 for LSIs or host identities, > that would be easiest. I'm not sure 127/8 is preferable to private > space for the reasons Jeff mentioned, but it probably should be tested. > If we were to obtain a smaller prefix such as /16, it probably would > still be OK but would reduce the likelihood that LSIs could easily be > randomly generated (such as using the low order bits of the HIT) without > collisions. > > I would be willing to amend my previous statement such as: > > For use within a larger scope, such as a site, an address range in an > existing private address block might be the best choice, unless the > host may, in the future, move to or obtain an address on a network > that uses such private addressing. > > Anyway, it is not going to affect interoperability if an implementation > chooses an unused private address block, an unallocated block, or > something like Net1. I think it would be better for usability of HIP if the "secure prefix" for LSIs would be always the same independently of the individual hosts. It's not really application layer issue, but rather human layer issue. From thomas.r.henderson@boeing.com Thu Aug 20 22:09:54 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868543A68B9 for ; Thu, 20 Aug 2009 22:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 Whm003b-ZTeK for ; Thu, 20 Aug 2009 22:09:53 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EB23D3A6D0A for ; Thu, 20 Aug 2009 22:09:17 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7L599h7022905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Aug 2009 22:09:12 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7L599Hc020548; Fri, 21 Aug 2009 00:09:09 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7L599EU020540; Fri, 21 Aug 2009 00:09:09 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 22:09:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Aug 2009 22:08:29 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B7266@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4A8E27A6.3050504@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Selection of LSI address block Thread-Index: AcoiGvL3U/4ZzvybRwGMFV51A5ynTAAAhBsQ References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com><77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> <4A8DC176.3000608@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D0A8B7265@XCH-NW-5V1.nw.nos.boeing.com> <4A8E27A6.3050504@hiit.fi> From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 21 Aug 2009 05:09:09.0093 (UTC) FILETIME=[839C3950:01CA221D] Cc: hip WG Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 05:09:54 -0000 =20 >=20 > there may be also some applications that don't scan networking and=20 > assume that all 192.168.0.0 and 10.0.0.0 networks are NATted. Such as=20 > p2p software. good point. Although this would be akin to a case where both peers are behind the same NAT, it may cause extra NAT traversal machinery to kick in. >=20 > >> 2) Mobility can cause more conflicts with the selection of the LSI=20 > >> prefix selection. Implementations would have to handle dynamic=20 > >> renumbering of the LSI prefix and it would be a mess! > >=20 > > Yes, if you are roaming into unknown networks, this would be a bad > > choice. > >=20 > >> 3) Management for LSIs without a fixed prefix would be more=20 > >> complicated=20 > >> for ACLs in legacy apps. It makes the administrators life=20 > >> more complicated. > >> > >=20 > > What kind of ACLs in applications are you thinking of? >=20 > The admin can allow only secure and/or authenticated=20 > communications with=20 > LSI-based ACLs in existing legacy applications. Either the whole LSI=20 > prefix or individual LSIs (that are locally statically mapped=20 > to HIs).=20 > Think about the ACLs in apache, sendmail or /etc/hosts.allow. Yes, but I was thinking that whatever LSI prefix was selected, it has to be put into such ACLs-- I'm not sure private addresses really changes this much. >=20 > >> The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is=20 > >> the second=20 > >> best, IMHO. > >=20 > > I agree that if we can obtain a full /8 for LSIs or host identities, > > that would be easiest. I'm not sure 127/8 is preferable to private > > space for the reasons Jeff mentioned, but it probably=20 > should be tested. > > If we were to obtain a smaller prefix such as /16, it probably would > > still be OK but would reduce the likelihood that LSIs could=20 > easily be > > randomly generated (such as using the low order bits of the=20 > HIT) without > > collisions. > >=20 > > I would be willing to amend my previous statement such as: > >=20 > > For use within a larger scope, such as a site, an address=20 > range in an > > existing private address block might be the best choice, unless the > > host may, in the future, move to or obtain an address on a network=20 > > that uses such private addressing. > >=20 > > Anyway, it is not going to affect interoperability if an=20 > implementation > > chooses an unused private address block, an unallocated block, or > > something like Net1. >=20 > I think it would be better for usability of HIP if the=20 > "secure prefix"=20 > for LSIs would be always the same independently of the=20 > individual hosts.=20 > It's not really application layer issue, but rather human layer issue. Agreed, if we can obtain it. Tom From miika.komu@hiit.fi Thu Aug 20 22:18:08 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758663A687B for ; Thu, 20 Aug 2009 22:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUD5OikbbK+c for ; Thu, 20 Aug 2009 22:18:07 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id A1D713A68F2 for ; Thu, 20 Aug 2009 22:18:07 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id CA12525ED16 for ; Fri, 21 Aug 2009 08:18:12 +0300 (EEST) Message-ID: <4A8E2E16.3060305@hiit.fi> Date: Fri, 21 Aug 2009 08:18:14 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: HIP References: <4A8CF111.5010901@hiit.fi> <4A8D2557.4060705@htt-consult.com><77F357662F8BFA4CA7074B0410171B6D0A8B7264@XCH-NW-5V1.nw.nos.boeing.com> <4A8DC176.3000608@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D0A8B7265@XCH-NW-5V1.nw.nos.boeing.com> <4A8E27A6.3050504@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D0A8B7266@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0A8B7266@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Selection of LSI address block X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 05:18:08 -0000 Henderson, Thomas R wrote: Hi, >> there may be also some applications that don't scan networking and >> assume that all 192.168.0.0 and 10.0.0.0 networks are NATted. Such as >> p2p software. > > good point. Although this would be akin to a case where both peers are > behind the same NAT, it may cause extra NAT traversal machinery to kick > in. btw, I am not saying that this is the right way to implement applications. In fact, ICE has a completely different philosophy which is more obvious when you think about building a large, isolate "lab" network from the private address range. But some apps, nevertheless, are just doing this even though it's "wrong". From thomas.r.henderson@boeing.com Fri Aug 21 11:15:48 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338533A6B5A for ; Fri, 21 Aug 2009 11:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 UQpMmY-JSMT4 for ; Fri, 21 Aug 2009 11:15:47 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 64B303A6A56 for ; Fri, 21 Aug 2009 11:15:47 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7LIFeBU012257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 11:15:43 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7LIFeH8002030; Fri, 21 Aug 2009 11:15:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7LIFZtA001854; Fri, 21 Aug 2009 11:15:40 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 11:15:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 11:15:27 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0A8B726A@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <4A8DBB16.3010705@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: Acoh2kDFlmojcBgNR5SB5TwJJBC8RAAr/w9g References: <4A8DBB16.3010705@hiit.fi> From: "Henderson, Thomas R" To: , "hip WG" X-OriginalArrivalTime: 21 Aug 2009 18:15:38.0397 (UTC) FILETIME=[62A094D0:01CA228B] Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:15:48 -0000 =20 > #2 How should the socket calls react to only-hip wildcard. Currently=20 > section 4.1.1 describes: >=20 > With the HIP_HIT_ANY address, > the underlying system allows only HIP-based data flows with the > corresponding socket. For incoming packets, the system=20 > transparently > discards all other traffic arriving at the socket than=20 > HIP related. > For outgoing packets, the system returns -1 in the socket call and > sets errno to ECOMM when the system failed to deliver the=20 > packet over > a HIP-based data channel. I would like to suggest these changes to the above paragraph: With the HIP_HIT_ANY address, the underlying system allows only HIP-based data flows with the corresponding socket. For incoming packets, the system discards all non-HIP-related traffic arriving at the socket. For outgoing packets, the system returns -1 in the socket call and sets errno to an appropriate error type when the system failed to deliver the packet over a HIP-based data channel. rationale: 1) for incoming datagrams, "discards" rather than "transparently discards" is a policy issue that is not related to the API (e.g. whether a system returns some type of ICMP error is out of scope for the API specification) 2) for outgoing packets, different systems appear to specify different errnos under different circumstances, so it probably is too restrictive to specify ECOMM here. ECOMM, for instance, does not appear to be an error type returned by Linux as a failure code for connect(). Tom From miika.komu@hiit.fi Mon Aug 24 01:56:02 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E876C3A6A03 for ; Mon, 24 Aug 2009 01:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAc3FiDp9ZM2 for ; Mon, 24 Aug 2009 01:55:59 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id CAD3F28C155 for ; Mon, 24 Aug 2009 01:55:58 -0700 (PDT) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 2057825ED0F; Mon, 24 Aug 2009 11:56:03 +0300 (EEST) Message-ID: <4A9255A2.1010903@hiit.fi> Date: Mon, 24 Aug 2009 11:56:02 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Henderson, Thomas R" References: <4A8DBB16.3010705@hiit.fi> <77F357662F8BFA4CA7074B0410171B6D0A8B726A@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0A8B726A@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre 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: Mon, 24 Aug 2009 08:56:03 -0000 Henderson, Thomas R wrote: Hi, >> #2 How should the socket calls react to only-hip wildcard. Currently >> section 4.1.1 describes: >> >> With the HIP_HIT_ANY address, >> the underlying system allows only HIP-based data flows with the >> corresponding socket. For incoming packets, the system >> transparently >> discards all other traffic arriving at the socket than >> HIP related. >> For outgoing packets, the system returns -1 in the socket call and >> sets errno to ECOMM when the system failed to deliver the >> packet over >> a HIP-based data channel. > > I would like to suggest these changes to the above paragraph: > > With the HIP_HIT_ANY address, > the underlying system allows only HIP-based data flows with the > corresponding socket. For incoming packets, the system > discards all non-HIP-related traffic arriving at the socket. > For outgoing packets, the system returns -1 in the socket call and > sets errno to an appropriate error type when the system failed to > deliver the packet over > a HIP-based data channel. > > rationale: > 1) for incoming datagrams, "discards" rather than "transparently > discards" is a policy issue that is not related to the API (e.g. whether > a system returns some type of ICMP error is out of scope for the API > specification) > 2) for outgoing packets, different systems appear to specify different > errnos under different circumstances, so it probably is too restrictive > to specify ECOMM here. ECOMM, for instance, does not appear to be an > error type returned by Linux as a failure code for connect(). seems reasonable to me. From miika.komu@hiit.fi Mon Aug 24 04:44:26 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8063A6971 for ; Mon, 24 Aug 2009 04:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntwKCoKiRJiy for ; Mon, 24 Aug 2009 04:44:26 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 8D8093A6D1B for ; Mon, 24 Aug 2009 04:44:08 -0700 (PDT) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 2B51525ED14; Mon, 24 Aug 2009 14:44:14 +0300 (EEST) Message-ID: <4A927D0D.7040707@hiit.fi> Date: Mon, 24 Aug 2009 14:44:13 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Moskowitz References: <4A72A3EF.90603@htt-consult.com> In-Reply-To: <4A72A3EF.90603@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] HIP support of AH on IPv6 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: Mon, 24 Aug 2009 11:44:26 -0000 Robert Moskowitz wrote: Hi, AH is basically a subset of ESP, so having e.g. ESP with tunnel mode supported would be more beneficial in terms of legacy systems? I had a discussion with Tony Hain last night and was reminded that there > ARE some valid uses for AH, particularly in IPv6. > > Any feelings about this? > > Would it be 'easy' to add AH support to our rev of 5202? > > Or is a case of cut and paste and make a new document? > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From miika.komu@hiit.fi Mon Aug 24 04:45:40 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4433A6A4C for ; Mon, 24 Aug 2009 04:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmflkwldM-Ab for ; Mon, 24 Aug 2009 04:45:39 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 599BD3A6783 for ; Mon, 24 Aug 2009 04:45:39 -0700 (PDT) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 4F8EC25ED14; Mon, 24 Aug 2009 14:45:45 +0300 (EEST) Message-ID: <4A927D69.60402@hiit.fi> Date: Mon, 24 Aug 2009 14:45:45 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Moskowitz References: <4A72AF52.90603@htt-consult.com> In-Reply-To: <4A72AF52.90603@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Building the first list of to Standards changes 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: Mon, 24 Aug 2009 11:45:40 -0000 Robert Moskowitz wrote: Hi, > Compressing Transport checksums > New HIP option? can you elaborate on this? From miika.komu@hiit.fi Mon Aug 24 05:20:51 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D3928B23E for ; Mon, 24 Aug 2009 05:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZC6KEieuhAC for ; Mon, 24 Aug 2009 05:20:50 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 999703A659C for ; Mon, 24 Aug 2009 05:20:49 -0700 (PDT) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id A7FB625ED0F; Mon, 24 Aug 2009 15:20:55 +0300 (EEST) Message-ID: <4A9285A7.4020704@hiit.fi> Date: Mon, 24 Aug 2009 15:20:55 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Moskowitz References: <4A8C7D0D.7010708@htt-consult.com> In-Reply-To: <4A8C7D0D.7010708@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] To tunnel or not 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: Mon, 24 Aug 2009 12:20:51 -0000 Robert Moskowitz wrote: Hi, > ESP Transport in a bound, end-to-end operation > > or > > ESP Tunnel with HITS (or LSI?) explicit. > > Developers have reported challenges in using what we have been calling > BEET mode, and have pointed out that if explicit tunnels were used, then > the special HIP "optimization" (? right word) of Transport mode would > be avoided. > > I have at least two technical problems with use of tunnel mode: > > What is enumerated in the tunnel? HITs always or HITs for IPv6 apps and > LSIs for IPv4? (as we have demonstarted that IPv4 apps work well over > HIP over IPv6). If HITs how will this work for IPv4? I suspect that > someone can explain how this could 'work'? We have two choices: a) Let the tunnel enumerate both LSI and HITs b) Let the tunnel enumerate only HITs. LSIs must be translated locally to HITs as with BEET. Option (a) is bad because LSIs are supposed to be local. So I'd vote for option (b). > Would there be expectations on tunnel behaviour that would have to be > negotiated? I think we should modularize negotiation to support different protocols (ESP vs. AH vs. some other like S-RTP) and their modes (tunnel vs. transport vs. beet). > My basic philosophy was ESP transport was used as a 'short hand' for the > HIP connection between two hosts. That HIP is not a key negotiation for > ESP, but that ESP is used operationally to simplify HIP (not to develop > YAP) with SPIs being pointers to the underlying HITs (did I remember > that right? :) ). > > I can see where the process between two hosts is a tunneling process and > in that HIP is used to secure the tunnel, but here the tunnel is not > coupled to HIP but rather the process between two hosts that uses HIP. > Does that make enough sense? > > These are reasonable questions that have been asked of me over the past > year, and I would like to get some other's views. Yes, it makes sense. From jeffrey.m.ahrenholz@boeing.com Mon Aug 24 10:16:58 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D343A6A91 for ; Mon, 24 Aug 2009 10:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Nn7YNJdOim for ; Mon, 24 Aug 2009 10:16:57 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id EF17328C2CC for ; Mon, 24 Aug 2009 10:16:55 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OHGrlY010288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 12:16:54 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OHGr2g022801; Mon, 24 Aug 2009 10:16:53 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OHGqL3022747; Mon, 24 Aug 2009 10:16:53 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 10:16:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 10:16:50 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4A8E25C6.1090100@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: AcoiGdVOYJD1krYvQkmsS0Lj7teqbgCwDcGw References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 24 Aug 2009 17:16:52.0084 (UTC) FILETIME=[AC052B40:01CA24DE] Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:16:58 -0000 > So, the 128-bit reserved field cannot really be used for=20 > extending the size of the HIT and we really need a completely new=20 > structure for them? OK, I overlooked the 128-bit ship_reserved field. Yes it seems like we need a new structure; right now we're considering 256-bit HITs but what about 512, 1024, etc.? > Jeff, what do you think about this? Are the associate=20 > problems now more=20 > clear? I think it's important to get this right. will larger HITs share the same prefix as existing 128-bit HITs?=20 if we have different prefixes, API calls can use sockaddr with sa_family=3DAF_HIP and we can inspect the prefix to determine the = bitsize; this is a departure from the sa_family alone determining the size of the structure > Should we actually have a function/macro called HIP_IS_HIT()? Or just=20 > add a flag as you suggested to avoid each application to=20 > hard-code their own macros for this? What do you think? Yes I think this HIP_IS_HIT() macro would be helpful. > > why is HIP_HIT_ANY_TMP used for anonymous identifiers?=20 > maybe it should be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB? >=20 > To align it with RFC5014 constants. Do you think ANON would=20 > be more clear? The _TMP is OK, makes sense to align with RFC 5014 terminology. =20 > Yes and I was asking also what should the actual error value be (pick=20 > one from /usr/include/asm-generic/errno.h)? It could be also=20 > ETIMEDOUT=20 > because the peer failed to respond with an R1. Or in the case of=20 > hiccups, there was no response from the transport layer... >=20 > In comparison, it seems like SCTP API just typically ignores errno=20 > issues with "the variable errno is then set appropriately": >=20 > http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 I think that Tom's suggested text addresses this with the "set errno appropriately" language. -Jeff From miika.komu@hiit.fi Mon Aug 24 14:26:17 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40203A6EC8 for ; Mon, 24 Aug 2009 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV4qOZ7IXE7s for ; Mon, 24 Aug 2009 14:26:17 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 923AA3A6EC9 for ; Mon, 24 Aug 2009 14:26:16 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id A0B2125ED0F; Tue, 25 Aug 2009 00:26:21 +0300 (EEST) Message-ID: <4A930581.8080100@hiit.fi> Date: Tue, 25 Aug 2009 00:26:25 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre 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: Mon, 24 Aug 2009 21:26:18 -0000 Ahrenholz, Jeffrey M wrote: Hi, thanks Jeff for feedback! >> So, the 128-bit reserved field cannot really be used for >> extending the size of the HIT and we really need a completely new >> structure for them? > > OK, I overlooked the 128-bit ship_reserved field. Yes it seems like we > need a new structure; right now we're considering 256-bit HITs but what > about 512, 1024, etc.? Good point. The maximum size for a socket address structure is 255 octets. Unfortunately, the old "endpoint descriptor" concept was voted out (at apps and hip area) and it would have been nice for this purpose. It proposed basically a handle that could hide an identifier of any size. >> Jeff, what do you think about this? Are the associate >> problems now more >> clear? I think it's important to get this right. > > will larger HITs share the same prefix as existing 128-bit HITs? Good question and we probably don't have a good answer for this now. > if we have different prefixes, API calls can use sockaddr with > sa_family=AF_HIP and we can inspect the prefix to determine the bitsize; > this is a departure from the sa_family alone determining the size of the > structure The sockets API basically gives constant size data structures for applications. I think we shouldn't break this design pattern. So reserving a constant size extension field is ok, but variable size structure (with the same name) is probably not a good idea. Based on this discussion, it appears that the best way for future proofing is to include a flag for getaddrinfo() in the hints arguments that will result in sockaddr_hip_long structures instead of sockaddr_hip. This way, applications get exactly what they want and can store the HITs easily in their ACLs. I'd also remove the extra space reserved space because it seems that it's not very usable for future proofing as it is now. Jeff, how do you feel about this or do you have a better suggestion? >> Should we actually have a function/macro called HIP_IS_HIT()? Or just >> add a flag as you suggested to avoid each application to >> hard-code their own macros for this? What do you think? > > Yes I think this HIP_IS_HIT() macro would be helpful. Ok. Then we'll have one function for testing the local HITs and a second one for testing both local and peer HITs. Is this ok or should they be unified? >>> why is HIP_HIT_ANY_TMP used for anonymous identifiers? >> maybe it should be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB? >> >> To align it with RFC5014 constants. Do you think ANON would >> be more clear? > > The _TMP is OK, makes sense to align with RFC 5014 terminology. Ok. >> Yes and I was asking also what should the actual error value be (pick >> one from /usr/include/asm-generic/errno.h)? It could be also >> ETIMEDOUT >> because the peer failed to respond with an R1. Or in the case of >> hiccups, there was no response from the transport layer... >> >> In comparison, it seems like SCTP API just typically ignores errno >> issues with "the variable errno is then set appropriately": >> >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19 > > I think that Tom's suggested text addresses this with the "set errno > appropriately" language. Agreed. From andrew@indranet.co.nz Mon Aug 24 14:40:16 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739C73A6978 for ; Mon, 24 Aug 2009 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 0XzOjvHzHQuq for ; Mon, 24 Aug 2009 14:40:15 -0700 (PDT) Received: from mail.indranet.co.nz (unknown [203.97.93.68]) by core3.amsl.com (Postfix) with ESMTP id 3A6EE3A6EE3 for ; Mon, 24 Aug 2009 14:39:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.indranet.co.nz (Postfix) with ESMTP id E1BC2A4295B; Tue, 25 Aug 2009 09:39:22 +1200 (NZST) X-Virus-Scanned: amavisd-new at indranet.co.nz Received: from mail.indranet.co.nz ([127.0.0.1]) by localhost (XServe-2.acheron.indranet.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQzwRoa6Nv6y; Tue, 25 Aug 2009 09:39:21 +1200 (NZST) Received: from [192.168.1.98] (203-167-186-3.dsl.clear.net.nz [203.167.186.3]) by mail.indranet.co.nz (Postfix) with ESMTP id 263EAA42951; Tue, 25 Aug 2009 09:39:21 +1200 (NZST) Message-Id: From: Andrew McGregor To: miika.komu@hiit.fi In-Reply-To: <4A930581.8080100@hiit.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 09:39:19 +1200 References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> X-Mailer: Apple Mail (2.936) Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 21:40:16 -0000 On 25/08/2009, at 9:26 AM, Miika Komu wrote: > > The sockets API basically gives constant size data structures for > applications. I think we shouldn't break this design pattern. So > reserving a constant size extension field is ok, but variable size > structure (with the same name) is probably not a good idea. > > Based on this discussion, it appears that the best way for future > proofing is to include a flag for getaddrinfo() in the hints > arguments that will result in sockaddr_hip_long structures instead > of sockaddr_hip. This way, applications get exactly what they want > and can store the HITs easily in their ACLs. I'd also remove the > extra space reserved space because it seems that it's not very > usable for future proofing as it is now. > > Jeff, how do you feel about this or do you have a better suggestion? I think you'd be better to define more than a flag... an explicit size (or enum) would be better. That way if some other odd size becomes a requirement later, it's not such an annoyance to fit in to the API Andrew From jeffrey.m.ahrenholz@boeing.com Mon Aug 24 15:25:03 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E0F3A68A7 for ; Mon, 24 Aug 2009 15:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMcKPkU+RBWP for ; Mon, 24 Aug 2009 15:25:02 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0593628C255 for ; Mon, 24 Aug 2009 15:24:21 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OMODZ0005960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 17:24:23 -0500 (CDT) 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 n7OMODCR024355; Mon, 24 Aug 2009 15:24:13 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OMOCJC024352; Mon, 24 Aug 2009 15:24:12 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:24:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 15:24:08 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C7B@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4A930581.8080100@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: AcolAbqGICL9M5R2RYGTu0WQlYigtAABorWQ References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 24 Aug 2009 22:24:09.0560 (UTC) FILETIME=[999CBD80:01CA2509] Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:25:03 -0000 >> Yes I think this HIP_IS_HIT() macro would be helpful. >=20 > Ok. Then we'll have one function for testing the local HITs=20 > and a second one for testing both local and peer HITs. Is this ok or=20 > should they be unified? seems like separate functions/macros are OK since sockaddr_is_srcaddr() attempts to align with inet6_is_srcaddr() the HIP_IS_HIT() macro I would think of as being much simpler, just checks for the presence of a HIT prefix similar to the IN6_IS_ADDR_LINKLOCAL() macro -Jeff From jeffrey.m.ahrenholz@boeing.com Mon Aug 24 15:25:03 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8893A68A7 for ; Mon, 24 Aug 2009 15:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzABRLn9ak3S for ; Mon, 24 Aug 2009 15:25:02 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 958123A67F2 for ; Mon, 24 Aug 2009 15:24:25 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OMOJ3M011035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Aug 2009 15:24:22 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OMOJd6024048; Mon, 24 Aug 2009 15:24:19 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OMOI86023924; Mon, 24 Aug 2009 15:24:18 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:24:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 15:24:18 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: AcolA2D86/eXuB/kR/WjyoKppWhTUAAA32NQ References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> From: "Ahrenholz, Jeffrey M" To: "Andrew McGregor" , X-OriginalArrivalTime: 24 Aug 2009 22:24:18.0747 (UTC) FILETIME=[9F1690B0:01CA2509] Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:25:03 -0000 > > Based on this discussion, it appears that the best way for future =20 > > proofing is to include a flag for getaddrinfo() in the hints =20 > > arguments that will result in sockaddr_hip_long structures instead =20 > > of sockaddr_hip. This way, applications get exactly what they want =20 > > and can store the HITs easily in their ACLs. I'd also remove the =20 > > extra space reserved space because it seems that it's not very =20 > > usable for future proofing as it is now. > > > > Jeff, how do you feel about this or do you have a better suggestion? >=20 > I think you'd be better to define more than a flag... an=20 > explicit size =20 > (or enum) would be better. That way if some other odd size=20 > becomes a =20 > requirement later, it's not such an annoyance to fit in to the API yes, a size or flag makes sense; looks like struct addrinfo already has "size_t ai_addrlen;" but that field must be zero when used as hints (looking at getaddrinfo(3) man) other calls such as connect(), bind(), and sendto() already take a "socklen_t addrlen" argument -Jeff From andrew@indranet.co.nz Mon Aug 24 15:27:30 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D918C3A69D1 for ; Mon, 24 Aug 2009 15:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 xkveKTuAB54N for ; Mon, 24 Aug 2009 15:27:30 -0700 (PDT) Received: from mail.indranet.co.nz (unknown [203.97.93.68]) by core3.amsl.com (Postfix) with ESMTP id DCBAB3A6AFE for ; Mon, 24 Aug 2009 15:27:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.indranet.co.nz (Postfix) with ESMTP id 7EECFA42D5A; Tue, 25 Aug 2009 10:27:28 +1200 (NZST) X-Virus-Scanned: amavisd-new at indranet.co.nz Received: from mail.indranet.co.nz ([127.0.0.1]) by localhost (XServe-2.acheron.indranet.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ7XhH2npPEx; Tue, 25 Aug 2009 10:27:28 +1200 (NZST) Received: from Andrew-X.ferryrd.indranet.co.nz (Andrew-X.ferryrd.indranet.co.nz [192.168.1.11]) by mail.indranet.co.nz (Postfix) with ESMTP id 29939A42D4E; Tue, 25 Aug 2009 10:27:28 +1200 (NZST) Message-Id: From: Andrew McGregor To: "Ahrenholz, Jeffrey M" In-Reply-To: <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 10:27:14 +1200 References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> X-Mailer: Apple Mail (2.936) Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 22:27:30 -0000 On 25/08/2009, at 10:24 AM, Ahrenholz, Jeffrey M wrote: >>> Based on this discussion, it appears that the best way for future >>> proofing is to include a flag for getaddrinfo() in the hints >>> arguments that will result in sockaddr_hip_long structures instead >>> of sockaddr_hip. This way, applications get exactly what they want >>> and can store the HITs easily in their ACLs. I'd also remove the >>> extra space reserved space because it seems that it's not very >>> usable for future proofing as it is now. >>> >>> Jeff, how do you feel about this or do you have a better suggestion? >> >> I think you'd be better to define more than a flag... an >> explicit size >> (or enum) would be better. That way if some other odd size >> becomes a >> requirement later, it's not such an annoyance to fit in to the API > > yes, a size or flag makes sense; looks like struct addrinfo already > has > "size_t ai_addrlen;" but that field must be zero when used as hints > (looking at getaddrinfo(3) man) > > other calls such as connect(), bind(), and sendto() already take a > "socklen_t addrlen" argument > > -Jeff > Ah, in that case... getaddrinfo should return whatever it can, and applications should be required to check lengths if they care. That avoids coding in bugs early. Andrew From miika.komu@hiit.fi Tue Aug 25 00:44:33 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EB13A6B9E for ; Tue, 25 Aug 2009 00:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nApGf9scpEWF for ; Tue, 25 Aug 2009 00:44:32 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 74C213A6A2C for ; Tue, 25 Aug 2009 00:44:32 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 234C225ED11; Tue, 25 Aug 2009 10:44:38 +0300 (EEST) Message-ID: <4A93966C.2000002@hiit.fi> Date: Tue, 25 Aug 2009 10:44:44 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andrew McGregor References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 07:44:33 -0000 Andrew McGregor wrote: Hi, > On 25/08/2009, at 10:24 AM, Ahrenholz, Jeffrey M wrote: > >>>> Based on this discussion, it appears that the best way for future >>>> proofing is to include a flag for getaddrinfo() in the hints >>>> arguments that will result in sockaddr_hip_long structures instead >>>> of sockaddr_hip. This way, applications get exactly what they want >>>> and can store the HITs easily in their ACLs. I'd also remove the >>>> extra space reserved space because it seems that it's not very >>>> usable for future proofing as it is now. >>>> >>>> Jeff, how do you feel about this or do you have a better suggestion? >>> >>> I think you'd be better to define more than a flag... an >>> explicit size >>> (or enum) would be better. That way if some other odd size >>> becomes a >>> requirement later, it's not such an annoyance to fit in to the API >> >> yes, a size or flag makes sense; looks like struct addrinfo already has >> "size_t ai_addrlen;" but that field must be zero when used as hints >> (looking at getaddrinfo(3) man) >> >> other calls such as connect(), bind(), and sendto() already take a >> "socklen_t addrlen" argument the socket address structure already contains the size of the socket within the first field. Having yet another size within the structure or a variable length socket address structure is confusing for people used to constant size structures such as sockaddr_in, sockaddr_in6 and sockaddr_storage. Have a look at section "EXAMPLES" on getaddrinfo() FreeBSD man pages: http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=getaddrinfo If there is an additional length field and it must be used in socket calls, it disrupts the flow of the client side example. > Ah, in that case... getaddrinfo should return whatever it can, and > applications should be required to check lengths if they care. That > avoids coding in bugs early. The problem is that they do have check lengths when the applications fill in the socket address structures by themselves. I think it also a show stopper for allocations from the heap (struct addrinfo foo;). Dynamic allocations get somewhat tricky because defining the allocated size is not trivial. A way to avoid the memory-related problem and "client flow" problem would be to define sockaddr_hip to contain the maximum number of bytes similarly as sockaddr_storage does. Would that work for you? We would still need the actual HIT field to be defined as an union to facilitate naming of larger HITs withing the structure in a backwards compatible way. Right? From wwwrun@core3.amsl.com Wed Aug 19 07:42:29 2009 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E3BED28C3F3; Wed, 19 Aug 2009 07:42:29 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090819144229.E3BED28C3F3@core3.amsl.com> Date: Wed, 19 Aug 2009 07:42:29 -0700 (PDT) X-Mailman-Approved-At: Wed, 26 Aug 2009 22:42:49 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-nat-traversal (Basic HIP Extensions for Traversal of Network Address Translators) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:42:30 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Basic HIP Extensions for Traversal of Network Address Translators ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15486&rfc_flag=0 From miika.komu@hiit.fi Thu Aug 27 00:29:26 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB1D3A6C29 for ; Thu, 27 Aug 2009 00:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DgJ3nZMn9X9 for ; Thu, 27 Aug 2009 00:29:26 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 125453A697E for ; Thu, 27 Aug 2009 00:29:25 -0700 (PDT) Received: from [192.168.1.2] (cs27101111.pp.htv.fi [89.27.101.111]) by argo.otaverkko.fi (Postfix) with ESMTP id 3782C25ED0F; Thu, 27 Aug 2009 10:29:31 +0300 (EEST) Message-ID: <4A9635E4.2030703@hiit.fi> Date: Thu, 27 Aug 2009 10:29:40 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" , Andrew McGregor References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> <4A93966C.2000002@hiit.fi> In-Reply-To: <4A93966C.2000002@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre 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, 27 Aug 2009 07:29:27 -0000 Miika Komu wrote: Hi, >> Ah, in that case... getaddrinfo should return whatever it can, and >> applications should be required to check lengths if they care. That >> avoids coding in bugs early. > > The problem is that they do have check lengths when the applications > fill in the socket address structures by themselves. I think it also a > show stopper for allocations from the heap (struct addrinfo foo;). > Dynamic allocations get somewhat tricky because defining the allocated > size is not trivial. > > A way to avoid the memory-related problem and "client flow" problem > would be to define sockaddr_hip to contain the maximum number of bytes > similarly as sockaddr_storage does. Would that work for you? > > We would still need the actual HIT field to be defined as an union to > facilitate naming of larger HITs withing the structure in a backwards > compatible way. Right? Actually, sockaddr_un is variable length, but getaddrinfo() returns only fixed sized identifiers. Anyway, this is what a fixed size structure would look like: struct sockaddr_hip { sa_family_t ship_family; in_port_t ship_port; uint32_t ship_pad; uint64_t ship_flags; union { hip_hit_t ship_hit; uint8_t ship_reserved[MAX]; } ship_id; }; According to some quick compilation testing, the implementation size of MAX in linux is: * 112 in the above definition * 122 if we get rid of the pad field and changes flags to 16 bits Size of sockaddr_storage is 128 on linux which should determine the maximum size of sockaddr_hip. Comments? From miika.komu@hiit.fi Mon Aug 31 06:37:29 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AA53A6E22 for ; Mon, 31 Aug 2009 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZZa7Tl+BgMB for ; Mon, 31 Aug 2009 06:37:28 -0700 (PDT) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 5A77128C25B for ; Mon, 31 Aug 2009 06:37:27 -0700 (PDT) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id C4B4D25ED14; Mon, 31 Aug 2009 16:37:37 +0300 (EEST) Message-ID: <4A9BD221.8030606@hiit.fi> Date: Mon, 31 Aug 2009 16:37:37 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" , Andrew McGregor References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> <4A93966C.2000002@hiit.fi> <4A9635E4.2030703@hiit.fi> In-Reply-To: <4A9635E4.2030703@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre 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: Mon, 31 Aug 2009 13:37:29 -0000 Miika Komu wrote: Hi, a new preversion is here: http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre2.txt it includes the future proofing changes in the sockaddr_hip structure in section 4.1. I also wrote the ship_len explicitly to the structure since we were discussing on size issues. Section 4.5 contains the sockaddr_is_hit() definition as requested by Jeff. Please note that it is not a macro due to future proofing. Both the sockaddr_is_srcaddr() and sockaddr_is_hit() function take care of the wildcards currently as follows: The function returns also returns -1 on a sockaddr_hip structure containing a HIP_ENDPOINT_ANY or HIP_HIT_ANY_* wildcard. Jeff and Andrew, please comment on the mailing if you are satisfied with the changes so that I can publish the final version of the draft. From jeffrey.m.ahrenholz@boeing.com Mon Aug 31 08:05:46 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E3928C2B2 for ; Mon, 31 Aug 2009 08:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BBlyXIItGeez for ; Mon, 31 Aug 2009 08:05:44 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 4C40028C2B5 for ; Mon, 31 Aug 2009 08:05:44 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7VF5ca1003472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2009 08:05:47 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7VF5c8f001145; Mon, 31 Aug 2009 10:05:38 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7VF5bZc001134; Mon, 31 Aug 2009 10:05:38 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 08:05:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Aug 2009 08:05:36 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7C88@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4A9BD221.8030606@hiit.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] draft-ietf-hip-native-api-09-pre Thread-Index: AcoqQDoMrDq9MlIcS8ieP6VVN2Hz/wACGJwg References: <4A8DBB16.3010705@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C73@XCH-NW-6V1.nw.nos.boeing.com> <4A8E25C6.1090100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C75@XCH-NW-6V1.nw.nos.boeing.com> <4A930581.8080100@hiit.fi> <0DF156EE7414494187B087A3C279BDB404AD7C7C@XCH-NW-6V1.nw.nos.boeing.com> <4A93966C.2000002@hiit.fi> <4A9635E4.2030703@hiit.fi> <4A9BD221.8030606@hiit.fi> From: "Ahrenholz, Jeffrey M" To: , "Andrew McGregor" X-OriginalArrivalTime: 31 Aug 2009 15:05:38.0070 (UTC) FILETIME=[7FA23B60:01CA2A4C] Cc: hip WG Subject: Re: [Hipsec] draft-ietf-hip-native-api-09-pre X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 15:05:46 -0000 Miika, > section 4.1. I also wrote the ship_len explicitly to the=20 > structure since we were discussing on size issues. In section 7 you might mention using the optional ship_len field (maybe instead of flags and prefix.)=20 > Both the sockaddr_is_srcaddr() and sockaddr_is_hit() function=20 > take care of the wildcards currently as follows: >=20 > The function returns also > returns -1 on a sockaddr_hip structure containing a=20 > HIP_ENDPOINT_ANY > or HIP_HIT_ANY_* wildcard. This is good since the wildcards aren't HITs. > Jeff and Andrew, please comment on the mailing if you are=20 > satisfied with=20 > the changes so that I can publish the final version of the draft. Just a couple of nits: Section 4.5 s/Application can call/Applications can call/ s/function returns also returns -1/function also returns -1/ Section 7 s/to indicate that can support/to indicate that it can support/ s/instead directly using/instead of directly using/ -Jeff