draft-ietf-grow-irr-routing-policy-considerations-05.txt   draft-ietf-grow-irr-routing-policy-considerations-06.txt 
GROW Working Group D. McPherson GROW Working Group D. McPherson
Internet-Draft Verisign, Inc. Internet-Draft Verisign, Inc.
Intended status: Informational S. Amante Intended status: Informational S. Amante
Expires: February 28, 2015 Level 3 Communications Expires: January 21, 2016 Apple, Inc.
E. Osterweil E. Osterweil
Verisign, Inc. Verisign, Inc.
L. Blunk L. Blunk
Merit Network, Inc. Merit Network, Inc.
D. Mitchell D. Mitchell
Twitter, Inc. Singularity Networks
August 27, 2014 July 20, 2015
IRR & Routing Policy Configuration Considerations IRR & Routing Policy Configuration Considerations
<draft-ietf-grow-irr-routing-policy-considerations-05> <draft-ietf-grow-irr-routing-policy-considerations-06>
Abstract Abstract
The purpose of this document is to catalog past issues influencing The purpose of this document is to catalog past issues influencing
the efficacy of Internet Routing Registries (IRR) for inter-domain the efficacy of Internet Routing Registries (IRR) for inter-domain
routing policy specification and application in the global routing routing policy specification and application in the global routing
system over the past two decades. Additionally, it provides a system over the past two decades. Additionally, it provides a
discussion regarding which of these issues are still problematic in discussion regarding which of these issues are still problematic in
practice, and which are simply artifacts that are no longer practice, and which are simply artifacts that are no longer
applicable but continue to stifle inter-provider policy-based applicable but continue to stifle inter-provider policy-based
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 28, 2015. This Internet-Draft will expire on January 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 4 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 4
4. Accuracy and Integrity of Data Contained within the IRR . . . 5 4. Accuracy and Integrity of Data Contained within the IRR . . . 5
4.1. Lack of Resource Certification . . . . . . . . . . . . . . 5 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 5
4.2. Incentives to Maintain Data within the IRR . . . . . . . . 6 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 6
4.3. Inability for Third Parties to Remove (Stale) 4.3. Inability for Third Parties to Remove (Stale)
Information from the IRRs . . . . . . . . . . . . . . . . 7 Information from the IRRs . . . . . . . . . . . . . . . . 7
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 8 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 8
4.5. Conclusions with respect to Data in the IRR . . . . . . . 9 4.5. Client-Side Considerations . . . . . . . . . . . . . . . . 9
4.6. Conclusions with respect to Data in the IRR . . . . . . . 9
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 9 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 9
5.1. Replication of Resources Among IRRs . . . . . . . . . . . 9 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 9
5.2. Updating Routing Policies from Updated IRR Resources . . . 10 5.2. Updating Routing Policies from Updated IRR Resources . . . 11
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 12 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 12
7. Historical Limitations of Routers . . . . . . . . . . . . . . 13 7. Historical Limitations of Routers . . . . . . . . . . . . . . 14
7.1. Incremental Updates to Policy on Routers . . . . . . . . . 13 7.1. Incremental Updates to Policy on Routers . . . . . . . . . 14
7.2. Storage Requirements for Policy on Routers . . . . . . . . 14 7.2. Storage Requirements for Policy on Routers . . . . . . . . 14
7.3. Updating Configuration on Routers . . . . . . . . . . . . 14 7.3. Updating Configuration on Routers . . . . . . . . . . . . 15
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . . 16 12. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The purpose of this document is to catalog past issues influencing The purpose of this document is to catalog past issues influencing
the efficacy of Internet Routing Registries (IRR) for inter-domain the efficacy of Internet Routing Registries (IRR) for inter-domain
routing policy specification and application in the global routing routing policy specification and application in the global routing
system over the past two decades. Additionally, it provides a system over the past two decades. Additionally, it provides a
discussion regarding which of these issues still pose problems in discussion regarding which of these issues still pose problems in
practice, and which are no longer obstacles, but whose perceived practice, and which are no longer obstacles, but whose perceived
drawbacks continue to stifle inter-provider policy-based filtering drawbacks continue to stifle inter-provider policy-based filtering
skipping to change at page 9, line 5 skipping to change at page 9, line 5
individual IRR operator is under no obligation to mirror all other individual IRR operator is under no obligation to mirror all other
IRRs and, in practice, some IRRs do not mirror the resources from all IRRs and, in practice, some IRRs do not mirror the resources from all
other IRRs. This could lead to the false impression that a other IRRs. This could lead to the false impression that a
particular resource is not registered or maintained at a particular particular resource is not registered or maintained at a particular
IRR. Furthermore, the authentication process of accepting updates by IRR. Furthermore, the authentication process of accepting updates by
any given IRR may, or may not, be robust enough to overcome any given IRR may, or may not, be robust enough to overcome
impersonation attacks. As a result, there is no rigorous assurance impersonation attacks. As a result, there is no rigorous assurance
that a mirrored RPSL statement was actually made by the authorized that a mirrored RPSL statement was actually made by the authorized
resource holder. resource holder.
4.5. Conclusions with respect to Data in the IRR 4.5. Client-Side Considerations
There are no provisions in the IRR mode for ensuring the
confidentiality component for clients issuing queries. The overall
Confidentiality, Integrity, and Availability (CIA) model of the
system does lack this component, because the interface to IRRs is
over an unencrypted TCP connection to port 43. This leaves the
transaction open to inspection such that an adversary could be able
to inspect the query and the response. However, the IRR system is
intended to be composed of public policy information, and protection
of queries was not part of the protection calculus when it was
designed, though the use of Transport Layer Security (TLS) [RFC5246]
would address protections of query information.
4.6. Conclusions with respect to Data in the IRR
All of the aforementioned issues related to integrity and accuracy of All of the aforementioned issues related to integrity and accuracy of
data within the IRR stem from a distinct lack of resource data within the IRR stem from a distinct lack of resource
certification for resources contained within the IRR. Only now is an certification for resources contained within the IRR. Only now is an
experimental test bed that reports to provide this function (under experimental test bed that reports to provide this function (under
the auspices of the Resource PKI [RFC6480]) being formally discussed, the auspices of the Resource PKI [RFC6480]) being formally discussed,
which could also aid in certification of resources within the IRR. which could also aid in certification of resources within the IRR.
It should be noted that the RPKI is only currently able to support It should be noted that the RPKI is only currently able to support
signing of Route Origin Authorization (ROA) resources that are the signing of Route Origin Authorization (ROA) resources that are the
equivalent of 'route' resources in the IRR. It is unclear if, in the equivalent of 'route' resources in the IRR. There has been some
future, the RPKI will be extended to support additional resources sentiment that the RPKI currently is not scoped to address the same
that already exist in the IRR, e.g.: aut-num, as-net, route-set, etc. set of issues and the nuanced policy applications that providers
Finally, a seemingly equivalent resource certification specification leverage in RPSL. It is unclear if, in the future, the RPKI will be
for all resources in the IRR has already been developed [RFC2725], extended to support additional resources that already exist in the
however it is unclear how widely it was ever implemented or deployed. IRR, e.g.: aut-num, as-net, route-set, etc. Finally, a seemingly
equivalent resource certification specification for all resources in
the IRR has already been developed [RFC2725], however it is unclear
how widely it was ever implemented or deployed.
5. Operation of the IRR Infrastructure 5. Operation of the IRR Infrastructure
5.1. Replication of Resources Among IRRs 5.1. Replication of Resources Among IRRs
Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring
(NRTM) protocol to replicate each others contents. However, this (NRTM) protocol to replicate each others contents. However, this
protocol has a several weaknesses. Namely, there is no way to protocol has a several weaknesses. Namely, there is no way to
validate that the copy of mirror is correct and synchronization validate that the copy of mirrored source is correct and
issues have often resulted. Furthermore, the NRTM protocol does not synchronization issues have often resulted. Furthermore, the NRTM
employ any security mechanisms. The NRTM protocol relies on a pull protocol does not employ any security mechanisms. The NRTM protocol
mechanism and is generally configured with a poll interval of 5 to 10 relies on a pull mechanism and is generally configured with a poll
minutes. There is currently no mechanism to notify an IRR when an interval of 5 to 10 minutes. There is currently no mechanism to
update has occurred in a mirrored IRR so that an immediate update can notify an IRR when an update has occurred in a mirrored IRR so that
be made. an immediate update can be made.
Some providers employ a process of mirroring an instance of an IRR Some providers employ a process of mirroring an instance of an IRR
that involves downloading a flat text file copy of the IRR that is that involves downloading a flat text file copy of the IRR that is
made available via FTP. These FTP files are exported at regular made available via FTP [RFC0959]. These FTP files are exported at
intervals of typically anywhere between 2 and 24 hours by the IRRs. regular intervals of typically anywhere between 2 and 24 hours by the
When a provider fetches those text files, it will process them to IRRs. When a provider fetches those text files, it will process them
identify any updates and reflect changes within its own internally to identify any updates and reflect changes within its own internally
maintained database. The use of an internally maintained database is maintained database. The use of an internally maintained database is
out-of-scope of this document, but is generally used to assist with out-of-scope of this document, but is generally used to assist with
more straightforward access to or modification of data by the IRR more straightforward access to or modification of data by the IRR
operator. Providers typically employ a 24 hour cycle to pull updated operator. Providers typically employ a 24 hour cycle to pull updated
resources from IRRs. Thus, depending on when resource holders resources from IRRs. Thus, depending on when resource holders
submitted their changes to an IRR, it may take up to 24 hours for submitted their changes to an IRR, it may take up to 24 hours for
those changes to be reflected in their policy configurations. In those changes to be reflected in their policy configurations. In
practice, it appears that the RPKI will also employ a 24 hour cycle practice, it appears that the RPKI will also employ a 24 hour cycle
whereby changes in resources are pushed out to other RPKI caches whereby changes in resources are pushed out to other RPKI caches
[RPKI_SIZING]. [RPKI_SIZING].
IRRs originated from Section 7 of [RFC1787], specifically: "The scale IRRs originated from Section 7 of [RFC1787], specifically: "The scale
of the Internet implies that the [routing requirements] information of the Internet implies that the [routing requirements] information
should be distributed." Regardless, the practical effect of an should be distributed." Regardless, the practical effect of an
organization maintaining its own local cache of IRR resources is an organization maintaining its own local cache of IRR resources is an
increase in resource resiliency (due to multiple copies of the same increase in resource resiliency (due to multiple copies of the same
resource being geographically distributed), a reduction in query time resource being geographically distributed), a reduction in query time
for resources and, likely, a reduction in inter-domain bandwidth for resources and, likely, a reduction in inter-domain bandwidth
consumption and associated costs. This is particularly beneficial consumption and associated costs. This is particularly beneficial
skipping to change at page 10, line 18 skipping to change at page 10, line 34
of the Internet implies that the [routing requirements] information of the Internet implies that the [routing requirements] information
should be distributed." Regardless, the practical effect of an should be distributed." Regardless, the practical effect of an
organization maintaining its own local cache of IRR resources is an organization maintaining its own local cache of IRR resources is an
increase in resource resiliency (due to multiple copies of the same increase in resource resiliency (due to multiple copies of the same
resource being geographically distributed), a reduction in query time resource being geographically distributed), a reduction in query time
for resources and, likely, a reduction in inter-domain bandwidth for resources and, likely, a reduction in inter-domain bandwidth
consumption and associated costs. This is particularly beneficial consumption and associated costs. This is particularly beneficial
when, for example, an ISP is evaluating resources in an IRR just to when, for example, an ISP is evaluating resources in an IRR just to
determine if there are any modifications to those resources that will determine if there are any modifications to those resources that will
ultimately be reflected in a new routing policy that will get ultimately be reflected in a new routing policy that will get
propagated to (Edge) routers in the ISP's network. Cache locality propagated to (edge) routers in the ISP's network. Cache locality
results in reduced inter-domain bandwidth utilization for each round results in reduced inter-domain bandwidth utilization for each round
trip. trip.
On the other hand, it is unclear from where the current provider On the other hand, it is unclear from where the current provider
replication interval of 24 hours originated or even whether it still replication interval of 24 hours originated or even whether it still
provides enough freshness in the face of available resources, provides enough freshness in the face of available resources,
particularly in today's environment where a typical IRR system particularly in today's environment where a typical IRR system
consists of a (multi-core) multi-GHz CPU connected to a network via a consists of a (multi-core) multi-GHz CPU connected to a network via a
physical connection of 100 Mbps or, more likely, higher bandwidth. physical connection of 100 Mbps or, more likely, higher bandwidth.
In addition, it can be observed that the most common circuit size In addition, increasing bandwidth demands have shifted demand towards
used by ISPs is now 10 Gbps, thus eliminating bandwidth as a circuit sizes used by ISPs to 10 Gbps, thus eliminating bandwidth as
significant factor in the transfer of data between IRRs. a significant factor in the transfer of data between IRRs.
Furthermore, it should be noted that Merit's Internet Routing Furthermore, it should be noted that Merit's Internet Routing
Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default
for "irr_mirror_interval". for "irr_mirror_interval".
Lastly, it should be noted that [RFC2769], Routing Policy System Lastly, it should be noted that [RFC2769], Routing Policy System
Replication, attempted to offer a more methodical solution for Replication, attempted to offer a more methodical solution for
distributed replication of resources between IRRs. It is unclear why distributed replication of resources between IRRs. It is unclear why
this RFC failed to gain traction, but it is suspected that this was this RFC failed to gain traction, but it is suspected that this was
due to that specification's reliance on [RFC2725], Routing Policy due to that specification's reliance on [RFC2725], Routing Policy
System Security, that addressed "the need to assure integrity of the System Security, that addressed "the need to assure integrity of the
data by providing an authentication and authorization model." data by providing an authentication and authorization model."
Indeed, [RFC2725] attempts to add an otherwise absent security model
to the integrity of policy statements made in RPSL. Without formal
protections, it is possible for anyone to author a policy statement
about an arbitrary set of resources, and publish it (as discussed
above in Section Section 4.1.
5.2. Updating Routing Policies from Updated IRR Resources 5.2. Updating Routing Policies from Updated IRR Resources
Ultimately, the length of time it takes to replicate resources among Ultimately, the length of time it takes to replicate resources among
IRRs is, generally, the dominant factor in reflecting changes to IRRs is, generally, the dominant factor in reflecting changes to
resources in policy that is eventually applied within the Control resources in policy that is eventually applied within the Control
Plane of routers. The length of time to update network elements will Plane of routers. The length of time to update network elements will
vary considerably depending on the size of the ISP and the number of vary considerably depending on the size of the ISP and the number of
IRR resources that were updated during any given interval. However, IRR resources that were updated during any given interval. However,
there are a variety of common techniques, that are outside the scope there are a variety of common techniques, that are outside the scope
skipping to change at page 11, line 46 skipping to change at page 12, line 20
maintenance or, more likely, need to rapidly begin announcing a new maintenance or, more likely, need to rapidly begin announcing a new
IP prefix as a result of, for example, an emergency turn-up of the IP prefix as a result of, for example, an emergency turn-up of the
ISP customer's new downstream customer. Unfortunately, the routine, ISP customer's new downstream customer. Unfortunately, the routine,
automated process employed by the ISP means that they may not begin automated process employed by the ISP means that they may not begin
updating their routing policy on their network for up to 24 hours, updating their routing policy on their network for up to 24 hours,
because the ISP or the IRRs the ISP uses might only mirror changes to because the ISP or the IRRs the ISP uses might only mirror changes to
IRR resources once every 24 hours. The time interval for the IRR resources once every 24 hours. The time interval for the
routine/automated process is not responsive to the needs of directly routine/automated process is not responsive to the needs of directly
paying customer(s) who need rapid changes in their policy in rare paying customer(s) who need rapid changes in their policy in rare
situations. In these situations, when a customer has an urgent need situations. In these situations, when a customer has an urgent need
for updates to take affect immediately, they will call up the Network for updates to take effect immediately, they will call the Network
Operations Center (NOC) of their ISP and request that the ISP Operations Center (NOC) of their ISP and request that the ISP
immediately fetch new IRR objects and push those changes out to their immediately fetch new IRR objects and push those changes out to their
network. This is often accomplished in as little as five minutes network. This is often accomplished in as little as five minutes
from the time a customer contacts their ISP's NOC to the time a new from the time a customer contacts their ISP's NOC to the time a new
filtering policy is pushed out to the PE routers that are attached to filtering policy is pushed out to the PE routers that are attached to
that customer's Attachment Circuits (AC's). It is conceivable that that customer's Attachment Circuits (AC's). It is conceivable that
some ISPs automate this using out-of-band mechanisms as well, some ISPs automate this using out-of-band mechanisms as well,
although the authors are unaware of any existing mechanisms that although the authors are unaware of any existing mechanisms that
support this. support this.
Ultimately, the aforementioned latency with respect to "emergency Ultimately, the aforementioned latency with respect to "emergency
changes" in IRR resources that need to be reflected in near-real-time changes" in IRR resources that need to be reflected in near-real-time
in the network is compounded if the IRR resources were being used by in the network is compounded if the IRR resources were being used by
third party ISPs to perform filtering on their peering circuits, third party ISPs to perform filtering on their peering circuits,
where typically no such policies are employed today for this very where typically no such policies are employed today for this very
reason. It is likely that the length of time at which IRRs mirror reason. It is likely that the length of time that it takes IRRs to
changes will have to be dramatically reduced with a corresponding mirror changes will have to be dramatically reduced. There will need
reduction in time at the ISPs that, in turn, need to evaluate whether to be a corresponding reduction in the time needed by ISPs to
changes in a set of IRR resources need to get reflected in updated evaluate whether those changes need to be re-compiled and reflected
router policies that will get pushed out to ASBR's, connected to in router policies, which would then get pushed out to ASBR's and
peering circuits, on their network. connected to peering circuits on their network.
6. Historical BGP Protocol Limitations 6. Historical BGP Protocol Limitations
As mentioned previously, after a resource holder made changes to As mentioned previously, after a resource holder made changes to
their resources in an IRR, those changes would automatically be their resources in an IRR, those changes would automatically be
distributed to other IRRs, ISPs would then learn of those changes, distributed to other IRRs, ISPs would then learn of those changes,
generate a new BGP policies, and then apply those to the appropriate generate a new BGP policies, and then apply those to the appropriate
subset of routers in their ASes. However, in the past, one subset of routers in their ASes. However, in the past, one
additional step is necessary in order to have any of those new BGP additional step is necessary in order to have any of those new BGP
policies take effect in the Control Plane and to allow/deny the policies take effect in the Control Plane and to allow/deny the
skipping to change at page 13, line 14 skipping to change at page 13, line 36
(attached to that customer), it would be propagated to that ISP's (attached to that customer), it would be propagated to that ISP's
ASBR's, attached to peers, at the perimeter of the ISP network. ASBR's, attached to peers, at the perimeter of the ISP network.
Unfortunately, if those peers had either not yet learned of the Unfortunately, if those peers had either not yet learned of the
changes to resources in the IRR or pushed out new BGP policies (and, changes to resources in the IRR or pushed out new BGP policies (and,
reset their BGP sessions immediately afterward) incorporating those reset their BGP sessions immediately afterward) incorporating those
changes, then the newly announced route would also get dropped at the changes, then the newly announced route would also get dropped at the
ingress ASBR's of the peers. ingress ASBR's of the peers.
Ultimately, either of the two scenarios above further lengthen the Ultimately, either of the two scenarios above further lengthen the
effective time it would take for changes in IRR resources to take effective time it would take for changes in IRR resources to take
affect within BGP in the network. Fortunately, BGP has been enhanced effect within BGP in the network. Fortunately, BGP has been enhanced
over the last several years in order that changes within BGP policy over the last several years in order that changes within BGP policy
will take affect without requiring a service impacting reset of BGP will take affect without requiring a service impacting reset of BGP
sessions. Specifically, BGP soft-reconfiguration [REF?] and, later, sessions. Specifically, BGP soft-reconfiguration ([RFC2918] Section
Route Refresh Capability for BGP-4 [RFC2918] were developed so that 1) and, later, Route Refresh Capability for BGP-4 [RFC2918] were
ISPs, or their customers, could induce BGP to apply a new policy developed so that ISPs, or their customers, could induce BGP to apply
while leaving both the existing eBGP session active as well as a new policy while leaving both the existing eBGP session active as
(unaffected) routes active in both the Loc-RIB and, more importantly, well as (unaffected) routes active in both the Loc-RIB and, more
FIB of the router. Thus, using either of these mechanisms, an ISP or importantly, FIB of the router. Thus, using either of these
its peers currently will deploy a newly generated BGP policy, based mechanisms, an ISP or its peers currently will deploy a newly
on changes to resources within the IRR, and immediately trigger a generated BGP policy, based on changes to resources within the IRR,
non-service impacting notification to the BGP process to have those and immediately trigger a non-service impacting notification to the
changes take affect in their Control Plane, either allowing a new IP BGP process to have those changes take effect in their Control Plane,
prefix to be announced or an old IP prefix to be dropped. This either allowing a new IP prefix to be announced or an old IP prefix
dramatically reduces the length of time after changes are propagated to be dropped. This dramatically reduces the length of time after
throughout the IRRs to when those changes are actually operational changes are propagated throughout the IRRs to when those changes are
within BGP policy in an ISP's network. actually operational within BGP policy in an ISP's network.
7. Historical Limitations of Routers 7. Historical Limitations of Routers
7.1. Incremental Updates to Policy on Routers 7.1. Incremental Updates to Policy on Routers
Routers in the mid 1990's rarely supported incrementally updatable Routers in the mid 1990's rarely supported incrementally updatable
prefix filters for BGP, and therefore, if new information was prefix filters for BGP, and therefore, if new information was
received from a policy or internal configuration database that would received from a policy or internal configuration database that would
impact a policy applied to a given eBGP peer, the entire prefix list impact a policy applied to a given eBGP peer, the entire prefix list
or access list would need to be deleted and rewritten, compiled, and or access list would need to be deleted and rewritten, compiled, and
skipping to change at page 14, line 21 skipping to change at page 14, line 42
7.2. Storage Requirements for Policy on Routers 7.2. Storage Requirements for Policy on Routers
Historically, routers had very limited storage capacity and would Historically, routers had very limited storage capacity and would
have difficulty in storing an extremely large BGP policy on-board. have difficulty in storing an extremely large BGP policy on-board.
This was typically the result of router hardware vendors using an This was typically the result of router hardware vendors using an
extremely limited amount of NVRAM for storage of router extremely limited amount of NVRAM for storage of router
configurations. configurations.
Another challenge with historical router hardware was that writing to Another challenge with historical router hardware was that writing to
NVRAM was extremely slow. Thus, when the router configuration had NVRAM was extremely slow. For example, when the router configuration
changed as a result of, for example, updating a BGP policy to had changed as a result of updating a BGP policy that needed to
accommodate changes in IRR resources, this would result in extremely accommodate changes in IRR resources, this would result in extremely
long times to write out these configuration changes and, sometimes, long times to write out these configuration changes. Sometimes, due
due to bugs would result in loss of protocol keep-alives, thus to bugs, this would result in loss of protocol keep-alives. This
causing an impact to routing or forwarding of packets through the would cause an impact to routing or forwarding of packets through the
platform. platform.
The above limitations have largely been resolved with more modern The above limitations have largely been resolved with more modern
equipment from the last few years shipping with increasing amounts of equipment from the last few years shipping with increasing amounts of
non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk
Drives or Solid State Disk Drives. Drives or Solid State Disk Drives.
However, as capacities and technologies have evolved on modern However, as capacities and technologies have evolved on modern
routing hardware, so have the some of the scaling requirements of the routing hardware, so have some of the scaling requirements of the
data. In some large networks, configuration growth has begun to data. In some large networks, configuration growth has begun to
"pose challenges" [IEPG89_NTT]. While the enhancements of hardware "pose challenges" [IEPG89_NTT]. While the enhancements of hardware
have overcome some historical limitations, evidence suggests that have overcome some historical limitations, evidence suggests that
further optimizations in configuration processing may be needed in further optimizations in configuration processing may be needed in
some cases. Some of the more recent operational issues include some cases. Some of the more recent operational issues include
scheduler slips and protracted commit times. This suggests that even scheduler slips and protracted commit times. This suggests that even
though many historical hurdles have been overcome, there are still though many historical hurdles have been overcome, there are still
motivations to optimize and modernize IRR technologies. motivations to optimize and modernize IRR technologies.
7.3. Updating Configuration on Routers 7.3. Updating Configuration on Routers
Historically, there has not been a standardized network configuration Historically, there has not been a standardized network configuration
modeling language or an associated method to update router modeling language or an associated method to update router
configurations. When an ISP detected a change in resources within configurations. When an ISP detected a change in resources within
the IRR, it would fashion a router vendor dependent BGP policy and the IRR, it would fashion a router vendor dependent BGP policy and
upload that to the router usually via the following method. upload that to the router usually via the following method.
First, an updated BGP policy configuration 'snippet' is generated via First, an updated BGP policy configuration 'snippet' is generated via
processes running on an offline server. Next, the operator uses processes running on an out-of-band server. Next, the operator uses
either telnet or SSH to login to the CLI of a target router and issue either telnet or SSH [RFC4253] to login to the CLI of a target router
router vendor dependent CLI commands that will trigger the target and issue router vendor dependent CLI commands that will trigger the
router to fetch the new configuration snippet via TFTP, FTP or Secure target router to fetch the new configuration snippet via TFTP, FTP or
Copy (SCP) stored on the offline server. The target router will then Secure Copy (SCP) stored on the out-of-band server. The target
perform syntax checking on that configuration snippet and, if that router will then perform syntax checking on that configuration
passes, merge that configuration snippet into the running snippet and, if that passes, merge that configuration snippet into
configuration of the router's Control Software. At this point, the the running configuration of the router's Control Software. At this
new BGP policy configuration 'snippet' is active within the Control point, the new BGP policy configuration 'snippet' is active within
Plane of the router. One last step remains, which is the operator the Control Plane of the router. One last step remains, which is the
will issue a CLI command to induce the router to perform a "soft operator will issue a CLI command to induce the router to perform a
reset", via BGP soft-reconfiguration or BGP Route Refresh, of the "soft reset", via BGP soft-reconfiguration or BGP Route Refresh, of
associated BGP session in order to trigger the router to apply the the associated BGP session in order to trigger the router to apply
new policy to routes learned from that BGP session without disrupting the new policy to routes learned from that BGP session without
traffic forwarding. disrupting traffic forwarding.
More recently, operators have the ability to use NETCONF/SSH (or, More recently, operators have the ability to use NETCONF [RFC6241] /
TLS) from an offline server to push a BGP configuration 'snippet' SSH (or, TLS) from an out-of-band server to push a BGP configuration
from an offline server toward a target router that has that 'snippet' from an out-of-band server toward a target router that has
capability. However, this activity is still dependent on generating, that capability. However, this activity is still dependent on
via the offline server, a router vendor dependent XML configuration generating, via the out-of-band server, a router vendor dependent XML
snippet that would get uploaded via SSH or TLS to the target router. configuration snippet that would get uploaded via SSH or TLS to the
target router.
In the future, the ability to upload new Route Origin Authorization In the future, the ability to upload new Route Origin Authorization
(ROA) information may be provided from the RPKI to routers via the (ROA) information may be provided from the RPKI to routers via the
RPKI-RTR [RFC6810] protocol. However, this will not allow operators RPKI-RTR [RFC6810] protocol. However, this will not allow operators
the ability to upload other configuration information such as BGP the ability to upload other configuration information such as BGP
policy information, such as AS_PATH's, BGP communities, etc. that policy information, such as AS_PATH's, BGP communities, etc. that
might be associated with that ROA information, like they can from IRR might be associated with that ROA information, like they can from IRR
generated BGP policies. generated BGP policies.
8. Summary 8. Summary
As discussed above, many of the problems that have historically As discussed above, many of the problems that have traditionally
stifled IRR deployment have, themselves, become historical. However, stifled IRR deployment have, themselves, become historical. However,
there are still real operational considerations that limit IRR usage there are still real operational considerations that limit IRR usage
from realizing its full effectiveness. The potential for IRRs to from realizing its full effectiveness. The potential for IRRs to
express inter-domain routing policy, and to allow relying parties to express inter-domain routing policy, and to allow relying parties to
learn policy, has always positioned it as a strong candidate to aid learn policy, has always positioned it as a strong candidate to aid
the security postures of operators. However, while routing density the security postures of operators. However, while routing density
and complexity have grown, so have some of the challenges facing IRRs and complexity have grown, so have some of the challenges facing IRRs
(even today). Because of this state increase, the potential to model (even today). Because of this state increase, the potential to model
all policies for all ASes in all routers may still remain illusive. all policies for all ASes in all routers may still remain illusive.
In addition, without an operationally deployed resource certification In addition, without an operationally deployed resource certification
framework that can tie policies to resource holders, there is a framework that can tie policies to resource holders, there is a
fundamental limitation that still exists. fundamental limitation that still exists.
9. Security Considerations 9. Security Considerations
One of the central concerns with IRRs is the ability of an IRR One of the central concerns with IRRs is the ability of an IRR
operator to remotely influence the routing operations of an external operator to remotely influence the routing operations of an external
consumer. Specifically, if the processing of IRR contents can become consumer. Specifically, if the processing of IRR contents can become
burdensome, or if the policy statements can be crafted to introduce burdensome, or if the policy statements can be crafted to introduce
routing problems or anomalies, then operators may want to be routing problems or anomalies, then operators may want to be
circumspect about ingesting contents from external parties. However, circumspect about ingesting contents from external parties. A
in regards to routing anomalies, as mentioned in Section 4.1 a
resource certification framework should be used to address the resource certification framework should be used to address the
authorization issues of IRR statements to make attestations and authorization of IRR statements to make attestations and to
assertions. assertions (as mentioned in Section 4.1, and discussed above in
Section Section 5.1).
Additionally, the external and systemic dependencies introduced by Additionally, the external and systemic dependencies introduced by
IRRs and other such systems employed to inform routing policy, and IRRs and other such systems employed to inform routing policy, and
how tightly or loosely coupled those systems are to the global how tightly or loosely coupled those systems are to the global
routing system and operational networks, introduces additional routing system and operational networks, introduces additional
vectors that operators and system architects should consider when vectors that operators and system architects should consider when
evaluating attack surface and service dependencies associated with evaluating attack surface and service dependencies associated with
those elements. These attributes and concerns are certainly not those elements. These attributes and concerns are certainly not
unique to IRRs, and operators should evaluate the implications of unique to IRRs, and operators should evaluate the implications of
external systems and varying degrees of coupling and operational external systems and varying degrees of coupling and operational
buffers that might be installed in their environments. buffers that might be installed in their environments.
10. IANA Considerations 10. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
11. Acknowledgements 11. Acknowledgements
The editors would like to acknowledge and thank Chris Morrow, Jeff The editors would like to acknowledge and thank Chris Morrow, Jeff
Haas, and Wes George for their help and constructive feedback. Haas, Wes George, and John Curran for their help and constructive
feedback.
12. Informative References 12. Informative References
[IEPG89_NTT] [IEPG89_NTT]
"NTT BGP Configuration Size and Scope", IEPG 89 http:// "NTT BGP Configuration Size and Scope", IEPG 89 http://
iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf. iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf.
[IRR_LIST] [IRR_LIST]
Merit Network, Inc., "List of Routing Registries", List of Merit Network, Inc., "List of Routing Registries", List of
Routing Registries http://www.irr.net/docs/list.html. Routing Registries http://www.irr.net/docs/list.html.
skipping to change at page 17, line 12 skipping to change at page 17, line 36
[MERIT-IRRD] [MERIT-IRRD]
Merit, "IRRd - Internet Routing Registry Daemon", Merit, "IRRd - Internet Routing Registry Daemon",
http://www.irrd.net. http://www.irrd.net.
[RC_HotNetsX] [RC_HotNetsX]
Osterweil, E., Amante, S., McPherson, D., and D. Massey, Osterweil, E., Amante, S., McPherson, D., and D. Massey,
"The Great IPv4 Land Grab: Resource Certification for the "The Great IPv4 Land Grab: Resource Certification for the
IPv4 Grey Market", IPv4 Grey Market",
HotNets-X http://dl.acm.org/citation.cfm?id=2070574. HotNets-X http://dl.acm.org/citation.cfm?id=2070574.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://www.rfc-editor.org/info/rfc959>.
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet",
RFC 1787, April 1995. RFC 1787, DOI 10.17487/RFC1787, April 1995,
<http://www.rfc-editor.org/info/rfc1787>.
[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,
June 1999. DOI 10.17487/RFC2622, June 1999,
<http://www.rfc-editor.org/info/rfc2622>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
Murphy, "Routing Policy System Security", RFC 2725, Murphy, "Routing Policy System Security", RFC 2725,
December 1999. DOI 10.17487/RFC2725, December 1999,
<http://www.rfc-editor.org/info/rfc2725>.
[RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D.
Meyer, "Routing Policy System Replication", RFC 2769, Meyer, "Routing Policy System Replication", RFC 2769,
February 2000. DOI 10.17487/RFC2769, February 2000,
<http://www.rfc-editor.org/info/rfc2769>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. DOI 10.17487/RFC2918, September 2000,
<http://www.rfc-editor.org/info/rfc2918>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[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, February 2012. Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013. DOI 10.17487/RFC6810, January 2013,
<http://www.rfc-editor.org/info/rfc6810>.
[RIPE2007-01] [RIPE2007-01]
RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment
Policies and Procedures", Foundation Policies and Procedures", Foundation
Policy http://www.ripe.net/ripe/docs/ripe-452. Policy http://www.ripe.net/ripe/docs/ripe-452.
[RPKI_SIZING] [RPKI_SIZING]
Osterweil, E., Manderson, T., White, R., and D. McPherson, Osterweil, E., Manderson, T., White, R., and D. McPherson,
"Sizing Estimates for a Fully Deployed RPKI", Verisign "Sizing Estimates for a Fully Deployed RPKI", Verisign
Labs Technical Report 1120005 version 2 http:// Labs Technical Report 1120005 version 2 http://
skipping to change at page 18, line 16 skipping to change at page 19, line 19
lookup.cgi?trid=1130009&rev=1. lookup.cgi?trid=1130009&rev=1.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. Verisign, Inc.
Email: dmcpherson@verisign.com Email: dmcpherson@verisign.com
Shane Amante Shane Amante
Level 3 Communications Apple, Inc.
1025 Eldorado Blvd
Broomfield, CO 80021
USA
Email: shane@level3.net
Eric Osterweil Eric Osterweil
Verisign, Inc. Verisign, Inc.
Email: eosterweil@verisign.com Email: eosterweil@verisign.com
Larry J. Blunk Larry J. Blunk
Merit Network, Inc. Merit Network, Inc.
Email: ljb@merit.edu Email: ljb@merit.edu
Dave Mitchell Dave Mitchell
Twitter, Inc. Singularity Networks
Email: dave@twitter.com
 End of changes. 44 change blocks. 
107 lines changed or deleted 151 lines changed or added

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