In so doing, HIP itself is subject to its own DoS and MitM attacks
that potentially could be more damaging to a host’s ability to
conduct business as usual.
Resource-exhausting DoS attacks take advantage of the cost of setting
up a state for a protocol on the responder compared to the
’cheapness’ on the initiator. HIP allows a responder to increase the
cost of the start of state on the initiator and makes an effort to
reduce the cost to the responder. This is done by having the
responder start the authenticated Diffie-Hellman exchange instead of
the initiator, making the HIP base exchange 4 packets long. There
are more details on this process in the Host Identity Protocol.
HIP optionally supports opportunistic negotiation. That is, if a
host receives a start of transport without a HIP negotiation, it can
attempt to force a HIP exchange before accepting the connection.
This has the potential for DoS attacks against both hosts. If the
method to force the start of HIP is expensive on either host, the
attacker need only spoof a TCP SYN. This would put both systems into
the expensive operations. HIP avoids this attack by having the
responder send a simple HIP packet that it can pre-build. Since this
packet is fixed and easily replayed, the initiator reacts to it only
if it has just started a connection to the responder.
MitM attacks are difficult to defend against, without third-party
authentication. A skillful MitM could easily handle all parts of the
HIP base exchange, but HIP indirectly provides the following
protection from an MitM attack. If the responder’s HI is retrieved
from a signed DNS zone or secured by some other means, the initiator
can use this to authenticate the signed HIP packets. Likewise, if
the initiator’s HI is in a secure DNS zone, the responder can
retrieve it and validate the signed HIP packets. However, since an
initiator may choose to use an unpublished HI, it knowingly risks an
MitM attack. The responder may choose not to accept a HIP exchange
with an initiator using an unknown HI.
In HIP, the Security Association for IPsec is indexed by the SPI; the
source address is always ignored, and the destination address may be
ignored as well. Therefore, HIP-enabled IPsec Encapsulated Security
Payload (ESP) is IP address independent. This might seem to make it
easier for an attacker, 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 IPsec ESP to DoS attacks.
Since not all hosts will ever support HIP, ICMPv4 ’Destination
Unreachable, Protocol Unreachable’ and ICMPv6 ’Parameter Problem,
Unrecognized Next Header’ messages are to be expected and present a
DoS attack. Against an initiator, the attack would look like the
responder does not support HIP, but shortly after receiving the ICMP
message, the initiator would receive a valid HIP packet. Thus, to
protect against this attack, an initiator should not react to an ICMP
message until a reasonable time has passed, allowing it to get the
real responder’s HIP packet. A similar attack against the responder
is more involved.
Another MitM attack is simulating a responder’s administrative
rejection of a HIP initiation. This is a simple ICMP ’Destination
Unreachable, Administratively Prohibited’ message. A HIP packet is
not used because it would have to either have unique content, and
thus difficult to generate, resulting in yet another DoS attack, or
be just as spoofable as the ICMP message. Like in the previous case,
the defense against this attack is for the initiator to wait a
reasonable time period to get a valid HIP packet. If one does not
come, then the initiator has to assume that the ICMP message is
valid. Since this is the only point in the HIP base exchange where
this ICMP message is appropriate, it can be ignored at any other
point in the exchange.
13.1. HITs Used in ACLs
It is expected that HITs will be used in Access Control Lists (ACLs).
Future firewalls can use HITs to control egress and ingress to
networks, with an assurance level difficult to achieve today. As
discussed above in Section 8, once a HIP session has been
established, the SPI value in an IPsec packet may be used as an
index, indicating the HITs. In practice, firewalls can inspect HIP
packets to learn of the bindings between HITs, SPI values, and IP
addresses. They can even explicitly control IPsec usage, dynamically
opening IPsec ESP only for specific SPI values and IP addresses. The
signatures in HIP packets allow a capable firewall to ensure that the
HIP exchange is indeed happening between two known hosts. This may
increase firewall security.
There has been considerable bad experience with distributed ACLs that
contain public-key-related material, for example, with Secure SHell
Protocol (SSH). If the owner of a key needs to revoke it for any
reason, the task of finding all locations where the key is held in an
ACL may be impossible. If the reason for the revocation is due to
private key theft, this could be a serious issue.
A host can keep track of all of its partners that might use its HIT
in an ACL by logging all remote HITs. It should only be necessary to
log responder hosts. With this information, the host can notify the
various hosts about the change to the HIT. There has been no attempt
to develop a secure method to issue the HIT revocation notice.
HIP-aware NATs, however, are transparent to the HIP-aware systems by
design. Thus, the host may find it difficult to notify any NAT that
is using a HIT in an ACL. Since most systems will know of the NATs
for their network, there should be a process by which they can notify
these NATs of the change of the HIT. This is mandatory for systems
that function as responders behind a NAT. In a similar vein, if a
host is notified of a change in a HIT of an initiator, it should
notify its NAT of the change. In this manner, NATs will get updated
with the HIT change.
13.2. Non-security considerations
The definition of the Host Identifier states that the HI need not be
a public key. It implies that the HI could be any value; for
example, an FQDN. This document does not describe how to support
such a non-cryptographic HI. A non-cryptographic HI would still
offer the services of the HIT or LSI for NAT traversal. It would be
possible to carry HITs in HIP packets that had neither privacy nor
authentication. Since such a mode would offer so little additional
functionality for so much addition to the IP kernel, it has not been
defined. Given how little public key cryptography HIP requires, HIP
should only be implemented using public key Host Identities.
If it is desirable to use HIP in a low-security situation where
public key computations are considered expensive, HIP can be used
with very short Diffie-Hellman and Host Identity keys. Such use
makes the participating hosts vulnerable to MitM and connection
hijacking attacks. However, it does not cause flooding dangers,
since the address check mechanism relies on the routing system and
not on cryptographic strength.
14. Acknowledgements
For the people historically involved in the early stages of HIP, see
the Acknowledgements section in the Host Identity Protocol
specification.
During the later stages of this document, when the editing baton was
transfered to Pekka Nikander, the comments from the early
implementors and others, including Jari Arkko, Tom Henderson, Petri
Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim
Shepard, Jukka Ylitalo, and Jorma Wall, were invaluable. Finally,
Lars Eggert, Spencer Dawkins, and Dave Crocker provided valuable
input during the final stages of publication, most of which was
incorporated but some of which the authors decided to ignore in order
to get this document published in the first place.
15. Informative References
[1] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005
[3] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[6] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
[7] Lear, E. and R. Droms, "What’s In A Name: Thoughts from the
NSRG", Work in Progress, September 2003.
[8] Nikander, P., et al, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[10] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", URL
http://users.exis.net/~jnc/tech/endpoints.txt, 1999.
[11] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", in Security Protocols, 9th
International Workshop, Cambridge, UK, April 25-27 2001, LNCS
2467, pp. 12-26, Springer, 2002.
[12] Bellovin, S., "EIDs, IPsec, and HostNAT", in Proceedings of the
41st IETF, Los Angeles, CA, March 1998.
Authors’ Addresses
Robert Moskowitz
ICSAlabs, a Division of Cybertrust Corporation
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
EMail: rgm@icsalabs.com
Pekka Nikander
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).