alternatives. It finds that IIPtran, a composite of a subset of
IPsec (i.e., transport mode) together with existing standard IPIP
encapsulation, results in an interoperable, standards-conforming
equivalent that is both simpler and modular.
7. Acknowledgments
The authors would like to thank the members of the X-Bone and
DynaBone projects at USC/ISI for their contributions to the ideas
behind this document, notably (current) Greg Finn and (past) Amy
Hughes, Steve Hotz and Anindo Banerjea.
The authors would also like to thank Jun-ichiro (itojun) Hagino and
the KAME project for bringing IKE implications of this proposal to
our attention, as well as implementing the mechanisms in this
document in the KAME IPv6/IPsec network stack. Members of several
IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul
Knight, various members of MobileIP) provided valuable input on the
details of IPsec processing in earlier revisions of this document.
Effort sponsored by the Defense Advanced Research Projects Agency
(DARPA) and Air Force Research Laboratory, Air Force Materiel
Command, USAF, under agreements number F30602-98-1-0200 entitled "X-
Bone" and number F30602-01-2-0529 entitled "DynaBone".
8. References
8.1. Normative References
[1] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[3] Touch, J., "Dynamic Internet overlay deployment and management
using the X-Bone", Computer Networks Vol. 36, No. 2-3, July
2001.
[4] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual
Internet Architecture", ISI Technical Report ISI-TR-570,
Workshop on Future Directions in Network Architecture (FDNA)
2003, March 2003.
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
2107, February 1997.
8.2. Informative References
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in
Progress, January 2004.
[11] Kent, S., "IP Authentication Header", Work in Progress,
February 2004.
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in
progress, February 2004.
[13] Kent, S., "Personal Communication", November 2002.
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
Appendix A. Encapsulation/Decapsulation Issues
There are inconsistencies between the IPIP encapsulation rules
specified by IPsec [1] and those specified by MobileIP [2]. The
latter specification is standards track, and the IP protocol number
of 4 (payload of an IP packet of type 4) is uniquely specified by RFC
2003 according to IANA [2]. The use of IPIP inside an IPsec
transport packet can be confused with IPsec tunnel mode, because
IPsec does not specify any limits on the types of IP packets that
transport mode can secure.
A.1. Encapsulation Issues
When an IP packet is encapsulated as payload inside another IP
packet, some of the outer header fields can be newly written (and the
inner header determines some others [2].) Among these fields is the
IP DF (do not fragment) flag. When the inner packet DF flag is
clear, the outer packet may copy it or set it; however, when the
inner DF flag is set, the outer header must copy it [2]. IPsec
defines conflicting rules, where that flag and other similar fields
(TOS, etc.) may be copied, cleared, or set as specified by an SA.
The IPsec specification indicates that such fields must be
controlled, to achieve security. Otherwise, such fields could
provide a covert channel between the inner packet header and outer
packet header. However, RFC 2003 [2] requires that the outer fields
not be cleared when the inner ones are set, to prevent MTU discovery
"black holes" [14][15].
To avoid a conflict between these rules, and to avoid security
weaknesses associated with solely copying the fields, it is
recommended that IPsec IPIP encapsulation not permit the clearing of
the outer DF flag. When the SA requires clearing the DF flag, and
the inner packet DF is set, it is proposed that IPsec drop that
packet, rather than violate RFC 2003 processing rules [2]. Similar
rules are being developed for TOS and other similar IP header fields,
to be included in an update of RFC 2003 [2].
Another approach to closing the covert channel is always to set the
DF flag in the outer header (whether or not it is set in the inner
header). Setting the DF flag allows PMTU discovery to operate
normally. The details of this approach are discussed in [2].
A.2. Decapsulation Issues
Given identical keys, a packet created by IPIP tunnel encapsulation
combined with IPsec transport mode and an IPsec tunnel mode packet
look identical on the wire. Thus, when an IPsec’ed packet arrives
that contains an IPIP inner packet, it is not possible to distinguish
whether the packet was created using IPsec tunnel mode or IPsec
transport mode of an IPIP encapsulated packet. In both cases, the
protocol field of the outer header is IPsec (AH or ESP), and the
"next header" field for the inner data is 4 (IP). IPsec requires the
SA matching a received packet to indicate whether to apply tunnel
mode or transport mode.
Incoming packet processing must check the SAD before determining
whether to decapsulate IPsec packets with inner payload of protocol
type 4. If the SAD indicates that a tunnel mode association applies,
IPsec must decapsulate the packet. If the SAD indicates that a
transport mode association applies, IPsec must not decapsulate the
packet. This requires that the SAD indicate one of these two
options; wildcard SAD entries ("ANY", or "TUNNEL or TRANSPORT")
cannot be supported.
A.3. Appendix Summary
IPsec’s use of IPIP encapsulation conflicts with the IPIP standard
[2]. This issue is already being resolved in an update to RFC 2003,
instead of specifying a non-standard conforming variant of IPIP
encapsulation inside IPsec.
Authors’ Addresses
Joe Touch
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Lars Eggert
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Yu-Shun Wang
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: yushunwa@isi.edu
URI: http://www.isi.edu/yushunwa
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 currently provided by the
Internet Society.