]> Merit Network

ljb@merit.edu

Operations IETF 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.

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.

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 .

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: Version number of the ROA Status attribute (field "v"). This field is REQUIRED and MUST be set to "1". 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. 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. 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 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. 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 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.

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.

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

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

The following example shows a ROA Status attribute with an invalid status.

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

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;