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 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
• 2. Specification of Requirements
• 3. ROA Status Syntax and Semantics
• 4. Security Considerations
• 5. Normative References
• Appendix A. ROA Status Examples
• Appendix B. Acknowledgements
• Author's Address

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:

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 [RFC6483].
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 [RFC3339] 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 [RFC5781] 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 database to verify it's integrity.

5. Normative References

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://.....

     route6: 2001:DB8::/32 
     origin: AS64497
     ...
     roa-status:  v=1; s=valid; m=40; t=2012-12-14T15:44:03Z;
                  u=rsync://.....

     route:  198.51.100.0/24
     origin: AS64498
     ...
     roa-status:  v=1; s=invalid; t=2012-12-14T15:59:42Z;
                  u=rsync://.....

     route:  192.0.2.0/24
     origin: AS64499
     ...
     roa-status:  v=1; s=unknown; t=2012-12-13T08:22:12Z;