idnits 2.17.1 draft-dupont-transient-pseudonat-00.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-24) 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 (June 2002) is 7984 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 3220 (ref. '1') (Obsoleted by RFC 3344) ** 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 (-07) exists of draft-ietf-mobileip-nat-traversal-04 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-02 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-02 -- Obsolete informational reference (is this intentional?): RFC 1631 (ref. '8') (Obsoleted by RFC 3022) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 December 2002 June 2002 5 Transient pseudo-NAT attacks or 6 how NATs are even more evil than you believed 8 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Abstract 36 When a "NAT traversal" capability is added to a class of signaling 37 protocols which can control some traffic aggregation points, 38 a new attack based on a temporary access to the path followed 39 by messages. 41 Mobile IP [1] with NAT traversal [5] or IKE [2] with NAT 42 traversal [6], including the IKEv2 [7] proposal, are potential 43 victims of this kind of attacks. 45 This document claims the vulnerability is an intrinsic property 46 of the NAT traversal capability, so is a new point where the 47 usage of NATs is very damaging. 49 ^L 51 1. Introduction 53 A Network Address Translator (NAT [8]) is a router which rewrites 54 the source address or/and destination address as well as usually 55 the transport protocol ports. There are many kinds of NATs [9] 56 but in this document a NAT is any device which modifies at least 57 one of the IP header addresses (a pseudo-NAT when this is done 58 for an attack). 60 NAT traversal capability consists in a NAT resilient transport, 61 usually UDP, and in address "agility", i.e., addresses in the 62 header of packets are taken as they are, especially the source 63 address (packets with a fake destination address likely don't 64 reach their intended recipient). 66 A traffic aggregation point where traffic from many sources and/or 67 many destinations are aggregated and sent to the same destination 68 and usually from the same source (the traffic aggregation point) 69 through a tunnel. Home agents in Mobile IP and security gateways 70 in IPsec [3] are typical examples of such traffic aggregation 71 points (which are not necessary for the attack but increase its 72 impact). 74 2. The Transient Pseudo-NAT Attack 76 An attacker acting as a NAT (i.e., a pseudo-NAT) may: 77 - redirect packets to an accomplice 78 - make the intended recipient not receive packets to it 79 (first form of Denial-of-Service (DoS) attack) 80 - flood a third party by the hijacked packets 81 (second form of DoS attack, perhaps the most dangerous) 82 To perform the attack, the attacker must be on the path of packets 83 during the attack. 85 When there is a traffic aggregation point, the effects of the 86 attack are amplified when the attack is done "at the exit" of 87 the aggregation point. 89 When a signaling protocol manages the direction followed by the 90 traffic, the attacker can only spoof the addresses in headers 91 of some messages of the protocol in order to hijack the traffic 92 during a long period (i.e., until an error is detected and the 93 correct path re-established). As the attacker has to stay on 94 the path only a short moment, at the limit only for one packet, 95 this attack is named the "transient" pseudo-NAT attack. 97 ^L 99 3. Attack Examples 101 3.1 Mobile IP 103 For Mobile IP the traffic aggregation point for choice is the 104 home agent and the target signaling protocol is the binding update - 105 binding acknowledgment exchange. If the NAT traversal capability 106 is enabled, the care-of address of the mobile may not be protected 107 therefore may be easily spoofed. 109 If no binding acknowledgment is required the attack can be reduced 110 to the modification in transit of only one packet so we recommend 111 to always require acknowledgment when NAT traversal is enabled 112 (as a weak form of return-routability check). 114 3.2 IKE 116 The attack against IKE is worse because IKE is supposed to ensure 117 a very high level of security, unfortunately defeated by NAT 118 traversal which is the first short-term work item of the IETF 119 ipsec working group charter [4]... 121 The attack follows the same scheme: addresses in headers of IKE 122 exchange messages are spoofed and the traffic, for instance between 123 two security gateways, is hijacked. 125 Any improvement of the IKE protocol makes the attack easier (a 126 very unpleasant property of this attack). For instance if an 127 implementation supports an address change between two "phases" 128 (something desirable and supported via the SPI of the phase one) 129 then to spoof the two or three messages of a quick mode exchange is 130 enough, or in IKEv2 only one packet of a CREATE-CHILD-SA exchange. 132 Again there is no easy defense which keeps the NAT traversal 133 capability. For instance the protection of the header addresses 134 (very easy to provide in the IKE framework) is effective against 135 both the vulnerability and the NAT traversal capability... 137 4. Security Considerations 139 The Mobile IP NAT traversal new document has a long description 140 of this attack [10,5]. We believe the ipsec working group will 141 examine in details what features can help mobility or/and NAT 142 traversal and what are their consequences for security. 144 The architectural implications of NAT document [11] does not 145 describe this attack but it can be considered as a result of 146 the violation of the end-to-end principle on the trust model. 148 ^L 150 5. Acknowledgments 152 Maryline Maknavicius-Laurent drew my attention on this attack at 153 the IP Cellular Network 2002 conference. Phil Roberts encouraged 154 me to point out this attack in the IETF mobileip WG mailing-list 155 ASAP. I'd like to thank a well known NAT hater who'd like to stay 156 anonymous for his help to write this document. 158 6. Normative References 160 [1] C. Perkins (ed.), "IP Mobility Support for IPv4", RFC 3220, 161 January 2002. 163 [2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 164 RFC 2409, November 1998. 166 [3] S. Kent, R. Atkinson, "Security Architecture for the Internet 167 Protocol", RFC 2401, November 1998. 169 [4] http://www.ietf.org/html.charters/ipsec-charter.html 171 7. Informative References 173 [5] H. Levkowetz, S. Vaarala, "Mobile IP NAT/NAPT Traversal using 174 UDP Tunnelling", draft-ietf-mobileip-nat-traversal-04.txt, 175 May 2002. 177 [6] A. Huttunen & all, "UDP Encapsulation of IPsec Packets", 178 draft-ietf-ipsec-udp-encaps-02.txt, April 2002. 180 [7] D. Harkins & all, "Proposal for the IKEv2 Protocol", 181 draft-ietf-ipsec-ikev2-02.txt, April 2002. 183 [8] K. Egevang, P. Francis, "The IP Network Address Translator 184 (NAT)", RFC 1631, May 1994. 186 [9] P. Srisuresh, M. Holdrege, "IP Network Address Translator 187 (NAT) Terminology and Considerations", RFC 2663, August 1999. 189 [10] S. Vaarala, public communication in the mobileip mailing-list, 190 , 191 May 2002. 193 [11] T. Hain, "Architectural Implications of NAT", RFC 2993, 194 November 2000. 196 ^L 198 8. Author's Address 200 Francis Dupont 201 ENST Bretagne 202 Campus de Rennes 203 2, rue de la Chataigneraie 204 BP 78 205 35512 Cesson-Sevigne Cedex 206 FRANCE 207 Fax: +33 2 99 12 70 30 208 EMail: Francis.Dupont@enst-bretagne.fr 210 ^L