idnits 2.17.1 draft-baker-sava-simple-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 236. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 19, 2007) is 6241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 181, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 184, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Address Validation F. Baker 3 Architecture Cisco Systems 4 Internet-Draft March 19, 2007 5 Intended status: Informational 6 Expires: September 20, 2007 8 Simple Source Address Validation 9 draft-baker-sava-simple-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "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 This Internet-Draft will expire on September 20, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This note proposes a simple solution to Source Address Validation, 43 assuming that the purpose of such validation is to prevent attacks 44 from using spoofed addresses. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Simple proposed solution . . . . . . . . . . . . . . . . . . . 3 50 2.1. The fundamental requirements: what is it that has to 51 be solved? . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. What to do . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.3. How to do it . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 Intellectual Property and Copyright Statements . . . . . . . . . . 6 63 1. Introduction 65 This note proposes a simple solution to Source Address Validation, 66 assuming that the purpose of such validation is to prevent attacks 67 from using spoofed addresses. The Source Address Validation problem 68 is proposed in other papers on this topic. I won't try to replicate 69 that discussion. 71 That said, it seems to this author that the principal mode of attack 72 in which a datagram with a spoofed source address is used is a single 73 datagram attack; it is possible to spoof an address for the first 74 exchange in a TCP session, but given that nothing is known of how a 75 peer replies to a datagram that was sent from a spoofed address, the 76 further into such a session one goes the more difficult it is to 77 maintain the illusion of coherence. As such, it seems like the first 78 requirement is that the first datagram in a session have its address 79 validated. 81 It also seems to this author that the network in which a datagram is 82 originated is among the targets that a bot might attack; an infected 83 host can attack the next host on the same wire or switch. As such, 84 the value of such an architecture is non-zero for the source LAN, and 85 only by derivation later. 87 2. Simple proposed solution 89 So I have a simple proposal. 91 2.1. The fundamental requirements: what is it that has to be solved? 93 If one buys the arguments that source address validation is of value 94 in the network the datagram is originated on and that it must be 95 applicable to the first datagram in any exchange, then it follows 96 that 98 o the place to implement source address validation is the set of 99 hosts and routers that directly connect to a host; e.g., those on 100 the same LAN, and 102 o that those devices must learn of that address before it is used or 103 as early as possible in its use. 105 2.2. What to do 107 Any host running IPv4 or IPv6 has one or more IP addresses that it 108 uses on any given interface. It also has some way of identifying 109 itself to its neighbors at Link Layer. On a LAN (fixed or wireless), 110 it uses a MAC Address; in a GPRS/3GPP network, it establishes a 111 circuit-like relationship with its router and is the only device at 112 the end of that circuit, so the circuit identifies the association. 113 If it is possible to associate addresses with hosts, it is possible 114 to associate them the way host is identified at the link layer. We 115 in fact do that, for the purpose of datagram delivery. 117 Implement what amounts to Local Unicast Reverse Path Forwarding. 118 Impose a policy that one IP system should accept IP datagrams from a 119 directly-connected IP neighbor (host or router) if and only if the 120 Source IP Address is among the equivalence class of IP addresses 121 known to be associated with the neighboring device. If traffic is 122 not accepted if that fails, this protects the devices each direct 123 recipient from the problem. Since one of those direct recipients is 124 the first hop router, by extension this protects the enterprise and 125 the Internet. 127 There are obvious exceptions to this, including routers and 128 multihomed hosts whose addresses are from other LANs. It seems that 129 these are eminently solvable: 131 o a host can identify each router it is a neighbor of, as it sends 132 Router Advertisements, 134 o a router can identify a neighboring router by the fact that it 135 enters into a routing protocol exchange, and 137 o multihomed hosts can follow a policy of only sending datagrams on 138 the LANs on which their source addresses are valid. 140 So these cases may be handled as exceptions in the logic. 142 2.3. How to do it 144 The way to accomplish this depends on the underlying Link Layer and 145 the way it associates devices. The set of valid IP addresses to be 146 used by the typical host may be established using ARP, by watching 147 DHCP assignments, or by asking for a Neighbor Discovery [RFC2461] 148 exchange to be accomplished per address the host will use. 150 3. IANA Considerations 152 This memo adds no new IANA considerations. 154 Note to RFC Editor: This section will have served its purpose if it 155 correctly tells IANA that no new assignments or registries are 156 required, or if those assignments or registries are created during 157 the RFC publication process. From the author's perspective, it may 158 therefore be removed upon publication as an RFC at the RFC Editor's 159 discretion. 161 4. Security Considerations 163 The security issues this document imposes are not worse than existing 164 security behavior. The use of ARP, Neighbor Discovery, and DHCP are 165 not currently secured, which may be an open attack vector. This is 166 considered a separate issue that, if real, must be addressed 167 separately. 169 5. Acknowledgements 171 6. References 173 6.1. Normative References 175 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 176 Discovery for IP Version 6 (IPv6)", RFC 2461, 177 December 1998. 179 6.2. Informative References 181 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 182 (IPv6) Specification", RFC 2460, December 1998. 184 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 185 Autoconfiguration", RFC 2462, December 1998. 187 Author's Address 189 Fred Baker 190 Cisco Systems 191 Santa Barbara, California 93117 192 USA 194 Phone: +1-408-526-4257 195 Fax: +1-413-473-2403 196 Email: fred@cisco.com 198 Full Copyright Statement 200 Copyright (C) The IETF Trust (2007). 202 This document is subject to the rights, licenses and restrictions 203 contained in BCP 78, and except as set forth therein, the authors 204 retain all their rights. 206 This document and the information contained herein are provided on an 207 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 208 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 209 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 210 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 211 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 212 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 214 Intellectual Property 216 The IETF takes no position regarding the validity or scope of any 217 Intellectual Property Rights or other rights that might be claimed to 218 pertain to the implementation or use of the technology described in 219 this document or the extent to which any license under such rights 220 might or might not be available; nor does it represent that it has 221 made any independent effort to identify any such rights. Information 222 on the procedures with respect to rights in RFC documents can be 223 found in BCP 78 and BCP 79. 225 Copies of IPR disclosures made to the IETF Secretariat and any 226 assurances of licenses to be made available, or the result of an 227 attempt made to obtain a general license or permission for the use of 228 such proprietary rights by implementers or users of this 229 specification can be obtained from the IETF on-line IPR repository at 230 http://www.ietf.org/ipr. 232 The IETF invites any interested party to bring to its attention any 233 copyrights, patents or patent applications, or other proprietary 234 rights that may cover technology that may be required to implement 235 this standard. Please address the information to the IETF at 236 ietf-ipr@ietf.org. 238 Acknowledgment 240 Funding for the RFC Editor function is provided by the IETF 241 Administrative Support Activity (IASA).