Hi Jeffrey,
thank you for reviewing this document.
I am responding to your comments because I have worked on the parts of the
document that address Credit-Based Authorization and the related security
considerations, which you are referring to in your review.
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?
This should probably be rephrased to:
This UPDATE packet is acknowledged by the peer. For reliability in
the presence of packet loss, the UPDATE packet is retransmitted in case
no acknowledgment is received within the period of a retransmission
timeout.
Along this line, the following should probably be changed in section 5.2,
5th paragraph:
OLD:
The UPDATE also contains a SEQ parameter as usual
and is protected by retransmission.
NEW:
The UPDATE also contains a SEQ parameter as usual.
The packet is retransmitted until acknowledged by the peer.
=====
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".
I assume that you mean the attacker itself is located somewhere in the
Internet, the correspondent node being tricked into sending flooding
packets sits inside the DMZ, and the flooding packets are directed to a
victim in the internal network -- is this correct?
In this case, wouldn't the flooding packets be dropped by the firewall
between the DMZ and the internal network because a node in the DMZ is not
allowed to contact a node in the intranet?
firewall firewall
| |
intranet | DMZ | Internet
~~~~~~~~ | ~~~ | ~~~~~~~~
| |
victim |X<-- correspondent <----- attacker
| node |
On the other hand, if no firewall exists between the correspondent node
and the victim, then the attacker could trick the correspondent node into
flooding the victim with unrequested packets. Yet in this case,
unamplified flooding would also be possible for the attacker without HIP
because the attacker could send flooding packets with an IPv6 Routing
header, directing the packets to the correspondent node first, and from
there to the victim. To prevent this attack, the firewall would have to
look into the flooding packets' extension headers since the IPv6 header
would (legitimately) include the correspondent node's IP address.
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.
In this case, too, the attacker could use an IPv6 Routing header to guide
its flooding packets to victim A first, and from there to victim B,
effectively flooding the link between A and B.
In any case, the above statement from the draft, which you are referring
to, should be rephrased to the following:
2. An attacker can always cause unamplified flooding by sending
itself packets to its victim, either directly addressing the
victim in the packets, or guiding the packets along a specific
path by means of an IPv6 Routing header.
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.
I agree there should be some clarifying text. But let me wait for your
response until suggest some.
=====
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?
We chose to limit this protocol specification to locators of type 1 (ESP
SPI plus IPv6 or IPv4-in-IPv6 address) at this point, and to leave
locators of type 0 for further study. This is briefly mentioned at the
end of section 5.2, but I think you are right that this should also be
mentioned at a more prominent position. I suggest adding the following
text to the end of section 4.2:
This protocol specification limits the use of locators to those with
Locator Type 1. Future extensions to this protocol may specify the
use of locators with Locator Type 0. One example where locators with
Locator Type 0 would be useful is the inclusion of a LOCATOR parameter
in an R1 packet. This requires the use of type-0 locators since no ESP
SAs are set up at that point.
=====
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.
Yes, that's true. We could extend the above sentence to the following:
Link-local addresses MAY be announced to peers that are known to be
neighbors on the same link, for example, when the IP destination
address of a peer is link-local, too. The announcement of link-local
addresses in this case is a policy decision; link-local addresses used
as Preferred locators will create reachability problems when the host
moves to another link. In any case, link-local addresses MUST NOT
be announced to a peer unless that peer is known to be 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.
Thanks again, Jeffrey. Appreciate the review.
Regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf