idnits 2.17.1 draft-ietf-grow-unique-origin-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 15, 2010) is 4909 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2119' is defined on line 385, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 Ryan Donnelly 3 Frank Scalzo 4 VeriSign, Inc. 5 Expires: May 2011 November 15, 2010 6 Intended Status: Best Current Practice 8 Unique Per-Node Origin ASNs for Globally Anycasted Services 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Copyright (c) 2010 IETF Trust and the persons identified as the document 17 authors. All rights reserved. 19 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 20 Relating to IETF Documents (http://trustee.ietf.org/license-info) 21 in effect on the date of publication of this document. Please 22 review these documents carefully, as they describe your rights and 23 restrictions with respect to this document. Code Components 24 extracted from this document must include Simplified BSD License 25 text as described in Section 4.e of the Trust Legal Provisions and 26 are provided without warranty as described in the Simplified BSD 27 License. 29 Internet-Drafts are working documents of the Internet Engineering Task 30 Force (IETF), its areas, and its working groups. Note that other groups 31 may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference material 36 or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright Notice 46 Copyright (C) (2010) The IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 Abstract 51 This document makes recommendations regarding the use of per-node 52 unique origin ASNs for globally anycasted critical infrastructure 53 services in order to provide routing system discriminators for a 54 given anycasted prefix. Network managment and monitoring techniques, 55 or other operational mechanisms may employ this new discriminator in 56 whatever manner fits their operating environment. 58 Table of Contents 60 1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Recommendation for Unique Origin ASNs. . . . . . . . . . . . . 6 63 4. Additional Recommendations for Globally Anycasted 64 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 66 6. Deployment Considerations. . . . . . . . . . . . . . . . . . . 9 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References. . . . . . . . . . . . . . . . . . . 11 72 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 11 74 1. Terminology 76 This document employs much of the following terminology, which was 77 taken in full from Section 2 of [RFC 4786]. 79 Anycast: the practice of making a particular Service Address 80 available in multiple, discrete, autonomous locations, such that 81 datagrams sent are routed to one of several available locations. 83 Anycast Node: an internally-connected collection of hosts and 84 routers that together provide service for an anycast Service 85 Address. An Anycast Node might be as simple as a single host 86 participating in a routing system with adjacent routers, or it 87 might include a number of hosts connected in some more elaborate 88 fashion; in either case, to the routing system across which the 89 service is being anycast, each Anycast Node presents a unique path 90 to the Service Address. The entire anycast system for the service 91 consists of two or more separate Anycast Nodes. 93 Catchment: in physical geography, an area drained by a river, also 94 known as a drainage basin. By analogy, as used in this document, 95 the topological region of a network within which packets directed 96 at an Anycast Address are routed to one particular node. 98 Local-Scope Anycast: reachability information for the anycast 99 Service Address is propagated through a routing system in such a 100 way that a particular anycast node is only visible to a subset of 101 the whole routing system. 103 Local Node: an Anycast Node providing service using a Local-Scope 104 Anycast Address. 106 Global Node: an Anycast Node providing service using a Global-Scope 107 Anycast Address. 109 Global-Scope Anycast: reachability information for the anycast 110 Service Address is propagated through a routing system in such a 111 way that a particular anycast node is potentially visible to the 112 whole routing system. 114 Service Address: an IP address associated with a particular service 115 (e.g., the destination address used by DNS resolvers to reach a 116 particular authority server). 118 2. Introduction 120 IP anycasting [RFC 4786] has been deployed for an array of network 121 services since the early 1990s. It provides a mechanism for a given 122 network resource to be available in a more distributed manner, 123 locally and/or globally, with a more robust and resilient footprint, 124 commonly yielding better localization and absorption of systemic 125 query loads, as well as better protections in the face of DDoS 126 attacks, network partitions, and other similar incidents. A large 127 part of the Internet root DNS infrastructure, as well as many other 128 resources, has been anycasted for nearly a decade. 130 While the benefits realized by anycasting network services is proven, 131 some issues do emerge with asserting routing system reachability for 132 a common network identifier from multiple locations. Specifically, 133 anycasting in BGP requires injection of reachability information in 134 the routing system for a common IP address prefix from multiple 135 locations. These anycasted prefixes and network services have 136 traditionally employed a common origin autonomous system number (ASN) 137 in order to preserve historically scarce 16-bit AS number space 138 utilized by BGP for routing domain identifiers in the global routing 139 system. Additionally, a common origin AS number was used in order to 140 ease management overhead of resource operations associated with 141 acquiring and maintaining multiple discrete AS numbers, as well as to 142 avoid triggering various operations- oriented reporting functions 143 aimed at identifying "inconsistent origin AS announcements" observed 144 in the routing system. As a result, the representation of routing 145 system path attributes associated with those service instances, and 146 that anycasted prefix itself, typically bear no per-instance 147 discriminators in the routing system (i.e., within the network 148 control plane itself). 150 Service level query capabilities may or may not provide a mechanism 151 to identify which anycast node responded to a particular query, 152 although this is likely both service (e.g., DNS or NTP) and 153 implementation dependent. For example, NSD, Unbound, and BIND all 154 provide 'hostname.bind or hostname.id' [HNAME] query support that 155 enables service-level identification of a given server. Tools such 156 as traceroute are also used to determine which location a given query 157 is being routed to, although it may not reveal local-scope anycast 158 instances, or if there are multiple servers within a given anycast 159 node, which of the servers responded to a given query, in particular 160 when multiple servers within an anycast node are connected to a 161 single IP router. When utilizing these service level capabilities, 162 query responses are typically both deterministic and inherently 163 topology-dependent, however, these service level identifiers at the 164 data plane provide no control plane (routing system) uniqueness. 166 As more services are globally anycasted, and existing anycasted 167 services realize wider deployment of anycast nodes for a given 168 service address in order to accommodate growing system loads, the 169 difficulty of providing safeguards and controls to better protect 170 those resources expands. Intuitively, the more widely distributed a 171 given anycasted service address is, the more difficult it becomes for 172 network operators to detect operational and security issues that 173 affect that service. Some examples of such security and operational 174 issues include BGP route leaks affecting the anycasted service, rogue 175 anycast nodes appearing for the service, or the emergence of other 176 aberrant behavior in either the routing system, the forward query 177 datapath, or query response datapath. Diagnosis of the routing 178 system issues is complicated by the fact that no unique 179 discriminators exist in the routing system to identify a given local 180 or global anycast node. Furthermore, both datapath and routing 181 system problem identification is compounded by the fact that either 182 incident type can be topologically-dependent. 184 Additionally, while it goes without saying that anycasted services 185 should always strive for exact synchronization across all instances 186 of an anycasted service address, if local policies or data plane 187 response manipulation techniques were to "influence" responses within 188 a given region in such a way that those response are no longer 189 authentic or that they diverge from what other nodes within an 190 anycasted service were providing, then it should be an absolute 191 necessity that those modified resources only be utilized by service 192 consumers within that region or influencer's jurisdiction. 194 Mechanisms should exist at both the network and service layer to make 195 it abundantly apparent to operators and users alike whether any of 196 the query responses are not authentic. For DNS, DNSSEC [RFC 4033] 197 provides this capability at the service layer with object level 198 integrity, assuming validation is being enforced by recursive name 199 servers, and DNSSEC deployment at the root and top level domain (TLD) 200 levels is well underway [DNSSEC-DEPLOY]. Furthermore, control plane 201 discriminators should exist to enable operators to know toward which 202 of a given set of instances a query is being directed, and to enable 203 detection and alerting capabilities when this changes. Such 204 discriminators may also be employed to enable anycast node preference 205 or filtering keys, should local operational policy require it. 207 3. Recommendation for Unique Origin ASNs 209 In order to be able to better detect changes to routing information 210 associated with crtical anycasted resources, globally anycasted 211 services with partitioned origin ASNs SHOULD utilize a unique origin 212 ASN per node where possible. 214 Discrete origin ASNs per node provide a discriminator in the routing 215 system that would enable detection of leaked or hijacked instances 216 more quickly, and would also enable operators that so choose to 217 proactively develop routing policies that express preferences or 218 avoidance for a given node or set of nodes associated with an 219 anycasted service. This is particularly useful when it is observed 220 that local policy or known issues exist with the performance or 221 authenticity of responses returned from a specific anycast node, or 222 that enacted policies meant to affect service within a particular 223 region are affecting users outside of that region as a result of a 224 given anycast catchment expanding beyond its intended scope. 226 Furthermore, inconsistent origin AS announcements associated with 227 anycasted services for critical infrastructure SHOULD NOT be deemed 228 undesirable by routing system reporting functions, but should instead 229 be embraced in order to better identify the connectedness and 230 footprint of a given anycasted service. 232 While namespace conservation and reasonable use of AS number 233 resources should always be a goal, the introduction of 32-bit ASNs 234 significantly lessens concerns in this space. Globally anycasted 235 resources, in particular those associated with critical 236 infrastructure-enabling services such as root and TLD name servers, 237 SHOULD warrant special consideration with regard to AS number 238 allocation practices during policy development by the constituents of 239 those responsible organizations (e.g., the Regional Internet 240 Registries). Additionally, defining precisely what constitutes 241 "critical infrastructure services" or "special consideration" (e.g., 242 some small range of 32-bit AS numbers might be provided) is left to 243 the constituents of those organizations. Additionally, critical 244 infrastructure employment of 32-bit ASNs for new nodes might well 245 help to foster adoption of native 32-bit ASN support by network 246 operators. 248 One additional benefit of unique origin AS numbers per anycast node 249 is that Resource PKI (RPKI) Secure Inter-domain Routing [SIDR] 250 machinery, and in particular, that of Route Origin Authorizations 251 (ROAs), and routing policies that may be derived based on those ROAs, 252 can be employed with per anycast node resolution, rather than relying 253 on a single ROA and common origin AS to cover all instantiations of 254 an anycasted prefix (possibly hundreds) within the global routing 255 system. For example, deployments that incorporate partitioned ASN 256 anycast models that have a single ASN bound to all nodes but cross 257 organizational or political boundaries, a situation may arise where 258 nobody would be deemed appropriate to hold the key for the ROA. 259 Additionally, a globally anycasted service within a given IP prefix 260 that shares a common ASN might be taken totally offline because of 261 the revocation of a ROA for that origin. 263 4. Additional Recommendations for Globally Anycasted Services 265 Two additional recommendations for globally anycasted critical 266 infrastructure services are related to publication of information 267 associated with a given node's physical location, and which adjacent 268 upstream ASNs an origin AS interconnects with. The former would 269 allow operators to better define and optimize preferences associated 270 with a given node to align with local policy and service 271 optimizations. The latter would allow expression through policy such 272 as Routing Policy Specification Language [RFC 4012] specified in 273 Internet Routing Registries (IRRs) in a manner that illustrates a 274 discrete set of upstream ASNs for each anycast node, rather than the 275 current model where all upstream ASNs associated with a common origin 276 AS may or may not be expressed. This information would provide an 277 additional level of static AS path validation or monitoring and 278 detection models by network operators, and perhaps explicit network 279 layer source address validation in the datapath. 281 5. Security Considerations 283 The recommendations made in this memo aim to provide more flexibility 284 for network operators hoping to better monitor and prevent issues 285 related to globally anycasted critical infrastructure resources. 286 Anycast itself provides considerable benefit in the face of certain 287 attacks, yet if a given instance of a service can appear at many 288 points in the routing system and legitimate instances are difficult 289 to distinguish from malicious ones, then anycast expands the 290 service's attack surface rather than reducing it. 292 The recommendations made in this document are expressed to assist 293 with visibility and policy specification capabilities in order to 294 improve the availability of critical Internet resources. Use cases 295 where the recommendations outlined in this memo may have helped to 296 more easily detect or scope the impact of a particular incident are 297 illustrated in [RENESYS-BLOG]. 299 Furthermore, while application layer protection mechanisms such as 300 DNSSEC provide object level integrity and authentication, they often 301 do so at the cost of introducing more failure conditions. For 302 example, if a recursive name server is performing DNSSEC validator 303 functions and receives a bogus response to a given query as a result 304 of a man-in-the-middle (MITM) or injected spoofed response packet 305 such as a cache poisoning attempt, the possibility might exist that 306 that packet is processed by the server and results in some temporal 307 or persistent DoS condition on the recursuve name server and for its 308 customer set. The unique origin AS mechanism outlined in this 309 document provides the capability for network operators to expressly 310 avoid anycast node catchments known to regularly elicit bogus 311 responses, while allowing the anycasted service address to remain 312 available otherwise. 314 6. Deployment Considerations 316 Maintenance of unique ASNs for each node within an anycasted service 317 may be challenging for some critical infrastructure service operators 318 initially, but for globally anycasted resources there needs to be 319 some type of per-node discriminator in the control plane to enable 320 detection, remediation, and optimally, preventative controls for 321 dealing with routing system anomalies that are intensified by the 322 application of IP anycasting. Additionally, this technique sets the 323 stage to employ RPKI-enabled machinery and more secure and explicit 324 routing policies, which all network operators should be considering. 326 The granularity of data publication related to anycast node location 327 should be left to the devises of each services operator, but some 328 reasonable level of detail to enable operators to make informed 329 decisions that align with their security and operational objectives 330 as outlined herein should be provided by each critical services 331 operator. 333 Adjacent AS information for a given origin AS can be obtained through 334 careful routing system analysis already when prefixes are advertised 335 via a given set of AS adjacencies, and therefore should present no 336 new threat. However, network interconnection and peering policies 337 may well present some challenges in this area. For example, if a 338 technique such as unique origin AS per node is employed then a single 339 orgnaizaton may no longer have a single AS for interconnection at 340 each location, and interconnection policies should expressly consider 341 this. That said, interconnection with networks that provide critical 342 infrastructure services should certainly be given due consideration 343 as such by network operators when evaluating interconnection 344 strategies. 346 Some root and TLD operators today identify erroneous anycast prefix 347 announcements by detecting prefix announcements with an origin AS 348 other than the common origin AS shared via all nodes. This detection 349 model would need to be expanded to account for unique origin ASNs per 350 node if a given service operators chooses to employ such as a model, 351 and given that AS paths are trivial to manipulate, the above 352 technique would only assist in the event of unintentional 353 configuration errors that reoriginate the route (e.g., it doesn't 354 even detect leaks that preserve the initial path elements). 356 Finally, anycast node presence at exchange points that employs route 357 servers may make enumeration of adjacent ASNs for a given node 358 challenging. While this is understood, service operators should make 359 every effort to enumerate the set of adjacent ASNs associated with a 360 given anycast node's origin AS. Without express understanding of 361 legitimate AS interconnection and authorized origin AS information, 362 more secure routing is difficult to acheive. 364 7. Acknowledgements 366 Thanks to David Conrad, Steve Kent, Mark Kosters, Andrei Robachevsky, 367 Paul Vixie, Brad Verd, Andrew Herrmann, Gaurab Raj Upadhaya, Joe 368 Abley, Benson Schliesser, Shane Amante, and Randy Bush for review and 369 comments on this concept. 371 Others? Your name could be here....... 373 8. IANA Considerations 375 This document requires no direct IANA actions, although it does 376 provide general guidance to number resource allocation and policy 377 development organizations, and in particular Regional Internet 378 Registries, regarding allocation of AS numbers for globally anycasted 379 services. 381 9. References 383 9.1. Normative References 385 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 [RFC 4786] Abley, J., and Lindqvist, K., "Operation of Anycast 389 Services", RFC 4786, BCP 126, December 2006. 391 9.2. Informative References 393 [RFC 4012] Blunk, et al., "Routing Policy Specification Language 394 next generation (RPSLng)", RFC 4012, March 2005. 396 [RFC 4033] Arends, et al., "DNS Security Introduction and 397 Requirements", RFC 4033, March 2005. 399 [DNSSEC-DEPLOY] "Root DNSSEC", 401 [HNAME] ISC, "Which F-root node am I using?" 402 404 [RENESYS-BLOG] Zmijewski, E., "Accidentally Importing Censorship", 405 Renesys Blog, March 30, 2010. 406 408 [SIDR] Lepinski, M., Kent, S., "An Infrastructure to Support Secure 409 Internet Routing", October 2009, Internet-Draft, "Work in 410 Progress". 412 10. Authors' Addresses 413 Danny McPherson 414 Verisign, Inc. 415 Email: dmcpherson@verisign.com 417 Ryan Donnelly 418 Verisign, Inc. 419 Email: rdonnelly@verisign.com 421 Frank Scalzo 422 Verisign, Inc. 423 Email: fscalzo@verisign.com 425 Copyright Statement 427 Copyright (C) (2010) The IETF Trust and the persons 428 identified as the document authors. All rights reserved. 430 This document is subject to BCP 78 and the IETF Trust's Legal 431 Provisions Relating to IETF Documents 432 (http://trustee.ietf.org/license-info) in effect on the date of 433 publication of this document. Please review these documents 434 carefully, as they describe your rights and restrictions with 435 respect to this document.