over the right SA. Some implementations are known to have problems
in this area.
In particular, simply storing the (remote tunnel header IP address,
remote SPI) pair in the SPD cache is not sufficient, since the pair
does not always uniquely identify a single SAD entry. For instance,
two hosts behind the same NAT can accidentally happen to choose the
same SPI value. The situation can also occur when a host is assigned
an IP address previously used by some other host, and the SAs
associated with the old host have not yet been deleted by Dead Peer
Detection. This may lead to packets being sent over the wrong SA or,
if the key management daemon ensures the pair is unique, denying the
creation of otherwise valid SAs.
Storing the remote tunnel header IP address in the SPD cache may also
complicate the implementation of MOBIKE, since the address can change
during the lifetime of the SA. Thus, we recommend implementing the
links between the SPD cache and the SAD in a way that does not
require modification when the tunnel header IP address is updated by
MOBIKE.
A.2. Creating Outbound SAs
When an outbound packet requires IPsec processing but no suitable SA
exists, a new SA will be created. In this case, the host has to
determine (1) who is the right peer for this SA, (2) whether the host
already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
the IP address(es) of the peer for contacting it.
Neither [IPsecArch] nor MOBIKE specifies how exactly these three
steps are carried out. [IPsecArch], Section 4.4.3.4, says:
For example, assume that IKE A receives an outbound packet
destined for IP address X, a host served by a security gateway.
RFC 2401 [RFC2401] and this document do not specify how A
determines the address of the IKE peer serving X. However, any
peer contacted by A as the presumed representative for X must be
registered in the PAD in order to allow the IKE exchange to be
authenticated. Moreover, when the authenticated peer asserts that
it represents X in its traffic selector exchange, the PAD will be
consulted to determine if the peer in question is authorized to
represent X.
In step 1, there may be more than one possible peer (e.g., several
security gateways that are allowed to represent X). In step 3, the
host may need to consult a directory such as DNS to determine the
peer IP address(es).
When performing these steps, implementations may use information
contained in the SPD, the PAD, and possibly some other
implementation-specific databases. Regardless of how exactly the
steps are implemented, it is important to remember that IP addresses
can change, and that an IP address alone does not always uniquely
identify a single IKE peer (for the same reasons as why the
combination of the remote IP address and SPI does not uniquely
identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
and 2 it may be easier to identify the "right peer" using its
authenticated identity instead of its current IP address. However,
these implementation details are beyond the scope of this
specification.
Author’s Address
Pasi Eronen (editor)
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.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).