I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
Overall, I found this document to be fairly straightforward and easy to
understand, even without a deep background in HIP. It does introduce
new security considerations associated with the ability to cause traffic
destined for a host to be redirected to a new location. However, these
are discussed and, provided HIP itself behaves as advertised, they are
adequately addressed. I have a few comments and questions, but nothing
to indicate this document should not be published as Experimental.
Section 3.1.2: Mobility Overview
This UPDATE packet is acknowledged by the peer, and is
protected by retransmission.
What does "protected by retransmission" mean here?
=====
Section 3.3.2: Credit-Based Authorization
2. An attacker can always cause unamplified flooding by sending
packets to its victim directly.
This is frequently untrue. The network may be configured such that the
attacker does not have direct connectivity to a victim, such as when the
victim is inside a firewall and the attack is carried out via a host within
within a "DMZ". Or, an attacker may attempt to create congestion on the
link between two victims, where the attacher has better connectivity to
both victims than they do to each other.
IMHO this is not a show-stopper -- the hypothesis quoted above is true in a
large number of cases, and it does appear to me that the credit-based
authorization scheme described here will have a positive erffect in those
cases without otherwise being harmful. However, it is worth pointing out
that this is not a cure-all.
=====
Section 4.2: Locator Type and Locator
Are locator types critical? What happens when a host tries to add or move
to a locator which is not supported by its peer?
=====
Section 5.2: Sending LOCATORs
The announcement of link-local addresses is a policy decision; such
addresses used as Preferred locators will create reachability
problems when the host moves to another link.
In fact, even a host which is not mobile should be careful to avoid
advertising link-local addresses to peers not on the same link.
=====
6. Security Considerations
The HIP mobility mechanism provides a secure means of updating a
host's IP address via HIP UPDATE packets. Upon receipt, a HIP host
cryptographically verifies the sender of an UPDATE, so forging or
replaying a HIP UPDATE packet is very difficult (see [2]).
Therefore, security issues reside in other attack domains.
I believe this is an accurate assessment.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf