[Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-rfc4423-bis-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Eric's concerns about the need for
second-preimage-resistance from the hash, and in particular with the
birthday bound, it's unclear that using a 128-bit hash leaves a very
large margin for growth.

Some other section-by-section notes follow.

Section 1

   [...] HIP provides for limited forms of trust between systems,
   enhance mobility, multi-homing and dynamic IP renumbering, aid in
   protocol translation / transition, and reduce certain types of
   denial-of-service (DoS) attacks.

I think that something is weird here with singular vs. plural in the
list elements.


Section 4

I agree with the secdir reviewer's not about "SHOULD NOT [implement
non-cryptographic HIP]"


Section 5.1

   At the client side, a host may have multiple Host Identities, for
   instance, for privacy purposes.  Another reason can be that the
   person utilizing the host employs different identities for different
   administrative domains as an extra security measure.  If a HIP-aware
   middlebox, such as a HIP-based firewall, is on the path between the
   client and server, the user or the underlying system should carefully
   choose the correct identity to avoid the firewall to unnecessarily
   drop HIP-based connectivity [komu-diss].

In addition to the firewall case, choosing the correct identifier
can also impact the privacy considerations, as a given identifier
would be trackable by on-path entities.


Section 6.2

   When a node moves while communication is already on-going, address
   changes are rather straightforward.  The peer of the mobile node can
   just accept a HIP or an integrity protected ESP packet from any
   address and ignore the source address.  However, as discussed in
   Section 12.2 below, a mobile node must send a HIP UPDATE packet to
   inform the peer of the new address(es), and the peer must verify that
   the mobile node is reachable through these addresses.

Am I reading this right that from a technical perspective, the peer
can just accept stuff from wherever, but from a policy/protocol
perspective the UPDATE requirement is included?  The text could
probably be a bit more clear, potentially even without using RFC
2119 language.


Section 10

   There are a number of variables that influence the HIP exchange that
   each host must support.  All HIP implementations should support at
   least 2 HIs, one to publish in DNS or similar directory service and
   an unpublished one for anonymous usage.  Although unpublished HIs

I suggest a parenthetical that the unpublished one should expect to
be rotated frequently in order to disrupt linkability/trackability.

   will be rarely used as responder HIs, they are likely to be common
   for initiators.  Support for multiple HIs is recommended.  [...]

If multiple means "more than two", it's probably better to say that.
(If multiple means "more than one", this is just a weaker version of
"should support at least 2", above.)  And it's rather tempting to
make it a MUST, anyway.

   Many initiators would want to use a different HI for different
   responders.  The implementations should provide for a policy mapping
   of initiator HITs to responder HITs.  This policy should also include
   preferred transforms and local lifetimes.

"mapping of initiator to responder" is potentially confusing, in
that in practice the procedure will be "I want to talk to responder
A, so let me look up that I use HIT X to talk to responder A", which
is the opposite direction from this text.


Section 11.1

I'd consider replacing "is an attempt to" with "attempts to" -- for
example, IPv6 tries to do a lot of things in addition to killing
NAT!


Section 11.3.1

   [...]Second, a
   data plane component is needed.  Most HIP implementations utilize the
   so called BEET mode of ESP that has been available since Linux kernel
   2.6.27, but is included also as a userspace component in a few of the
   implementations.

Nit: "but ESP is included", I think.


Section 12.1

I don't understand the usage of "a-priori" in:
   The need to support multiple hashes for generating the HIT from the
   HI affords the MitM to mount a potentially powerful downgrade attack
   due to the a-priori need of the HIT in the HIP base exchange.


   In HIP, the Security Association for ESP is indexed by the SPI; the
   source address is always ignored, and the destination address may be
   ignored as well.  Therefore, HIP-enabled Encapsulated Security
   Payload (ESP) is IP address independent.  This might seem to make
   attacking easier, but ESP with replay protection is already as well
   protected as possible, and the removal of the IP address as a check
   should not increase the exposure of ESP to DoS attacks.

It seems like there's still some potential incrased exposure, as
validating the ESP crypto is presumably more expensive than
validating source/destination IP addresses.


Section 12.3

   [...] At middleboxes, HIP-aware
   firewalls [lindqvist-enterprise] can use HITs or public keys to
   control both ingress and egress access to networks or individual
   hosts, even in the presence of mobile devices because the HITs and
   public keys are topologically independent. [...]

Nit: I think that just "topology independent" is what's intended.