idnits 2.17.1 draft-dupont-transient-pseudonat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [5], [6], [7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7803 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 2409 (ref. '2') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-04 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-03 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT ENST Bretagne 3 Expires in June 2003 Jean-Jacques Bernard 4 AFNIC 5 December 2002 7 Transient pseudo-NAT attacks or 8 how NATs are even more evil than you believed 10 12 Status of this Memo 14 This document is an Internet Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Abstract 38 When a "NAT traversal" capability is added to a class of signaling 39 protocols which can control some traffic aggregation points, an 40 attack based on a temporary access to the path followed by messages 41 exists. 43 Mobile IP [1] with NAT traversal [5] or IKE [2] with NAT 44 traversal [6], including the IKEv2 [7] proposal, are potentially 45 affected by this kind of attacks. 47 This document claims this vulnerability is an intrinsic property 48 of the NAT traversal capability, so is another point where the 49 usage of NATs is very damaging. 51 ^L 53 1. Introduction 55 A Network Address Translator (NAT [8]) is a device which rewrites 56 the source address or/and destination address as well as usually 57 the transport protocol ports of a communication. Many kinds of NATs 58 [9] exist but in this document the term NAT will be used for any 59 device which modifies at least one of the IP header addresses (a 60 pseudo-NAT when this is done for an attack). 62 NAT traversal capability consists in a NAT resilient transport, 63 usually UDP, and in address "agility", i.e., addresses in the 64 header of packets are taken as they are, especially the source 65 address (packets with a fake destination address likely will not 66 reach their intended recipient). 68 A traffic aggregation point is a place where traffic from many 69 sources and/or many destinations is aggregated and sent to the same 70 destination and usually arriving from the same source (the traffic 71 aggregation point) through a tunnel. Home agents in Mobile IP and 72 security gateways in IPsec [3] are typical examples of such traffic 73 aggregation points (which are not necessary for the attack to work 74 but increase its impact). 76 2. The Transient Pseudo-NAT Attack 78 An attacker acting as a NAT (i.e., a pseudo-NAT) may: 79 - redirect packets to another node 80 - make the intended recipient not receive packets to it 81 (first form of Denial-of-Service (DoS) attack) 82 - flood a third party with the hijacked packets 83 (second form of DoS attack, perhaps the most serious) 84 To perform the attack, the attacker must be on the path of packets 85 during the attack. 87 When there is a traffic aggregation point, the effects of the 88 attack are amplified when the attack is done "at the outgoing side" 89 of the aggregation point. 91 When a signaling protocol manages the direction followed by the 92 traffic, the attacker has only to spoof the addresses in headers 93 of some messages of the protocol in order to hijack the traffic 94 during a long period (i.e., until an error is detected and the 95 correct path re-established). Since the attacker has to stay on 96 the path only for a short moment (to the extent of some packets, 97 one packet is enough in some cases), this attack is named the 98 "transient" pseudo-NAT attack. 100 ^L 102 3. Attack Examples 104 3.1 Mobile IP 106 For Mobile IP the traffic aggregation point for choice is the 107 home agent and the target signaling protocol is the binding update - 108 binding acknowledgment exchange. If the NAT traversal capability 109 is enabled, the care-of address of the mobile may not be protected, 110 and therefore may be easily spoofed. 112 If no binding acknowledgment is required the attack can be reduced 113 to the modification in transit of only one packet so we recommend 114 to always require acknowledgment when NAT traversal is enabled 115 (as a weak form of return-routability check). 117 3.2 IKE 119 The attack against IKE is worse because IKE is supposed to ensure 120 a very high level of security, unfortunately defeated by NAT 121 traversal which is the first short-term work item of the IETF 122 ipsec working group charter [4]... 124 The attack follows the same scheme: addresses in headers of IKE 125 exchange messages are spoofed and the traffic, for instance between 126 two security gateways, is hijacked. 128 Any improvement to the IKE protocol makes the attack easier (a 129 very unpleasant property of this attack). For instance if an 130 implementation supports an address change between two "phases" 131 (something desirable and supported via the SPI of the phase one) 132 then to spoof the two or three messages of a quick mode exchange is 133 enough, or in IKEv2 only one packet of a CREATE-CHILD-SA exchange. 135 Again there is no easy defense which keeps the NAT traversal 136 capability. For instance the protection of the header addresses 137 (very easy to provide in the IKE framework) is effective against 138 both the vulnerability and the NAT traversal capability... 140 4. Security Considerations 142 The Mobile IP NAT traversal new document has a long description 143 of this attack [10,5]. We believe the ipsec working group will 144 examine in details which features can help mobility or/and NAT 145 traversal and what are their consequences for security. 147 The architectural implications of the NAT document [11] do not 148 describe this attack but it can be considered as a result of 149 the violation of the end-to-end principle on the trust model. 151 ^L 153 5. Acknowledgments 155 Maryline Maknavicius-Laurent drew my attention on this attack at 156 the IP Cellular Network 2002 conference. Phil Roberts encouraged 157 me to point out this attack in the IETF mobileip WG mailing-list 158 ASAP. I'd like to thank a well known NAT hater who'd like to stay 159 anonymous for his help to write this document. 161 6. Normative References 163 [1] C. Perkins (ed.), "IP Mobility Support for IPv4", RFC 3344, 164 August 2002. 166 [2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 167 RFC 2409, November 1998. 169 [3] S. Kent, R. Atkinson, "Security Architecture for the Internet 170 Protocol", RFC 2401, November 1998. 172 [4] http://www.ietf.org/html.charters/ipsec-charter.html 174 7. Informative References 176 [5] H. Levkowetz, S. Vaarala, "Mobile IP NAT/NAPT Traversal using 177 UDP Tunnelling", draft-ietf-mobileip-nat-traversal-07.txt, 178 November 2002. 180 [6] A. Huttunen & all, "UDP Encapsulation of IPsec Packets", 181 draft-ietf-ipsec-udp-encaps-04.txt, November 2002. 183 [7] C. Kaufman (ed.), "Internet Key Exchange (IKEv2) Protocol", 184 draft-ietf-ipsec-ikev2-03.txt, October 2002. 186 [8] P. Srisuresh, K. Egevang, "Traditional IP Network Address 187 Translator (Traditional NAT)", RFC 3022,January 2001 . 189 [9] P. Srisuresh, M. Holdrege, "IP Network Address Translator 190 (NAT) Terminology and Considerations", RFC 2663, August 1999. 192 [10] S. Vaarala, public communication in the mobileip mailing-list, 193 , 194 May 2002. 196 [11] T. Hain, "Architectural Implications of NAT", RFC 2993, 197 November 2000. 199 ^L 201 8. Authors' Addresses 203 Francis Dupont 204 ENST Bretagne 205 Campus de Rennes 206 2, rue de la Chataigneraie 207 BP 78 208 35512 Cesson-Sevigne Cedex 209 FRANCE 210 Fax: +33 2 99 12 70 30 211 EMail: Francis.Dupont@enst-bretagne.fr 213 Jean-Jacques Bernard 214 AFNIC / NIC France 215 Immeuble International 216 2 rue Stephenson 217 78181 Saint-Quentin-en-Yvelines Cedex 218 FRANCE 219 Fax: +33 1 39 30 83 01 220 EMail: Jean-Jacques.Bernard@nic.fr 222 ^L