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

From: Tom Henderson <[email-masked]>
Date: Sat, 28 Jun 2014 10:53:14 -0700

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: Francis Dupont <[email-masked]>
Date: Mon, 30 Jun 2014 13:55:10 +0200

>  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

[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Jun 2014 13:46:42 -0400

Comments below marked with [PTT].

Tom Taylor

> Minor issues (pointed out by Gen-ART reviewer Tom Taylor)
[PTT]
s/recommended/RECOMMENDED/ in the second-last line
Why "should" at the end of that line rather than MUST?
>                      DIFFIE_HELLMAN parameter. Each DH Group ID is one
[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.

>     The following Group IDs have been defined:
[PTT] Good.
> Changes to address this would likely complicate things or increase the

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

---

From: Tom Henderson <[email-masked]>
Date: Mon, 30 Jun 2014 13:11:23 -0700

> add "truncated " in the 4843bis example, and cleanup the table 11

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: Tom Taylor <[email-masked]>
Date: Mon, 30 Jun 2014 16:55:44 -0400

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

---

From: Tom Henderson <[email-masked]>
Date: Mon, 30 Jun 2014 16:09:37 -0700

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

> confusing.) I think s/defines/specifies/ was one of my suggested

I am fine with the change to 'specify'.

> adjustment of the rate of key rollover.

Unsure; leaving to others to comment.

Thanks,
Tom

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Jun 2014 21:36:38 -0400

Apologies to the hipsec list administrator. If we have more exchanges 
I'll subscribe to the list.

Tom Taylor

> also be changed from MAY to RECOMMENDED (i.e. are MAY and RECOMMENDED

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