From rgm@htt-consult.com Fri Oct 5 07:33:41 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C53121F8518 for ; Fri, 5 Oct 2012 07:33: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n22RpdKKLHRn for ; Fri, 5 Oct 2012 07:33:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3745121F84D6 for ; Fri, 5 Oct 2012 07:33:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 9622562A70; Fri, 5 Oct 2012 14:33:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvj3BuqgtKzA; Fri, 5 Oct 2012 10:32:54 -0400 (EDT) Received: from lx120e.htt-consult.com (pool-71-246-70-228.bltmmd.east.verizon.net [71.246.70.228]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1AD7062A6B; Fri, 5 Oct 2012 10:32:52 -0400 (EDT) Message-ID: <506EEF91.8060801@htt-consult.com> Date: Fri, 05 Oct 2012 10:32:49 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gonzalo Camarillo References: <5067F3AD.3030001@ericsson.com> In-Reply-To: <5067F3AD.3030001@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] No HIP WG session in Atlanta X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:33:41 -0000 On 09/30/2012 03:24 AM, Gonzalo Camarillo wrote: > Folks, > > as you know, we have been working under the assumption that we will not > have a HIP WG session in Atlanta. So far, it seems WGLC comments can be > handled on the mailing list. Well what fun is that? How can you expect to foster disagreement without mic time? :) Hopefully we CAN wrap things up here soonish. It would help for people to really go through the docs and provide some content-rich responses. > > Cheers, > > Gonzalo > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From sasu.tarkoma@helsinki.fi Wed Oct 10 12:05:58 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57A111E809A for ; Wed, 10 Oct 2012 12:05: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp6iHePt3Z7W for ; Wed, 10 Oct 2012 12:05:58 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736311E8091 for ; Wed, 10 Oct 2012 12:05:56 -0700 (PDT) Received: from [192.168.0.16] (cs181201041.pp.htv.fi [82.181.201.41]) (AUTH: PLAIN starkoma, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 10 Oct 2012 22:05:46 +0300 id 0008C5DC.5075C70A.00005E82 From: Sasu Tarkoma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> Date: Wed, 10 Oct 2012 22:05:47 +0300 To: hipsec@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Hipsec] Feedback for 4423bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:05:59 -0000 Hi all, I read the latest HIP architecture draft (4423bis-05) and it looks very good. Below you will find some observations that I made when reading the draft. Best regards, - Sasu ------ - Architecture and implementation details are partly intertwined here. Perhaps the generic model can be summarised first and then the implementation specific details. Theory of HI is mentioned in the beginning, but I think it is not clear for all readers what is meant by this. - It is stated that the model is general and it does not require public key crypto; however, this is not really elaborated. Also it is stated that the model can be applied at any layer, but this is not explained. The description assumes that Host Identity decouples internetworking and transport layers. - The draft does not discuss architecture and protocol deployment issues. This is one practical requirement given the momentum of the current solutions. - The description of the HIP protocol is quite light in this draft. The introductory part to section 5 could briefly state the key components of HIP including BEX, mobility/multihoming support, and rendezvous that are covered by the following subsections. - In section 5, it is stated that: "Similarly, if it is possible to distribute the processing of a single Host Identity over several physical computers, HIP provides for cluster based services without any changes at the client end-point." I think the base specification and implementation do not directly support this, but additional management extensions are needed. - Computational puzzle does not appear to be mentioned. - Extensions (new hash functions) are not elaborated. This is related to a general requirement that a protocol should be evolvable. - p. 17 section 10 needs a reference - p. 21 the downgrade attack should be elaborated. - Typo: p. 5 Identfier From mkomu@cs.hut.fi Tue Oct 16 12:00:34 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6FD21F8A82 for ; Tue, 16 Oct 2012 12:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB66jFMymDtY for ; Tue, 16 Oct 2012 12:00:33 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD421F8A53 for ; Tue, 16 Oct 2012 12:00:32 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 367A3308A9A; Tue, 16 Oct 2012 22:00:21 +0300 (EEST) Message-ID: <507DAEC4.6060804@cs.hut.fi> Date: Tue, 16 Oct 2012 22:00:20 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:00:35 -0000 Hi, On 09/23/2012 06:35 PM, René Hummen wrote: > Hi all, > > I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some > technical as well as editorial issues that I consider worth discussing > and fixing. Please note that especially the technical issues regarding > the used packet space may not be considered problematic in case of > everyday Internet connections. However, resource-constrained > environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard > payload limits. Here, a few bytes of additional packet size can > determine whether packets need to be fragmented or not. Therefore, I > think, we should also consider these scenarios in the basic HIP > specification that is shared by all HIP variants. > > I structured my feedback into different topics highlight by ###. > > > Technical issues: > ------------------------ > > ### R1 Counter ### > > 4.1.4. HIP Replay Protection > "The R1 counter SHOULD NOT roll over." > > No explanation is given what implementors should do when a roll over > occurs. Did you notice that the same section continues with: Upon conclusion of an active HIP association with another host, the R1 generation counter associated with the peer host SHOULD be flushed. A local policy MAY override the default flushing of R1 counters on a per-HIT basis. The reason for recommending the flushing of this counter is that there may be hosts where the R1 generation counter (occasionally) decreases; e.g., due to hardware failure. Then, later we have in section 6.16. Handling State Loss: In the case of system crash and unanticipated state loss, the system SHOULD delete the corresponding HIP state, including the keying material. That is, the state SHOULD NOT be stored on stable storage. If the implementation does drop the state (as RECOMMENDED), it MUST also drop the peer's R1 generation counter value, unless a local policy explicitly defines that the value of that particular host is stored. An implementation MUST NOT store R1 generation counters by default, but storing R1 generation counter values, if done, MUST be configured by explicit HITs. > I suggest to add the following text: > > "If a roll over is detected, the associated HIs SHOULD be removed and > new ones should be generated." > > Note, however, that such a change would also invalidate ACLs and HI-IP > lookup information based on the original HIs. I believe a responder could be tricked into exhausting it's counter values by a malign initiator? This is bad because changing the identity would affect all host associations, not only the one with the malign initiator? > ### HIP Checksum ### > > 5.1.1. Checksum > > What is the reason for using the IP-based pseudo-headers here? If I am > not overlooking something, non-HIP-aware NATs on the communication > path effectively break the HIP checksum. I know that this is the way > how TCP/IP pseudo-headers are defined. Still, I suggest to only > checksum the HIP header and the HIP parameters to avoid problems in > the future and to maintain layer separation. What happens if HIP is > used in non-IP environments? I have never liked the pseudo-header concept myself either but I think it's mandated by IPv4 and optional in IPv6 (for instance, with UDP). For instance, RFC5770 overrides that HIP checksum should be zero when the HIP control packet is encapsulated in UDP: http://tools.ietf.org/html/rfc5770 5.1. HIP Control Packets: The HIP header and parameters follow the conventions of [RFC5201] with the exception that the HIP header checksum MUST be zero. Authors, can we get rid of the pseudo header or are we stuck with it? Or can we make it optional (like with UDP and IPv6)? I think we can live with it but, at least, it would be useful to mention that the checksum MAY be zero depending on the underlying encapsulation as specified by further extensions. > ### Decreasing the per-packet overhead ### > > 4.1.2. Puzzle Exchange > "Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an > ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an > ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder > can include some data in R1 that the Initiator MUST copy unmodified in > the corresponding I2 packet." > > 5.2.4. PUZZLE > "The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 > parameter." > > Especially in resource-constrained environments such as targeted by > HIP DEX, each byte that needs to be transmitted is valuable (from a > power perspective) and may lead to fragmentation at the lower layers. > Hence, I suggest removing the 2 bytes of opaque value from the PUZZLE > parameter and to add +2 to the type number (resulting in 259) for the > new PUZZLE type. If the Responder has to transfer state in an unsigned > fashion, we already provide the ECHO_REQUEST_UNSIGNED parameter for > this purpose. Furthermore, the opaque value does not seem to be > necessary, as HIPL currently does not use it. maybe HIPL should start using it. AFAIK, the echo requests are optional, so I think having the puzzle opaque field is good from the view point of extra security. At least puzzle nonces can be used for puzzle indexing: 4.1.2. Puzzle Exchange: Using the Opaque data field in the PUZZLE (Section 5.2.4), in an ECHO_REQUEST_SIGNED (Section 5.2.19) or in an ECHO_REQUEST_UNSIGNED parameter (Section 5.2.20), the Responder can include some data in R1 that the Initiator must copy unmodified in the corresponding I2 packet. The Responder can generate the Opaque data in various ways; e.g., using encryption or hashing with some secret, the sent I, and possibly other related data. Using the same secret, the received I (from the I2), and the other related data (if any), the Receiver can verify that it has itself sent the I to the Initiator. The Responder MUST periodically change such a used secret. Have you considered this? Or maybe it's better to skip just the ECHO REQUESTS in constrained environments? Have you calculated that the 2 bytes are really makes a real difference in practice for fragmentation with 6lowpan? Power perspective has been discussed at least in the link below but care to elaborate? http://www.cs.helsinki.fi/u/gurtov/papers/hip_dex.pdf > 5.2.5. SOLUTION > > Here, I suggest removing 1 byte of reserved space and the 2 byte, > echoed opaque value for the same reason presented above. The type > number could be moved to 323 (SOLUTION + 2). If we need to modify the > puzzle parameter for some reason in the future, I suggest to design a > new parameter instead of using the reserved field. That is how new > semantics are handled for any other parameter as well (see MAC_X). I am not really objecting to your change but it would helpful to understand the real need and see some numbers (with ECC HIP) behind your suggestions. IEEE 802.15.4 payload size is between 72–116. Here's some numbers: http://www.cs.helsinki.fi/u/gurtov/papers/hip-medical.pdf While DEX MTU is considerably smaller, HIP BEX payload size with ECDH+ECDSA is reported (in bytes) as follows: * 40 (I1) * 916 (R1) * 644 (I2) * 108 (R2) So, the main problem is the R1 and I2 that are fragmented and their "tail" (modulo) size is as follows (first number with 72 and the second with 116 payload size): * R1: 52 / 104 * I2: 68 / 639 As the tail is a bit large, I think saving few bytes does not seem worth the extra trouble but it would helpful if somebody could verify my figures? Some people have also argued that the puzzle concept is not that useful at all and we could get rid of it (hence, we would save more MTU this way). We'd still need the I and J for the keymaterial in some other parameter though (like the echo request). > 5.2.3. R1_COUNTER > "It SHOULD be included in the R1 (in which case, it is covered by the > signature), and if present in the R1, it MUST be echoed (including the > Reserved field verbatim) by the Initiator in the I2 packet." > > Similar to the SOLUTION parameter, I suggest removing the 4 bytes of > reserved space from the R1 counter parameter and to add +2 to the type > number (resulting in 131) for the new R1_COUNTER type. This comes at the cost of losing some future compatibility. Assuming my figures are correct, this does not save enough bytes? > I understand that these changes break parameter compatibility with > existing v1 implementations. However, I do not consider a new > parameter layout problematic as the semantics won't change > considerably allowing for code re-use in most cases. We have the version bit, so changing things for HIPv2 is fine as long as the header remains intact. This brings into my mind that I guess we can't save bits by applying compression to the HITs a'la 6lowpan, but have people considered if the following optimizations would be worth the trouble: * delta encoding * removal of parameter padding Thanks for great comments Rene! From mkomu@cs.hut.fi Tue Oct 16 12:21:41 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2169421F8962 for ; Tue, 16 Oct 2012 12:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.029 X-Spam-Level: X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDvuUAg7yYGg for ; Tue, 16 Oct 2012 12:21:40 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3021F8966 for ; Tue, 16 Oct 2012 12:21:28 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id A58A8308ADB; Tue, 16 Oct 2012 22:21:27 +0300 (EEST) Message-ID: <507DB3B7.5000509@cs.hut.fi> Date: Tue, 16 Oct 2012 22:21:27 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org, =?windows-1252?Q?Ren=E9_Hummen?= References: <507DAEC4.6060804@cs.hut.fi> In-Reply-To: <507DAEC4.6060804@cs.hut.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 19:21:41 -0000 Hi, On 10/16/2012 10:00 PM, Miika Komu wrote: >> 5.2.5. SOLUTION >> >> Here, I suggest removing 1 byte of reserved space and the 2 byte, >> echoed opaque value for the same reason presented above. The type >> number could be moved to 323 (SOLUTION + 2). If we need to modify the >> puzzle parameter for some reason in the future, I suggest to design a >> new parameter instead of using the reserved field. That is how new >> semantics are handled for any other parameter as well (see MAC_X). > > I am not really objecting to your change but it would helpful to > understand the real need and see some numbers (with ECC HIP) behind your > suggestions. IEEE 802.15.4 payload size is between 72–116. Here's some > numbers: > > http://www.cs.helsinki.fi/u/gurtov/papers/hip-medical.pdf > > While DEX MTU is considerably smaller, HIP BEX payload size with > ECDH+ECDSA is reported (in bytes) as follows: > > * 40 (I1) > * 916 (R1) > * 644 (I2) > * 108 (R2) > > So, the main problem is the R1 and I2 that are fragmented and their > "tail" (modulo) size is as follows (first number with 72 and the second > with 116 payload size): > > * R1: 52 / 104 > * I2: 68 / 639 (with R2 the modulo is 107 when MTU is 72) DEX figures were reported as follows: * 40 (I1) * 92 (R1) * 148 (I2) * 102 (R2) So I think we should be should be able to shrink packet size at least 20 or preferably 30 bytes to reduce the number of fragments and make all this worthwhile just for DEX: * R1: 20 / fits * I2: 146 / 32 * R2: 30 / fits But I am getting tired and perhaps I got something wrong. From thomas.r.henderson@boeing.com Tue Oct 16 20:36:08 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFBB21F8683 for ; Tue, 16 Oct 2012 20:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WylSj9-lSLOI for ; Tue, 16 Oct 2012 20:36:08 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 206C821F867C for ; Tue, 16 Oct 2012 20:36:08 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9H3aIUY005598 for ; Tue, 16 Oct 2012 20:36:18 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9H3aHrk005595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Oct 2012 20:36:18 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 16 Oct 2012 20:36:06 -0700 From: "Henderson, Thomas R" To: "'Miika Komu'" , "hipsec@ietf.org" Date: Tue, 16 Oct 2012 20:36:06 -0700 Thread-Topic: [Hipsec] WGLCs: 4423bis and 5201bis Thread-Index: Ac2r0K2i+im3mCYdQUKs39kJgHNWBAARqc1Q Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C18A@XCH-NW-16V.nw.nos.boeing.com> References: <507DAEC4.6060804@cs.hut.fi> In-Reply-To: <507DAEC4.6060804@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 03:36:08 -0000 >=20 > > ### HIP Checksum ### > > > > 5.1.1. Checksum > > > > What is the reason for using the IP-based pseudo-headers here? If I > am > > not overlooking something, non-HIP-aware NATs on the communication > > path effectively break the HIP checksum. I know that this is the way > > how TCP/IP pseudo-headers are defined. Still, I suggest to only > > checksum the HIP header and the HIP parameters to avoid problems in > > the future and to maintain layer separation. What happens if HIP is > > used in non-IP environments? >=20 > I have never liked the pseudo-header concept myself either but I think > it's mandated by IPv4 and optional in IPv6 (for instance, with UDP). For UDP, it is the reverse of the above (optional for IPv4, mandatory for I= Pv6). =20 > For instance, RFC5770 overrides that HIP checksum should be zero when > the HIP control packet is encapsulated in UDP: >=20 > http://tools.ietf.org/html/rfc5770 Yes, but UDP checksum covers IPv6 header in that case. There is also a pro= posal to zero the UDP checksum in other UDP tunnel situations: http://tools.ietf.org/html/draft-ietf-6man-udpzero-06 but I haven't seen it proposed for non-tunnel situations. >=20 > 5.1. HIP Control Packets: >=20 > The HIP header and parameters follow the conventions of [RFC5201] with > the exception that the HIP header checksum MUST be zero. >=20 > Authors, can we get rid of the pseudo header or are we stuck with it? > Or can we make it optional (like with UDP and IPv6)? >=20 > I think we can live with it but, at least, it would be useful to > mention that the checksum MAY be zero depending on the underlying > encapsulation as specified by further extensions. I am hesitant to be a trailblazer in removing the IPv6 header integrity che= cking. I'd rather add a note such as you suggest (if underlying transport = provides necessary integrity check, as specified in other documents). - Tom From thomas.r.henderson@boeing.com Tue Oct 16 20:44:01 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1821F8629 for ; Tue, 16 Oct 2012 20:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm1mk5JsIbzI for ; Tue, 16 Oct 2012 20:44:00 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id B6F0E21F8628 for ; Tue, 16 Oct 2012 20:44:00 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9H3hk8j006920 for ; Tue, 16 Oct 2012 20:43:46 -0700 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9H3hkeB006909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 16 Oct 2012 20:43:46 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 16 Oct 2012 20:43:59 -0700 From: "Henderson, Thomas R" To: "hipsec@ietf.org" Date: Tue, 16 Oct 2012 20:43:59 -0700 Thread-Topic: [Hipsec] WGLCs: 4423bis and 5201bis Thread-Index: Ac2r03yx8AUEejQbQSy91AXy/YTz5AARUUjQ Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C18B@XCH-NW-16V.nw.nos.boeing.com> References: <507DAEC4.6060804@cs.hut.fi> <507DB3B7.5000509@cs.hut.fi> In-Reply-To: <507DB3B7.5000509@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 03:44:01 -0000 This is a brief summary of what I believe to be the remaining open issues a= fter WGLC. RFC 4423:=20 - I raised some issues in a review, still not addressed in the recent -05 v= ersion: -- section 13 incomplete -- no mention of revocation -- need better summary of multicast I'll try to propose some text to Robert. - Sasu Tarkoma published some observations (10 October) which may lead to f= urther editorial changes=20 - Gonzalo asks whether to go for PS or Information; response to this seemed= mixed or neutral RFC 5201: - Rene Hummen raised some issues on 23 Sept. The non-editorial ones: -- R1 counter roll over -- HIP checksum using pseudoheader -- Decreasing overhead with some format changes The above issues (especially the last two) seem to be still under discussio= n. Are there other open issues that I'm forgetting? =20 - Tom From mkomu@cs.hut.fi Wed Oct 17 02:52:51 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF3B21F8833 for ; Wed, 17 Oct 2012 02:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtgYw-Fa7mCj for ; Wed, 17 Oct 2012 02:52:51 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id EF04E21F8820 for ; Wed, 17 Oct 2012 02:52:50 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 768D030820A for ; Wed, 17 Oct 2012 12:52:49 +0300 (EEST) Message-ID: <507E7FF1.7030309@cs.hut.fi> Date: Wed, 17 Oct 2012 12:52:49 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <507DAEC4.6060804@cs.hut.fi> <758141CC3D829043A8C3164DD3D593EA2E4C38C18A@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C18A@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:52:51 -0000 Hi, On 10/17/2012 06:36 AM, Henderson, Thomas R wrote: >> 5.1. HIP Control Packets: >> >> The HIP header and parameters follow the conventions of [RFC5201] >> with the exception that the HIP header checksum MUST be zero. >> >> Authors, can we get rid of the pseudo header or are we stuck with >> it? Or can we make it optional (like with UDP and IPv6)? >> >> I think we can live with it but, at least, it would be useful to >> mention that the checksum MAY be zero depending on the underlying >> encapsulation as specified by further extensions. > > I am hesitant to be a trailblazer in removing the IPv6 header > integrity checking. I'd rather add a note such as you suggest (if > underlying transport provides necessary integrity check, as specified > in other documents). I am fine with just adding such a note. From rene.hummen@comsys.rwth-aachen.de Wed Oct 17 06:04:33 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24E21F877C for ; Wed, 17 Oct 2012 06:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-vjp7jLg0lo for ; Wed, 17 Oct 2012 06:04:32 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 004D521F8793 for ; Wed, 17 Oct 2012 06:04:31 -0700 (PDT) MIME-version: 1.0 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MC100FDXGBHIO90@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 17 Oct 2012 15:04:29 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.80,600,1344204000"; d="p7s'?scan'208";a="107796038" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; Wed, 17 Oct 2012 15:04:29 +0200 Received: from i4-mbp.informatik.rwth-aachen.de ([unknown] [137.226.12.102]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MC100FPGGBHWB80@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 17 Oct 2012 15:04:29 +0200 (CEST) Content-type: multipart/signed; boundary="Apple-Mail=_2F878384-5E84-493F-AB4B-910FF929FD26"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <507DAEC4.6060804@cs.hut.fi> Date: Wed, 17 Oct 2012 15:04:31 +0200 Message-id: References: <507DAEC4.6060804@cs.hut.fi> To: Miika Komu X-Mailer: Apple Mail (2.1499) Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:04:33 -0000 --Apple-Mail=_2F878384-5E84-493F-AB4B-910FF929FD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 16.10.2012, at 21:00, Miika Komu wrote: > On 09/23/2012 06:35 PM, Ren=E9 Hummen wrote: >> Hi all, >>=20 >> I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some >> technical as well as editorial issues that I consider worth = discussing >> and fixing. Please note that especially the technical issues = regarding >> the used packet space may not be considered problematic in case of >> everyday Internet connections. However, resource-constrained >> environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard >> payload limits. Here, a few bytes of additional packet size can >> determine whether packets need to be fragmented or not. Therefore, I >> think, we should also consider these scenarios in the basic HIP >> specification that is shared by all HIP variants. >>=20 >> I structured my feedback into different topics highlight by ###. >>=20 >>=20 >> Technical issues: >> ------------------------ >>=20 >> ### R1 Counter ### >>=20 >> 4.1.4. HIP Replay Protection >> "The R1 counter SHOULD NOT roll over." >>=20 >> No explanation is given what implementors should do when a roll over >> occurs. >=20 > Did you notice that the same section continues with: >=20 > Upon conclusion of an active HIP association with another host, the > R1 generation counter associated with the peer host SHOULD be > flushed. A local policy MAY override the default flushing of R1 > counters on a per-HIT basis. The reason for recommending the > flushing of this counter is that there may be hosts where the R1 > generation counter (occasionally) decreases; e.g., due to hardware > failure. Yes, but this describes the behavior of the peer, not of the host = sending the R1 counter value. Hence, this does not mention how to deal = with roll overs. Still, how does this text (same section) apply if the peer does not = store the R1 generation counter? "Initiators are protected against R1 replays by a monotonically = increasing "R1 generation counter" included in the R1." > Then, later we have in section 6.16. Handling State Loss: >=20 > In the case of system crash and unanticipated state loss, the = system > SHOULD delete the corresponding HIP state, including the keying > material. That is, the state SHOULD NOT be stored on stable = storage. > If the implementation does drop the state (as RECOMMENDED), it MUST > also drop the peer's R1 generation counter value, unless a local > policy explicitly defines that the value of that particular host is > stored. An implementation MUST NOT store R1 generation counters by > default, but storing R1 generation counter values, if done, MUST be > configured by explicit HITs. Ok, so a system crash effectively resets the generation counter without = expiring the HI. However, what about the case when the peer really uses = the generation counter for replay protection purposes? This will = possibly break connectivity for a long time... >> I suggest to add the following text: >>=20 >> "If a roll over is detected, the associated HIs SHOULD be removed and >> new ones should be generated." >>=20 >> Note, however, that such a change would also invalidate ACLs and = HI-IP >> lookup information based on the original HIs. >=20 > I believe a responder could be tricked into exhausting it's counter=20 > values by a malign initiator? This is bad because changing the = identity=20 > would affect all host associations, not only the one with the malign=20= > initiator? Your described vulnerability strongly depends on how a system maintains = puzzle generations: "Implementations MUST accept puzzles from the current generation and = MAY accept puzzles from earlier generations. A system's local counter = MUST be incremented at least as often as every time old R1s cease to be = valid." Furthermore, should the latter sentence be rephrased as follows for = higher clarity? "A system's puzzle generation counter MUST be incremented at least as = often as old puzzle values cease to be valid." BR, Ren=E9 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_2F878384-5E84-493F-AB4B-910FF929FD26 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTcxMzA0MzJaMCMGCSqGSIb3DQEJBDEWBBS2XCLff6ma m6RhpAkGoC+3ldlxkTB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQCThZXsir+w VXvngX5gJs4IWtiebN5Jd9h2X/onQGaxHo2XeBUBJQPu7G6d5w9dtYr1YmtUsREQOa3ssL62H1t7 m//AsHNjP+HXfB84MvhwYqBYakDPdLMEoXLefgf6vH1Bk+xUIbh2BclVSS2P0pC6/O8ZnBXqE93Q rR/jBNhszD0AbZhzOThfJuOEROPuwxnuG9hvZSReWD5kcuylKUuDbZdMf7fhPZBjc52BKGp93ar3 ed4sfUnu3Fs6omkQwPXkqOzorRDeIdf1g/Xck104gF0ZMJDCuV/W3roS9OrFnIi6tD0bXUpGLZk2 O+Wmgxu4YNCwS6MGJT9trKnLEbCaAAAAAAAA --Apple-Mail=_2F878384-5E84-493F-AB4B-910FF929FD26-- From mkomu@cs.hut.fi Thu Oct 18 02:42:46 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902021F85E6 for ; Thu, 18 Oct 2012 02:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrYUYqSF7OvV for ; Thu, 18 Oct 2012 02:42:45 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id E55B521F85C6 for ; Thu, 18 Oct 2012 02:42:44 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 478A2308EE6; Thu, 18 Oct 2012 12:42:43 +0300 (EEST) Message-ID: <507FCF12.4060502@cs.hut.fi> Date: Thu, 18 Oct 2012 12:42:42 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Hummen?= References: <507DAEC4.6060804@cs.hut.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:42:46 -0000 Hi, On 10/17/2012 04:04 PM, René Hummen wrote: > Hi, > On 16.10.2012, at 21:00, Miika Komu wrote: >> On 09/23/2012 06:35 PM, René Hummen wrote: >>> Hi all, >>> >>> I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some >>> technical as well as editorial issues that I consider worth discussing >>> and fixing. Please note that especially the technical issues regarding >>> the used packet space may not be considered problematic in case of >>> everyday Internet connections. However, resource-constrained >>> environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard >>> payload limits. Here, a few bytes of additional packet size can >>> determine whether packets need to be fragmented or not. Therefore, I >>> think, we should also consider these scenarios in the basic HIP >>> specification that is shared by all HIP variants. >>> >>> I structured my feedback into different topics highlight by ###. >>> >>> >>> Technical issues: >>> ------------------------ >>> >>> ### R1 Counter ### >>> >>> 4.1.4. HIP Replay Protection >>> "The R1 counter SHOULD NOT roll over." >>> >>> No explanation is given what implementors should do when a roll over >>> occurs. >> >> Did you notice that the same section continues with: >> >> Upon conclusion of an active HIP association with another host, the >> R1 generation counter associated with the peer host SHOULD be >> flushed. A local policy MAY override the default flushing of R1 >> counters on a per-HIT basis. The reason for recommending the >> flushing of this counter is that there may be hosts where the R1 >> generation counter (occasionally) decreases; e.g., due to hardware >> failure. > > Yes, but this describes the behavior of the peer, not of the host sending the R1 counter value. Hence, this does not mention how to deal with roll overs. You're right, this is an open issue. Authors, I find this text a bit tricky to read because does not use the absolute terms of "Initiator" and "Responder". I suggest improving the text unless the R1 generation counter is used for e.g. UPDATE. The same applies to section 6.16. (Handling State Loss). > Still, how does this text (same section) apply if the peer does not store the R1 generation counter? > > "Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1." I assume that you mean initiator with peer? I think it's in the best interest of the initiator to store it as it improves security. If it doesn't and always accepts it, then the communications is less secure. If you mean the responder, I think it can opt out and not send the R1 generation counter at all, since it's optional. If it does send the generation counter, it MUST store the counter. >> Then, later we have in section 6.16. Handling State Loss: >> >> In the case of system crash and unanticipated state loss, the system >> SHOULD delete the corresponding HIP state, including the keying >> material. That is, the state SHOULD NOT be stored on stable storage. >> If the implementation does drop the state (as RECOMMENDED), it MUST >> also drop the peer's R1 generation counter value, unless a local >> policy explicitly defines that the value of that particular host is >> stored. An implementation MUST NOT store R1 generation counters by >> default, but storing R1 generation counter values, if done, MUST be >> configured by explicit HITs. > > Ok, so a system crash effectively resets the generation counter without expiring the HI. However, what about the case when the peer really uses the generation counter for replay protection purposes? This will possibly break connectivity for a long time... There's several editorial issues with this text: * As said earlier, please use Initiator and Responder terms for clarity avoid ambiguity with relative terms? * The last sentence is in conflict with section 6.8: "The system MUST store the received R1 generation counter for future reference" * It is unclear if the stable storage applies to R1 counters or not. Particularly, I think the authors should break down the crashing cases separately: 1. Initiator crashes: it should reset the stored counter and accept any new values from Responders. 2. Responder crashes: it should start with a new counter value. Initiating hosts with previous contact with the Responder may experience some delay until the Host Association at the Initiator expires and it resets the counter value. 3. Both crash. The previous case combined; no issue here. >>> I suggest to add the following text: >>> >>> "If a roll over is detected, the associated HIs SHOULD be removed and >>> new ones should be generated." >>> >>> Note, however, that such a change would also invalidate ACLs and HI-IP >>> lookup information based on the original HIs. >> >> I believe a responder could be tricked into exhausting it's counter >> values by a malign initiator? This is bad because changing the identity >> would affect all host associations, not only the one with the malign >> initiator? > > > Your described vulnerability strongly depends on how a system maintains puzzle generations: > "Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be incremented at least as often as every time old R1s cease to be valid." 4.1.2. Puzzle Exchange: It is RECOMMENDED that the Responder generates a new puzzle and new R1s once every few minutes I take my comment back; the counter is liked to puzzle generation which, in turn, is recommended to be periodical rather than based on the number of iniatiators. So, the roll over is bound to time. > Furthermore, should the latter sentence be rephrased as follows for higher clarity? > "A system's puzzle generation counter MUST be incremented at least as often as old puzzle values cease to be valid." Fine by me. From mkomu@cs.hut.fi Thu Oct 18 02:50:53 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A38D21F85C0 for ; Thu, 18 Oct 2012 02:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSPT4ZEboDjX for ; Thu, 18 Oct 2012 02:50:52 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0176021F85A8 for ; Thu, 18 Oct 2012 02:50:52 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 225B7308EFA; Thu, 18 Oct 2012 12:50:50 +0300 (EEST) Message-ID: <507FD0FA.3070402@cs.hut.fi> Date: Thu, 18 Oct 2012 12:50:50 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <507DAEC4.6060804@cs.hut.fi> <507FCF12.4060502@cs.hut.fi> In-Reply-To: <507FCF12.4060502@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:50:53 -0000 Hi, On 10/18/2012 12:42 PM, Miika Komu wrote: > Hi, > > On 10/17/2012 04:04 PM, René Hummen wrote: >> Hi, >> On 16.10.2012, at 21:00, Miika Komu wrote: >>> On 09/23/2012 06:35 PM, René Hummen wrote: >>>> Hi all, >>>> >>>> I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some >>>> technical as well as editorial issues that I consider worth discussing >>>> and fixing. Please note that especially the technical issues regarding >>>> the used packet space may not be considered problematic in case of >>>> everyday Internet connections. However, resource-constrained >>>> environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard >>>> payload limits. Here, a few bytes of additional packet size can >>>> determine whether packets need to be fragmented or not. Therefore, I >>>> think, we should also consider these scenarios in the basic HIP >>>> specification that is shared by all HIP variants. >>>> >>>> I structured my feedback into different topics highlight by ###. >>>> >>>> >>>> Technical issues: >>>> ------------------------ >>>> >>>> ### R1 Counter ### >>>> >>>> 4.1.4. HIP Replay Protection >>>> "The R1 counter SHOULD NOT roll over." >>>> >>>> No explanation is given what implementors should do when a roll over >>>> occurs. >>> >>> Did you notice that the same section continues with: >>> >>> Upon conclusion of an active HIP association with another host, the >>> R1 generation counter associated with the peer host SHOULD be >>> flushed. A local policy MAY override the default flushing of R1 >>> counters on a per-HIT basis. The reason for recommending the >>> flushing of this counter is that there may be hosts where the R1 >>> generation counter (occasionally) decreases; e.g., due to hardware >>> failure. >> >> Yes, but this describes the behavior of the peer, not of the host >> sending the R1 counter value. Hence, this does not mention how to deal >> with roll overs. > > You're right, this is an open issue. I think the whole R1 counter concept is a bit cumbersome because it is buried into local policy issues and the roll over is problematic. I would suggest removing the R1 counter and simply mandating the Responder to send ECHO_REQUEST_SIGNED and the Initiator to send it in I2. Since the nonce is fresh and signed, it should provide replay protection even against a man-in-the-middle attacker. Opinions? From mkomu@cs.hut.fi Thu Oct 18 05:32:34 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEA321F8733 for ; Thu, 18 Oct 2012 05:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRNOrxGrbJJw for ; Thu, 18 Oct 2012 05:32:34 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 018FD21F8732 for ; Thu, 18 Oct 2012 05:32:33 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id AA4B130810A for ; Thu, 18 Oct 2012 15:32:32 +0300 (EEST) Message-ID: <507FF6E0.6030203@cs.hut.fi> Date: Thu, 18 Oct 2012 15:32:32 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <507DAEC4.6060804@cs.hut.fi> In-Reply-To: <507DAEC4.6060804@cs.hut.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:32:34 -0000 Hi, On 10/16/2012 10:00 PM, Miika Komu wrote: > Some people have also argued that the puzzle concept is not that useful > at all and we could get rid of it (hence, we would save more MTU this > way). We'd still need the I and J for the keymaterial in some other > parameter though (like the echo request). forget about this, after a walk along the memory lane with Tom, Bob and Pin, the puzzle is useful and we should stick to it. It allows the responder to delay an initiator without introducing any initiator-specific state at the responder. From mkomu@cs.hut.fi Thu Oct 18 06:16:04 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20AA21F8771 for ; Thu, 18 Oct 2012 06:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTZ+kFWSzkbR for ; Thu, 18 Oct 2012 06:16:04 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6C59721F877E for ; Thu, 18 Oct 2012 06:16:00 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 4270930817B for ; Thu, 18 Oct 2012 16:15:56 +0300 (EEST) Message-ID: <5080010B.7030605@cs.hut.fi> Date: Thu, 18 Oct 2012 16:15:55 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <505C213F.6050701@ericsson.com> <50615C93.6090300@ericsson.com> In-Reply-To: <50615C93.6090300@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Fwd: Status of WG items X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:16:05 -0000 Hi Julien, your suggestion sounds fine. On 09/25/2012 10:26 AM, Gonzalo Camarillo wrote: > Hi, > > if we have the appropriate hooks in the main specs, we could do as you > suggest. I would be interested in hearing more opinions, though. > > Cheers, > > Gonzalo > > On 24/09/2012 5:48 PM, Julien Laganier wrote: >> Hi Gonzalo, all, >> >> So if we include in the registration a dependency towards the standard >> tracks HIP certificates draft (that doesn't exist yet) we would be >> tying the two together such that the registration can't be published >> before the HIP certificate RFC is. >> >> An alternative would be to move ahead with the current registration >> draft without specific dependency on HIP certificates but leaving the >> door open for these to be used once they are defined in standard >> track; the current draft and RFC already have hooks for authentication >> means beyond HIT authentication: >> >> >> In particular, >> REG_FAILED with a failure type of zero indicates the service(s) >> type(s) that require further credentials for registration. >> >> If the registrar requires further authorization and the requester has >> additional credentials available, the requester SHOULD try to >> register again with the service after the HIP association has been >> established. The precise means of establishing and verifying >> credentials are beyond the scope of this document and are expected to >> be defined in other documents. >> >> Would that be an appropriate way forward? >> >> --julien >> >> On Fri, Sep 21, 2012 at 1:11 AM, Gonzalo Camarillo >> wrote: >>> Hi Julien, >>> >>> my take on this is that we need to produce a standards-track document >>> specifying exactly that. This is what our charter says about it: >>> >>> https://datatracker.ietf.org/wg/hip/charter/ >>> >>>> o Specify in a standards track RFC how to carry certificates in the >>>> base exchange. This was removed from the base HIP spec so that the >>>> mechanism is specified in a stand-alone spec. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 21/09/2012 2:49 AM, Julien Laganier wrote: >>>> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen wrote: >>>>> Hi Julien, >>>>> >>>>> >>>>> On 7/6/12 3:37 AM, Julien Laganier wrote: >>>>>> >>>>>> - 5203bis (registration) can IMHO be republished as is as I haven't >>>>>> seen any issue with the original version. If people agree I could >>>>>> republish it and we could WGLC it... >>>>> >>>>> >>>>> I posted some comments about 5203bis earlier this year but back then there >>>>> was no discussion regarding them. So, here goes again. >>>>> >>>>> Some of these have been discussed also earlier on this list (these relate to >>>>> requirements discovered with the native NAT traversal draft [1]), but I'll >>>>> have them all here for easier reference. >>>>> >>>>> Currently, the registrar has no way of indicating that it would otherwise >>>>> accept the registration, but it's currently running low on resources. For >>>>> this purpose, a failure type "Insufficient resources" could be added to the >>>>> "registration failure types". >>>>> >>>>> Registration using authentication with certificates could be part of the >>>>> registration RFC. Currently, only authentication with HI is defined, but >>>>> knowing all HIs beforehand is not practical in many cases. >>>>> >>>>> Text in section 3.2. of [1] could be used as a basis for this (just replace >>>>> "HIP' data relay" with "registrar"). Also, if this authentication mode is >>>>> added to the draft, failure type "Invalid certificate" should be added for >>>>> the failure case. >>>>> >>>>> Should we have these in the registration draft? >>>>> >>>>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal >>>> >>>> I was going to shamelessly copy/paste section 3.2 of [1] in the >>>> registration draft but I noticed that [1] actually has a normative >>>> dependency on RFC 6253 "Host Identity Protocol Certificates" which is >>>> Experimental. Thus adding the support for certificates to a standard >>>> track HIP registration would cause a so-called downref which could be >>>> problematic... >>>> >>>> Gonzalo - what is your take on this? >>>> >>>> --julien >>>> >>> >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Thu Oct 18 14:10:27 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA8021F8491 for ; Thu, 18 Oct 2012 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voVMCWyPW3oT for ; Thu, 18 Oct 2012 14:10:26 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 587FB21F8493 for ; Thu, 18 Oct 2012 14:10:26 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C2E3562A6C; Thu, 18 Oct 2012 21:09:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB5wHXyRas42; Thu, 18 Oct 2012 17:09:36 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 28A5362A61; Thu, 18 Oct 2012 17:09:36 -0400 (EDT) Message-ID: <5080700F.3010909@htt-consult.com> Date: Thu, 18 Oct 2012 17:09:35 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <507DAEC4.6060804@cs.hut.fi> <507DB3B7.5000509@cs.hut.fi> <758141CC3D829043A8C3164DD3D593EA2E4C38C18B@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C18B@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:10:27 -0000 On 10/16/2012 11:43 PM, Henderson, Thomas R wrote: > This is a brief summary of what I believe to be the remaining open issues after WGLC. > > RFC 4423: > > - I raised some issues in a review, still not addressed in the recent -05 version: > > -- section 13 incomplete > -- no mention of revocation I am working on the next revision and have some revocation text. I will try and post that here tomorrow. > -- need better summary of multicast > > I'll try to propose some text to Robert. > > - Sasu Tarkoma published some observations (10 October) which may lead to further editorial changes > > - Gonzalo asks whether to go for PS or Information; response to this seemed mixed or neutral > > RFC 5201: > > - Rene Hummen raised some issues on 23 Sept. The non-editorial ones: > > -- R1 counter roll over > -- HIP checksum using pseudoheader > -- Decreasing overhead with some format changes > > The above issues (especially the last two) seem to be still under discussion. > > Are there other open issues that I'm forgetting? > > - Tom > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Thu Oct 18 14:13:22 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72F321F8623 for ; Thu, 18 Oct 2012 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XA1VoXSHvlg for ; Thu, 18 Oct 2012 14:13:21 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 18AE821F8493 for ; Thu, 18 Oct 2012 14:13:21 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B282362A61; Thu, 18 Oct 2012 21:12:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O2A5HquvDaW; Thu, 18 Oct 2012 17:12:38 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id C75F362A5B; Thu, 18 Oct 2012 17:12:38 -0400 (EDT) Message-ID: <508070C6.3060606@htt-consult.com> Date: Thu, 18 Oct 2012 17:12:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Miika Komu References: <507DAEC4.6060804@cs.hut.fi> <507FCF12.4060502@cs.hut.fi> <507FD0FA.3070402@cs.hut.fi> In-Reply-To: <507FD0FA.3070402@cs.hut.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLCs: 4423bis and 5201bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:13:22 -0000 On 10/18/2012 05:50 AM, Miika Komu wrote: > Hi, > > On 10/18/2012 12:42 PM, Miika Komu wrote: >> Hi, >> >> On 10/17/2012 04:04 PM, René Hummen wrote: >>> Hi, >>> On 16.10.2012, at 21:00, Miika Komu wrote: >>>> On 09/23/2012 06:35 PM, René Hummen wrote: >>>>> Hi all, >>>>> >>>>> I had a close look at draft-ietf-hip-rfc5201-bis-09 and found some >>>>> technical as well as editorial issues that I consider worth >>>>> discussing >>>>> and fixing. Please note that especially the technical issues >>>>> regarding >>>>> the used packet space may not be considered problematic in case of >>>>> everyday Internet connections. However, resource-constrained >>>>> environments as targeted by RPL, 6LowPAN, CoAP, and HIP DEX have hard >>>>> payload limits. Here, a few bytes of additional packet size can >>>>> determine whether packets need to be fragmented or not. Therefore, I >>>>> think, we should also consider these scenarios in the basic HIP >>>>> specification that is shared by all HIP variants. >>>>> >>>>> I structured my feedback into different topics highlight by ###. >>>>> >>>>> >>>>> Technical issues: >>>>> ------------------------ >>>>> >>>>> ### R1 Counter ### >>>>> >>>>> 4.1.4. HIP Replay Protection >>>>> "The R1 counter SHOULD NOT roll over." >>>>> >>>>> No explanation is given what implementors should do when a roll over >>>>> occurs. >>>> >>>> Did you notice that the same section continues with: >>>> >>>> Upon conclusion of an active HIP association with another host, >>>> the >>>> R1 generation counter associated with the peer host SHOULD be >>>> flushed. A local policy MAY override the default flushing of R1 >>>> counters on a per-HIT basis. The reason for recommending the >>>> flushing of this counter is that there may be hosts where the R1 >>>> generation counter (occasionally) decreases; e.g., due to hardware >>>> failure. >>> >>> Yes, but this describes the behavior of the peer, not of the host >>> sending the R1 counter value. Hence, this does not mention how to deal >>> with roll overs. >> >> You're right, this is an open issue. > > I think the whole R1 counter concept is a bit cumbersome because it is > buried into local policy issues and the roll over is problematic. I > would suggest removing the R1 counter and simply mandating the > Responder to send ECHO_REQUEST_SIGNED and the Initiator to send it in > I2. Since the nonce is fresh and signed, it should provide replay > protection even against a man-in-the-middle attacker. > > Opinions? I am using R1 counter for AES-CTR in HIP encryption in DEX for the CTR offset. You are pointing out how this MAY be a problem. Got to block time out to work through this. From mkomu@cs.hut.fi Thu Oct 18 14:38:57 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D450E21F845B for ; Thu, 18 Oct 2012 14:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5ygG52-s0m for ; Thu, 18 Oct 2012 14:38:56 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7E95921F843C for ; Thu, 18 Oct 2012 14:38:56 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id F32D530867E for ; Fri, 19 Oct 2012 00:38:54 +0300 (EEST) Message-ID: <508076EE.1050700@cs.hut.fi> Date: Fri, 19 Oct 2012 00:38:54 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> In-Reply-To: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Feedback for 4423bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:38:58 -0000 Hi, On 10/10/2012 10:05 PM, Sasu Tarkoma wrote: > Hi all, > > I read the latest HIP architecture draft (4423bis-05) and it looks > very good. Below you will find some observations that I made > when reading the draft. looks good to me too but I have also some suggestions for improvement. Here's the first batch of comments, I'll send the remaining ones later. > 1. Introduction > ... > Although the Host Identifiers could be used in many authentication > systems, such as IKEv2 [RFC4306], the presented architecture > introduces a new protocol, called the Host Identity Protocol (HIP), > and a cryptographic exchange, called the HIP base exchange; see also > Section 7. The HIP protocols provide for limited forms of trust > between systems, enhance mobility, multi-homing and dynamic IP > renumbering, aid in protocol translation / transition, and reduce > certain types of denial-of-service (DoS) attacks. (The HIP protocols provide -> HIP provides) based on offline discussions with a few people, I'd suggest adding something like the following: Back-to-My-Mac [RFC6281] from Apple comes pretty close to the functionality of HIP. Unlike HIP, it is based on non-cryptographic identifiers and is based on a collection of protocols rather than a single one like HIP. As an analogy to UNIX software, Back-to-My-Mac could be considered as command line tools combined using piping. In contrast, HIP takes the approach that the bandwidth and latency of the "pipe", that is the network, is constrained resource, and combines multiple functionalities to a single protocol. > Much has been learned about HIP since [RFC4423] was published. This > document expands Host Identities beyond use to enable IP connectivity > and security to general interhost secure signalling at any protocol > layer. The signal may establish a security association between the > hosts, or simply pass information within the channel. Much has been learned... I would suggest to add an information reference to the experiment report (RFC6538). > 2.1. Terms common to other documents You talk about RSA and DSA, perhaps you could mention also ECC. > 3. Background > ... > (silicon based people, if you will). All these components need to be > .. silicon-based people > Secondly, anonymity is not provided in a consistent, trustable manner. Yes, blind extensions support anonymity but I think the point here should be about confidentiality rather than anonymity. > 3.1. A desire for a namespace for computing platforms > > * The namespace should fully decouple the internetworking layer from > the higher layers. The names should replace all occurrences of IP > addresses within applications (like in the Transport Control > Block, TCB). This may require changes to the current APIs. In > the long run, it is probable that some new APIs are needed. I would suggest to replace the last two sentences with the following: While HIP is compatible with legacy applications [RFC5338], developers trying to harness to full benefits of HIP should employ APIs for HIP-aware applications [RFC6317]. (Both references should be informative) > * Sometimes the names may contain a delegation component. This > is the cost of resolvability. Please elaborate, this is too vague. Are referring to the referral issues, please see section 4.2 in RFC6538. Or process migration and delegation? > 4. Host Identity namespace > .. > However, in the authors' > opinion, a public key of a 'public key pair' makes the best Host > Identifier. Suggest replacing with: In the HIP architecture, the public key of a private-public key pair has been chosen as the Host Identifier because it can be self managed and computationally difficult to forge. > There is on-going research in challenge puzzles to use > non-cryptographic HI, like RFIDs, in an HIP exchange > tailored to the workings of such challenges. is on-going -> has been past (should you reference to rfid draft?) > The actual Host Identifiers are never directly used in any Internet > protocols At least, not intentionally (referral issues). Or what you mean by "Internet protocols"? > 4.2. Host Identity Hash (HIH) where does intermediary term "HIH" comes from? I think it's not necessary (is it in the other RFCs?) > The Host Identity Hash is the cryptographic hash used in producing > the HIT from the HI. hash -> hash algorithm > It is possible to for the two hosts in the HIP exchange to use > different hashes. hashes -> hash algorithms > 4.3. Host Identity Tag (HIT) > .. > There can be multiple HITs per Host Identifier when multiple hashes > are supported. An Initator may have to initially guess which HIT to > use for the Responder, typically based on what it prefers, until it > learns the appropriate HIT through the HIP exchange. Isn't this information directly in the OGA bits? > 4.4. Local Scope Identifier (LSI) I would add in the end of the last paragraph that "LSIs make it possible for an IPv4-based application to communicate with an IPv6-based application". > 4.5. Storing Host Identifiers in Directories > > Alternatively, or in addition to storing Host Identifiers in the DNS, > they may be stored in various other directories (e.g. LDAP, DHT) or > in a Public Key Infrastructure (PKI) Please add an informational reference to RFC6537 just after the DHT. > 5.1. Transport associations and end-points > .. > It is possible that a single physical computer hosts several logical > end-points. With HIP, each of these end-points would have a distinct > Host Identity. Furthermore, since the transport associations are > bound to Host Identities, HIP provides for process migration and > clustered servers. That is, if a Host Identity is moved from one > physical computer to another, it is also possible to simultaneously > move all the transport associations without breaking them. > Similarly, if it is possible to distribute the processing of a single > Host Identity over several physical computers, HIP provides for > cluster based services without any changes at the client end-point. I think there was also some other comments about this. This text is not in good shape and it needs to written. It mixes two separate topics into a single paragraph: * Distributing HI processing - sounds like a nice research idea but it's badly explained and lacks a reference. I'd suggest removing. * Process migration is way more complicated than the text implies (suggest removing). Btw, the best reference for HIP-based process migration with delegation is this: S. Herborn, A. Huber, R. Boreli, and A. Seneviratne. Secure host identity delegation for mobility. In COMSWARE. IEEE, 2007. (Talking about clusters and process migration is a bit old fashioned since nowadays as cloud computing and VM migration are more fashionable :) > 6. End-host mobility and multi-homing > .. > However, as discussed in > Section 6.2 below, a mobile node must send a HIP readdress packet to > inform the peer of the new address(es), and the peer must verify that > the mobile node is reachable through these addresses. readdress -> UPDATE Remaining comments later! P.S. Please add also "Aalto University" and "RWTH Aachen" to the acknowledgement list, thanks! From rgm@htt-consult.com Thu Oct 18 21:25:54 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D251F0C3A for ; Thu, 18 Oct 2012 21:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahTp+zdLoAiI for ; Thu, 18 Oct 2012 21:25:53 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 78DBD1F0425 for ; Thu, 18 Oct 2012 21:25:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5D1AB62A6E; Fri, 19 Oct 2012 04:25:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yM3A6BClflz; Fri, 19 Oct 2012 00:24:54 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DC0DD62A61; Fri, 19 Oct 2012 00:24:53 -0400 (EDT) Message-ID: <5080D615.5010409@htt-consult.com> Date: Fri, 19 Oct 2012 00:24:53 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Miika Komu References: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> <508076EE.1050700@cs.hut.fi> In-Reply-To: <508076EE.1050700@cs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] Feedback for 4423bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 04:25:54 -0000 I want to thank both of you for these comments. Updating 4423 has been hard; there is a historical prospective that has needed to be addressed, and I missed a number of points. Note that 4423-bis NEEDs to remain an architectual document, and not a protocol document. This is a fine line to tread; particularly here in the IETF where protocols are our life. But it needs to reflect the current state of the art, not a forecast of where the art is going. This means that there are many items that were TBDs back when 4423 was penned, but are now finished. Likewise, HIP-RFID is still work in progress. So my goal is to work up the next version for mid-next week. I will be posting some text here for review purposes. On 10/18/2012 05:38 PM, Miika Komu wrote: > Hi, > > On 10/10/2012 10:05 PM, Sasu Tarkoma wrote: >> Hi all, >> >> I read the latest HIP architecture draft (4423bis-05) and it looks >> very good. Below you will find some observations that I made >> when reading the draft. > > looks good to me too but I have also some suggestions for improvement. > Here's the first batch of comments, I'll send the remaining ones later. > >> 1. Introduction >> ... >> Although the Host Identifiers could be used in many authentication >> systems, such as IKEv2 [RFC4306], the presented architecture >> introduces a new protocol, called the Host Identity Protocol (HIP), >> and a cryptographic exchange, called the HIP base exchange; see also >> Section 7. The HIP protocols provide for limited forms of trust >> between systems, enhance mobility, multi-homing and dynamic IP >> renumbering, aid in protocol translation / transition, and reduce >> certain types of denial-of-service (DoS) attacks. > > (The HIP protocols provide -> HIP provides) > > based on offline discussions with a few people, I'd suggest adding > something like the following: > > Back-to-My-Mac [RFC6281] from Apple comes pretty close to the > functionality of HIP. Unlike HIP, it is based on non-cryptographic > identifiers and is based on a collection of protocols rather than a > single one like HIP. As an analogy to UNIX software, Back-to-My-Mac > could be considered as command line tools combined using piping. In > contrast, HIP takes the approach that the bandwidth and latency of the > "pipe", that is the network, is constrained resource, and combines > multiple functionalities to a single protocol. > >> Much has been learned about HIP since [RFC4423] was published. This >> document expands Host Identities beyond use to enable IP connectivity >> and security to general interhost secure signalling at any protocol >> layer. The signal may establish a security association between the >> hosts, or simply pass information within the channel. > > Much has been learned... I would suggest to add an information > reference to the experiment report (RFC6538). > >> 2.1. Terms common to other documents > > You talk about RSA and DSA, perhaps you could mention also ECC. > >> 3. Background >> ... >> (silicon based people, if you will). All these components need to be >> .. > > silicon-based people > >> Secondly, anonymity is not provided in a consistent, trustable manner. > > Yes, blind extensions support anonymity but I think the point here > should be about confidentiality rather than anonymity. > >> 3.1. A desire for a namespace for computing platforms >> >> * The namespace should fully decouple the internetworking layer from >> the higher layers. The names should replace all occurrences of IP >> addresses within applications (like in the Transport Control >> Block, TCB). This may require changes to the current APIs. In >> the long run, it is probable that some new APIs are needed. > > I would suggest to replace the last two sentences with the following: > > While HIP is compatible with legacy applications [RFC5338], developers > trying to harness to full benefits of HIP should employ APIs for > HIP-aware applications [RFC6317]. > > (Both references should be informative) > >> * Sometimes the names may contain a delegation component. This >> is the cost of resolvability. > > Please elaborate, this is too vague. Are referring to the referral > issues, please see section 4.2 in RFC6538. Or process migration and > delegation? > >> 4. Host Identity namespace >> .. >> However, in the authors' >> opinion, a public key of a 'public key pair' makes the best Host >> Identifier. > > Suggest replacing with: > > In the HIP architecture, the public key of a private-public key pair > has been chosen as the Host Identifier because it can be self managed > and computationally difficult to forge. > >> There is on-going research in challenge puzzles to use >> non-cryptographic HI, like RFIDs, in an HIP exchange >> tailored to the workings of such challenges. > > is on-going -> has been past (should you reference to rfid draft?) > >> The actual Host Identifiers are never directly used in any Internet >> protocols > > At least, not intentionally (referral issues). Or what you mean by > "Internet protocols"? > >> 4.2. Host Identity Hash (HIH) > > where does intermediary term "HIH" comes from? I think it's not > necessary (is it in the other RFCs?) > >> The Host Identity Hash is the cryptographic hash used in producing >> the HIT from the HI. > > hash -> hash algorithm > >> It is possible to for the two hosts in the HIP exchange to use >> different hashes. > > hashes -> hash algorithms > >> 4.3. Host Identity Tag (HIT) >> .. >> There can be multiple HITs per Host Identifier when multiple hashes >> are supported. An Initator may have to initially guess which HIT to >> use for the Responder, typically based on what it prefers, until it >> learns the appropriate HIT through the HIP exchange. > > Isn't this information directly in the OGA bits? > >> 4.4. Local Scope Identifier (LSI) > > I would add in the end of the last paragraph that "LSIs make it > possible for an IPv4-based application to communicate with an > IPv6-based application". > >> 4.5. Storing Host Identifiers in Directories >> >> Alternatively, or in addition to storing Host Identifiers in the DNS, >> they may be stored in various other directories (e.g. LDAP, DHT) or >> in a Public Key Infrastructure (PKI) > > Please add an informational reference to RFC6537 just after the DHT. > >> 5.1. Transport associations and end-points >> .. >> It is possible that a single physical computer hosts several logical >> end-points. With HIP, each of these end-points would have a distinct >> Host Identity. Furthermore, since the transport associations are >> bound to Host Identities, HIP provides for process migration and >> clustered servers. That is, if a Host Identity is moved from one >> physical computer to another, it is also possible to simultaneously >> move all the transport associations without breaking them. >> Similarly, if it is possible to distribute the processing of a single >> Host Identity over several physical computers, HIP provides for >> cluster based services without any changes at the client end-point. > > I think there was also some other comments about this. This text is > not in good shape and it needs to written. It mixes two separate > topics into a single paragraph: > > * Distributing HI processing - sounds like a nice research idea but > it's badly explained and lacks a reference. I'd suggest removing. > * Process migration is way more complicated than the text implies > (suggest removing). > > Btw, the best reference for HIP-based process migration with > delegation is this: > > S. Herborn, A. Huber, R. Boreli, and A. Seneviratne. Secure host > identity delegation for mobility. In COMSWARE. IEEE, 2007. > > (Talking about clusters and process migration is a bit old fashioned > since nowadays as cloud computing and VM migration are more > fashionable :) > >> 6. End-host mobility and multi-homing >> .. >> However, as discussed in >> Section 6.2 below, a mobile node must send a HIP readdress packet to >> inform the peer of the new address(es), and the peer must verify that >> the mobile node is reachable through these addresses. > > readdress -> UPDATE > > Remaining comments later! > > P.S. Please add also "Aalto University" and "RWTH Aachen" to the > acknowledgement list, thanks! > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Fri Oct 19 05:06:44 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B37B21F8686 for ; Fri, 19 Oct 2012 05:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEOn4T1JdbMF for ; Fri, 19 Oct 2012 05:06:42 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id DEDAA21F8682 for ; Fri, 19 Oct 2012 05:06:38 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id BC17762A63 for ; Fri, 19 Oct 2012 12:06:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+kIfCx6RaRd for ; Fri, 19 Oct 2012 08:05:54 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0DA9862A61 for ; Fri, 19 Oct 2012 08:05:54 -0400 (EDT) Message-ID: <50814221.1060700@htt-consult.com> Date: Fri, 19 Oct 2012 08:05:53 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <50759ACB.7070304@cs.hut.fi> In-Reply-To: <50759ACB.7070304@cs.hut.fi> X-Forwarded-Message-Id: <50759ACB.7070304@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:06:44 -0000 There has been a side converstation going on about the use of DNSKEY RR format for RSA/DSA HOST_IDs per sec 5.2.9. I am bringing the discussion to a larger audience so we can get a 'decide' and put this one to bed. Historically speaking, this was a good quick choice made at a lobby meeting way back when (Andrew, I believe you were part of the meeting, do you remember what year it was? :) ). It had everything needed to define the Host ID and had existing code not tied into 'certficate stuff'. While we were developing HIP, we decided to ignore RFC 4043, as we are NOT using DNSKEY RR to store HIP information, only how to format it. We have our own RR. Now it is choice time. Do we stay the course as currently shown in 5.2.9 or do we use: RFC3279 as mentioned below or do we follow with those that are following us with draft-ietf-tls-oob-pubkey-04.txt Do either of these provide all that we need for RSA/DSA Host ID representation and are they more compact? Note that for ECDSA (and ECDH in HIP DEX) we use a very simple format that carries the (x,y) coordinate for the key (compact notation WOULD be nicer for DEX, but there seems to be security concerns around it). -------- Original Message -------- That started to discussion from Miika... Hi René, sorry for the belated response. I recall that we discussed about the use of SRV records but I do not have a recollection of the DNSKEY issue you mentioned. On 09/23/2012 07:16 PM, René Hummen wrote: > Hi Miika, > > I found one more issue that I did not yet report to the mailing list. As > I am not completely sure about the consequences of this issue and the > necessary changes, I would like some feedback from you first. Is it > still worth mentioning this at such a late state of the standardization > process? > > Thanks for having a look at the following few line! > > René > > --------------------- TEXT FOR WG ---------------------- > > > While going through draft-ietf-hip-rfc5201-bis-09, I stumbled across an > old issue that came up in a discussion with Stefan Götz at our > chair. The issue concerns the serialization format for HI public keys. > > > 5.2.9 > . > HOST_ID > > "The Host Identity is derived from the DNSKEY format for RSA and DSA. For these, the Public Key field of the RDATA part fromRFC 4034 [RFC4034 ] is used." > > > This implies that public keys in HIP are stored in the "DNSKEY RDATA > Wire Format" as defined in RFC 4043 Section 2.1 [1]. > > However, RFC 4043 Section 2 states: > "The DNSKEY RR is not intended as a record for storing arbitrary public > keys and MUST NOT be used to store certificates or public keys that do > not directly relate to the DNS infrastructure." > > While HIs can be stored in DNS, they do not have a direct relation to > the DNS infrastructure. Still there seems to be no harm in using this > serialization format in practice. The question is, do we want to move > to a different serialization format? A good candidate seems to be > ASN.1/DER encoding as detailed in RFC 3279 with a compact binary > representation for data in a cryptographic context. > > BR, > René > > > [1] http://tools.ietf.org/html//rfc4034#section-2.1 > From andrewmcgr@gmail.com Fri Oct 19 14:22:00 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EF221F87A2 for ; Fri, 19 Oct 2012 14:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.986 X-Spam-Level: X-Spam-Status: No, score=-2.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuTKuYlplpyo for ; Fri, 19 Oct 2012 14:21:59 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB6B21F879B for ; Fri, 19 Oct 2012 14:21:59 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so421579dan.31 for ; Fri, 19 Oct 2012 14:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rwGjqb0FxEzP/FFPcuC8SixopR9Tzn2tmXg4azAPEoQ=; b=S0kIPn5bm52GFKGFTjFlng0yAgOIakuIB8VdXSxCY3z0DV4ZhnkBZbG3KQjRHwLQWS 1SYlexKwwqezT6iTWXsENCl2cAgr2qfpD4CfuItc02k+io+4XnGmSDiiIiC6H3vRNF1a Ixtc0g/+BAaTC4r/8itunH4PgFhll++EE29BeoT6nxxa6WtINe4oDLAnZ9wpZhOvpCQw 85VbzmBhd/BoNezrWBs0bCIo0gACBJBQHAA6usXXsfqOutRzR7ENHF2DN5bqibO5B1RP UMqaSM/qSNLDrXa8lX+9HNUk/eDyvtxPnk+/j20GLAfYi2TjTi44jeFndbLpPMCx1Chk Dfhw== Received: by 10.66.79.168 with SMTP id k8mr7018571pax.12.1350681718974; Fri, 19 Oct 2012 14:21:58 -0700 (PDT) Received: from ?IPv6:2406:e000:63ed:1:fdeb:afa9:bd7f:b963? ([2406:e000:63ed:1:fdeb:afa9:bd7f:b963]) by mx.google.com with ESMTPS id j4sm1620065pax.31.2012.10.19.14.21.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 14:21:57 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Andrew McGregor In-Reply-To: <50814221.1060700@htt-consult.com> Date: Sat, 20 Oct 2012 10:21:48 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1498) Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:22:00 -0000 As best I can recall, it was either Pittsburgh in 2000 or Minneapolis in = 2001. If you follow the reference chains, you find that = draft-ietf-tls-oob-pubkey-04.txt ends up pointing to RFC 3279 anyway, so = really it comes down to, do we use DNS formatting or x509 formatting? Since parsing and formatting code for both is pretty much ubiquitous and = the packet space is dominated by the key itself, I see no real reason to = change. That DNSKEY is supposed only to be used for DNSSEC is a = distraction, we have our own RR and reusing the wire format is merely a = convenience. Andrew On 20/10/2012, at 1:05 AM, Robert Moskowitz wrote: > There has been a side converstation going on about the use of DNSKEY = RR format for RSA/DSA HOST_IDs per sec 5.2.9. >=20 > I am bringing the discussion to a larger audience so we can get a = 'decide' and put this one to bed. >=20 > Historically speaking, this was a good quick choice made at a lobby = meeting way back when (Andrew, I believe you were part of the meeting, = do you remember what year it was? :) ). It had everything needed to = define the Host ID and had existing code not tied into 'certficate = stuff'. While we were developing HIP, we decided to ignore RFC 4043, as = we are NOT using DNSKEY RR to store HIP information, only how to format = it. We have our own RR. >=20 > Now it is choice time. Do we stay the course as currently shown in = 5.2.9 or do we use: >=20 > RFC3279 as mentioned below >=20 > or do we follow with those that are following us with >=20 > draft-ietf-tls-oob-pubkey-04.txt >=20 > Do either of these provide all that we need for RSA/DSA Host ID = representation and are they more compact? >=20 > Note that for ECDSA (and ECDH in HIP DEX) we use a very simple format = that carries the (x,y) coordinate for the key (compact notation WOULD be = nicer for DEX, but there seems to be security concerns around it). >=20 >=20 > -------- Original Message -------- That started to discussion from = Miika... >=20 > Hi Ren=E9, >=20 > sorry for the belated response. I recall that we discussed about the = use > of SRV records but I do not have a recollection of the DNSKEY issue = you > mentioned. >=20 > On 09/23/2012 07:16 PM, Ren=E9 Hummen wrote: >> Hi Miika, >>=20 >> I found one more issue that I did not yet report to the mailing list. = As >> I am not completely sure about the consequences of this issue and the >> necessary changes, I would like some feedback from you first. Is it >> still worth mentioning this at such a late state of the = standardization >> process? >>=20 >> Thanks for having a look at the following few line! >>=20 >> Ren=E9 >>=20 >> --------------------- TEXT FOR WG ---------------------- >>=20 >>=20 >> While going through draft-ietf-hip-rfc5201-bis-09, I stumbled across = an >> old issue that came up in a discussion with Stefan G=F6tz at our >> chair. The issue concerns the serialization format for HI public = keys. >>=20 >>=20 >> 5.2.9 >> = . >> HOST_ID >>=20 >> "The Host Identity is derived from the DNSKEY format for RSA and DSA. = For these, the Public Key field of the RDATA part fromRFC 4034 = [RFC4034 = ] is used." >>=20 >>=20 >> This implies that public keys in HIP are stored in the "DNSKEY RDATA >> Wire Format" as defined in RFC 4043 Section 2.1 [1]. >>=20 >> However, RFC 4043 Section 2 states: >> "The DNSKEY RR is not intended as a record for storing arbitrary = public >> keys and MUST NOT be used to store certificates or public keys that = do >> not directly relate to the DNS infrastructure." >>=20 >> While HIs can be stored in DNS, they do not have a direct relation to >> the DNS infrastructure. Still there seems to be no harm in using this >> serialization format in practice. The question is, do we want to = move >> to a different serialization format? A good candidate seems to be >> ASN.1/DER encoding as detailed in RFC 3279 with a compact binary >> representation for data in a cryptographic context. >>=20 >> BR, >> Ren=E9 >>=20 >>=20 >> [1] http://tools.ietf.org/html//rfc4034#section-2.1 >>=20 >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Fri Oct 19 15:28:13 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3321F87A1 for ; Fri, 19 Oct 2012 15:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArALZqNa7FoI for ; Fri, 19 Oct 2012 15:28:13 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4821F8816 for ; Fri, 19 Oct 2012 15:28:07 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9JMS6no013310 for ; Fri, 19 Oct 2012 17:28:07 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9JMS4qA013278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 19 Oct 2012 17:28:05 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 19 Oct 2012 15:28:04 -0700 From: "Henderson, Thomas R" To: "'Andrew McGregor'" , Robert Moskowitz Date: Fri, 19 Oct 2012 15:28:04 -0700 Thread-Topic: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities Thread-Index: Ac2uP97SqZmt/vkZRQeqEXDFfrPvswACQiyQ Message-ID: <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:28:13 -0000 >=20 > Since parsing and formatting code for both is pretty much ubiquitous > and the packet space is dominated by the key itself, I see no real > reason to change. That DNSKEY is supposed only to be used for DNSSEC > is a distraction, we have our own RR and reusing the wire format is > merely a convenience. +1 - Tom From mkomu@cs.hut.fi Sat Oct 20 08:04:47 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78F21F84CD for ; Sat, 20 Oct 2012 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNA47YgfUZVd for ; Sat, 20 Oct 2012 08:04:47 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1721F8480 for ; Sat, 20 Oct 2012 08:04:46 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 262CE3085C8 for ; Sat, 20 Oct 2012 18:04:44 +0300 (EEST) Message-ID: <5082BD8C.4090205@cs.hut.fi> Date: Sat, 20 Oct 2012 18:04:44 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:04:47 -0000 Hi, On 10/20/2012 01:28 AM, Henderson, Thomas R wrote: >> >> Since parsing and formatting code for both is pretty much ubiquitous >> and the packet space is dominated by the key itself, I see no real >> reason to change. That DNSKEY is supposed only to be used for DNSSEC >> is a distraction, we have our own RR and reusing the wire format is >> merely a convenience. > > +1 fine by me as well. From heer@informatik.rwth-aachen.de Sat Oct 20 14:21:13 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EC21F8467 for ; Sat, 20 Oct 2012 14:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2llj4OofzjLr for ; Sat, 20 Oct 2012 14:21:12 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4030421F846F for ; Sat, 20 Oct 2012 14:21:12 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dfGbQ5UP5DR2avR9iGD+3A)" Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MC7009Z0NBA9AB0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sat, 20 Oct 2012 23:21:10 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.80,622,1344204000"; d="scan'208";a="108226658" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; Sat, 20 Oct 2012 23:21:11 +0200 Received: from mail-ie0-f172.google.com ([unknown] [209.85.223.172]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MC700H9ANB9ZA20@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sat, 20 Oct 2012 23:21:10 +0200 (CEST) Received: by mail-ie0-f172.google.com with SMTP id 9so2568791iec.31 for ; Sat, 20 Oct 2012 14:21:08 -0700 (PDT) Received: by 10.50.94.198 with SMTP id de6mr5142638igb.49.1350768068902; Sat, 20 Oct 2012 14:21:08 -0700 (PDT) Received: by 10.50.17.131 with HTTP; Sat, 20 Oct 2012 14:21:08 -0700 (PDT) Received: by 10.50.17.131 with HTTP; Sat, 20 Oct 2012 14:21:08 -0700 (PDT) In-reply-to: <5082BD8C.4090205@cs.hut.fi> References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> <5082BD8C.4090205@cs.hut.fi> Date: Sat, 20 Oct 2012 23:21:08 +0200 Message-id: From: Tobias Heer To: Miika Komu Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:21:13 -0000 --Boundary_(ID_dfGbQ5UP5DR2avR9iGD+3A) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Am 20.10.2012 17:04 schrieb "Miika Komu" @ cs.hut.fi >: > > Hi, > > > On 10/20/2012 01:28 AM, Henderson, Thomas R wrote: >>> >>> >>> Since parsing and formatting code for both is pretty much ubiquitous >>> and the packet space is dominated by the key itself, I see no real >>> reason to change. That DNSKEY is supposed only to be used for DNSSEC >>> is a distraction, we have our own RR and reusing the wire format is >>> merely a convenience. >> >> >> +1 > > > fine by me as well. I agree. +1. Tobias > > _______________________________________________ > Hipsec mailing list > Hipsec @ ietf.org > https :// www.ietf.org / mailman / listinfo / hipsec I --Boundary_(ID_dfGbQ5UP5DR2avR9iGD+3A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable


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

I agree. +1.

Tobias
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

I

--Boundary_(ID_dfGbQ5UP5DR2avR9iGD+3A)-- From rgm@htt-consult.com Sat Oct 20 17:51:30 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347FE21F891B for ; Sat, 20 Oct 2012 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VZvBtF4Xgl4 for ; Sat, 20 Oct 2012 17:51:29 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0459321F8880 for ; Sat, 20 Oct 2012 17:51:29 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1969862A6F; Sun, 21 Oct 2012 00:50:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWA3AzTSwiRc; Sat, 20 Oct 2012 20:50:39 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1542762A63; Sat, 20 Oct 2012 20:50:39 -0400 (EDT) Message-ID: <508346D5.4040908@htt-consult.com> Date: Sat, 20 Oct 2012 20:50:29 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tobias Heer References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> <5082BD8C.4090205@cs.hut.fi> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090409090806060700040602" Cc: hipsec@ietf.org Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 00:51:30 -0000 This is a multi-part message in MIME format. --------------090409090806060700040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/20/2012 05:21 PM, Tobias Heer wrote: > > > Am 20.10.2012 17:04 schrieb "Miika Komu" @ cs.hut.fi > >: > > > > Hi, > > > > > > On 10/20/2012 01:28 AM, Henderson, Thomas R wrote: > >>> > >>> > >>> Since parsing and formatting code for both is pretty much ubiquitous > >>> and the packet space is dominated by the key itself, I see no real > >>> reason to change. That DNSKEY is supposed only to be used for DNSSEC > >>> is a distraction, we have our own RR and reusing the wire format is > >>> merely a convenience. > >> > >> > >> +1 > > > > > > fine by me as well. > > I agree. +1. > All we need is for the Ericsson people to chime in and we have pretty much all the original developers. As Andrew, I remember the meeting where we chose DNSKEY format. I remember the lobby, but could not place the meeting date, but Andrew was busy coding already so he is a reliable source of when we did this. There was a attitude of avoiding x509ish things, plus DNSKEY format was more readable than ASN.1. Don't know if that what others were thinking, but I sure was! I would rather leave it as is. No real justification to switch, and it keeps ASN.1 out of the basic parameters. Only if you are supporting real certs will you be working with ASN.1. --------------090409090806060700040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/20/2012 05:21 PM, Tobias Heer wrote:


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

I agree. +1.


All we need is for the Ericsson people to chime in and we have pretty much all the original developers.

As Andrew, I remember the meeting where we chose DNSKEY format.  I remember the lobby, but could not place the meeting date, but Andrew was busy coding already so he is a reliable source of when we did this.

There was a attitude of avoiding x509ish things, plus DNSKEY format was more readable than ASN.1.  Don't know if that what others were thinking, but I sure was!

I would rather leave it as is.  No real justification to switch, and it keeps ASN.1 out of the basic parameters.  Only if you are supporting real certs will you be working with ASN.1.
--------------090409090806060700040602-- From mkomu@cs.hut.fi Sun Oct 21 05:37:45 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E40D21F8989 for ; Sun, 21 Oct 2012 05:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRYL33khRHhC for ; Sun, 21 Oct 2012 05:37:45 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id C209621F8988 for ; Sun, 21 Oct 2012 05:37:44 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 3C4DB308C43 for ; Sun, 21 Oct 2012 15:37:42 +0300 (EEST) Message-ID: <5083EC97.9030604@cs.hut.fi> Date: Sun, 21 Oct 2012 15:37:43 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> <5082BD8C.4090205@cs.hut.fi> <508346D5.4040908@htt-consult.com> In-Reply-To: <508346D5.4040908@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 12:37:45 -0000 Hi, On 10/21/2012 03:50 AM, Robert Moskowitz wrote: > All we need is for the Ericsson people to chime in and we have pretty > much all the original developers. sure, but I think we can just proceed because the decision was actually not to change anything. The discussion was more about the justification for the original decision. Let's keep rolling, no need to create unnecessary dependencies along the road. From rene.hummen@comsys.rwth-aachen.de Sun Oct 21 06:19:17 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDD21F8596 for ; Sun, 21 Oct 2012 06:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjevVoK76bto for ; Sun, 21 Oct 2012 06:19:17 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.rwth-aachen.de [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4721F849A for ; Sun, 21 Oct 2012 06:19:16 -0700 (PDT) MIME-version: 1.0 Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0MC800NUXVO34430@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sun, 21 Oct 2012 15:19:15 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.80,625,1344204000"; d="p7s'?scan'208,217";a="196363759" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-1.rz.rwth-aachen.de with ESMTP; Sun, 21 Oct 2012 15:19:15 +0200 Received: from [192.168.2.12] ([unknown] [77.11.72.229]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MC800B5TVO21U70@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sun, 21 Oct 2012 15:19:15 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-type: multipart/signed; boundary="Apple-Mail=_EE114AD8-40AB-4191-A5F5-2928262AFFA8"; protocol="application/pkcs7-signature"; micalg=sha1 Message-id: <2A95A711-0A60-4D83-82BC-EB0163FD61B1@comsys.rwth-aachen.de> Date: Sun, 21 Oct 2012 15:19:13 +0200 References: <50759ACB.7070304@cs.hut.fi> <50814221.1060700@htt-consult.com> <758141CC3D829043A8C3164DD3D593EA2E4C38C193@XCH-NW-16V.nw.nos.boeing.com> <5082BD8C.4090205@cs.hut.fi> To: "hipsec@ietf.org WG" In-reply-to: X-Mailer: Apple Mail (2.1499) Subject: Re: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 13:19:18 -0000 --Apple-Mail=_EE114AD8-40AB-4191-A5F5-2928262AFFA8 Content-Type: multipart/alternative; boundary="Apple-Mail=_1980D251-1068-459C-8080-808D97B70CE9" --Apple-Mail=_1980D251-1068-459C-8080-808D97B70CE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 20.10.2012, at 23:21, Tobias Heer wrote: > Am 20.10.2012 17:04 schrieb "Miika Komu" : > > > > Hi, > > > > > > On 10/20/2012 01:28 AM, Henderson, Thomas R wrote: > >>> > >>> > >>> Since parsing and formatting code for both is pretty much = ubiquitous > >>> and the packet space is dominated by the key itself, I see no real > >>> reason to change. That DNSKEY is supposed only to be used for = DNSSEC > >>> is a distraction, we have our own RR and reusing the wire format = is > >>> merely a convenience. > >> > >> > >> +1 > > > > > > fine by me as well. >=20 > I agree. +1. >=20 I originally brought up the issue because I was not sure if 5201-bis was = conflicting with the statement in RFC 4043. Now that things are = clarified, it's fine by me. -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_1980D251-1068-459C-8080-808D97B70CE9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 20.10.2012, at 23:21, Tobias Heer <heer@cs.rwth-aachen.de> wrote:

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

I agree. +1.

I originally brought up the issue because I was not sure if 5201-bis was conflicting with the statement in RFC 4043. Now that things are clarified, it's fine by me.



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21429
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

--Apple-Mail=_1980D251-1068-459C-8080-808D97B70CE9-- --Apple-Mail=_EE114AD8-40AB-4191-A5F5-2928262AFFA8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjExMzE5MTNaMCMGCSqGSIb3DQEJBDEWBBRVaUaOkEJw 52DZ+B3GPq5Zmzj2PzB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQBGIbRadsy8 dXn4XRLSyJInGxHUM427g+w+LmZZ3bVReC7pF1Xis0BM46g4z/0r2Dk13VEuvFRCEzl34bQvfDSo tbhoNA957JNt8BnwBUtvuOlIILxjC7T2ZcrV6a70rJokP18DTorLtByAXjkDcgt8xmV+2xvTkQsz YZMM2b4LBm+LoJEONc/gJ781CyfS5r+d+dpaJquWcA/tr2QyamDeFW7yyytMo2suRy0I11alMHbR zQeSuVf9H7+7Y+dcPdLtlZTyS6sPAtQrxwjFDMZnljDvegEGgdrsvafoAVTHlVcZaEapHF5ZGww+ SBVjbBEcv+wApEFRTBptYdx2stRiAAAAAAAA --Apple-Mail=_EE114AD8-40AB-4191-A5F5-2928262AFFA8-- From mkomu@cs.hut.fi Sun Oct 21 08:21:37 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8521F897E for ; Sun, 21 Oct 2012 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viLnwDwFPA6U for ; Sun, 21 Oct 2012 08:21:35 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72721F897A for ; Sun, 21 Oct 2012 08:21:35 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id D8D52308D3D for ; Sun, 21 Oct 2012 18:21:33 +0300 (EEST) Message-ID: <508412FD.2010606@cs.hut.fi> Date: Sun, 21 Oct 2012 18:21:33 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> <508076EE.1050700@cs.hut.fi> In-Reply-To: <508076EE.1050700@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Feedback for 4423bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 15:21:37 -0000 Hi, On 10/19/2012 12:38 AM, Miika Komu wrote: > Hi, > > On 10/10/2012 10:05 PM, Sasu Tarkoma wrote: >> Hi all, >> >> I read the latest HIP architecture draft (4423bis-05) and it looks >> very good. Below you will find some observations that I made >> when reading the draft. > > looks good to me too but I have also some suggestions for improvement. > Here's the first batch of comments, I'll send the remaining ones later. the second batch is here, I'll send the third and final later. > 6.2. Protection against flooding attacks > > HIP includes an address check mechanism (or return routability test) > 7. HIP and ESP > > The preferred way of implementing HIP is to use ESP to carry the > actual data traffic. As of today, the only completely defined method > is to use ESP Encapsulated Security Payload (ESP) to carry the data > packets [I-D.ietf-hip-rfc5202-bis]. In the future, other ways of > transporting payload data may be developed, including ones that do > not use cryptographic protection. Several comments: * I would start the discussion by mentioning that the data plane encapsulation is not fixed and can be negotiated during the key exchange. * ESP offers confidentiality protection or integrity protection, or both, and this is negotiable * More precisely, the default ESP mode is BEET (tunnel mode semantics but transport mode syntax) to reduce the overhead of tunneling but transport and tunnel mode are negotiable by further extensions. * Other encapsulations have been proposed: http://tools.ietf.org/html/draft-tschofenig-hiprg-hip-srtp-01 > In practice, the HIP base exchange uses the cryptographic Host > Identifiers to set up a pair of ESP Security Associations (SAs) to > enable ESP in an end-to-end manner. This is implemented in a way > that can span addressing realms. How? Unless you want to explain, please just reference RFC 5770 or the draft: http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal Informal reference is fine. > First, IKE (and IKEv2) were not designed with middle boxes in mind. Yes, historically, but also IKE has UDP encapsulation nowadays and products can even fake TCP/HTTP encapsulation. This sentence actually a bit ambiguous since IKE(v2) is actually *is* a middlebox (gateway) based solution (where as the end-to-end mode is the default for HIP). Please rephrase and I would also urge to stick to the state of art rather than history. > Originally, as HIP is designed for host usage, not for gateways or so > called Bump-in-the-Wire (BITW) implementations, only ESP transport > mode is supported. Again, let's just focus on the state of the art; you start the description with "originally" and never describe "presently". Also, the most popular mode is the BEET, not transport. > An ESP SA pair is indexed by the SPIs and the two > HITs (both HITs since a system can have more than one HIT). Yes, internally for hosts, but externally on the wire it's just the SPI when BEET mode is applied. HITs are not included in the packet. > Thus, real-world conditions > like loss of a PPP connection and its re-establishment or a mobile > handover will not require a HIP negotiation or disruption of > transport services [Bel1998]. Yet another historical reference. Bel1998 points to a slide set which is not really the best type of reference you can have. I would suggest omitting the reference since it's rather unimportant. > 8. HIP and MAC Security Does this count as MAC-based security scheme: http://tools.ietf.org/html/draft-henderson-hip-vpls > 9. HIP and NATs > .. > This may happen, .. This may occur, > For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the > mapping of HITs, and the corresponding ESP SPIs, to an IP address. > The NAT system has to learn mappings both from HITs and from SPIs to > IP addresses. Many HITs (and SPIs) can map to a single IP address on > a NAT, simplifying connections on address poor NAT interfaces. The > NAT can gain much of its knowledge from the HIP packets themselves; > however, some NAT configuration may be necessary. You're missing a reference: http://dl.acm.org/citation.cfm?id=1128500 Also, you're giving an impression that HIP-aware NATs are typically used but this is not really the case. As a concrete way to improve the text, please start with the RFC5770 reference and only then describe the above mentioned SPINAT draft. Regarding to RFC5770, I would suggest to mention that also Teredo (RFC 4380) has been successfully experimented with HIP: http://dl.acm.org/citation.cfm?id=1719793 In a nutshell, Teredo has more infrastructure but some additional overhead naturally results from additional tunneling. > HIP provides for 'Distributed NAT', and uses the HIT or the > LSI as a placeholder for embedded IP addresses. Suggestion: HIP provides for 'Distributed NAT' operating between network and upper layers, and uses the HIT or the LSI as a placeholder for embedded IP addresses. For this reason, HIP is able to support communications between an IPv4 and IPv6-based application. > An experimental HIP and NAT traversal is defined in [RFC5770]. Or... http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal ? > 9.1. HIP and Upper-layer checksums > .. > 10. Multicast The discussion is really void without any references: http://dl.acm.org/citation.cfm?id=277744 http://dl.acm.org/citation.cfm?id=2006035 http://dl.acm.org/citation.cfm?id=2006035 > 11. HIP policies > .. > Opportunistic mode (where the initator starts a HIP exchange without > prior knowledge of the responder's HI) presents a policy tradeoff. the most detailed reference for this is: http://dl.acm.org/citation.cfm?id=1700740 But feel free to reference also the experiment report: http://tools.ietf.org/html/rfc6538#section-2.3.2 > It provides some security benefits but may be subject to MITM. At the expense of being subject to MITM attacks, the opportunistic mode allows the initiator learn the the identity of the responder during communications rather than from an external directory. A good reference for opportunistic mode is: V. Pham and T. Aura. Security Analysis of Leap-of-Faith Protocols. In Seventh ICST International Conference on Security and Privacy for Com- munication Networks, Sept. 2011. > 12. Benefits of HIP Please add a section for drawbacks: * Additional management complexity by additional indirection layer and namespace * Any tunneling mechanism causes some extra latency and bandwidth limitations for the data plane * Referrals (which are already a problem due to NATs) > In the beginning, the network layer protocol (i.e., IP) had the > following four "classic" invariants: What's your reference for the classic invariants? I suggest also switching to numbered bullets when listing them because you then later reference them by number. > IPv6 is an attempt to reinstate the first invariant. What about NAT64? > Few systems on the Internet have DNS names that are meaningful. Few client-side systems... > Although each namespace can be stretched (IP > with v6, DNS with KEY records), neither can adequately provide for > host authentication or act as a separation between internetworking > and transport layers. URIs and URLs also extend the DNS namespace and are more common than KEY records. > The Host Identity (HI) namespace fills an important gap between the > IP and DNS namespaces. An interesting thing about the HI is that it > actually allows one to give up all but the 3rd network-layer > invariant. That is to say, as long as the source and destination > addresses in the network-layer protocol are reversible, then things > work ok because HIP takes care of host identification, and > reversibility allows one to get a packet back to one's partner host. > You do not care if the network-layer address changes in transit > (mutable) and you don't care what network-layer address the partner > is using (non-omniscient). Actually, even the third invariant is lost due to NATs that involve the transport layer ports, but HIP can be used even in such a case. The invariants are not "given up", they just shifted to the HIP layer for proper handling. > 12.1. HIP's answers to NSRG questions > > 1. How would a stack name improve the overall functionality of the > Internet? > > HIP decouples the internetworking layer from the transport > layer, allowing each to evolve separately. The decoupling > makes end-host mobility and multi-homing easier, also across > IPv4 and IPv6 networks. HIs make network renumbering easier, > and they also make process migration and clustered servers > easier to implement. Furthermore, being cryptographic in > nature, they provide the basis for solving the security > problems related to end-host mobility and multi-homing. You're missing IPv6 interoperability at the *application* layer. > 3. What is its lifetime? > > HIP provides both stable and temporary Host Identifiers. > Stable HIs are typically long lived, with a lifetime of years > or more. The lifetime of temporary HIs depends on how long > the upper-layer connections and applications need them, and > can range from a few seconds to years. Advancements in crypto analysis may also reduce the lifetime of the Identifiers because they are bound to cryptographic algorithms. > 4. Where does it live in the stack? > > The HIs live between the transport and internetworking layers. ...but are referenced by the application and transport layers. > 6. What administrative infrastructure is needed to support it? > > In some environments, it is possible to use HIP > opportunistically, without any infrastructure. again, the most detailed reference for this is: http://dl.acm.org/citation.cfm?id=1700740 But feel free to reference also the experiment report: http://tools.ietf.org/html/rfc6538#section-2.3.2 > However, to > gain full benefit from HIP, the HIs must be stored in the DNS > or a PKI, and a new rendezvous mechanism is needed > [I-D.ietf-hip-rfc5205-bis]. LDAP (RFC4510) is missing, this has been used successfully. > 8. What additional security benefits would a new naming scheme > offer? > > HIP reduces dependency on IP addresses, making the so called > address ownership [Nik2001] problems easier to solve. In > practice, HIP provides security for end-host mobility and > multi-homing. Furthermore, since HIP Host Identifiers are > public keys, standard public key certificate infrastructures > can be applied on the top of HIP. You're missing a reference to RFC6253. > 9. What would the resolution mechanisms be, or what characteristics > of a resolution mechanisms would be required? > > For most purposes, an approach where DNS names are resolved > simultaneously to HIs and IP addresses is sufficient. Typically, a locally installed DNS proxy has been deployed at the client-side host to support this for legacy applications. > However, if it becomes necessary to resolve HIs into IP > addresses or back to DNS names, a flat resolution > infrastructure is needed. Such an infrastructure could be > based on the ideas of Distributed Hash Tables, but would > require significant new development and deployment. Missing a DHT reference to RFC 6537. Actually, the ORCHID prefix for HIP could be delegated to an organization, and look ups distributed within the servers of the organization. DHT is not the only solution, we can stick to DNS: http://tools.ietf.org/html/draft-ponomarev-hip-hit2ip-00 From mkomu@cs.hut.fi Thu Oct 25 11:09:33 2012 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338421F8508 for ; Thu, 25 Oct 2012 11:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFFJ3ryDMTJf for ; Thu, 25 Oct 2012 11:09:32 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1505221F848B for ; Thu, 25 Oct 2012 11:09:31 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 4AB4D308D90 for ; Thu, 25 Oct 2012 21:09:30 +0300 (EEST) Message-ID: <50898059.503@cs.hut.fi> Date: Thu, 25 Oct 2012 21:09:29 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: hipsec@ietf.org References: <502A164E-8CCA-459B-A404-4E668150A684@helsinki.fi> <508076EE.1050700@cs.hut.fi> <508412FD.2010606@cs.hut.fi> In-Reply-To: <508412FD.2010606@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] Feedback for 4423bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:09:33 -0000 Hi, On 10/21/2012 06:21 PM, Miika Komu wrote: > Hi, > > On 10/19/2012 12:38 AM, Miika Komu wrote: >> Hi, >> >> On 10/10/2012 10:05 PM, Sasu Tarkoma wrote: >>> Hi all, >>> >>> I read the latest HIP architecture draft (4423bis-05) and it looks >>> very good. Below you will find some observations that I made >>> when reading the draft. >> >> looks good to me too but I have also some suggestions for improvement. >> Here's the first batch of comments, I'll send the remaining ones later. > > the second batch is here, I'll send the third and final later. the third and final batch is now here. Sorry for the delay. > 14. Security considerations > .. > There are more details on this process in the Host Identity Protocol. I think we're pretty much done with the details. > HIP optionally supports opportunistic negotiation. That is, if a > host receives a start of transport without a HIP negotiation, it can > attempt to force a HIP exchange before accepting the connection. > This has the potential for DoS attacks against both hosts. If the > method to force the start of HIP is expensive on either host, the > attacker need only spoof a TCP SYN. This would put both systems into > the expensive operations. HIP avoids this attack by having the > responder send a simple HIP packet that it can pre-build. Since this > packet is fixed and easily replayed, the initiator only reacts to it > if it has just started a connection to the responder. send a simple HIP packet -> send a simple R1 packe I think this text tries to describe a SHIM6-like upgrade feature that is poorly defined by any of the RFCs for HIP. The description is difficult to understand (for instance, "opportunistic" can be confused with opportunistic mode) and a bit too research oriented for this document. > If the responder's HI is > retrieved from a signed DNS zone or secured by some other means, the > initiator can use this to authenticate the signed HIP packets. secure -> securely obtained > The need to support multiple hashes for generating the HIT from the > HI affords the MitM a potentially powerful downgrade attack due to > the a-priori need of the HIT in the HIP base exchange. ...MitM to *mount* a... > 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. happens -> occurs > 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. ..the *potentially* additional.. .. are not a *security* problem at all.. > This might seem to make it > easier for an attacker, but ESP with replay protection is already as > well protected as possible, and the removal of the IP address as a > check should not increase the exposure of ESP to DoS attacks. make it easier for an attacker -> make attacking easier > Since not all hosts will ever support HIP, ICMPv4 'Destination > Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem, > Unrecognized Next Header' messages are to be expected and present a > DoS attack. Against an initiator, the attack would look like the > responder does not support HIP, but shortly after receiving the ICMP > message, the initiator would receive a valid HIP packet. Thus, to > protect against this attack, an initiator should not react to an ICMP > message until a reasonable time has passed, allowing it to get the > real responder's HIP packet. A similar attack against the responder > is more involved. I would clarify that the attack scenario is MitM here. ..get the real.. -> ..receive the real.. > A HIP packet is > not used because it would either have to have unique content, and > thus difficult to generate, resulting in yet another DoS attack, or > just as spoofable as the ICMP message. Suggest rewriting the beginning to avoid passive voice: In this scenario, the attacker would not use a HIP control packet because ... Why would it create yet another DoS attack? Are mixing the R1 counter to the discussion here (I suggest not doing this). > Like in the previous case, > the defense against this attack is for the initiator to wait a > reasonable time period to get a valid HIP packet. Like -> Similarly as get -> receive If one does not > come, then the initiator has to assume that the ICMP message is > valid. come -> arrive or appear Since this is the only point in the HIP base exchange where > this ICMP message is appropriate, it can be ignored at any other > point in the exchange. this -> an > 14.1. HITs used in ACLs > > It is expected that HITs will be used in ACLs. (they have already been used for such purposes) "At end-hosts, HITs can be used in IP-based access control lists at the application and network layers". > Future firewalls can use HITs to control egress and ingress to > networks, with an assurance level difficult to achieve today. "At middleboxes, HIP-aware firewalls [FW] can use HITs or public keys to control both ingress and egress access to networks or individual hosts, even in the presence of mobile devices because the HITs and public keys are topologically independent". [FW] Janne Lindqvist, Essi Vehmersalo, Miika Komu and Jukka Manner. Enterprise Network Packet Filtering for Mobile Cryptographic Identi- ties. International Journal of Handheld Computing Research (IJHCR), Volume 1, Issue 1, pp. 79-94, ISSN 1947-9158, January 2010. > The signatures in HIP packets allow a capable firewall > to ensure that the HIP exchange is indeed happening between two known > hosts. happening -> occurring > A potential of HITs in ACLs is their 'flatness' means they cannot be > aggregated and this could result in large table searches "A potential drawback of HITs in ACLs is their 'flatness' means they cannot be aggregated ,and this could potentially result in large table searches in HIP-aware firewalls. However, all hosts are treated as individuals in HIP, meaning that it is also easier to exclude individual hosts out simply by removing the corresponding HIT from the firewall ACL". > A host can keep track of all of its partners that might use its HIT > in an ACL by logging all remote HITs. It should only be necessary to > log responder hosts. With this information, the host can notify the > various hosts about the change to the HIT. There has been no attempt > to develop a secure method to issue the HIT revocation notice. untrue, you're missing an (informal) reference to here: http://tools.ietf.org/html/draft-irtf-hiprg-revocation-05 > HIP-aware NATs, however, are transparent to the HIP aware systems by > design. Thus, the host may find it difficult to notify any NAT that > is using a HIT in an ACL. Since most systems will know of the NATs > for their network, there should be a process by which they can notify > these NATs of the change of the HIT. This is mandatory for systems > that function as responders behind a NAT. In a similar vein, if a > host is notified of a change in a HIT of an initiator, it should > notify its NAT of the change. In this manner, NATs will get updated > with the HIT change. NAT is a middlebox that does address translation. It should not be concerned with access control, besides that they typically drop inbound data flows due to absence of mappings. I think you should be rather talking about passive, on-path HIP-aware firewalls such as described in [FW], or this text should be removed. > 14.2. Alternative HI considerations > The definition of the Host Identifier states that the HI need not be > a public key. It implies that the HI could be any value; for example > a FQDN. This document does not describe how to support such a non- > cryptographic HI. A non-cryptographic HI would still offer the > services of the HIT or LSI for NAT traversal. It would be possible > to carry HITs in HIP packets that had neither privacy nor > authentication. RFID version of HIP could maybe cited (as informational) as an example of such a compromise? http://tools.ietf.org/html/draft-irtf-hiprg-rfid-06 > Since such a mode would offer so little additional > functionality for so much addition to the IP kernel, it has not been > defined. Given how little public key cryptography HIP requires, HIP > should only be implemented using public key Host Identities. I suggest rephrasing the last sentence because the cryptography may be just too much some constrained devices. > 15. IANA considerations > Finally, > Lars Eggert, Spencer Dawkins and Dave Crocker provided valuable input > during the final stages of publication, most of which was > incorporated but some of which the authors decided to ignore in order > to get this document published in the first place. What were the issues? > 16. Acknowledgments Please add Aalto University, University of Helsinki and RWTH Aachen. > 17.2. Informative references Consider adding the following reference, for example, in the introduction of the draft if seem fit: P. Nikander, A. Gurtov, T. Henderson, Host Identity Protocol (HIP): Connectivity, Mobility, Multi-homing, Security, and Privacy over IPv4 and IPv6 networks, IEEE Communications Surveys and Tutorials, 12 (2), 2010. http://www.cs.helsinki.fi/u/gurtov/papers/hip_survey.pdf