[Hipsec] processing review comments on RFC 5201-bis

[Tom Henderson <[e-mail]>]

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.