idnits 2.17.1 draft-blunk-rpslng-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 297 has weird spacing: '...-routes lis...' == Line 334 has weird spacing: '...members list ...' == Line 422 has weird spacing: '...ons> or opt...' == Line 423 has weird spacing: '...ons> or mul...' == Line 438 has weird spacing: '...members list ...' == (1 more instance...) -- 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 (July 25, 2003) is 7574 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) -- Looks like a reference, but probably isn't: 'ATOMIC' on line 289 -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Blunk 3 Internet-Draft Merit Network 4 Expires: January 23, 2004 J. Damas 5 Internet Software Consortium 6 F. Parent 7 Viagenie 8 A. Robachevski 9 RIPE NCC 10 July 25, 2003 12 RPSLng 13 draft-blunk-rpslng-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 23, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This memo presents a new set of simple extensions to the RPSL 44 language enabling the language to document routing policies for the 45 IPv6 and multicast address families currently used in the Internet. 47 1. Introduction 49 RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing 50 protocols and a series of guidelines for extending the RPSL language 51 itself. Additionally, security extensions to the RPSL language are 52 specified in RFC 2725 [2]. 54 This document proposes to extend RPSL according to the following 55 goals and requirements: 57 Provide RPSL extensibility in the dimension of address families. 58 Specifically, to allow users to document routing policy for IPv6 59 and multicast. 61 Extensions should be backward compatible with minimal impact on 62 existing tools and processes, following Section 10 of RFC 2622 [1] 63 for guidelines on extending RPSL. 65 Clarity and non-ambiguity: RPSL information is used by humans in 66 addition to software tools. 68 Minimize duplication of information, particularly when routing 69 policies for different address families are the same. 71 The addition of IPv6 and multicast support to RPSL leads to four 72 distinct routing policies that need to be distinguished in this 73 specification, namely, (IPv4 {unicast|multicast}, IPv6 74 {unicast|multicast}). 76 2. Specifying routing policy for different address families 78 Routing policy is currently specified in the aut-num class using 79 "import:", "export:", and "default:" attributes. Sometimes it is 80 important to distinguish policy for different address families, as 81 well as a unicast routing policy from a multicast one. 83 While the syntax of the existing import, export, and default 84 attributes could be extended, this would present backward 85 compatibility issues and could undermine clarity in the expressions. 87 Keeping this in mind, the "import:", "export:", and "default:" 88 attributes implicitly specify IPv4 unicast policy and remain as 89 defined previously in RPSL, and new multi-protocol (prefixed with the 90 string "mp-") attributes are introduced. These will be described 91 below. 93 2.1 The afi dictionary attribute 95 In this section we introduce a new dictionary attribute: 97 Address Family Identifier, , is a RPSL list of address families 98 for which a given routing policy expression should be evaluated. 99 is mandatory within the new multi-protocol attributes 100 introduced in the aut-num class. 102 The possible values for are: 104 ipv4 105 ipv4.unicast (equivalent to ipv4) 106 ipv4.multicast 107 ipv6 108 ipv6.unicast (equivalent to ipv6) 109 ipv6.multicast 111 Appearance of these values in an attribute must be preceded by the 112 keyword afi. 114 An is defined as a comma separated list of one or more afi 115 values. 117 2.2 Additional dictionary extensions 119 In order to support IPv6 addresses specified with the next-hop 120 rp-attribute, a new predefined dictionary type entitled ipv6_address 121 is added to the RPSL dictionary. In addition, the next-hop 122 rp-attribute is re-defined in the dictionary as follows: 124 rp-attribute: # next hop router in a static route 125 next-hop 126 operator=(union ipv4_address, ipv6_address, enum[self]) 128 A new value has been added for the dictionary 129 specification: 131 MPBGP 133 MPBGP is understood to be BGP4 with multi-protocol extensions (often 134 referred to as BGP4+). BGP4+ could not be used as the '+' character 135 is not allowed by the RPSL specification in protocol names. 137 2.3 mp-import, mp-export, and mp-default 139 Three new policy attributes are introduced in the aut-num Class: 141 mp-import: 142 mp-export: 143 mp-default: 145 These attributes incorporate the afi (address-family) specification. 146 The mp-import and mp-export attributes have both a basic policy 147 specification and a more powerful structured policy specification. 149 The syntax for the mp-default attribute and the basic policy 150 specification of the mp-import and mp-export attributes is as 151 follows: 153 Attribute Value Type 154 mp-import [protocol ] [into ] optional, 155 afi multi-valued 156 from [action ] 157 . . . 158 from [action ] 159 accept 161 mp-export [protocol ] [into ] optional, 162 afi multi-valued 163 to [action ] 164 . . . 165 to [action ] 166 announce 168 mp-default afi to optional, 169 [action ] [networks ] multi-valued 171 The mp-import and mp-export policies can be structured. As with RFC 172 2622 [1], structured policies are recommended only to advanced RPSL 173 users. For the sake of brevity, only the mp-import structured policy 174 syntax is defined below. The mp-export structured policy syntax is 175 expressed in a symmetric way to the mp-import attribute. 177 mp-import ::= 178 [protocol ] [into ] 180 ::= 181 afi accept | 182 afi accept EXCEPT 183 | 184 afi accept REFINE 185 187 ::= | 188 { 189 190 ... 191 192 } 194 ::= from [action ]; 196 2.3.1 198 indicates the AS (and the router if present) and is 199 defined as follows: 201 ::= [] 202 [at ] | 204 with and being 205 expressions over router IPv4 or IPv6 addresses, inet-rtr names, and 206 rtr-set names using operators AND, OR, and EXCEPT. 208 2.3.2 210 The expression is an extension of the RPSL 211 expression [section 5.4 of RFC 2622 [1]], with the inclusion of the 212 ability to specify IPv6 address prefixes in Address-Prefix sets. For 213 the sake of brevity, we do not include the full definition of 214 here and refer the reader to RFC 2622 [1]. 216 2.3.3 Policy examples 218 The address family may be specified at any level of nesting of 219 , and is valid only within the 220 that contains it. 222 Therefore in the example: 224 aut-num: AS65534 225 mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo 226 except { afi ipv6.unicast,ipv4 227 from AS2 action pref = 2; accept AS226 228 except { afi ipv6.unicast 229 from AS3 action pref = 3; accept {3FFE:FFFF::/35} 230 } 231 } 233 the last (rightmost) "except" is evaluated only for the IPv6 unicast 234 address family, while other import-expressions are evaluated for both 235 the IPv6 and IPv4 unicast address families. 237 The evaluation of an is done by evaluating all of 238 its components. Evaluation of peering-sets and filter-sets is 239 constrained by the address family. Such constraints may result in a 240 {NOT ANY} or invalid depending on implicit 241 or explicit definitions of the address family in the set. In the 242 latter case an error is returned. {NOT ANY} may issue a 243 warning. 245 Conflicts with explicit or implicit declarations are resolved at 246 runtime, that is during evaluation of a policy expression. For 247 example, when evaluating the following import policy: 249 aut-num: AS2 250 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} 252 the mp-filter should be evaluated as {NOT ANY}. A more complex 253 example follows: 255 aut-num: AS2 256 mp-import: afi ipv6.unicast { 257 from AS-ANY action med = 0; accept {3FFE:FFFF::/35}; 258 } refine { afi ipv6.unicast 259 from AS1 at 3FFE:FFFF::1 action pref = 1; accept AS-UPSTREAM; 260 from prng6-ebgp-peers action pref = 2; accept AS1; 261 } 263 In this example only IPv6 prefixes originated by AS1 will be 264 collected, and while evaluating AS-UPSTREAM, an as-set, only IPv6 265 prefixes of the member ASes will be considered. 267 3. New route6 Class 269 The route6 class is the IPv6 equivalent of the route class. As with 270 the route class, the class key for the route6 class is specified by 271 the route6 and origin attribute pair. Other than the route6 272 attribute, the route6 class shares the same attribute names with the 273 route class. While the attribute names remain identical, the inject, 274 components, exports-comps, holes, and mnt-routes attributes must 275 specify IPv6 prefixes and addresses rather than IPv4 prefixes and 276 addresses. This requirement is reflected by the specification of 277 , , and 278 below. 280 Attribute Value Type 281 route6 mandatory, class key, 282 single-valued 283 origin mandatory, class key, 284 single-valued 285 member-of list of optional, multi-valued 286 inject [at ] ... optional, multi-valued 287 [action ] 288 [upon ] 289 components [ATOMIC] [[] optional, single-valued 290 [protocol ...]] 291 aggr-bndry optional, single-valued 292 aggr-mtd inbound or outbound optional, single-valued 293 [] 294 export-comps optional, single-valued 295 holes list of optional, multi-valued 296 mnt-lower list of optional, multi-valued 297 mnt-routes list of optional, multi-valued 298 [{list of } or ANY] 300 Example: 302 route6: 2001:610:240::/48 303 origin: AS3333 305 4. Updates to existing Classes to support the extensions 307 4.1 as-set Class 309 The as-set class defines a set of Autonomous Systems (AS), specified 310 either directly by listing them in the members attribute, or 311 indirectly by referring to another as-sets or using the mbrs-by-ref 312 facility. More importantly, "In a context that expects a route set 313 (e.g. members attribute of the route-set class), [...] an as-set 314 AS-X defines the set of routes that are originated by the ASes in 315 AS-X.", [section 5.3 of RFC2622]. 317 The as-set class is therefore used to collect a set of route 318 prefixes, which may be restricted to a specific address family. 320 The existing as-set class does not need any modifications. The 321 evaluation of the class must be filtered to obtain prefixes belonging 322 to a particular address family using the traditional filtering 323 mechanism in use in IRR systems today. 325 4.2 route-set Class 327 This class is used to specify a set of route prefixes. 329 A new attribute "mp-members:" is defined for this class. This 330 attributes allow the specification of IPv4 or IPv6 331 address-prefix-ranges. 333 Attribute Value Type 334 mp-members list of ( optional, multi-valued 335 or 336 or 337 or ) 339 Example: 341 route-set: rs-foo 342 mp-members: rs-bar 343 mp-members: 3FFE:FFFF::/35 # v6 member 344 mp-members: 128.9.0.0/16 # v4 member 346 4.3 filter-set Class 348 The new "mp-filter:" attribute defines the set's policy filter. A 349 policy filter is a logical expression which when applied to a set of 350 routes returns a subset of these routes. The relevant parts of the 351 updated filter-set class are shown below: 353 Attribute Value Type 354 filter-set mandatory, single-valued, class key 355 filter optional, single-valued 356 mp-filter optional, single-valued 357 ... 359 Where is defined above in Section 2.3.2. While the 360 "filter:" and "mp-filter:" attributes are of type "optional", a 361 filter-set must contain one of these two attributes. Implementations 362 should reject instances where both attributes are defined in an 363 object as the interpretation of such a filter-set is undefined. 365 4.4 peering-set Class 367 The peering set class is updated with a "mp-peering:" attribute. 369 Attribute Value Type 370 peering-set mandatory, single-valued, class key 371 peering optional, multi-valued 372 mp-peering optional, multi-valued 373 ... 375 Example: 377 peering-set: prng-ebgp-peers 378 mp-peering: AS2 3FFE:FFFF::1 at 3FFE:FFFF::2 380 With defined as above in Section 2.3.1. While the 381 "peering:" and "mp-peering:" attributes are of type "optional", a 382 peering-set must contain at least one of these two attributes. 384 4.5 inet-rtr Class 386 Two new attributes are introduced to the inet-rtr class -- 387 "interface:" which allows the definition of generic interfaces, 388 including the information previously contained in the "ifaddr:" 389 attribute, as well as support for tunnel definitions. And, 390 "mp-peer:", which includes and extends the functionality of the 391 existing "peer:" attribute. 393 Below is the syntax definition for the new "interface:" attribute. 395 Attribute Value Type 396 interface or optional, multi-valued 397 masklen 398 [action ] 399 [tunnel ,] 401 The new syntax allows native IPv4 and IPv6 interface definitions as 402 well as the definition of tunnels as virtual interfaces. Without the 403 optional tunnel definition, this attribute allows the same 404 functionality as the "ifaddr:" attribute but extends it to allow IPv6 405 addresses. 407 In the case of the interface being a tunnel, the syntax is as 408 follows: 410 indicates the IPv4 or IPv6 address of the 411 remote endpoint of the tunnel. The address family must match that of 412 the local endpoint. denotes the encapsulation used in 413 the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing 414 policies for these routers should be described in the appropriate 415 classes (eg. aut-num). 417 The "mp-peer:" attribute is defined below. The difference between 418 this attribute and the "peer:" attribute is the inclusion of support 419 for IPv6 addresses. 421 Attribute Value Type 422 mp-peer or optional, 423 or multi-valued 424 or 425 or 426 428 where is a protocol name, and is a comma 429 separated list of peering options for as provided in the 430 RPSL dictionary. 432 4.6 rtr-set Class 434 The rtr-set class is extended with a new attribute, "mp-members:", 435 defined as 437 Attribute Value Type 438 mp-members list of ( optional, multi-valued 439 or 440 or 441 ) 443 This attribute extends the original "members:" attribute by allowing 444 the specification of IPv6 addresses. 446 5. RFC 2725 extensions 448 RFC 2725 [2] introduces an authorization model to address the 449 integrity of policy expressed in routing registries. In particular, 450 two new attributes were defined to support this authorization model, 451 namely, the "mnt-routes" and "mnt-lower" attributes. 453 In RPSLng, these attributes are extended to the route6 and inet6num 454 (described below) classes. Further, the syntax of the existing 455 mnt-routes attribute is modified to allow the optional specification 456 of IPv6 prefix range lists when present in inet6num, route6, and 457 aut-num class objects. This optional list of prefix ranges is a 458 comma-separated list enclosed in curly braces. In the aut-num class, 459 the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They 460 keyword "ANY" is also allowed which means all more specifics. The 461 default when no additional set items are specified is "ANY". 463 Note, the inclusion of IPv6 prefix ranges within a mnt-routes 464 attribute in an aut-num object may conflict with existing 465 implementations of RPSL which support only IPv4 prefix ranges. 466 However, given the perceived lack of implementation of this optional 467 prefix range list, it was considered acceptable to extend the 468 existing definition of the mnt-routes attribute in the aut-num class 469 rather than creating a new attribute type. 471 Attribute Value Type 472 inet6num mandatory, single-valued, 473 class key 474 netname mandatory, single-valued 475 descr mandatory, multi-valued 476 country mandatory, multi-valued 477 admin-c mandatory, multi-valued 478 tech-c mandatory, multi-valued 479 remarks optional, multi-valued 480 notify optional, multi-valued 481 mnt-lower list of optional, multi-valued 482 mnt-routes list of optional, multi-valued 483 [{list of } or ANY] 484 mnt-by list of mandatory, multi-valued 485 changed mandatory, multi-valued 486 source mandatory, single-valued 488 The must be a valid two-letter ISO 3166 country code 489 identifier. is a symbolic name for the specified IPv6 490 address space. It does not have a restriction on RPSL reserved 491 prefixes. These definitions are taken from the RIPE Database 492 Reference Manual [3]. 494 5.1 Authorization model for route6 Objects 496 Deletion and update of a route6 object is not different from other 497 objects, as defined in RFC 2725 [2]. Creation rules of a route6 498 object is replicated here from the corresponding rules for route 499 object in RFC 2725 [2] section 9.9. 501 When adding a route6 object, the submission must satisfy two 502 authentication criteria. It must match the authentication specified 503 in the aut-num object and the authentication specified in either a 504 route6 object or if no applicable route6 object is found, then an 505 inet6num object. 507 An addition is submitted with an AS number and IPv6 prefix as its 508 key. If the aut-num object does not exist on a route6 to add, then 509 the addition is rejected. If the aut-num exists then the submission 510 is checked against the applicable maintainers. A search is then done 511 for the prefix first looking for an exact match. If the search for an 512 exact match fails, a search is made for the longest prefix match that 513 is less specific than the prefix specified. If this search succeeds 514 it will return one or more route6 objects. The submission must match 515 an applicable maintainer in at least one of these route6 objects for 516 the addition to succeed. If the search for a route6 object fails, 517 then a search is performed for an inet6num object that exactly 518 matches the prefix or for the most specific inet6num that is less 519 specific than the route6 object submission. 521 Having found the aut-num and either a list of route6 objects or an 522 inet6num, the authorization is taken from these objects. The 523 applicable maintainer object is any referenced by the mnt-routes 524 attributes. If one or more mnt-routes attributes are present in an 525 object, the mnt-by or mnt-lower attributes are not considered. In the 526 absence of a mnt-routes attribute in a given object, then first 527 mnt-lower attributes are used (only in the case the given object is 528 inet6num object and it is less specific than the route6 object to be 529 added), and if no applicable mnt-lower attribute is found, then the 530 mnt-by attributes are used for that object. The authentication must 531 match one of the authorization in each of the two objects. 533 6. Security Considerations 535 This document describes extensions to RFC 2622 [1] and RFC 2725 [2]. 536 The extensions address the limitations of the aforementioned 537 documents with respect to IPv6 and multicast. The extensions do not 538 introduce any new security functionality or threats. 540 While the extensions introduce no additional security threats, it 541 should be noted that the original RFC 2622 [1] RPSL standard included 542 several weak and/or vulnerable authentication mechanisms. First, the 543 "MAIL-FROM" scheme, which can be easily defeated via source email 544 address spoofing. Secondly, the "CRYPT-PW" scheme, which is subject 545 to dictionary attacks and password sniffing if RPSL objects are 546 submitted via unencrypted channels such as email. And finally, the 547 "NONE" mechanism, which offers no protection for objects. 549 7. Acknowledgments 551 The authors wish to thank all the people who have contributed to this 552 document through numerous discussions. 554 Particularly Ekaterina Petrusha for highly valuable discussions and 555 suggestions. Shane Kerr, Engin Gunduz, Mark Blanchet and David 556 Kessens participated constructively in many discussions. Finally, 557 Cengiz Alaettinoglu who is still the reference in all things RPSL. 559 References 561 [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 562 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 563 Policy Specification Language (RPSL)", RFC 2622, June 1999. 565 [2] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy, 566 "Routing Policy System Security", RFC 2725, December 1999. 568 [3] Damas, J. and A. Robachevski, "RIPE Database Reference Manual", 569 August 2002. 571 Authors' Addresses 573 Larry Blunk 574 Merit Network 576 EMail: ljb@merit.edu 578 Joao Damas 579 Internet Software Consortium 581 EMail: joao@psg.com 583 Florent Parent 584 Viagenie 586 EMail: Florent.Parent@viagenie.qc.ca 588 Andrei Robachevski 589 RIPE NCC 591 EMail: andrei@ripe.net 593 Intellectual Property Statement 595 The IETF takes no position regarding the validity or scope of any 596 intellectual property or other rights that might be claimed to 597 pertain to the implementation or use of the technology described in 598 this document or the extent to which any license under such rights 599 might or might not be available; neither does it represent that it 600 has made any effort to identify any such rights. Information on the 601 IETF's procedures with respect to rights in standards-track and 602 standards-related documentation can be found in BCP-11. Copies of 603 claims of rights made available for publication and any assurances of 604 licenses to be made available, or the result of an attempt made to 605 obtain a general license or permission for the use of such 606 proprietary rights by implementors or users of this specification can 607 be obtained from the IETF Secretariat. 609 The IETF invites any interested party to bring to its attention any 610 copyrights, patents or patent applications, or other proprietary 611 rights which may cover technology that may be required to practice 612 this standard. Please address the information to the IETF Executive 613 Director. 615 Full Copyright Statement 617 Copyright (C) The Internet Society (2003). All Rights Reserved. 619 This document and translations of it may be copied and furnished to 620 others, and derivative works that comment on or otherwise explain it 621 or assist in its implementation may be prepared, copied, published 622 and distributed, in whole or in part, without restriction of any 623 kind, provided that the above copyright notice and this paragraph are 624 included on all such copies and derivative works. However, this 625 document itself may not be modified in any way, such as by removing 626 the copyright notice or references to the Internet Society or other 627 Internet organizations, except as needed for the purpose of 628 developing Internet standards in which case the procedures for 629 copyrights defined in the Internet Standards process must be 630 followed, or as required to translate it into languages other than 631 English. 633 The limited permissions granted above are perpetual and will not be 634 revoked by the Internet Society or its successors or assignees. 636 This document and the information contained herein is provided on an 637 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 638 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 639 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 640 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 641 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 643 Acknowledgement 645 Funding for the RFC Editor function is currently provided by the 646 Internet Society.