To Cliff: Server to NAT, ALL ICMP, clear text
Note that this policy also lets Ari and Bob send cleartext ICMP to
the server.
The server sees all clients behind the NAT as the same IP address, so
setting up different policies for the same traffic descriptor is in
principle impossible.
A problematic example of configuration on the server is as follows:
Server to NAT, TCP, secure (for Ari and Bob)
Server to NAT, TCP, clear (for Cliff)
The server cannot enforce his policy, as it is possible that
misbehaving Bob sends traffic in the clear. This is
indistinguishable from when Cliff sends traffic in the clear. So it
is impossible to guarantee security from some clients behind a NAT,
while allowing clear text from different clients behind the SAME NAT.
If the server’s security policy allows this, however, it can do
best-effort security: If the client from behind the NAT initiates
security, his connection will be secured. If he sends in the clear,
the server will still accept that clear text.
For security guarantees, the above problematic scenario MUST NOT be
allowed on servers. For best effort security, this scenario MAY be
used.
Please see Appendix A.
6. IAB Considerations
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT
compatibility requirements document [RFC3715].
7. Acknowledgments
Thanks to Tero Kivinen and William Dixon, who contributed actively to
this document.
Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri
Paavolainen, who contributed to the early documents about NAT
traversal.
8. References
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
RFC 3947, January 2005.
8.2. Informative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Work in Progress, October 2004.
Appendix A. Clarification of Potential NAT Multiple Client Solutions
This appendix provides clarification about potential solutions to the
problem of multiple clients behind the same NAT simultaneously
connecting to the same destination IP address.
Sections 5.1 and 5.2 say that you MUST avoid this problem. As this
is not a matter of wire protocol, but a matter local implementation,
the mechanisms do not belong in the protocol specification itself.
They are instead listed in this appendix.
Choosing an option will likely depend on the scenarios for which one
uses/supports IPsec NAT-T. This list is not meant to be exhaustive,
so other solutions may exist. We first describe the generic choices
that solve the problem for all upper-layer protocols.
Generic choices for ESP transport mode:
Tr1) Implement a built-in NAT (network address translation) above
IPsec decapsulation.
Tr2) Implement a built-in NAPT (network address port translation)
above IPsec decapsulation.
Tr3) An initiator may decide not to request transport mode once NAT
is detected and may instead request a tunnel-mode SA. This may be a
retry after transport mode is denied by the responder, or the
initiator may choose to propose a tunnel SA initially. This is no
more difficult than knowing whether to propose transport mode or
tunnel mode without NAT. If for some reason the responder prefers or
requires tunnel mode for NAT traversal, it must reject the quick mode
SA proposal for transport mode.
Generic choices for ESP tunnel mode:
Tn1) Same as Tr1.
Tn2) Same as Tr2.
Tn3) This option is possible if an initiator can be assigned an
address through its tunnel SA, with the responder using DHCP. The
initiator may initially request an internal address via the
DHCP-IPsec method, regardless of whether it knows it is behind a NAT.
It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA
after the responder fails the quick mode SA transport mode proposal.
This happens either when a NAT-OA payload is sent or because it
discovers from NAT-D that the initiator is behind a NAT and its local
configuration/policy will only accept a NAT connection when being
assigned an address through DHCP-IPsec.
There are also implementation choices that offer limited
interoperability. Implementors should specify which applications or
protocols should work if these options are selected. Note that
neither Tr4 nor Tn4, as described below, are expected to work with
TCP traffic.
Limited interoperability choices for ESP transport mode:
Tr4) Implement upper-layer protocol awareness of the inbound and
outbound IPsec SA so that it doesn’t use the source IP and the source
port as the session identifier (e.g., an L2TP session ID mapped to
the IPsec SA pair that doesn’t use the UDP source port or the source
IP address for peer uniqueness).
Tr5) Implement application integration with IKE initiation so that it
can rebind to a different source port if the IKE quick mode SA
proposal is rejected by the responder; then it can repropose the new
QM selector.
Limited interoperability choices for ESP tunnel mode:
Tn4) Same as Tr4.
Authors’ Addresses
Ari Huttunen
F-Secure Corporation
Tammasaarenkatu 7
HELSINKI FIN-00181
FI
EMail: Ari.Huttunen@F-Secure.com
Brian Swander
Microsoft
One Microsoft Way
Redmond, WA 98052
US
EMail: briansw@microsoft.com
Victor Volpe
Cisco Systems
124 Grove Street
Suite 205
Franklin, MA 02038
US
EMail: vvolpe@cisco.com
Larry DiBurro
Nortel Networks
80 Central Street
Boxborough, MA 01719
US
EMail: ldiburro@nortelnetworks.com
Markus Stenberg
FI
EMail: markus.stenberg@iki.fi
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 IETF’s procedures with respect to rights in IETF 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 currently provided by the
Internet Society.