Re: [Hipsec] processing review comments on RFC 5201-bis
Tom Taylor <tom.taylor.stds@gmail.com> Mon, 30 June 2014 17:46 UTC
Return-Path: <tom.taylor.stds@gmail.com>
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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietf.org>; Mon, 30 Jun 2014 10:46:51 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id y20so7111641ier.4 for <hipsec@ietf.org>; 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 <multiple recipients> (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 <tom.taylor.stds@gmail.com>
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 <tomh@tomh.org>, 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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=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. > >
- [Hipsec] processing review comments on RFC 5201-b… Tom Henderson
- Re: [Hipsec] processing review comments on RFC 52… Francis Dupont
- Re: [Hipsec] processing review comments on RFC 52… Tom Taylor
- Re: [Hipsec] processing review comments on RFC 52… Tom Henderson
- Re: [Hipsec] processing review comments on RFC 52… Tom Taylor
- Re: [Hipsec] processing review comments on RFC 52… Tom Henderson
- Re: [Hipsec] processing review comments on RFC 52… Tom Taylor
- Re: [Hipsec] processing review comments on RFC 52… Miika Komu
- Re: [Hipsec] processing review comments on RFC 52… Miika Komu
- Re: [Hipsec] processing review comments on RFC 52… Robert Moskowitz
- Re: [Hipsec] processing review comments on RFC 52… Robert Moskowitz
- Re: [Hipsec] processing review comments on RFC 52… Rene Hummen