Internet DRAFT - draft-blunk-rpsl-roa
draft-blunk-rpsl-roa
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 [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
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, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010.
[RFC6483] 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: ljb@merit.edu
Blunk Expires December 16, 2013 [Page 6]
