A ROA Status Attribute for RPSL Objects
Author(s): Larry Blunk
This document describes an attribute for Routing Policy Specification Language (RPSL) route and route6 objects that documents the presence and validity of a Route Origin Authorization (ROA) for the given prefix and origin values contained within the object....
IETF L. Blunk Internet-Draft Merit Network Intended status: Informational June 14, 2013 Expires: December 16, 2013 A ROA Status Attribute for RPSL Objects draft-blunk-rpsl-roa-01.txt Abstract This document describes an attribute for Routing Policy Specification Language (RPSL) route and route6 objects that documents the presence and validity of a Route Origin Authorization (ROA) for the given prefix and origin values contained within the object. It allows parties who employ Internet Routing Registries (IRR's) for routing policy configuration generation to easily ascertain whether a given object has a ROA covering the object. The primary objective is to enable existing IRR tools to make use of the ROA information with minimal modifications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 16, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Blunk Expires December 16, 2013 [Page 1] Internet-Draft RPSL ROA Status June 2013 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 3. ROA Status Syntax and Semantics . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. ROA Status Examples . . . . . . . . . . . . . . . . . 5 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Blunk Expires December 16, 2013 [Page 2] Internet-Draft RPSL ROA Status June 2013 1. Introduction Objects stored in Internet Routing Registries are used by a number of Internet Providers to generate router configurations. The tools they employ are based upon the RPSL format. The IETF work within the SIDR Working Group will likely require extensive modifications to these existing tools in order to support new standards such as the ROA which provides equivalent functionality to the RPSL route and route6 objects. However, the RPSL standard provides a number of capabilities and object types which do not yet have functional equivalents defined within the SIDR Working Group. Examples include RPSL objects such as aut-num's, as-set's, and route-set's. It is likely that Internet Providers will wish to continue to use the RPSL standard for some time, while potentially leveraging the work that is being done in the SIDR Working Group to improve the security and robustness of the RPSL information that is present in IRR's. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. ROA Status Syntax and Semantics The ROA Status attribute is named "roa-status" (case insensitive) and is a generated attribute. An IRR user MUST NOT be permitted to submit an object with the ROA Status attribute already present. It is dependent on the routing registry service to securely verify the ROA Status and generate the attribute for a given route or route6 object. Further, the ROA Status of an object must be periodically re-checked after initial generation. It is RECOMMENDED that the ROA Status attribute be regenerated at least once per day. The ROA Status attribute consists of multiple fields. These fields are structured in a sequence of name and value pairs, separated by a semicolon ";" and a white space. Collectively, these fields make up the value of the ROA Status attribute. The "name" part of such a component is always a single ASCII character that serves as an identifier; the value is an ASCII string the contents of which depend on the field type. Fields of the ROA Status attribute: Blunk Expires December 16, 2013 [Page 3] Internet-Draft RPSL ROA Status June 2013 1. Version number of the ROA Status attribute (field "v"). This field is REQUIRED and MUST be set to "1". 2. The ROA validity status (field "s") of the prefix and origin pair given in the route or route6 object. This field is REQUIRED and MUST contain one of three possible values -- "valid", "invalid", or "unknown". These possible three values reflect the "validity state" of the prefix/origin pair following RFC 6483 [RFC 6483]. 3. ROA Max length (field "m"). For objects with a "valid" ROA Status, this fields contains the value of maxLength in the ROA covering the prefix in the route or route6 object, if present. If the covering ROA does not contain a maxLength value, this field MUST be omitted. 4. Time ROA cache last refreshed (field "t"). This field is REQUIRED and represents the last time the ROA cache data used to determine the "status" field value was refreshed. The time is expressed in RFC 3339 [RFC 3339] Internet time format. The timestamp is expected to contain the time of the last successful cache refresh and is used to indicate the freshness of the status check. 5. ROA URI (field "u"). This is an OPTIONAL field which SHOULD be provided upon request. Whois servers may choose to use a query flag as a signal to provide this field in the whois output. The field contains an RFC 5781 [RFC 5781] rsync reference to a ROA. In the case of a "valid" status, the field contains the URI for ROA that was used to validate the prefix/origin pair in the object. For an "invalid" status, the will be at least one, and possibly multiple ROA's, with different origin AS fields which result in the invalid status. In the case of multiple ROA's, there will be multiple "u" fields -- one for each ROA covering the prefix. In the case of an "unknown" status, there are no covering ROA's and this field is omitted. 4. Security Considerations RPSL objects stored in the IRR databases are public, and as such there is no need for confidentiality. Applications may wish to validate the referenced ROA in the ROA-URI field for objects with a "valid" ROA Status. IRR objects are traditionally retrieved by the insecure whois TCP protocol and objects may be subject to modification or deletion while in transit. IRR operators may want to pursue more secure protocols for query interfaces such as SSL. Additionally, IRR operators that provide their database in a bulk format for download may wish to provide a digital signature for the Blunk Expires December 16, 2013 [Page 4] Internet-Draft RPSL ROA Status June 2013 database to verify it's integrity. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC 3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC 5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010. [RFC 6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012. Appendix A. ROA Status Examples The following example shows a ROA Status attribute with a valid status and no maxLength value. route: 203.0.113.0/24 origin: AS64496 ... roa-status: v=1; s=valid; t=2012-12-14T14:38:00Z; u=rsync://..... Figure 1: ROA Status Example 1 The following example shows a route6 object with a valid ROA Status. The covering ROA has a maxLength value of 40. route6: 2001:DB8::/32 origin: AS64497 ... roa-status: v=1; s=valid; m=40; t=2012-12-14T15:44:03Z; u=rsync://..... Figure 2: ROA Status Example 2 The following example shows a ROA Status attribute with an invalid status. Blunk Expires December 16, 2013 [Page 5] Internet-Draft RPSL ROA Status June 2013 route: 198.51.100.0/24 origin: AS64498 ... roa-status: v=1; s=invalid; t=2012-12-14T15:59:42Z; u=rsync://..... Figure 3: ROA Status Example 3 The following example shows a ROA Status attribute with an unknown status. Note there is no "u" field present as there is no covering ROA. route: 192.0.2.0/24 origin: AS64499 ... roa-status: v=1; s=unknown; t=2012-12-13T08:22:12Z; Figure 4: ROA Status Example 4 Appendix B. Acknowledgements Author's Address Larry Blunk Merit Network Email: firstname.lastname@example.org Blunk Expires December 16, 2013 [Page 6]