draft-ietf-grow-rpki-as-cones-01.txt   draft-ietf-grow-rpki-as-cones-02.txt 
Global Routing Operations J. Snijders Global Routing Operations J. Snijders
Internet-Draft NTT Internet-Draft NTT
Intended status: Informational M. Stucchi Intended status: Informational M. Stucchi
Expires: September 6, 2019 RIPE NCC Expires: October 26, 2020 Independent
March 5, 2019 M. Aelmans
Juniper Networks
April 24, 2020
RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous
Systems Numbers To Facilitate BGP Filtering Systems Numbers To Facilitate BGP Filtering
draft-ietf-grow-rpki-as-cones-01 draft-ietf-grow-rpki-as-cones-02
Abstract Abstract
This document describes a way to define groups of Autonomous System This document describes a way to define groups of Autonomous System
numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide
a mechanism to be used by operators for filtering BGP-4 [RFC4271] a mechanism to be used by operators for filtering BGP-4 [RFC4271]
announcements. announcements.
Requirements Language Requirements Language
skipping to change at page 1, line 43 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2019. This Internet-Draft will expire on October 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Format of AS-Cone objects . . . . . . . . . . . . . . . . . . 3 2. Format of AS-Cone objects . . . . . . . . . . . . . . . . . . 3
2.1. Policy definition object . . . . . . . . . . . . . . . . 3 2.1. Policy definition object . . . . . . . . . . . . . . . . 3
2.1.1. Naming convention for Policy definition objects . . . 3 2.1.1. Naming convention for Policy definition objects . . . 4
2.1.2. ASN.1 format of a Policy Definition object . . . . . 3 2.1.2. ASN.1 format of a Policy Definition object . . . . . 4
2.1.3. Naming convention for neighbour relationships . . . . 4 2.1.3. Naming convention for neighbour relationships . . . . 4
2.2. AS-Cone definition object . . . . . . . . . . . . . . . . 4 2.2. AS-Cone definition object . . . . . . . . . . . . . . . . 5
2.2.1. Naming convention for AS-Cone objects . . . . . . . . 4 2.2.1. Adding entries in an AS-Cone object . . . . . . . . . 5
2.2.2. ASN.1 format of an AS-Cone . . . . . . . . . . . . . 5 2.2.2. Removal of entries from an AS-Cone object . . . . . . 5
3. Validating an AS-Cone . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Naming convention for AS-Cone objects . . . . . . . . 6
4. Recommendations for use of AS-Cones at Internet Exchange 2.2.4. ASN.1 format of an AS-Cone . . . . . . . . . . . . . 6
points . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Validating an AS-Cone . . . . . . . . . . . . . . . . . . . . 6
5. Publication of AS-Cones as IRR objects . . . . . . . . . . . 7 4. Types of validation for AS-Cones . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Recommendations for use of AS-Cones at Internet Exchange
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 points . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Publication of AS-Cones as IRR objects . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The main goal of the Resource Public Key Infrastructure (RPKI) system The main goal of the Resource Public Key Infrastructure (RPKI) system
[RFC6480] is to support improved security for the global routing [RFC6480] is to support improved security for the global routing
system. This is achieved through the use of information stored in a system. This is achieved through the use of information stored in a
distributed repository system comprised of signed objects. A distributed repository system comprised of signed objects. A
commonly used object type is the Route Object Authorisation (ROAs), commonly used object type is the Route Object Authorisation (ROAs),
which describe the prefixes originated by ASNs. which describe the relation between a prefix and its originating
ASNs.
There is however no way for an operator to assert the routes for its There is however no method for an operator to assert the routes for
customer networks, making it difficult to use the information carried its customer networks, making it difficult to use the information
by RPKI to create meaningful BGP-4 filters without relying on RPSL carried by RPKI to create meaningful BGP-4 filters without relying on
[RFC2622] as-sets. RPSL [RFC2622] as-sets.
This memo introduces a new attestation object, called an AS-Cone. An This document introduces a new attestation object, called an AS-Cone.
AS-Cone is a digitally signed object with the goal to enable An AS-Cone is a digitally signed object with the goal to enable
operators to define a set of customers that can be found as "right operators to define a set of customer or downstream ASNs that can be
adjacencies", or transit customer networks, facilitating the found as "right adjacencies", or transit customer networks,
construction of prefix filters for a given ASN, thus making routing facilitating the construction of prefix filters for a given ASN, thus
more secure. making routing more secure.
The goal of AS-Cones is to be able to recursively define all the
originating ASNs that define the customer base of a given ASN,
including all the transit relationships. This means that through AS-
Cones, it is possible to create a tree of all the neighbour
relationships for the customers of a given Autonomous System.
2. Format of AS-Cone objects 2. Format of AS-Cone objects
AS-Cones are composed of two types of distinct objects: AS-Cones are composed of two types of distinct objects:
o Policy definitions; and o Policy definitions; and
o The AS-Cones themselves. o The AS-Cones themselves.
These objects are stored in ASN.1 format and are digitally signed These objects are stored in ASN.1 format and are digitally signed
according to the same rules and conventions applied for RPKI ROA according to the same rules and conventions applied for RPKI ROA
Objects ([RFC6482]). Objects ([RFC6482]).
2.1. Policy definition object 2.1. Policy definition object
A policy definition contains a list the upstream and peering A policy definition object contains a list of the upstream and
relationships for a given Autonomous System that need an AS-Cone to peering relationships for a given Autonomous System that need an AS-
be used for filtering. For each relationship, an AS-Cone is Cone to be used for filtering. For each relationship, either an AS-
referenced to indicate which BGP networks will be announced to the Cone or a plain Autonomous System Number is referenced to indicate
other end of the relationship. which networks will be announced to the other end of the relationship
using BGP.
The default behaviour for a neighbour, if the relationship is not The default behaviour for a neighbour, if the relationship is not
explicitly described in the policy, is to only accept the networks explicitly described in the policy, is to only accept the networks
originated by the ASN. This means that a stub ASN neither has to set originated by the ASN. This means that a stub ASN neither has to set
up any AS-Cone, description, nor policy. up any AS-Cone, description, nor policy.
Only one AS-Cone can be supplied for a given relationship. If more The Policy Definition object contains a field called "ContactEmail"
than one AS-Cone needs to be announced in the relationship, then it containing the E-Mail address for which all the communication related
is mandatory to create a third AS-Cone that includes those two. to this policy definition should be sent to.
Only one AS-Cone or Autonomous System Number can be supplied for a
given relationship. If more than one AS-Cone needs to be announced
in the relationship, then it is mandatory to create a third AS-Cone
that includes those two. If more than one ASN needs to be
referenced, then an AS-Cone for the relationship needs to be created.
2.1.1. Naming convention for Policy definition objects 2.1.1. Naming convention for Policy definition objects
A Policy object is referenced using the Autonomous System number it A Policy object is referenced using the Autonomous System number it
refers to, preceded by the string "AS". refers to, preceded by the string "AS".
2.1.2. ASN.1 format of a Policy Definition object 2.1.2. ASN.1 format of a Policy Definition object
ASNPolicy DEFINITIONS ::= ASNPolicy DEFINITIONS ::=
BEGIN BEGIN
Neighbours ::= SEQUENCE OF Neighbour Neighbours ::= SEQUENCE OF Neighbour
Neighbour ::= SEQUENCE Neighbour ::= SEQUENCE
{ {
ASN INTEGER (1..42949672965), ASN INTEGER (1..42949672965),
ASCone VisibleString ASCone VisibleString
} }
Version ::= INTEGER Version ::= INTEGER
LastModified ::= GeneralizedTime LastModified ::= GeneralizedTime
Created ::= GeneralizedTime Created ::= GeneralizedTime
ContactEmail ::= PrintableString(SIZE (1..75))
END END
ASN.1 format of a Policy definition object ASN.1 format of a Policy definition object
2.1.3. Naming convention for neighbour relationships 2.1.3. Naming convention for neighbour relationships
When referring to a neighbour relationship contained in a Policy When referring to a neighbour relationship contained in a Policy
definition object the following convention should be used: definition object, the following convention should be used:
ASX:ASY ASX:ASY
Where X is the number of the AS holder and Y is the number of the ASN Where X is the number of the ASN holder and Y is the number of the
intended to use the AS-Cone object to generate a filter. ASN intended to use the AS-Cone object to generate a filter.
2.2. AS-Cone definition object 2.2. AS-Cone definition object
An AS-Cone contains a list of the downstream customers and AS-Cones An AS-Cone contains a list of the downstream customer ASNs and AS-
of a given ASN. The list is used to create filter lists by the Cones of a given ASN. The list is used to create filter lists by the
networks providing transit or a peering relationship with the ASN. networks providing transit to or having a peering relationship with
the ASN.
An AS-Cone can reference another AS-Cone if a customer of the An AS-Cone can reference another AS-Cone.
operator also has defined an AS-Cone to be announced upstream.
2.2.1. Naming convention for AS-Cone objects 2.2.1. Adding entries in an AS-Cone object
When an entry is added, it is in the Unverified status, and its
"Verified" variable is set to 0.
If an ASN is added as an entry, it becomes directly visible and
usable in building prefix lists, and a notification is sent to the
E-mail address contained in the "ContactEmail" field of the AS-Cone
Policy Object for that Autonomous System Number. The holder of the
Autonomous System Number can acknowledge the notification, in which
case the "Verified" field is switched to the value of 1.
If an AS-Cone is added to the object, a notification is sent to the
E-Mail address contained in the "ContactEmail" field of the AS-Cone
object that is being added. If the "ContactEmail" field is blank,
the notification is sent to the E-mail address contained in the
"ContactEmail" field of the AS-Cone Policy Object of the ASN of which
the AS-Cone is part of. Only when an acknowledgement from the holder
of the object is obtained, the "Verified" field is changed to a value
of 1, and the AS-Cone becomes visible.
The value of the "Verified" field is fundamental for the creation of
appropriate prefix filtering rules as described later.
2.2.2. Removal of entries from an AS-Cone object
The owner of an AS-Cone can remove any entry from its object without
requesting any permission from the holders of the entries being
removed.
The holder of an entry in a third party AS-Cone can remove the entry
by performing authentication based on the E-mail address contained in
the "ContactEmail" field of the resource itself. The RIRs MUST
provide means to perform this authentication via an auth code, an
API, or other means. The removal of an entry SHOULD be immediate
upon successful authentication.
2.2.3. Naming convention for AS-Cone objects
AS-Cones MUST have a unique name for the ASN they belong to. Names AS-Cones MUST have a unique name for the ASN they belong to. Names
are composed of ASCII strings up to 255 characters long and cannot are composed of ASCII strings up to 255 characters long and cannot
contain spaces. contain spaces.
In order for AS-Cones to be unique in the global routing system, In order for AS-Cones to be unique in the global routing system,
their string name is preceded by the AS number of the ASN they are their string name is preceded by the AS number of the ASN they are
part of, followed by ":". For example, AS-Cone "EuropeanCustomers" part of, followed by ":". For example, AS-Cone "EuropeanCustomers"
for ASN 65530 is represented as "AS65530:EuropeanCustomers" when for ASN 65530 is represented as "AS65530:EuropeanCustomers" when
referenced from a third party. referenced from a third party.
2.2.2. ASN.1 format of an AS-Cone 2.2.4. ASN.1 format of an AS-Cone
ASCone DEFINITIONS ::= ASCone DEFINITIONS ::=
BEGIN BEGIN
Entities ::= SEQUENCE OF Entity Entities ::= SEQUENCE OF Entity
Entity CHOICE Entity CHOICE
{ {
ASN INTEGER (1..4294967295), ASN INTEGER (1..4294967295),
OtherASCone VisibleString OtherASCone VisibleString
Verified ::= BOOLEAN
} }
Version ::= INTEGER Version ::= INTEGER
LastModified ::= GeneralizedTime LastModified ::= GeneralizedTime
Created ::= GeneralizedTime Created ::= GeneralizedTime
ContactEmail ::= PrintableString(SIZE (1..75))
END END
ASN.1 format of an AS-Cone ASN.1 format of an AS-Cone
3. Validating an AS-Cone 3. Validating an AS-Cone
The goal of AS-Cones is to be able to recursively define all the
originating ASNs that define the customer base of a given ASN,
including all the transit relationships. This means that through AS-
Cones, it is possible to create a graph of all the neighbour
relationships for the customers of a given ASN.
In order to validate a full AS-Cone, a network operator MUST have In order to validate a full AS-Cone, a network operator MUST have
access to the validated cache of an RPKI validator software access to the validated cache of an RPKI validator software
containing all the Policy definition and AS-Cone objects. Validation containing all the Policy definition and AS-Cone objects. Validation
occurs following the description in: [RFC6488]. occurs following the description in [RFC6488]:
In order to validate a full AS-Cone, an operator SHOULD perform the In order to validate a full AS-Cone, an operator SHOULD perform the
following steps: following steps:
1. For Every downstream ASN, the operator takes its policy 1. For every downstream ASN, the operator verifies if a related
definition file and collects a list of ASNs for the cone by policy definition (see Section 2.1) file exists. If no object
exists, the status of the AS-Cone is "Unknown". If instead it
exists, it proceeds to collect a list of ASNs for the cone by
looking at the following data, in exact order: looking at the following data, in exact order:
1. A policy for the specific relationship, in the form of 1. A policy for the specific relationship, in the form of
ASX:ASY, where ASX is the downstream ASN, and ASY is the ASN ASX:ASY, where ASX is the downstream ASN, and ASY is the ASN
of the operator validating the AS-Cone; of the operator validating the AS-Cone;
2. If there is no specific definition for the relationship, the 2. If there is no specific definition for the relationship, the
ASX:Default policy; ASX:Default policy;
If none of the two objects above exists, then the operator should If none of the two definitions above exists, then the operator
only consider the ASN of its downstream to be added to the list. should only consider the ASN of its downstream to be added to the
list.
2. These objects can either point to: 2. These objects can either point to:
1. An AS-Cone; or 1. An AS-Cone; or
2. An ASN 2. An ASN
3. If the definition points to an AS-Cone, the operator looks for 3. If the definition points to an AS-Cone, the operator looks for
the object referenced, which should be contained in the validated the object referenced, which should be contained in the validated
cache; cache;
skipping to change at page 6, line 46 skipping to change at page 8, line 8
once to the list. This is intended to avoid endless loops, and once to the list. This is intended to avoid endless loops, and
in order to avoid cross-reference of AS-Cones. in order to avoid cross-reference of AS-Cones.
6. When all the AS-Cones referenced in the policies have been 6. When all the AS-Cones referenced in the policies have been
recursively iterated, and all the originating ASNs have been recursively iterated, and all the originating ASNs have been
taken into account, the operator can then build a full prefix- taken into account, the operator can then build a full prefix-
list with all the prefixes originated in its AS-Cone. This can list with all the prefixes originated in its AS-Cone. This can
be done by querying the RPKI validator software for all the be done by querying the RPKI validator software for all the
networks originated by every ASN referenced in the AS-Cone. networks originated by every ASN referenced in the AS-Cone.
4. Recommendations for use of AS-Cones at Internet Exchange points 4. Types of validation for AS-Cones
AS-Cones can be validated in 4 different ways:
Loose Validation. This is the method described in the procedure
above;
Opportunistic Validation. This is similar to Loose validation,
but it discards all the ASNs for which the "Validated" fields have
a value of 0. The intent is to remove from the prefix list all
the ASNs that haven't validated their entry in the customer cone
for the operator;
Almost-Strict validation. In this method, whenever an entry with
the "Validated" field set to 0 is found, the entire sub-tree (the
AS-Cone) in which it is contained is discarded.
Strict Validation. In this method, only the entries with the
"Validated" field set to 1 are considered. If even a single entry
has a "Validated" field set to 0, the whole AS-Cone is discarded.
It is important to note that no AS-Cone with the "Validated" field
set to 0 is going to be visible at any time, so they are
automatically discarded. This protects AS-Cone holders from being
considered customers of a third party without their consent.
5. Recommendations for use of AS-Cones at Internet Exchange points
When an operator is a member of an internet exchange point, it is When an operator is a member of an internet exchange point, it is
recommended for it to create at least a Default policy. recommended for it to create at least a Default policy.
In case of a peering session with a route server, the operator could In case of a peering session with a route server, the operator could
publish a policy pointing to the ASN of the route server. A route publish a policy pointing to the ASN of the route server. A route
server operator, then, could build strict prefix filtering rules for server operator, then, could build strict prefix filtering rules for
all the participants, and offer it as a service to its members. all the participants, and offer it as a service to its members.
5. Publication of AS-Cones as IRR objects For internet exchange points operators, the recommendation is to use
Strict Filtering as explained in the previous section.
6. Publication of AS-Cones as IRR objects
AS-Cones are very similar to AS-Set RPSL Objects, so they could also AS-Cones are very similar to AS-Set RPSL Objects, so they could also
be published in IRR Databases as AS-Set objects. Every ASN contained be published in IRR Databases as AS-Set objects. Every ASN contained
in an AS-Cone, and all the AS-Cones referenced should be considered in an AS-Cone, and all the AS-Cones referenced should be considered
as member: attributes. The naming convention for AS-Cones (ASX:AS- as member: attributes. The naming convention for AS-Cones (ASX:AS-
Cone) should be maintained, in order to keep consistency between the Cone) should be maintained, in order to keep consistency between the
two databases. two databases.
6. Security Considerations 7. Security Considerations
TBW TBW
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Contributors 9. Contributors
The following people contributed significantly to the content of the The following people contributed significantly to the content of the
document: Greg Skinner. document: Greg Skinner.
9. Acknowledgments 10. Acknowledgments
The authors would like to thank ... The authors would like to thank Randy Bush, Nick Hilliard and Aftab
Siddiqui.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>. <https://www.rfc-editor.org/info/rfc2622>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
skipping to change at page 8, line 30 skipping to change at page 10, line 22
<https://www.rfc-editor.org/info/rfc6482>. <https://www.rfc-editor.org/info/rfc6482>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
NTT Communications NTT Ltd.
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
Email: job@ntt.net Email: job@ntt.net
Massimiliano Stucchi Massimiliano Stucchi
RIPE NCC Independent
Stationsplein, 11
Amsterdam 1012 AB Email: max@stucchi.ch
Melchior Aelmans
Juniper Networks
Boeing Avenue 240
Schiphol-Rijk 1119 PZ
The Netherlands The Netherlands
Email: mstucchi@ripe.net Email: maelmans@juniper.net
 End of changes. 39 change blocks. 
80 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/