Re: [Hipsec] processing review comments on RFC 5201-bis

[Tom Taylor <[e-mail]>]

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.
>
>