From nobody Mon Jun 9 07:41:22 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164911A01E4; Mon, 9 Jun 2014 07:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iimyBkauLWXe; Mon, 9 Jun 2014 07:41:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4531A01D9; Mon, 9 Jun 2014 07:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140609144120.27691.41247.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 07:41:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/86X1BZ0bPr8VvXNXN7LqR_s-QSw Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5204-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:41:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extension Authors : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5204-bis-04.txt Pages : 14 Date : 2014-06-09 Abstract: This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5204-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 08:03:19 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97C61A0081 for ; Sat, 7 Jun 2014 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EVbSVeoLOx1 for ; Sat, 7 Jun 2014 09:45:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 419DB1A007E for ; Sat, 7 Jun 2014 09:45:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.136.172]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s57GjEZu010064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jun 2014 09:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402159527; x=1402245927; bh=WJJ84/1iGuFzICqzUxojsPqjW2ltf10G7fSDl1WIal0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GuFS2viyY6ZOGcP0+AQzEQBNylDc17S1BVS87fhPDF1a1HegXz/tnLn7rHdgrWQbi ElsDYn+GRohe0uL++A2Nv2L7pRPJgJz6Ty9JiS1WpGPL6qkFMiCBCH4xpWjr7I6nPo KqVt09xiMNIf8zGWGfqKF9PkupXXnDiQ8MALV7Zs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402159527; x=1402245927; i=@elandsys.com; bh=WJJ84/1iGuFzICqzUxojsPqjW2ltf10G7fSDl1WIal0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Jyhq9zk+vCbNRrutzHuIiLVz39+kDQF37aicEhMvDDS5bLSgWcrHOUD0p1916XHLW jRYtTshmnB4MzOfBonmR5N65tp07nEb3x8qbi1vjLPfZfHjYUMedw7S+/3F4Y5cQPe XRrQ6lAADuXNv/Xu3+8ke3V7By//TiR86iLRuqTU= Message-Id: <6.2.5.6.2.20140607073853.0b975758@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jun 2014 08:22:47 -0700 To: hipsec@ietf.org From: S Moonesamy In-Reply-To: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/N948OGv5AgncV-Uk9WhgaWmhm3E X-Mailman-Approved-At: Tue, 10 Jun 2014 08:03:18 -0700 Cc: Julien Laganier , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2014 16:45:41 -0000 At 09:04 28-05-2014, The IESG wrote: >The IESG has received a request from the Host Identity Protocol WG (hip) >to consider the following document: >- 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers > Version 2 (ORCHIDv2)' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-06-11. Exceptionally, comments may be I took a quick look at the draft. In Section 1.1: "While being technically possible to use ORCHIDs between consenting hosts without any co-ordination with the IETF and the IANA, the authors would consider such practice potentially dangerous." The document is intended as an IETF RFC. I suggest framing the about from an IETF perspective instead of the authors' perspective. "A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other new purpose." My reading of the above is that the working group is trying to make a case for some free IPv6 addresses. According to the sixth paragraph in that section ORCHIDs are about allowing people to experiment. The question that arises is why is an intended Proposed Standard being used to describe an experiment. I don't understand the "danger" argument. Is the ORCHID request for an experiment or for a prefix to be set aside for people using the technology? In Section 3: "Router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, MUST be implemented via configuration and NOT by hardwired software code. At this time, it is RECOMMENDED that the default router configuration not handle ORCHIDs in any special way. In other words, there is no need to touch existing or new routers due to ORCHIDs. If such a reason should later appear, for example, due to a faulty implementation leaking ORCHIDs to the IP layer, the prefix can be and should be blocked by a simple configuration rule." There is, in my opinion, excessive usage of RFC 2119 key words in the above. I suggest using RFC 2119 key words for the main points. The IANA Considerations in Section 6 could do with a few changes. Please see RFC 6890 for the information requirements for having a reservation in the IPv6 Special-Purpose Address Registry. The termination date for the ORCHID assignment is March 2014. It may be easier to note the fact that the experiment has ended instead of saying that the prefix is to be returned to IANA in 2014. Regards, S. Moonesamy From nobody Thu Jun 19 07:24:34 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0051A03C3 for ; Thu, 19 Jun 2014 07:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Iz2wstHwb_s for ; Thu, 19 Jun 2014 07:24:31 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C841D1A03C0 for ; Thu, 19 Jun 2014 07:24:30 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ik5so2270061vcb.35 for ; Thu, 19 Jun 2014 07:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gs0j8J0XOQ+dZ5EGOJSzk/pFDHavs0VMMke3Cq7gtVc=; b=uhgnjV7eILw95PqJwVtDFgeDDaUCyAxmHIj9OHf3uk3vG96tEtuPnwQ8DK/LaKugCB o3uxdW7ucetBCGN0n5/Fv3eb9tpitaSpOfkWCcsh1qP/Aw2c8FdNs/74RdvkxfrFtWnP GqOy+vv6FI9Vp0FgDDNJ1rIZXqV7PkIG6QpP6Ineidl2N/b07b/KU/MtM3lbTyrzDhOu zs6cm07ziEUjCJvJELsriAqKdMNIqDwgEbK+hYZzSaSz7xaUQYpdRlSdowkHejaQjd5y jwDnf0nVxJEGtl+5c7PsVykroG5fbngz16EB6mSAsuV2DpBiZx5zrPx+NQFUnPJ4yP0I Tjcg== MIME-Version: 1.0 X-Received: by 10.221.27.8 with SMTP id ro8mr4264795vcb.30.1403187869956; Thu, 19 Jun 2014 07:24:29 -0700 (PDT) Received: by 10.52.117.9 with HTTP; Thu, 19 Jun 2014 07:24:29 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140607073853.0b975758@resistor.net> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> Date: Thu, 19 Jun 2014 07:24:29 -0700 Message-ID: From: Julien Laganier To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/_rmyptZrUxJVOrHQ_mYJJz5bM4E Cc: HIP , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2014 14:24:32 -0000 On Sat, Jun 7, 2014 at 8:22 AM, S Moonesamy wrote: > At 09:04 28-05-2014, The IESG wrote: >> >> The IESG has received a request from the Host Identity Protocol WG (hip) >> to consider the following document: >> - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers >> Version 2 (ORCHIDv2)' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2014-06-11. Exceptionally, comments may be > > > I took a quick look at the draft. > > In Section 1.1: > > "While being technically possible to use ORCHIDs between consenting > hosts without any co-ordination with the IETF and the IANA, the > authors would consider such practice potentially dangerous." > > The document is intended as an IETF RFC. I suggest framing the about from > an IETF perspective instead of the authors' perspective. s/the authors/the IETF/ ? > "A specific danger would be realised if the IETF community later > decided to use the ORCHID prefix for some different purpose. In > that case, hosts using the ORCHID prefix would be, for practical > purposes, unable to use the prefix for the other new purpose." > > My reading of the above is that the working group is trying to make a case > for some free IPv6 addresses. According to the sixth paragraph in that > section ORCHIDs are about allowing people to experiment. The question that > arises is why is an intended Proposed Standard being used to describe an > experiment. I don't understand the "danger" argument. Is the ORCHID > request for an experiment or for a prefix to be set aside for people using > the technology? HIP _was_ an experiment supported by ORCHIDs. The experiment has concluded and HIP is going to proposed standard, requiring a propose standard ORCHID, so the sixth paragraph can be adapted accordingly: OLD: ORCHIDs are designed to address this situation: to allow people to experiment with protocol stack extensions, such as secure overlay routing, HIP, or Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale experiments with minimum user effort. NEW: ORCHIDs are designed to address this situation: to allow people to implement protocol stack extensions, such as secure overlay routing, HIP, or Mobile IP privacy extensions, without requiring them to update their applications. The goal is to facilitate large-scale deployments with minimum user effort. > In Section 3: > > "Router software MUST NOT include any special handling code for > ORCHIDs. In other words, the non-routability property of ORCHIDs, if > implemented, MUST be implemented via configuration and NOT by > hardwired software code. At this time, it is RECOMMENDED that the > default router configuration not handle ORCHIDs in any special way. > In other words, there is no need to touch existing or new routers due > to ORCHIDs. If such a reason should later appear, for example, due > to a faulty implementation leaking ORCHIDs to the IP layer, the > prefix can be and should be blocked by a simple configuration rule." > > There is, in my opinion, excessive usage of RFC 2119 key words in the above. > I suggest using RFC 2119 key words for the main points. Specific suggestions would be welcome w.r.t. to what is excessive, and the proposed remedy. > The IANA Considerations in Section 6 could do with a few changes. Please > see RFC 6890 for the information requirements for having a reservation in > the IPv6 Special-Purpose Address Registry. IANA considerations will be clarified based on the forthcoming IANA review. > The termination date for the ORCHID assignment is March 2014. It may be > easier to note the fact that the experiment has ended instead of saying that > the prefix is to be returned to IANA in 2014. This provides useful information on the need for an allocation for the time being, and I believe can be edited as you suggest as an editorial change during AUTH48 once the draft has been approved by IESG. --julien From nobody Mon Jun 23 08:43:22 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A941B296A for ; Mon, 23 Jun 2014 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTLNU4cZON6O for ; Mon, 23 Jun 2014 08:43:20 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021B11B2B3D for ; Mon, 23 Jun 2014 08:43:16 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D9DE31B81C7 for ; Mon, 23 Jun 2014 08:43:15 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CEFDF190071; Mon, 23 Jun 2014 08:43:15 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 08:43:15 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 23 Jun 2014 11:43:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> To: Julien Laganier X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/q4zKO4KxHZnTWgLvPxDgWXgxRRw Cc: HIP , S Moonesamy , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:43:21 -0000 On Jun 19, 2014, at 10:24 AM, Julien Laganier = wrote: > This provides useful information on the need for an allocation for > the time being, and I believe can be edited as you suggest as an > editorial change during AUTH48 once the draft has been approved by > IESG. SM, are you satisfied with Julien's response? Julien, I'd prefer that you update the draft--it would be highly unusual = to address IETF last call comments during AUTH48. From nobody Mon Jun 23 09:30:27 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD11B2BFC for ; Mon, 23 Jun 2014 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pMEml__Tuqx for ; Mon, 23 Jun 2014 09:30:20 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392A01B2B1F for ; Mon, 23 Jun 2014 09:18:58 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so6467432veb.30 for ; Mon, 23 Jun 2014 09:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ac3Z0VicUbcHPdQCOaGwuvcrYNKPc6xIMj17ZHLemz0=; b=oK/HwCO2aCIIoQUp+Lq/GUd+O8vHAQbBtaB1WWawNsqh46fxiSOJkVuufS9cJDGmE9 E9lK9JvuYBqLcbnCC+lsVBLmoVUrTIm2BGTwTTBI/8ONSRe5Q/phPgHZ2R8laOq7OJch qqubzQcOlrq9RNdKA9/wiaygNkW0D5oFRoqkN4XxrRS9K01JM5xJV+WpH1UjMuGkkxa/ pnOspIJ2gwjlHu4AOTZ5DvZb6sZQZJZbIHle0Krt9DBtJRdn9m+j5D60phJ4uyr2u9GH SblqyZLWHTy4bx6GV0ICaFHrJxeCpIeUNSX3uZmBZ4Ayu1JjZ4WfktD0g0MCATwogYJQ vUGw== MIME-Version: 1.0 X-Received: by 10.58.197.193 with SMTP id iw1mr1481846vec.57.1403540337301; Mon, 23 Jun 2014 09:18:57 -0700 (PDT) Received: by 10.52.117.9 with HTTP; Mon, 23 Jun 2014 09:18:57 -0700 (PDT) In-Reply-To: <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> Date: Mon, 23 Jun 2014 09:18:57 -0700 Message-ID: From: Julien Laganier To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/Ghxdu7cTRFpi8cBR6SH2-LHYkJI Cc: HIP , S Moonesamy , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 16:30:25 -0000 Ted, the specific comment here is w.r.t. a statement in the IANA considerations that reads "The prefix that was temporarily allocated for the experimental ORCHID is to be returned to IANA in 2014 [RFC4843]." Do we really need an update of the draft for the sake of "s/is to be/was/"? --julien On Mon, Jun 23, 2014 at 8:43 AM, Ted Lemon wrote: > On Jun 19, 2014, at 10:24 AM, Julien Laganier wrote: >> This provides useful information on the need for an allocation for >> the time being, and I believe can be edited as you suggest as an >> editorial change during AUTH48 once the draft has been approved by >> IESG. > > SM, are you satisfied with Julien's response? > > Julien, I'd prefer that you update the draft--it would be highly unusual to address IETF last call comments during AUTH48. > From nobody Mon Jun 23 10:13:06 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8B01B2982 for ; Mon, 23 Jun 2014 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2x0NWXxxZur for ; Mon, 23 Jun 2014 10:13:01 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF35E1A037D for ; Mon, 23 Jun 2014 10:12:53 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 92BE61B81C7 for ; Mon, 23 Jun 2014 10:12:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8BC0F190071; Mon, 23 Jun 2014 10:12:53 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 10:12:48 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 23 Jun 2014 13:12:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0084C183-CC5A-45D4-8680-7BE65F2E0E3F@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> To: Julien Laganier X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1rozSkMSnQhydBVjVyGU04Tm0jY Cc: HIP , S Moonesamy , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:13:02 -0000 On Jun 23, 2014, at 12:18 PM, Julien Laganier = wrote: > Do we really need an update of the draft for the sake of "s/is to = be/was/"? Well, see Barry's DISCUSS... :) The other way to address comments like this is in an RFC Editor note, = but if you update the draft, then you don't have to worry about the = information accidentally being lost. From nobody Mon Jun 23 10:45:33 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889F71B2BCD for ; Mon, 23 Jun 2014 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GEo4i52y1Ly for ; Mon, 23 Jun 2014 10:45:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F51F1B2BD5 for ; Mon, 23 Jun 2014 10:45:14 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EDD8F1B81D5 for ; Mon, 23 Jun 2014 10:45:13 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 60BBA190071; Mon, 23 Jun 2014 10:45:07 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 10:45:02 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> Date: Mon, 23 Jun 2014 13:44:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7826FE0A-C388-466A-94B9-1228973AFE9B@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/majt323lcZxPrc_5kXziYO3ZGhg Cc: Julien Laganier , Francis Dupont , hipsec@ietf.org Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:45:28 -0000 On Jun 23, 2014, at 1:40 PM, S Moonesamy wrote: > I would not consider my comments about the RFC 2119 key words as = addressed (re. Section 6 of RFC 2119). I commented about that a few = minutes ago. Fair enough. Do you think the text as written will create = interoperability problems? From nobody Mon Jun 23 10:46:25 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84DD1B2BE0 for ; Mon, 23 Jun 2014 10:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYyL5TSZ7e3W for ; Mon, 23 Jun 2014 10:46:13 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AFF1B2BEC for ; Mon, 23 Jun 2014 10:45:33 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ij19so6285653vcb.36 for ; Mon, 23 Jun 2014 10:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I0LBXTIS7V8/4wCxZJJHd2Ks2vAwo3Xcm1xGQIrIEtw=; b=WqV9FwkSXsb/Ut874vhOFydjm3iyKUf5QzN9C7aZlgP4lGbWNgO5qwkV3IMLBaBjuQ cBHocuGVafyv5uxR8b0f57A+pZ0npXf1tHfl+pi7rs+YRAwENvHNEvCtwL2zq51bt+uC 81LbZmc7mZum6QVoiEqR6iFeTxzAEPUI3zTd+V1w+Mm8hlW0wN6VVrt/2Hn2hFHKhe1N A2hcGjTt9GAW+biKykBzwditmlV18wWhswvj/GLVMoOI8m8/6UuEWwC1KDx4rHzeLdRO ZhBSsnKxQJ1uZRqI5CPggrgGifIf7JmEw6C+Pf6Y+GjYP+Q+9/YnJIGMcb0DECHPDB/Y M8qQ== MIME-Version: 1.0 X-Received: by 10.221.5.1 with SMTP id oe1mr20834360vcb.10.1403545533136; Mon, 23 Jun 2014 10:45:33 -0700 (PDT) Received: by 10.52.117.9 with HTTP; Mon, 23 Jun 2014 10:45:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> Date: Mon, 23 Jun 2014 10:45:33 -0700 Message-ID: From: Julien Laganier To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1DtgCV7EgdDxDglodOvj75iiYW0 Cc: HIP , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:46:16 -0000 Hi S.M., Pls. see below. On Mon, Jun 23, 2014 at 10:32 AM, S Moonesamy wrote: > > > >> > In Section 3: >> > >> > "Router software MUST NOT include any special handling code for >> > ORCHIDs. In other words, the non-routability property of ORCHIDs, if >> > implemented, MUST be implemented via configuration and NOT by >> > hardwired software code. At this time, it is RECOMMENDED that the >> > default router configuration not handle ORCHIDs in any special way. >> > In other words, there is no need to touch existing or new routers due >> > to ORCHIDs. If such a reason should later appear, for example, due >> > to a faulty implementation leaking ORCHIDs to the IP layer, the >> > prefix can be and should be blocked by a simple configuration rule." >> > >> > There is, in my opinion, excessive usage of RFC 2119 key words in the >> > above. >> > I suggest using RFC 2119 key words for the main points. >> >> Specific suggestions would be welcome w.r.t. to what is excessive, and >> the proposed remedy. > > > The second RFC 2119 requirement restates the requirement in the first > sentence. There is then a RFC 2119 recommendation. I am short of time or > else I would have verified some RFCs to see how this was previously tackled. > I suggest having a requirement (if you want to have one) which states that > there must be a configuration knob and define a default setting. You could > keep the rest of the text as an explanation to the reader. How about this: "Router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, is to be implemented via configuration rather than by hardwired software code. At this time, it is RECOMMENDED that the default router configuration not handle ORCHIDs in any special way. In other words, there is no need to touch existing or new routers due to ORCHIDs. If such a reason should later appear, for example, due to a faulty implementation leaking ORCHIDs to the IP layer, the prefix can be and should be blocked by a simple configuration rule such as, e.g., an Access Control List entry." [...] >> This provides useful information on the need for an allocation for >> the time being, and I believe can be edited as you suggest as an >> editorial change during AUTH48 once the draft has been approved by >> IESG. > > That's an unusual usage of AUTH48. I'll defer to the Responsible Area > Director. Will update saying the prefix was returned in 2014. From nobody Mon Jun 23 12:54:07 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA31B2B1D for ; Mon, 23 Jun 2014 12:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFziO89x6UaF for ; Mon, 23 Jun 2014 12:54:04 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFDF1A038D for ; Mon, 23 Jun 2014 12:54:03 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so6501704veb.2 for ; Mon, 23 Jun 2014 12:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=++ZIJkGwT8P6JPBPHChJH2jIT7EEVOZxrrFWVgCrsIU=; b=xAfuYKwBEMR6semKL6pgbhOm/7MApsz7A9LIrcrp+FBcdCCs5zZfiv3EUeoRgZnDvR iCGhBkLheAzi+q8DxSufxNcpaz4rXxKl75pNiNUA5GO4Jo3oJ5w7auYHl8alQuXuRz3c NumviidpELH7FhjATCvsFkpdItSqke7Iq0ircdv6gMXiNJg84JWhHR6DDxfXKwPKF78h R9SlxEdS0lO4ldo7UJEU7pHhg2AwBFc1SNr3RU7kX/IKASDqzxZZcXFhN4E8EHsWIJ51 2AG9RnrlYchWBSBEZNTuQ5KuBk0iiZX4f36g7EiSQl7PVVQS2D+0MTDHoPjgRuF0uxL2 YLjA== MIME-Version: 1.0 X-Received: by 10.221.64.20 with SMTP id xg20mr21094674vcb.3.1403553243246; Mon, 23 Jun 2014 12:54:03 -0700 (PDT) Received: by 10.52.117.9 with HTTP; Mon, 23 Jun 2014 12:54:03 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140623111840.0bbb9c08@elandnews.com> References: <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> <7826FE0A-C388-466A-94B9-1228973AFE9B@nominum.com> <6.2.5.6.2.20140623111840.0bbb9c08@elandnews.com> Date: Mon, 23 Jun 2014 12:54:03 -0700 Message-ID: From: Julien Laganier To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/4lBF7ET7HiyEwXgSvmCchu0Yexw Cc: HIP , Francis Dupont Subject: Re: [Hipsec] Last Call: (An, etc. X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:54:05 -0000 On Mon, Jun 23, 2014 at 11:41 AM, S Moonesamy wrote: > > At 10:45 23-06-2014, Julien Laganier wrote: >> >> How about this: >> >> "Router software MUST NOT include any special handling code for >> ORCHIDs. In other words, the non-routability property of ORCHIDs, if >> implemented, is to be implemented via configuration rather than by >> hardwired software code. At this time, it is RECOMMENDED that the >> default router configuration not handle ORCHIDs in any special way. >> In other words, there is no need to touch existing or new routers due >> to ORCHIDs. If such a reason should later appear, for example, due >> to a faulty implementation leaking ORCHIDs to the IP layer, the >> prefix can be and should be blocked by a simple configuration rule such >> as, >> e.g., an Access Control List entry." > > > The first two sentences look fine. I suggest trying to look at the > "recommendation" part as something after the document is published. I am > not thinking clearly enough to suggest text. :-( I would avoid the "should" > in the last sentence. How about this then: "Router software MUST NOT include any special handling code for ORCHIDs. In other words, the non-routability property of ORCHIDs, if implemented, is to be implemented via configuration rather than by hardwired software code, e.g., the ORCHID prefix can be blocked by a simple configuration rule such as an Access Control List entry." Please let me know if this is Ok so that I can publish an update carrying agreed upon changes. --julien From nobody Mon Jun 23 13:13:37 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11CE1B2C52; Mon, 23 Jun 2014 13:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNvAyWgXdU5z; Mon, 23 Jun 2014 13:13:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2992F1B2C7A; Mon, 23 Jun 2014 13:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623201306.26338.5507.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 13:13:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/nqVhe3NLeaF4O8q2xt2YNuRx5V8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4843-bis-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:13:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) Authors : Julien Laganier Francis Dupont Filename : draft-ietf-hip-rfc4843-bis-06.txt Pages : 12 Date : 2014-06-23 Abstract: This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes RFC4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4843-bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 14:30:58 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350381B2CE3; Mon, 23 Jun 2014 14:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIVFrOAPW_q4; Mon, 23 Jun 2014 14:30:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CAC1B2C7A; Mon, 23 Jun 2014 14:30:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623213050.27922.72168.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 14:30:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/GjJw3VB-ZTD1raGIWtNhZ0jf7Y4 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-07.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:30:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melen Filename : draft-ietf-hip-native-nat-traversal-07.txt Pages : 14 Date : 2014-06-23 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 25 08:12:20 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407E41B2D17; Wed, 25 Jun 2014 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBNwW4dLpY_s; Wed, 25 Jun 2014 08:12:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0DF1B2D03; Wed, 25 Jun 2014 08:12:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625151203.28435.80142.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 08:12:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/fke037ZJ8tQodB3stho1UnwnQo0 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4843-bis-07.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2014 15:12:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) Authors : Julien Laganier Francis Dupont Filename : draft-ietf-hip-rfc4843-bis-07.txt Pages : 12 Date : 2014-06-25 Abstract: This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes RFC4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4843-bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 21:05:52 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2BA1B2F7F; Thu, 26 Jun 2014 21:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaKxo-nA0SIg; Thu, 26 Jun 2014 21:05:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2551B2F49; Thu, 26 Jun 2014 21:05:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627040546.6179.51465.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 21:05:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/O_5aLmqjOu0kcpEGZMaiKAsacUY Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4843-bis-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 04:05:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) Authors : Julien Laganier Francis Dupont Filename : draft-ietf-hip-rfc4843-bis-08.txt Pages : 13 Date : 2014-06-26 Abstract: This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes RFC4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4843-bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 28 10:53:30 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955441A038A for ; Sat, 28 Jun 2014 10:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvEZb6GFVUGi for ; Sat, 28 Jun 2014 10:53:24 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 9B4851A02C2 for ; Sat, 28 Jun 2014 10:53:23 -0700 (PDT) Received: (qmail 15941 invoked by uid 0); 28 Jun 2014 17:53:21 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 28 Jun 2014 17:53:21 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id KttH1o00W2molgS01ttLph; Sat, 28 Jun 2014 11:53:21 -0600 X-Authority-Analysis: v=2.1 cv=U6cBU4bu c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=X72Mzoh-KEgA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=iNbM8ds5DLivw92eKuMA:9 a=PImtIktPMneEpYRS:21 a=Z5NzHAYUuO43l-tc:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hJr++PQCKU3d3cKY3SoX7DkZTHZ5yj1rsJKX4hBzgjs=; b=Os+ccSjhEsy5G9+J1RuXV5/3DjkQilPCZ9EWR9rL95Fj7ka1IX00WcsCQIjIKeaWDV0TLYKK6SdNs8ZTtQZjAA6YBa4wanbQ7eryYe6oajQ2zd979Ps1OapnLzcH1dW4; Received: from [71.231.123.189] (port=58131 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X0woP-00058B-H3; Sat, 28 Jun 2014 11:53:17 -0600 Message-ID: <53AF010A.70606@tomh.org> Date: Sat, 28 Jun 2014 10:53:14 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/EdpPM73bsUZmiDYaKOxf8dWe4mA Cc: Tom Taylor Subject: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jun 2014 17:53:26 -0000 Hi all, we received a number of comments during the IESG evaluation of RFC 5201-bis. Below are the non-editorial comments. There were also several IANA questions that I plan to handle in a separate message. I'll plan to post an updated draft version 15 that addresses the editorial comments received, then once we give people a chance to review the below, publish another new version with additional revisions. Please review the below suggested resolutions (there is one issue for which I am not sure whether we should make any changes). Minor issues (pointed out by Gen-ART reviewer Tom Taylor) --------------------------------------------------------- 1) Section 4.3 (Error Processing) final case: if the receiving host does not send some sort of response (e.g., ICMP) to the sender, the sender may have no way of knowing that the HIP session has failed. The state transitions from ESTABLISHED in Table 6 time out on no packet "sent/received" for a given period of time. If the sending application doesn't expect a response, it could be sending packets that are ignored at the other end for an indefinitely long time. At the least, this point should be brought out in the text of that error case, and possibly the ICMP response should be RECOMMENDED. Discussion: Sending ICMP packets in response to this situation could also possibly be abused for DoS, so sending of ICMP should be rate-limited in this case. I'm proposing some text to try to balance these concerns; any comments or other suggestions? OLD TEXT: Optionally, the receiving host MAY send an ICMP packet, with the type Parameter Problem, to inform the sender that the HIP association does not exist (see Section 5.4), and it MAY initiate a new HIP BEX. However, responding with these optional mechanisms is implementation or policy dependent. SUGGESTED NEW TEXT: Optionally, the receiving host MAY send an ICMP packet, with the type Parameter Problem, to inform the sender that the HIP association does not exist (see Section 5.4), and it MAY initiate a new HIP BEX. However, responding with these optional mechanisms is implementation or policy dependent. If the sending application doesn't expect a response, the system could possibly send a large number of packets in this state, so for this reason, the sending of one or more ICMP packets is recommended. However, any such responses should be rate-limited to prevent abuse (see Section 5.4). 2) Section 5.2.7: when the host supports more than one D-H Group, is each group specified in a separate instance of the Diffie-Hellman parameter? The text does not say. Discussion: This seems to require some clarification. The DH_GROUP_LIST in I1 is used to select the single instance of DIFFIE_HELLMAN sent in the R1. I also found some awkward wording in the parameter definition of 5.2.6. OLD TEXT in section 5.2.6: DH GROUP ID defines a DH GROUP ID supported by the host. The list of IDs is ordered by preference of the host. The list of define DH Group IDs in the DIFFIE_HELLMAN parameter. Each DH Group ID is one octet long. NEW TEXT in section 5.2.6: DH GROUP ID defines a DH GROUP ID supported by the host. The list of IDs is ordered by preference of the host. The possible DH Group ID values are defined in the DIFFIE_HELLMAN parameter. Each DH Group ID is one octet long. OLD TEXT in section 5.2.7: The following Group IDs have been defined: NEW TEXT in section 5.2.7: A single DIFFIE_HELLMAN parameter may be included in selected HIP packets based on the DH Group ID selected (section 5.2.6). The following Group IDs have been defined: 3) Section 5.2.18: given the strict ordering of HIP parameters, the initial plaintext for the Encrypted content (type and length of initial parameter) may be fairly easily guessed. This opens up the minor possibility of a known plaintext attack. [Comment to be reviewed after further examination.] [Upon review: I1 packets have fixed type but variable length due to varying lengths of DH-GROUP-LISTS. The set of such lengths is limited, however, so it is worth considering whether known plain-text attacks offer any real threat.] Discussion: I don't know how/whether to handle this, or whether other similar vulnerabilities in other security protocols are addressed. Changes to address this would likely complicate things or increase the packet sizes. 4) Section 5.3, last paragraph: forbids fragmentation of the HIP packet. Doesn't this contradict Section 5.1.3? Discussion: I believe that this comment refers to fragmentation of a HIP packet into multiple IPv6 extension headers (i.e. fragmentation at the HIP layer, not the IP layer). As discussed in section 5.1, the Header Length field limits the size of the HIP parameters field to 2008 bytes. Suggested text to clarify in section 5.3; do people agree with the implied intent? OLD TEXT: The HIP packet, however, MUST NOT be fragmented. NEW TEXT: The HIP packet, however, MUST NOT be fragmented into multiple extension headers by setting the Next Header field in a HIP header to the HIP protocol number. Expired reference (pointed out by Gonzalo in July 2013): --------------------------------------------------------- http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-12 [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, M., and S. Tarkoma, "C-Bindings for IPsec Application Programming Interfaces", draft-ietf-btns-c-api-04 (work in progress), March 2009. This is cited in draft version -14 as follows: o As with all HIP base exchanges, the handling of locator-based or interface-based policy is unclear for HIP in opportunistic mode. An application may create a connection to a specific locator because the application has knowledge of the security properties along the network to that locator. If one of the nodes moves and the locators are updated, these security properties may not be maintained. Depending on the security policy of the application, this may be a problem. This is an area of ongoing study. As an example, there is work to create an API that applications can use to specify their security requirements in a similar context [I-D.ietf-btns-c-api]. I am not sure that this is really an issue with opportunistic mode, but instead with assumptions about mobility in security policy expressions. So, I propose to delete this bullet and the reference. Perhaps it instead belongs in the mobility and multihoming drafts. From nobody Sun Jun 29 23:51:22 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6491B2B9F for ; Mon, 23 Jun 2014 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_m6Va_pR7X3 for ; Mon, 23 Jun 2014 10:33:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5B1B2B96 for ; Mon, 23 Jun 2014 10:33:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5NHX44f021520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 10:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403544797; x=1403631197; bh=mLAk79eiGNIhMHLT1FTkI3MQ6mgDIoBhXWAx+eYIQ9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wiGtimUsEwjBgTmfDyT868r9Pic0h0rqf0m6iwHJ1mutV4ruaW89NJDbFoXNUS17f 7twL0kJ9BF16bn1AByaUm19XDl81cMo4M9ECraem6Xlr+9X3XA6MOC0KYPK0gEQKxm hAuyfd0fEK6PCCCeb0YbA1qqK+qpqJxgekC9o8ew= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403544797; x=1403631197; i=@elandsys.com; bh=mLAk79eiGNIhMHLT1FTkI3MQ6mgDIoBhXWAx+eYIQ9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wRns70ZDSZvX3ptT6eUxqohMGxDloC5SIJt5R+5yX9FkRtXSqg5KtCJYijqK9HvqQ 2I8JUn31cIckyh/moVkLUg/MAcjQViGC8XFDJMjbEAAegabek/0YHmResU23mQ765I bu451bIjSCOQCkitE4qm7ry+oUy4HusZCiYYFxzM= Message-Id: <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jun 2014 10:32:49 -0700 To: Julien Laganier From: S Moonesamy In-Reply-To: References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/rWRg6_CoFpDh0Sh24oVonDfepP0 X-Mailman-Approved-At: Sun, 29 Jun 2014 23:51:18 -0700 Cc: HIP , Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:33:27 -0000 Hi Julien, {Ted, sorry for the slow reply] At 07:24 19-06-2014, Julien Laganier wrote: >s/the authors/the IETF/ ? Yes. >HIP _was_ an experiment supported by ORCHIDs. The experiment has >concluded and HIP is going to proposed standard, requiring a propose >standard ORCHID, so the sixth paragraph can be adapted accordingly: > >OLD: > >ORCHIDs are > designed to address this situation: to allow people to experiment > with protocol stack extensions, such as secure overlay routing, HIP, > or Mobile IP privacy extensions, without requiring them to update > their applications. The goal is to facilitate large-scale > experiments with minimum user effort. > > >NEW: > >ORCHIDs are > designed to address this situation: to allow people to implement > protocol stack extensions, such as secure overlay routing, HIP, > or Mobile IP privacy extensions, without requiring them to update > their applications. The goal is to facilitate large-scale > deployments with minimum user effort. Ok. > > In Section 3: > > > > "Router software MUST NOT include any special handling code for > > ORCHIDs. In other words, the non-routability property of ORCHIDs, if > > implemented, MUST be implemented via configuration and NOT by > > hardwired software code. At this time, it is RECOMMENDED that the > > default router configuration not handle ORCHIDs in any special way. > > In other words, there is no need to touch existing or new routers due > > to ORCHIDs. If such a reason should later appear, for example, due > > to a faulty implementation leaking ORCHIDs to the IP layer, the > > prefix can be and should be blocked by a simple configuration rule." > > > > There is, in my opinion, excessive usage of RFC 2119 key words in > the above. > > I suggest using RFC 2119 key words for the main points. > >Specific suggestions would be welcome w.r.t. to what is excessive, and >the proposed remedy. The second RFC 2119 requirement restates the requirement in the first sentence. There is then a RFC 2119 recommendation. I am short of time or else I would have verified some RFCs to see how this was previously tackled. I suggest having a requirement (if you want to have one) which states that there must be a configuration knob and define a default setting. You could keep the rest of the text as an explanation to the reader. >IANA considerations will be clarified based on the forthcoming IANA review. Ok. >This provides useful information on the need for an allocation for >the time being, and I believe can be edited as you suggest as an >editorial change during AUTH48 once the draft has been approved by >IESG. That's an unusual usage of AUTH48. I'll defer to the Responsible Area Director. Regards, S. Moonesamy From nobody Sun Jun 29 23:51:23 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4D1B2B9F for ; Mon, 23 Jun 2014 10:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ6n7vxR2ogJ for ; Mon, 23 Jun 2014 10:41:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A4E1B2AE3 for ; Mon, 23 Jun 2014 10:41:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5NHfMx2011803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403545296; x=1403631696; bh=n1iKkSqGOhccyYvBuscueVXE2NnoOLso+dLMk3uNrM4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ml06QXsN/ko4vRmegPV/WTXwe31FsG53DLi+dw/Yyb3cSAOu9i+GAToFKM/u20kvy OffpudjBO5vc24aDboOJ8ucdTz5yM/gxOspkvEYWhaTVDwfC1xAxN+IAmR9I+pMsuC XBSSUZdXGjthx/AL/a7Wvr9MiyEUTMGDY2bRLzpE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403545296; x=1403631696; i=@elandsys.com; bh=n1iKkSqGOhccyYvBuscueVXE2NnoOLso+dLMk3uNrM4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zmFo+pMy/2GngXh7D5KgP+3yrr2M4S09TlU6ZM7PSVzyhs7C49bd2l4VP4q1XAmRi GVA0tHWz6koO5cE4+04NtjKfuC1XF3h8Q3mM9c1KEUyS5YoZlDLRgqc85DsovQeOKL pVut0ifRMvMy27yKAOzIfk9LHYLuOUZHNwebzPS0= Message-Id: <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jun 2014 10:40:27 -0700 To: Ted Lemon , Julien Laganier From: S Moonesamy In-Reply-To: <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/iW4X2EkuXKkKCCAdhZvZneZ6v9Q X-Mailman-Approved-At: Sun, 29 Jun 2014 23:51:18 -0700 Cc: hipsec@ietf.org, Francis Dupont Subject: Re: [Hipsec] Last Call: (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:41:42 -0000 Hi Ted, Thanks for following up on this. At 08:43 23-06-2014, Ted Lemon wrote: >SM, are you satisfied with Julien's response? I would not consider my comments about the RFC 2119 key words as addressed (re. Section 6 of RFC 2119). I commented about that a few minutes ago. Regards, S. Moonesamy From nobody Sun Jun 29 23:51:25 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755451B2C19 for ; Mon, 23 Jun 2014 11:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2svUm1UqWgqf for ; Mon, 23 Jun 2014 11:42:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A0C1B2BD2 for ; Mon, 23 Jun 2014 11:42:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5NIgNF9026702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 11:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403548956; x=1403635356; bh=iXK8dGMK5kWGCtFk3W+vsjGe9YzrMcMNU2xEybWH/Bc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2mBsZan/6UNU3cMn392P60TZZUiAS1hPiXj0O+OiEOYm7hXXFGnGMjk5dXGB2Wqtx azqCgnddTacYRit4uyuC0LkKiOa2LV1/uru6jT+JVC8rPkPYepos57OKxtnU8emNDm zEnQM79k9tGYEkEhK0Io9HUu32dy/BTbLUY3s3FI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403548956; x=1403635356; i=@elandsys.com; bh=iXK8dGMK5kWGCtFk3W+vsjGe9YzrMcMNU2xEybWH/Bc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jN/EuabXIe6vL44mNksVvkBqBGnUCjgpSHta/HRo7KhmuYHc3zTCyNJmfZuWxMgg7 NoPuskduy2P0oLuEZ0aSfamlx1SHPGH6tQgWGjZ1sqrD3bYo9hh3UFi/+DZ4HvrtpR GJ5tROC04kvQkSllxlS9eVVptmch2ltZtLaKOlhA= Message-Id: <6.2.5.6.2.20140623111840.0bbb9c08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jun 2014 11:41:40 -0700 To: Ted Lemon , Julien Laganier From: S Moonesamy In-Reply-To: <7826FE0A-C388-466A-94B9-1228973AFE9B@nominum.com> References: <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> <7826FE0A-C388-466A-94B9-1228973AFE9B@nominum.com> <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/9kGi9BvNyYvzNkRNG1Z8k2IdyhQ X-Mailman-Approved-At: Sun, 29 Jun 2014 23:51:18 -0700 Cc: hipsec@ietf.org, Francis Dupont Subject: Re: [Hipsec] Last Call: (An, etc. X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:42:52 -0000 Hi Ted, At 10:44 23-06-2014, Ted Lemon wrote: >Fair enough. Do you think the text as written will create >interoperability problems? I would say avoid that type of phrasing as it may lead to problems. At 10:45 23-06-2014, Julien Laganier wrote: >How about this: > >"Router software MUST NOT include any special handling code for >ORCHIDs. In other words, the non-routability property of ORCHIDs, if >implemented, is to be implemented via configuration rather than by >hardwired software code. At this time, it is RECOMMENDED that the >default router configuration not handle ORCHIDs in any special way. >In other words, there is no need to touch existing or new routers due >to ORCHIDs. If such a reason should later appear, for example, due >to a faulty implementation leaking ORCHIDs to the IP layer, the >prefix can be and should be blocked by a simple configuration rule such as, >e.g., an Access Control List entry." The first two sentences look fine. I suggest trying to look at the "recommendation" part as something after the document is published. I am not thinking clearly enough to suggest text. :-( I would avoid the "should" in the last sentence. Regards, S. Moonesamy From nobody Sun Jun 29 23:51:27 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EF91B2C72 for ; Mon, 23 Jun 2014 13:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS5mxUzC5AtK for ; Mon, 23 Jun 2014 13:06:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 459361B2C4B for ; Mon, 23 Jun 2014 13:06:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5NK6fQw012256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 13:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403554014; x=1403640414; bh=ffcCxBsxpaiywMkXoQg3nZsuTVPf+GPNifvUfRv9iM0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rs3fzQFU9rgtTfL2Qz7TqcwDzBadzstlt1UAwj/ZMlAuUxkSBLTJYSaCoqBOdWbDt SJlUBQa7DZjau7uHsdaLJ8zyGFmDoUXou3nFtYc4RKT36UQi8xsmuQoyjZf4v+/Mdm Sf+nxJ2nOmlZVAPer4eoC+J8oQiYR80Z6RYlxmK0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403554014; x=1403640414; i=@elandsys.com; bh=ffcCxBsxpaiywMkXoQg3nZsuTVPf+GPNifvUfRv9iM0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VCEOwX7vMXfR7Mny3iciztbp5F4eZQLWodWVfmlW1tMt8TY+ze1EsAdt9inRf12Nj kZ9XetRd8BnqbFqiOUo4ImbbEBn+ScmCovccWZqZIrWiNhgs/Kmzq6HtY3SJjKa2jx U8IFZ6y6hIM9sXDKipuRXhgV8gvUOMTZFp2NGYXI= Message-Id: <6.2.5.6.2.20140623130454.0bbbccb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jun 2014 13:06:16 -0700 To: Julien Laganier From: S Moonesamy In-Reply-To: References: <0B09A467-1447-4D61-804D-9DD581A89275@nominum.com> <6.2.5.6.2.20140623103438.0c2c1490@elandnews.com> <20140528160426.31345.98483.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140607073853.0b975758@resistor.net> <6.2.5.6.2.20140623102349.0c2c19b0@elandnews.com> <7826FE0A-C388-466A-94B9-1228973AFE9B@nominum.com> <6.2.5.6.2.20140623111840.0bbb9c08@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/AVWh4d2117glMO9vWoZ_ITIXfe4 X-Mailman-Approved-At: Sun, 29 Jun 2014 23:51:18 -0700 Cc: hipsec@ietf.org, Francis Dupont Subject: Re: [Hipsec] Last Call: (An, etc. X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:07:05 -0000 Hu Julien, At 12:54 23-06-2014, Julien Laganier wrote: >How about this then: > >"Router software MUST NOT include any special handling code for > ORCHIDs. In other words, the non-routability property of ORCHIDs, if > implemented, is to be implemented via configuration rather than by > hardwired software code, e.g., the ORCHID prefix can be blocked by > a simple configuration rule such as an Access Control List entry." The above looks fine. Regards, S. Moonesamy From nobody Mon Jun 30 04:55:16 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379681A023E for ; Mon, 30 Jun 2014 04:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzNetBp_1wPy for ; Mon, 30 Jun 2014 04:55:14 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33901A020A for ; Mon, 30 Jun 2014 04:55:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5UBtAEc021262; Mon, 30 Jun 2014 13:55:11 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406301155.s5UBtAEc021262@givry.fdupont.fr> From: Francis Dupont To: Tom Henderson In-reply-to: Your message of Sat, 28 Jun 2014 10:53:14 PDT. <53AF010A.70606@tomh.org> Date: Mon, 30 Jun 2014 13:55:10 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/QdlbqBWI8DItKOLyeAXKvkQy-wk Cc: hipsec@ietf.org, Tom Taylor Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:55:15 -0000 In your previous mail you wrote: > Hi all, we received a number of comments during the IESG evaluation of > RFC 5201-bis. Below are the non-editorial comments. There were also > several IANA questions that I plan to handle in a separate message. => as a co-author of RFC 4843bis I found a mismatch between 4843bis, section 3.2 and appendix E... (PS: my proposal is to follow 3.2, add "truncated " in the 4843bis example, and cleanup the table 11 of appendix E). Regards Francis.Dupont@fdupont.fr From nobody Mon Jun 30 11:54:19 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1611A03B5 for ; Mon, 30 Jun 2014 10:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqnPkDvA8diE for ; Mon, 30 Jun 2014 10:46:51 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5F31A03AB for ; Mon, 30 Jun 2014 10:46:51 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id y20so7111641ier.4 for ; Mon, 30 Jun 2014 10:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=STJSdJYige6z5EChlcxV+NNKHC3VqHBwrEBZFJ959TQ=; b=DqHJQ2LoS151mWBRiiy0vmVcKr3JVMSPCpwVl+Zmp7V5i9L9FYnbgSGrqil2nnnLM9 jpCr2cpJNSDsrFGjcC9TU4gTJID5oXC/6rSVTDQlg+fIKHwur3hN2RQQfX/gAA9RC3eA d5U8ztZYI5UYoOsK6MCrQezMCefmV9ZAmINbq4aGMkCbQUuPHa+DdSFW0c8nb9ubMolI mqvoNdVBPSFZx/RWY7VHjOqs5dypJEBcOmEM9ssPMd+nw3zwLgW5bY6VXTId+UVCZOIc dUCUH/XT2VKlvDkc3AFGK6Xa2QhlfOv5WJrpanhhx38BX+SpmxvAAiqTrKZVELXKifqj k9hw== X-Received: by 10.50.126.7 with SMTP id mu7mr34796954igb.20.1404150410842; Mon, 30 Jun 2014 10:46:50 -0700 (PDT) Received: from [192.168.0.100] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id d3sm26606804igc.17.2014.06.30.10.46.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 10:46:50 -0700 (PDT) Message-ID: <53B1A282.2060907@gmail.com> Date: Mon, 30 Jun 2014 13:46:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org References: <53AF010A.70606@tomh.org> In-Reply-To: <53AF010A.70606@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/pGaSBlVpSnYPtc5sZrTAIXl5JgM X-Mailman-Approved-At: Mon, 30 Jun 2014 11:54:11 -0700 Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:46:53 -0000 Comments below marked with [PTT]. Tom Taylor On 28/06/2014 1:53 PM, Tom Henderson wrote: > Hi all, we received a number of comments during the IESG evaluation of > RFC 5201-bis. Below are the non-editorial comments. There were also > several IANA questions that I plan to handle in a separate message. > > I'll plan to post an updated draft version 15 that addresses the > editorial comments received, then once we give people a chance to review > the below, publish another new version with additional revisions. > > Please review the below suggested resolutions (there is one issue for > which I am not sure whether we should make any changes). > > Minor issues (pointed out by Gen-ART reviewer Tom Taylor) > --------------------------------------------------------- > > 1) Section 4.3 (Error Processing) final case: if the receiving host does > not send some sort of response (e.g., ICMP) to the sender, the sender > may have no way of knowing that the HIP session has failed. The state > transitions from ESTABLISHED in Table 6 time out on no packet > "sent/received" for a given period of time. If the sending application > doesn't expect a response, it could be sending packets that are ignored > at the other end for an indefinitely long time. At the least, this point > should be brought out in the text of that error case, and possibly the > ICMP response should be RECOMMENDED. > > Discussion: Sending ICMP packets in response to this situation could > also possibly be abused for DoS, so sending of ICMP should be > rate-limited in this case. I'm proposing some text to try to balance > these concerns; any comments or other suggestions? > > OLD TEXT: > > Optionally, the receiving host MAY send an ICMP packet, with > the type Parameter Problem, to inform the sender that the HIP > association does not exist (see Section 5.4), and it MAY > initiate a new HIP BEX. However, responding with these > optional mechanisms is implementation or policy dependent. > > SUGGESTED NEW TEXT: > > Optionally, the receiving host MAY send an ICMP packet, with > the type Parameter Problem, to inform the sender that the HIP > association does not exist (see Section 5.4), and it MAY > initiate a new HIP BEX. However, responding with these > optional mechanisms is implementation or policy dependent. > If the sending application doesn't expect a response, the > system could possibly send a large number of packets in this > state, so for this reason, the sending of one or more ICMP > packets is recommended. However, any such responses should > be rate-limited to prevent abuse (see Section 5.4). [PTT] s/recommended/RECOMMENDED/ in the second-last line Why "should" at the end of that line rather than MUST? > > > 2) Section 5.2.7: when the host supports more than one D-H Group, is > each group specified in a separate instance of the Diffie-Hellman > parameter? The text does not say. > > Discussion: This seems to require some clarification. The > DH_GROUP_LIST in I1 is used to select the single instance of > DIFFIE_HELLMAN sent in the R1. I also found some awkward wording > in the parameter definition of 5.2.6. > > OLD TEXT in section 5.2.6: > > DH GROUP ID defines a DH GROUP ID supported by the host. > The list of IDs is ordered by preference of the > host. The list of define DH Group IDs in the > DIFFIE_HELLMAN parameter. Each DH Group ID is one > octet long. > > NEW TEXT in section 5.2.6: > > DH GROUP ID defines a DH GROUP ID supported by the host. > The list of IDs is ordered by preference of the > host. The possible DH Group ID values are defined > in the > DIFFIE_HELLMAN parameter. Each DH Group ID is one > octet long. > [PTT] The parameter contents do not constitute a definition. (But the description of the parameter in the document does -- hope this isn't too confusing.) I think s/defines/specifies/ was one of my suggested editorial changes. > OLD TEXT in section 5.2.7: > > The following Group IDs have been defined: > > NEW TEXT in section 5.2.7: > > A single DIFFIE_HELLMAN parameter may be included in selected > HIP packets based on the DH Group ID selected (section 5.2.6). > The following Group IDs have been defined: > [PTT] Good. > > 3) Section 5.2.18: given the strict ordering of HIP parameters, the initial > plaintext for the Encrypted content (type and length of initial > parameter) may be fairly easily guessed. This opens up the minor > possibility of a known plaintext attack. [Comment to be reviewed after > further examination.] [Upon review: I1 packets have fixed type but > variable length due to varying lengths of DH-GROUP-LISTS. The set of > such lengths is limited, however, so it is worth considering whether > known plain-text attacks offer any real threat.] > > Discussion: I don't know how/whether to handle this, or whether other > similar vulnerabilities in other security protocols are addressed. > Changes to address this would likely complicate things or increase the > packet sizes. [PTT] I have to leave it to people more knowledgeable in security to judge whether this is a realistic attack. One point of approach is to find out what sample size is needed for known plain-text attacks for specific algorithms, compare that with the rate at which an attacker could collect encrypted messages in specific scenarios, and decide whether there is a real threat. Mitigation presumably might be through adjustment of the rate of key rollover. > > 4) Section 5.3, last paragraph: forbids fragmentation of the HIP packet. > Doesn't this contradict Section 5.1.3? > > Discussion: I believe that this comment refers to fragmentation of a > HIP packet into multiple IPv6 extension headers (i.e. fragmentation > at the HIP layer, not the IP layer). As discussed in section 5.1, the > Header Length field limits the size of the HIP parameters field to 2008 > bytes. > > Suggested text to clarify in section 5.3; do people agree with the > implied intent? > > OLD TEXT: > > The HIP packet, however, MUST NOT be fragmented. > > NEW TEXT: > > The HIP packet, however, MUST NOT be fragmented into multiple > extension headers by setting the Next Header field in a HIP > header to the HIP protocol number. > > Expired reference (pointed out by Gonzalo in July 2013): > --------------------------------------------------------- > > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-12 > > [I-D.ietf-btns-c-api] Richardson, M., Williams, N., Komu, > M., > and S. Tarkoma, "C-Bindings for IPsec > Application Programming Interfaces", > draft-ietf-btns-c-api-04 (work in > progress), March 2009. > > This is cited in draft version -14 as follows: > > o As with all HIP base exchanges, the handling of locator-based or > interface-based policy is unclear for HIP in opportunistic mode. > An application may create a connection to a specific locator > because the application has knowledge of the security properties > along the network to that locator. If one of the nodes moves and > the locators are updated, these security properties may not be > maintained. Depending on the security policy of the application, > this may be a problem. This is an area of ongoing study. As an > example, there is work to create an API that applications can use > to specify their security requirements in a similar context > [I-D.ietf-btns-c-api]. > > I am not sure that this is really an issue with opportunistic mode, but > instead with assumptions about mobility in security policy expressions. > So, I propose to delete this bullet and the reference. Perhaps it > instead belongs in the mobility and multihoming drafts. > > From nobody Mon Jun 30 13:11:46 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125271A037D for ; Mon, 30 Jun 2014 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHyLhoxn6tgf for ; Mon, 30 Jun 2014 13:11:42 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 415CC1A02FB for ; Mon, 30 Jun 2014 13:11:41 -0700 (PDT) Received: (qmail 4665 invoked by uid 0); 30 Jun 2014 20:11:36 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 30 Jun 2014 20:11:36 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id LkBW1o0082molgS01kBZwj; Mon, 30 Jun 2014 14:11:36 -0600 X-Authority-Analysis: v=2.1 cv=U6cBU4bu c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=Z9rLFpqb_HIA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=Fae6CvlGR6wz3-q2ugwA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=aiobI/4wvAxPZuDgX+RcBPM1VAOopUZaHPlJoQYL1Aw=; b=rMogY+rqu6cOLSBUh5V+DM32mtSP7WeYpI9+xFfwLibulJPPBnP/7Qc88N4mZ42G8I4A5VRZp9wB4ZzzKgBJVvBQzgkeDFsNZBM7EvkTq9gM1Mi5gjIOVU6b0+QmW+dI; Received: from [71.231.123.189] (port=41117 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1hvD-0007oW-SR; Mon, 30 Jun 2014 14:11:27 -0600 Message-ID: <53B1C46B.10307@tomh.org> Date: Mon, 30 Jun 2014 13:11:23 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Francis Dupont References: <201406301155.s5UBtAEc021262@givry.fdupont.fr> In-Reply-To: <201406301155.s5UBtAEc021262@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/3zqhro3xLHv3FmkI-4-QaYq8l34 Cc: hipsec@ietf.org, Tom Taylor Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:11:43 -0000 On 06/30/2014 04:55 AM, Francis Dupont wrote: > In your previous mail you wrote: > >> Hi all, we received a number of comments during the IESG evaluation of >> RFC 5201-bis. Below are the non-editorial comments. There were also >> several IANA questions that I plan to handle in a separate message. > > => as a co-author of RFC 4843bis I found a mismatch between 4843bis, > section 3.2 and appendix E... (PS: my proposal is to follow 3.2, > add "truncated " in the 4843bis example, and cleanup the table 11 > of appendix E). > Francis, I had a look at appendix E but couldn't determine what you are suggesting be changed; could you propose some specific text? While we are on this topic, Tom Taylor had suggested as an editorial comment: "Appendix E, opening sentence: ORCHID prefix is now 23 bits, not 28 bits." but I believe that this is not correct (ORCHID prefix will eventually be 28 bits long out of the 2001::/23 space, if I am not mistaken). - Tom From nobody Mon Jun 30 13:55:50 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23801A0452 for ; Mon, 30 Jun 2014 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oESoyffJnpEg for ; Mon, 30 Jun 2014 13:55:47 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7DD1A0300 for ; Mon, 30 Jun 2014 13:55:46 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id at1so7416138iec.0 for ; Mon, 30 Jun 2014 13:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8/G79cO+RceYT+l7bIb5eLIxT5bOFsO9Uvpc7U3mMqg=; b=YOVqM3nuSyWabt2/2FgXnbDc4zc++9ZXWDxT8gOL//a01wqFZ8tb+UUTpyvM8KGTMG cl5aBLjGmiQiVFTynK3TSpogWtL/lTh505cP5IOqJnRGwoMjMA7zJL6NwPaw4VkdUfKy l0xLCmnScER4I100iOJzeI+AiIBCJPF/3jBXEiESbgCC5zEXjdY8L4GMP2EAdcUenm4u oAjJnBroRt7Tl4A3+77jJeL8V2JhY7KhpaAtso80EUhYX8FgJFaO32p2ZmIRDyPXG5Gn 5XrU4qAwODb1Z7+ct+A0cUXyEuO5ZgFzGGDMa4p1qAOiMFrIZ7cbRtQGnzymePcyQwYr duSA== X-Received: by 10.50.114.34 with SMTP id jd2mr35288554igb.35.1404161746328; Mon, 30 Jun 2014 13:55:46 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id q11sm22233758igr.7.2014.06.30.13.55.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 13:55:46 -0700 (PDT) Message-ID: <53B1CED0.40406@gmail.com> Date: Mon, 30 Jun 2014 16:55:44 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , Francis Dupont References: <201406301155.s5UBtAEc021262@givry.fdupont.fr> <53B1C46B.10307@tomh.org> In-Reply-To: <53B1C46B.10307@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/ZsZpPcAxO7qB-7DI4RJJYqsSsxA Cc: hipsec@ietf.org Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:55:48 -0000 Oops. I see I read 4843bis too quickly. the /23 is the source numbering space, out of which a single 28-bit prefix is to be allocated. Tom Taylor On 30/06/2014 4:11 PM, Tom Henderson wrote: ... > > While we are on this topic, Tom Taylor had suggested as an editorial > comment: > > "Appendix E, opening sentence: ORCHID prefix is now 23 bits, not 28 bits." > > but I believe that this is not correct (ORCHID prefix will eventually be > 28 bits long out of the 2001::/23 space, if I am not mistaken). > > - Tom > > From nobody Mon Jun 30 16:09:50 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895A51A8BB1 for ; Mon, 30 Jun 2014 16:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8NLWFPEXpOj for ; Mon, 30 Jun 2014 16:09:47 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 7A36A1A0B11 for ; Mon, 30 Jun 2014 16:09:47 -0700 (PDT) Received: (qmail 6612 invoked by uid 0); 30 Jun 2014 23:09:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 30 Jun 2014 23:09:44 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id Ln9h1o00C2molgS01n9klM; Mon, 30 Jun 2014 17:09:44 -0600 X-Authority-Analysis: v=2.1 cv=erRMkOZX c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=uTBrZwhWQCYA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=Y_K-EGdPfeshJdvKNj4A:9 a=B5CBAiHSXIwuDPPI:21 a=rpPJTHNCu9WWPyvy:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Pb+cdgaptKln8BwpMseyDbtQDozeTrasNit+lPtDzzM=; b=uk2AaOznzl1H5JpLm9lP6JfHdIaydKAv/bldqElfTIRLckEzGK8kc92y303CvlF+Ay2YvkAIC6XBH4GR3FwVHFBRGP8tuvqm51XHItlNttiGcvbf2ADT1spmIoiu3ltQ; Received: from [71.231.123.189] (port=42126 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1khg-00079b-S7; Mon, 30 Jun 2014 17:09:40 -0600 Message-ID: <53B1EE31.9060200@tomh.org> Date: Mon, 30 Jun 2014 16:09:37 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Taylor , hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> In-Reply-To: <53B1A282.2060907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/RsNoIxGhnW8X52sOEv6w41cmeDs Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 23:09:48 -0000 On 06/30/2014 10:46 AM, Tom Taylor wrote: > Comments below marked with [PTT]. > > Tom Taylor > > On 28/06/2014 1:53 PM, Tom Henderson wrote: >> Hi all, we received a number of comments during the IESG evaluation of >> RFC 5201-bis. Below are the non-editorial comments. There were also >> several IANA questions that I plan to handle in a separate message. >> >> I'll plan to post an updated draft version 15 that addresses the >> editorial comments received, then once we give people a chance to review >> the below, publish another new version with additional revisions. >> >> Please review the below suggested resolutions (there is one issue for >> which I am not sure whether we should make any changes). >> >> Minor issues (pointed out by Gen-ART reviewer Tom Taylor) >> --------------------------------------------------------- >> >> 1) Section 4.3 (Error Processing) final case: if the receiving host does >> not send some sort of response (e.g., ICMP) to the sender, the sender >> may have no way of knowing that the HIP session has failed. The state >> transitions from ESTABLISHED in Table 6 time out on no packet >> "sent/received" for a given period of time. If the sending application >> doesn't expect a response, it could be sending packets that are ignored >> at the other end for an indefinitely long time. At the least, this point >> should be brought out in the text of that error case, and possibly the >> ICMP response should be RECOMMENDED. >> >> Discussion: Sending ICMP packets in response to this situation could >> also possibly be abused for DoS, so sending of ICMP should be >> rate-limited in this case. I'm proposing some text to try to balance >> these concerns; any comments or other suggestions? >> >> OLD TEXT: >> >> Optionally, the receiving host MAY send an ICMP packet, with >> the type Parameter Problem, to inform the sender that the HIP >> association does not exist (see Section 5.4), and it MAY >> initiate a new HIP BEX. However, responding with these >> optional mechanisms is implementation or policy dependent. >> >> SUGGESTED NEW TEXT: >> >> Optionally, the receiving host MAY send an ICMP packet, with >> the type Parameter Problem, to inform the sender that the HIP >> association does not exist (see Section 5.4), and it MAY >> initiate a new HIP BEX. However, responding with these >> optional mechanisms is implementation or policy dependent. >> If the sending application doesn't expect a response, the >> system could possibly send a large number of packets in this >> state, so for this reason, the sending of one or more ICMP >> packets is recommended. However, any such responses should >> be rate-limited to prevent abuse (see Section 5.4). > [PTT] > s/recommended/RECOMMENDED/ in the second-last line > Why "should" at the end of that line rather than MUST? OK, if I change to capitalized RECOMMENDED, should the first sentence also be changed from MAY to RECOMMENDED (i.e. are MAY and RECOMMENDED incompatible terms)? I would be fine with changing the last line to a MUST. >> >> >> 2) Section 5.2.7: when the host supports more than one D-H Group, is >> each group specified in a separate instance of the Diffie-Hellman >> parameter? The text does not say. >> >> Discussion: This seems to require some clarification. The >> DH_GROUP_LIST in I1 is used to select the single instance of >> DIFFIE_HELLMAN sent in the R1. I also found some awkward wording >> in the parameter definition of 5.2.6. >> >> OLD TEXT in section 5.2.6: >> >> DH GROUP ID defines a DH GROUP ID supported by the host. >> The list of IDs is ordered by preference of the >> host. The list of define DH Group IDs in the >> DIFFIE_HELLMAN parameter. Each DH Group ID is one >> octet long. >> >> NEW TEXT in section 5.2.6: >> >> DH GROUP ID defines a DH GROUP ID supported by the host. >> The list of IDs is ordered by preference of the >> host. The possible DH Group ID values are defined >> in the >> DIFFIE_HELLMAN parameter. Each DH Group ID is one >> octet long. >> > [PTT] The parameter contents do not constitute a definition. (But the > description of the parameter in the document does -- hope this isn't too > confusing.) I think s/defines/specifies/ was one of my suggested > editorial changes. I am fine with the change to 'specify'. > >> OLD TEXT in section 5.2.7: >> >> The following Group IDs have been defined: >> >> NEW TEXT in section 5.2.7: >> >> A single DIFFIE_HELLMAN parameter may be included in selected >> HIP packets based on the DH Group ID selected (section 5.2.6). >> The following Group IDs have been defined: >> > [PTT] Good. >> >> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >> initial >> plaintext for the Encrypted content (type and length of initial >> parameter) may be fairly easily guessed. This opens up the minor >> possibility of a known plaintext attack. [Comment to be reviewed after >> further examination.] [Upon review: I1 packets have fixed type but >> variable length due to varying lengths of DH-GROUP-LISTS. The set of >> such lengths is limited, however, so it is worth considering whether >> known plain-text attacks offer any real threat.] >> >> Discussion: I don't know how/whether to handle this, or whether other >> similar vulnerabilities in other security protocols are addressed. >> Changes to address this would likely complicate things or increase the >> packet sizes. > > [PTT] I have to leave it to people more knowledgeable in security to > judge whether this is a realistic attack. One point of approach is to > find out what sample size is needed for known plain-text attacks for > specific algorithms, compare that with the rate at which an attacker > could collect encrypted messages in specific scenarios, and decide > whether there is a real threat. Mitigation presumably might be through > adjustment of the rate of key rollover. Unsure; leaving to others to comment. Thanks, Tom From nobody Mon Jun 30 18:36:52 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664751A007B for ; Mon, 30 Jun 2014 18:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyX5ju85Zts6 for ; Mon, 30 Jun 2014 18:36:49 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EF71A0078 for ; Mon, 30 Jun 2014 18:36:48 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so7658378ieb.34 for ; Mon, 30 Jun 2014 18:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=W0/nBNy3LYxbqScOoGNePsChWhmFJzAkPRbcnrQeUkc=; b=Bcff3ZaPCdxkcpRSSP4lxJ5vcT/P3B0faaIL0UB4XhUDqmt84YDOse45jV9u9hQ0y6 B0mJgIp6hzzkR5Dtbk2aAv+HJSQmOZQqpA2dAz4jW+4vCWSO/vHbFpbXsiUkPLuCsiBK O8Kz+fKTGZ1vCbQeP7yOVmmi+i+qcOI+HWL9EPVksPcgJONiGtFL9ztX4afBpU9tUKJO ZWQk5z1KEMY9rbAXB4CRRIo3ErZu+ML5+2n1FAk0GPmgyr3nWM6XQFcO/CHsMWlbgG2z Yltr6hcoqFTtk3k1FLLQtLsQgAZkV6r3oE0N5skHDhrvoFfHix+9SFbKWqp35fv+Uz8S mvzw== X-Received: by 10.50.114.226 with SMTP id jj2mr37239471igb.27.1404178607347; Mon, 30 Jun 2014 18:36:47 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id rq5sm29752375igb.0.2014.06.30.18.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 18:36:47 -0700 (PDT) Message-ID: <53B210A6.6040601@gmail.com> Date: Mon, 30 Jun 2014 21:36:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B1EE31.9060200@tomh.org> In-Reply-To: <53B1EE31.9060200@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/tEOHFoXZbag7oTkh7FKyPjK2-G0 Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 01:36:50 -0000 Apologies to the hipsec list administrator. If we have more exchanges I'll subscribe to the list. Tom Taylor On 30/06/2014 7:09 PM, Tom Henderson wrote: > On 06/30/2014 10:46 AM, Tom Taylor wrote: >> Comments below marked with [PTT]. >> >> Tom Taylor >> >> On 28/06/2014 1:53 PM, Tom Henderson wrote: >>> Hi all, we received a number of comments during the IESG evaluation of >>> RFC 5201-bis. Below are the non-editorial comments. There were also >>> several IANA questions that I plan to handle in a separate message. >>> >>> I'll plan to post an updated draft version 15 that addresses the >>> editorial comments received, then once we give people a chance to review >>> the below, publish another new version with additional revisions. >>> >>> Please review the below suggested resolutions (there is one issue for >>> which I am not sure whether we should make any changes). >>> >>> Minor issues (pointed out by Gen-ART reviewer Tom Taylor) >>> --------------------------------------------------------- >>> >>> 1) Section 4.3 (Error Processing) final case: if the receiving host does >>> not send some sort of response (e.g., ICMP) to the sender, the sender >>> may have no way of knowing that the HIP session has failed. The state >>> transitions from ESTABLISHED in Table 6 time out on no packet >>> "sent/received" for a given period of time. If the sending application >>> doesn't expect a response, it could be sending packets that are ignored >>> at the other end for an indefinitely long time. At the least, this point >>> should be brought out in the text of that error case, and possibly the >>> ICMP response should be RECOMMENDED. >>> >>> Discussion: Sending ICMP packets in response to this situation could >>> also possibly be abused for DoS, so sending of ICMP should be >>> rate-limited in this case. I'm proposing some text to try to balance >>> these concerns; any comments or other suggestions? >>> >>> OLD TEXT: >>> >>> Optionally, the receiving host MAY send an ICMP packet, with >>> the type Parameter Problem, to inform the sender that the HIP >>> association does not exist (see Section 5.4), and it MAY >>> initiate a new HIP BEX. However, responding with these >>> optional mechanisms is implementation or policy dependent. >>> >>> SUGGESTED NEW TEXT: >>> >>> Optionally, the receiving host MAY send an ICMP packet, with >>> the type Parameter Problem, to inform the sender that the HIP >>> association does not exist (see Section 5.4), and it MAY >>> initiate a new HIP BEX. However, responding with these >>> optional mechanisms is implementation or policy dependent. >>> If the sending application doesn't expect a response, the >>> system could possibly send a large number of packets in this >>> state, so for this reason, the sending of one or more ICMP >>> packets is recommended. However, any such responses should >>> be rate-limited to prevent abuse (see Section 5.4). >> [PTT] >> s/recommended/RECOMMENDED/ in the second-last line >> Why "should" at the end of that line rather than MUST? > > OK, if I change to capitalized RECOMMENDED, should the first sentence > also be changed from MAY to RECOMMENDED (i.e. are MAY and RECOMMENDED > incompatible terms)? [PTT2] Yes, good catch. I sent the E-mail off in a hurry because someone wanted my attention, and failed to review the whole paragraph. So the paragraph could start: "The receiving host SHOULD send an ICMP packet ...". SHOULD and RECOMMENDED are equivalent, and definitely not compatible with MAY. > > I would be fine with changing the last line to a MUST. > [PTT2] Good. > ...