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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
