[Hipsec] processing review comments on RFC 5201-bis
Tom Henderson <tomh@tomh.org> Sat, 28 June 2014 17:53 UTC
Return-Path: <tomh@tomh.org>
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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietf.org>; 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 <tomh@tomh.org>) 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 <tomh@tomh.org>
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 <tom.taylor.stds@gmail.com>
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." <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: 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.
- [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