idnits 2.17.1 draft-dupont-transient-pseudonat-03.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-03-28) 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 90 lines == 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.) ** There are 6 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. '3') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-07 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Return-Path: owner-internet-drafts 2 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) 3 by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19693 4 for ; Tue, 10 Feb 2004 09:27:51 -0500 (EST) 5 Received: from ietf-mx ([132.151.6.1]) 6 by ietf-mx with esmtp (Exim 4.12) 7 id 1AqYrg-0005EV-00 8 for internet-drafts@ietf.org; Tue, 10 Feb 2004 09:27:52 -0500 9 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) 10 id 1AqYqm-00059n-00 11 for internet-drafts@ietf.org; Tue, 10 Feb 2004 09:26:57 -0500 12 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) 13 by ietf-mx with esmtp (Exim 4.12) 14 id 1AqYpx-0004zt-00 15 for internet-drafts@ietf.org; Tue, 10 Feb 2004 09:26:05 -0500 16 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) 17 by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i1AEPUB00839; 18 Tue, 10 Feb 2004 15:25:30 +0100 19 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) 20 by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i1AEPUSj070148; 21 Tue, 10 Feb 2004 15:25:30 +0100 (CET) 22 (envelope-from dupont@givry.rennes.enst-bretagne.fr) 23 Message-Id: <200402101425.i1AEPUSj070148@givry.rennes.enst-bretagne.fr> 24 From: Francis Dupont 25 To: internet-drafts@ietf.org 26 Cc: Jean-Jacques Bernard 27 Subject: new version: draft-dupont-transient-pseudonat-03.txt 28 Date: Tue, 10 Feb 2004 15:25:30 +0100 29 Sender: Francis.Dupont@enst-bretagne.fr 30 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 31 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 32 ietf-mx.ietf.org 33 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 35 Internet Engineering Task Force Francis Dupont 36 Expires in August 2004 Jean-Jacques Bernard 37 AFNIC 38 February 2004 40 Transient pseudo-NAT attacks or 41 how NATs are even more evil than you believed 43 45 Status of this Memo 47 This document is an Internet Draft and is in full conformance with 48 all provisions of Section 10 of RFC 2026. 50 This document is an Internet-Draft. Internet-Drafts are working 51 documents of the Internet Engineering Task Force (IETF), its 52 areas, and its working groups. Note that other groups may also 53 distribute working documents as Internet-Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six 56 months and may be updated, replaced, or obsoleted by other 57 documents at any time. It is inappropriate to use Internet- 58 Drafts as reference material or to cite them other than as 59 "work in progress." 61 The list of current Internet Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html. 67 Distribution of this memo is unlimited. 69 Abstract 71 When a "NAT traversal" capability is added to a class of signaling 72 protocols which can control some traffic aggregation points, an 73 attack based on a temporary access to the path followed by messages 74 exists. 76 Mobile IP [1] with NAT traversal [2] or IKE [3] with NAT 77 traversal [6], including the IKEv2 [7] proposal, are potentially 78 affected by this kind of attacks. 80 This document claims this vulnerability is an intrinsic property 81 of the NAT traversal capability, and so is another point where the 82 usage of NATs is very damaging. 84 ^L 86 1. Introduction 88 A Network Address Translator (NAT [8]) is a device which rewrites 89 the source address or/and destination address as well as usually 90 the transport protocol ports of a communication. Many kinds of NATs 91 [9] exist but in this document the term NAT will be used for any 92 device which modifies at least one of the IP header addresses (a 93 pseudo-NAT when this is done for an attack, i.e., we will call 94 pseudo-NAT an attacker spoofing a NAT device). 96 NAT traversal capability consists in a NAT resilient transport 97 protocol , usually UDP, and in address "agility", i.e., addresses 98 in the header of packets are taken as they are, without control, 99 especially the source address (packets with a fake destination 100 address are likely to not reach their intended recipient). 102 A traffic aggregation point is a place where traffic from many 103 sources and/or many destinations is aggregated and sent to the same 104 destination. The traffic usually arrives from the same source (the 105 traffic aggregation point) through a tunnel. Home agents in Mobile 106 IP and security gateways in IPsec [4] are typical examples of such 107 traffic aggregation points (which are not necessary for the attack 108 to work but increase its impact). 110 2. The Transient Pseudo-NAT Attack 112 An attacker acting as a NAT (i.e., a pseudo-NAT) may: 113 - redirect packets to another node 114 - make the intended recipient to not receive packets 115 (first form of Denial-of-Service (DoS) attack) 116 - flood a third party with the hijacked packets 117 (second form of DoS attack, perhaps the most serious) 118 To perform the attack, the attacker must be on the path of packets 119 during the attack. 121 When there is a traffic aggregation point, the effects of the 122 attack are amplified when the attack is done "at the outgoing side" 123 of the aggregation point. 125 When a signaling protocol manages the direction followed by the 126 traffic, the attacker only has to spoof the addresses in the 127 headers of some messages of the protocol in order to hijack the 128 traffic during a long period (i.e., until an error is detected and 129 the correct path re-established). Since the attacker has to stay on 130 the path only for a short moment this attack is named the 131 "transient" pseudo-NAT attack. 133 ^L 135 3. Attack Examples 137 3.1 Mobile IP 139 For Mobile IP the traffic aggregation point fo choice is the home 140 agent and the target signaling protocol is the binding update (the 141 binding acknowledgment exchange). If the NAT traversal capability 142 is enabled, the care-of address of the mobile may not be protected, 143 and therefore may be easily spoofed. 145 If no binding acknowledgment is required, the attack can be reduced 146 to the modification in transit of only one packet. Thus we 147 recommend to always require acknowledgment when NAT traversal is 148 enabled (as a weak form of return-routability check). 150 3.2 IKE 152 The context of IKE is a bit different: because of an under- 153 specification in IKE documents, there is no standard provision for 154 address protection and most implementations fix this security flaw 155 in ways which clearly interfere with NAT traversal features. 157 The attack against IKE is worse because IKE is supposed to ensure 158 a high level of security, unfortunately bypassed by NAT traversal 159 which is the first short-term work item of the IETF ipsec working 160 group charter [5]... 162 The attack follows the same scheme: addresses in headers of IKE 163 exchange messages are spoofed and the traffic is hijacked. 165 Any improvement to the IKE protocol makes the attack easier (a 166 very unpleasant property of this attack). For instance if an 167 implementation supports an address change between two "phases", 168 (something desirable and supported via the SPI of the phase one) 169 then spoofing the two or three messages of a quick mode exchange is 170 enough to perform the attack. In IKEv2 only one packet of a 171 CREATE-CHILD-SA exchange is necessary to do so. 173 Again there is no easy way to keep the NAT traversal capability and 174 to achieve a good level of security at the same time. For instance 175 the protection of the header addresses (which is very easy to provide 176 in the IKE framework) cannot work with the NAT traversal capability. 178 4. Security Considerations 180 The Mobile IP NAT traversal document has a long description 181 of this attack [10,5]. We believe the ipsec working group will 182 examine in details which features can help mobility or/and NAT 183 traversal and what are their consequences for security. 185 ^L 186 The architectural implications of the NAT document [11] do not 187 describe this attack but it can be considered a result of 188 the violation of the end-to-end principle. 190 5. Acknowledgments 192 Maryline Maknavicius-Laurent drew my attention on this attack at 193 the IP Cellular Network 2002 conference. Phil Roberts encouraged 194 me to point out this attack in the IETF mobileip WG mailing-list 195 ASAP. I'd like to thank a well known NAT hater who'd like to stay 196 anonymous for his help to write this document. Mohan Parthasarathy 197 helped us to clarify the context of IKE. 199 6. Normative References 201 [1] C. Perkins (ed.), "IP Mobility Support for IPv4", RFC 3344, 202 August 2002. 204 [2] H. Levkowetz, S. Vaarala, "Mobile IP Traversal of Network 205 Address Translation (NAT) Devices", RFC 3519, April 2003. 207 [3] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 208 RFC 2409, November 1998. 210 [4] S. Kent, R. Atkinson, "Security Architecture for the Internet 211 Protocol", RFC 2401, November 1998. 213 [5] http://www.ietf.org/html.charters/ipsec-charter.html 215 7. Informative References 217 [6] A. Huttunen & all, "UDP Encapsulation of IPsec Packets", 218 draft-ietf-ipsec-udp-encaps-07.txt, October 2003. 220 [7] C. Kaufman (ed.), "Internet Key Exchange (IKEv2) Protocol", 221 draft-ietf-ipsec-ikev2-12.txt, January 2004. 223 [8] P. Srisuresh, K. Egevang, "Traditional IP Network Address 224 Translator (Traditional NAT)", RFC 3022,January 2001 . 226 [9] P. Srisuresh, M. Holdrege, "IP Network Address Translator 227 (NAT) Terminology and Considerations", RFC 2663, August 1999. 229 [10] S. Vaarala, public communication in the mobileip mailing-list, 230 , 231 May 2002. 233 [11] T. Hain, "Architectural Implications of NAT", RFC 2993, 234 November 2000. 236 ^L 238 8. Authors' Addresses 240 Francis Dupont 241 ENST Bretagne 242 Campus de Rennes 243 2, rue de la Chataigneraie 244 CS 17607 245 35576 Cesson-Sevigne Cedex 246 FRANCE 247 Fax: +33 2 99 12 70 30 248 EMail: Francis.Dupont@enst-bretagne.fr 250 Jean-Jacques Bernard 251 AFNIC / NIC France 252 Immeuble International 253 2 rue Stephenson 254 78181 Saint-Quentin-en-Yvelines Cedex 255 FRANCE 256 Fax: +33 1 39 30 83 01 257 EMail: Jean-Jacques.Bernard@nic.fr 259 ^L