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