Network Working Group L. Blunk Internet-Draft Merit Network Expires: January 23, 2004 J. Damas Internet Software Consortium F. Parent Viagenie A. Robachevski RIPE NCC July 25, 2003 RPSLng draft-blunk-rpslng-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 23, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. Blunk, et al. Expires January 23, 2004 [Page 1] Internet-Draft RPSLng July 2003 1. Introduction RFC 2622 [1] defines the RPSL language for the IPv4 unicast routing protocols and a series of guidelines for extending the RPSL language itself. Additionally, security extensions to the RPSL language are specified in RFC 2725 [2]. This document proposes to extend RPSL according to the following goals and requirements: Provide RPSL extensibility in the dimension of address families. Specifically, to allow users to document routing policy for IPv6 and multicast. Extensions should be backward compatible with minimal impact on existing tools and processes, following Section 10 of RFC 2622 [1] for guidelines on extending RPSL. Clarity and non-ambiguity: RPSL information is used by humans in addition to software tools. Minimize duplication of information, particularly when routing policies for different address families are the same. The addition of IPv6 and multicast support to RPSL leads to four distinct routing policies that need to be distinguished in this specification, namely, (IPv4 {unicast|multicast}, IPv6 {unicast|multicast}). Blunk, et al. Expires January 23, 2004 [Page 2] Internet-Draft RPSLng July 2003 2. Specifying routing policy for different address families Routing policy is currently specified in the aut-num class using "import:", "export:", and "default:" attributes. Sometimes it is important to distinguish policy for different address families, as well as a unicast routing policy from a multicast one. While the syntax of the existing import, export, and default attributes could be extended, this would present backward compatibility issues and could undermine clarity in the expressions. Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below. 2.1 The afi dictionary attribute In this section we introduce a new dictionary attribute: Address Family Identifier, , is a RPSL list of address families for which a given routing policy expression should be evaluated. is mandatory within the new multi-protocol attributes introduced in the aut-num class. The possible values for are: ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast Appearance of these values in an attribute must be preceded by the keyword afi. An is defined as a comma separated list of one or more afi values. 2.2 Additional dictionary extensions In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary. In addition, the next-hop rp-attribute is re-defined in the dictionary as follows: Blunk, et al. Expires January 23, 2004 [Page 3] Internet-Draft RPSLng July 2003 rp-attribute: # next hop router in a static route next-hop operator=(union ipv4_address, ipv6_address, enum[self]) A new value has been added for the dictionary specification: MPBGP MPBGP is understood to be BGP4 with multi-protocol extensions (often referred to as BGP4+). BGP4+ could not be used as the '+' character is not allowed by the RPSL specification in protocol names. 2.3 mp-import, mp-export, and mp-default Three new policy attributes are introduced in the aut-num Class: mp-import: mp-export: mp-default: These attributes incorporate the afi (address-family) specification. The mp-import and mp-export attributes have both a basic policy specification and a more powerful structured policy specification. The syntax for the mp-default attribute and the basic policy specification of the mp-import and mp-export attributes is as follows: Attribute Value Type mp-import [protocol ] [into ] optional, afi multi-valued from [action ] . . . from [action ] accept mp-export [protocol ] [into ] optional, afi multi-valued to [action ] . . . to [action ] announce mp-default afi to optional, [action ] [networks ] multi-valued Blunk, et al. Expires January 23, 2004 [Page 4] Internet-Draft RPSLng July 2003 The mp-import and mp-export policies can be structured. As with RFC 2622 [1], structured policies are recommended only to advanced RPSL users. For the sake of brevity, only the mp-import structured policy syntax is defined below. The mp-export structured policy syntax is expressed in a symmetric way to the mp-import attribute. mp-import ::= [protocol ] [into ] ::= afi accept | afi accept EXCEPT | afi accept REFINE ::= | { ... } ::= from [action ]; 2.3.1 indicates the AS (and the router if present) and is defined as follows: ::= [] [at ] | with and being expressions over router IPv4 or IPv6 addresses, inet-rtr names, and rtr-set names using operators AND, OR, and EXCEPT. 2.3.2 The expression is an extension of the RPSL expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of Blunk, et al. Expires January 23, 2004 [Page 5] Internet-Draft RPSLng July 2003 here and refer the reader to RFC 2622 [1]. 2.3.3 Policy examples The address family may be specified at any level of nesting of , and is valid only within the that contains it. Therefore in the example: aut-num: AS65534 mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS2 action pref = 2; accept AS226 except { afi ipv6.unicast from AS3 action pref = 3; accept {3FFE:FFFF::/35} } } the last (rightmost) "except" is evaluated only for the IPv6 unicast address family, while other import-expressions are evaluated for both the IPv6 and IPv4 unicast address families. The evaluation of an is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} or invalid depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} may issue a warning. Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} the mp-filter should be evaluated as {NOT ANY}. A more complex example follows: aut-num: AS2 mp-import: afi ipv6.unicast { from AS-ANY action med = 0; accept {3FFE:FFFF::/35}; } refine { afi ipv6.unicast from AS1 at 3FFE:FFFF::1 action pref = 1; accept AS-UPSTREAM; from prng6-ebgp-peers action pref = 2; accept AS1; } Blunk, et al. Expires January 23, 2004 [Page 6] Internet-Draft RPSLng July 2003 In this example only IPv6 prefixes originated by AS1 will be collected, and while evaluating AS-UPSTREAM, an as-set, only IPv6 prefixes of the member ASes will be considered. Blunk, et al. Expires January 23, 2004 [Page 7] Internet-Draft RPSLng July 2003 3. New route6 Class The route6 class is the IPv6 equivalent of the route class. As with the route class, the class key for the route6 class is specified by the route6 and origin attribute pair. Other than the route6 attribute, the route6 class shares the same attribute names with the route class. While the attribute names remain identical, the inject, components, exports-comps, holes, and mnt-routes attributes must specify IPv6 prefixes and addresses rather than IPv4 prefixes and addresses. This requirement is reflected by the specification of , , and below. Attribute Value Type route6 mandatory, class key, single-valued origin mandatory, class key, single-valued member-of list of optional, multi-valued inject [at ] ... optional, multi-valued [action ] [upon ] components [ATOMIC] [[] optional, single-valued [protocol ...]] aggr-bndry optional, single-valued aggr-mtd inbound or outbound optional, single-valued [] export-comps optional, single-valued holes list of optional, multi-valued mnt-lower list of optional, multi-valued mnt-routes list of optional, multi-valued [{list of } or ANY] Example: route6: 2001:610:240::/48 origin: AS3333 Blunk, et al. Expires January 23, 2004 [Page 8] Internet-Draft RPSLng July 2003 4. Updates to existing Classes to support the extensions 4.1 as-set Class The as-set class defines a set of Autonomous Systems (AS), specified either directly by listing them in the members attribute, or indirectly by referring to another as-sets or using the mbrs-by-ref facility. More importantly, "In a context that expects a route set (e.g. members attribute of the route-set class), [...] an as-set AS-X defines the set of routes that are originated by the ASes in AS-X.", [section 5.3 of RFC2622]. The as-set class is therefore used to collect a set of route prefixes, which may be restricted to a specific address family. The existing as-set class does not need any modifications. The evaluation of the class must be filtered to obtain prefixes belonging to a particular address family using the traditional filtering mechanism in use in IRR systems today. 4.2 route-set Class This class is used to specify a set of route prefixes. A new attribute "mp-members:" is defined for this class. This attributes allow the specification of IPv4 or IPv6 address-prefix-ranges. Attribute Value Type mp-members list of ( optional, multi-valued or or or ) Example: route-set: rs-foo mp-members: rs-bar mp-members: 3FFE:FFFF::/35 # v6 member mp-members: 128.9.0.0/16 # v4 member 4.3 filter-set Class The new "mp-filter:" attribute defines the set's policy filter. A policy filter is a logical expression which when applied to a set of routes returns a subset of these routes. The relevant parts of the Blunk, et al. Expires January 23, 2004 [Page 9] Internet-Draft RPSLng July 2003 updated filter-set class are shown below: Attribute Value Type filter-set mandatory, single-valued, class key filter optional, single-valued mp-filter optional, single-valued ... Where is defined above in Section 2.3.2. While the "filter:" and "mp-filter:" attributes are of type "optional", a filter-set must contain one of these two attributes. Implementations should reject instances where both attributes are defined in an object as the interpretation of such a filter-set is undefined. 4.4 peering-set Class The peering set class is updated with a "mp-peering:" attribute. Attribute Value Type peering-set mandatory, single-valued, class key peering optional, multi-valued mp-peering optional, multi-valued ... Example: peering-set: prng-ebgp-peers mp-peering: AS2 3FFE:FFFF::1 at 3FFE:FFFF::2 With defined as above in Section 2.3.1. While the "peering:" and "mp-peering:" attributes are of type "optional", a peering-set must contain at least one of these two attributes. 4.5 inet-rtr Class Two new attributes are introduced to the inet-rtr class -- "interface:" which allows the definition of generic interfaces, including the information previously contained in the "ifaddr:" attribute, as well as support for tunnel definitions. And, "mp-peer:", which includes and extends the functionality of the existing "peer:" attribute. Below is the syntax definition for the new "interface:" attribute. Attribute Value Type Blunk, et al. Expires January 23, 2004 [Page 10] Internet-Draft RPSLng July 2003 interface or optional, multi-valued masklen [action ] [tunnel ,] The new syntax allows native IPv4 and IPv6 interface definitions as well as the definition of tunnels as virtual interfaces. Without the optional tunnel definition, this attribute allows the same functionality as the "ifaddr:" attribute but extends it to allow IPv6 addresses. In the case of the interface being a tunnel, the syntax is as follows: indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num). The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses. Attribute Value Type mp-peer or optional, or multi-valued or or where is a protocol name, and is a comma separated list of peering options for as provided in the RPSL dictionary. 4.6 rtr-set Class The rtr-set class is extended with a new attribute, "mp-members:", defined as Attribute Value Type mp-members list of ( optional, multi-valued or or ) Blunk, et al. Expires January 23, 2004 [Page 11] Internet-Draft RPSLng July 2003 This attribute extends the original "members:" attribute by allowing the specification of IPv6 addresses. Blunk, et al. Expires January 23, 2004 [Page 12] Internet-Draft RPSLng July 2003 5. RFC 2725 extensions RFC 2725 [2] introduces an authorization model to address the integrity of policy expressed in routing registries. In particular, two new attributes were defined to support this authorization model, namely, the "mnt-routes" and "mnt-lower" attributes. In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects. This optional list of prefix ranges is a comma-separated list enclosed in curly braces. In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The default when no additional set items are specified is "ANY". Note, the inclusion of IPv6 prefix ranges within a mnt-routes attribute in an aut-num object may conflict with existing implementations of RPSL which support only IPv4 prefix ranges. However, given the perceived lack of implementation of this optional prefix range list, it was considered acceptable to extend the existing definition of the mnt-routes attribute in the aut-num class rather than creating a new attribute type. Attribute Value Type inet6num mandatory, single-valued, class key netname mandatory, single-valued descr mandatory, multi-valued country mandatory, multi-valued admin-c mandatory, multi-valued tech-c mandatory, multi-valued remarks optional, multi-valued notify optional, multi-valued mnt-lower list of optional, multi-valued mnt-routes list of optional, multi-valued [{list of } or ANY] mnt-by list of mandatory, multi-valued changed mandatory, multi-valued source mandatory, single-valued The must be a valid two-letter ISO 3166 country code identifier. is a symbolic name for the specified IPv6 address space. It does not have a restriction on RPSL reserved prefixes. These definitions are taken from the RIPE Database Blunk, et al. Expires January 23, 2004 [Page 13] Internet-Draft RPSLng July 2003 Reference Manual [3]. 5.1 Authorization model for route6 Objects Deletion and update of a route6 object is not different from other objects, as defined in RFC 2725 [2]. Creation rules of a route6 object is replicated here from the corresponding rules for route object in RFC 2725 [2] section 9.9. When adding a route6 object, the submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num object and the authentication specified in either a route6 object or if no applicable route6 object is found, then an inet6num object. An addition is submitted with an AS number and IPv6 prefix as its key. If the aut-num object does not exist on a route6 to add, then the addition is rejected. If the aut-num exists then the submission is checked against the applicable maintainers. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route6 objects. The submission must match an applicable maintainer in at least one of these route6 objects for the addition to succeed. If the search for a route6 object fails, then a search is performed for an inet6num object that exactly matches the prefix or for the most specific inet6num that is less specific than the route6 object submission. Having found the aut-num and either a list of route6 objects or an inet6num, the authorization is taken from these objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt-by or mnt-lower attributes are not considered. In the absence of a mnt-routes attribute in a given object, then first mnt-lower attributes are used (only in the case the given object is inet6num object and it is less specific than the route6 object to be added), and if no applicable mnt-lower attribute is found, then the mnt-by attributes are used for that object. The authentication must match one of the authorization in each of the two objects. Blunk, et al. Expires January 23, 2004 [Page 14] Internet-Draft RPSLng July 2003 6. Security Considerations This document describes extensions to RFC 2622 [1] and RFC 2725 [2]. The extensions address the limitations of the aforementioned documents with respect to IPv6 and multicast. The extensions do not introduce any new security functionality or threats. While the extensions introduce no additional security threats, it should be noted that the original RFC 2622 [1] RPSL standard included several weak and/or vulnerable authentication mechanisms. First, the "MAIL-FROM" scheme, which can be easily defeated via source email address spoofing. Secondly, the "CRYPT-PW" scheme, which is subject to dictionary attacks and password sniffing if RPSL objects are submitted via unencrypted channels such as email. And finally, the "NONE" mechanism, which offers no protection for objects. Blunk, et al. Expires January 23, 2004 [Page 15] Internet-Draft RPSLng July 2003 7. Acknowledgments The authors wish to thank all the people who have contributed to this document through numerous discussions. Particularly Ekaterina Petrusha for highly valuable discussions and suggestions. Shane Kerr, Engin Gunduz, Mark Blanchet and David Kessens participated constructively in many discussions. Finally, Cengiz Alaettinoglu who is still the reference in all things RPSL. Blunk, et al. Expires January 23, 2004 [Page 16] Internet-Draft RPSLng July 2003 References [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. [2] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999. [3] Damas, J. and A. Robachevski, "RIPE Database Reference Manual", August 2002. Authors' Addresses Larry Blunk Merit Network EMail: ljb@merit.edu Joao Damas Internet Software Consortium EMail: joao@psg.com Florent Parent Viagenie EMail: Florent.Parent@viagenie.qc.ca Andrei Robachevski RIPE NCC EMail: andrei@ripe.net Blunk, et al. Expires January 23, 2004 [Page 17] Internet-Draft RPSLng July 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Blunk, et al. Expires January 23, 2004 [Page 18] Internet-Draft RPSLng July 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Blunk, et al. Expires January 23, 2004 [Page 19]