< draft-ietf-sidrops-aspa-verification-00.txt   draft-ietf-sidrops-aspa-verification-01.txt >
Network Working Group A. Azimov Network Working Group A. Azimov
Internet-Draft Yandex Internet-Draft Yandex
Intended status: Standards Track E. Bogomazov Intended status: Standards Track E. Bogomazov
Expires: November 18, 2019 Qrator Labs Expires: January 9, 2020 Qrator Labs
R. Bush
Internet Initiative Japan
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
J. Snijders J. Snijders
NTT NTT
May 17, 2019 July 8, 2019
Verification of AS_PATH Using the Resource Certificate Public Key Verification of AS_PATH Using the Resource Certificate Public Key
Infrastructure and Autonomous System Provider Authorization Infrastructure and Autonomous System Provider Authorization
draft-ietf-sidrops-aspa-verification-00 draft-ietf-sidrops-aspa-verification-01
Abstract Abstract
This document defines the semantics of an Autonomous System Provider This document defines the semantics of an Autonomous System Provider
Authorization object in the Resource Public Key Infrastructure to Authorization object in the Resource Public Key Infrastructure to
verify the AS_PATH attribute of routes advertised in the Border verify the AS_PATH attribute of routes advertised in the Border
Gateway Protocol. Gateway Protocol.
Requirements Language Requirements Language
skipping to change at page 1, line 49 skipping to change at page 1, line 47
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 November 18, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3
3. Autonomous System Provider Authorization . . . . . . . . . . 4 3. Autonomous System Provider Authorization . . . . . . . . . . 4
4. Customer-Provider Verification Procedure . . . . . . . . . . 4 4. Customer-Provider Verification Procedure . . . . . . . . . . 4
5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5
6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 6 5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5
7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 6 5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 6
5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 6
6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 7
7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Border Gateway Protocol (BGP) was designed with no mechanisms to The Border Gateway Protocol (BGP) was designed without mechanisms to
validate BGP attributes. Two consequences are BGP Hijacks and BGP validate BGP attributes. Two consequences are BGP Hijacks and BGP
Route Leaks [RFC7908]. BGP extensions are able to partially solve Route Leaks [RFC7908]. BGP extensions are able to partially solve
these problems. For example, ROA-based Origin Validation [RFC6483] these problems. For example, ROA-based Origin Validation [RFC6483]
can be used to detect and filter accidental mis-originations, and can be used to detect and filter accidental mis-originations, and
[I-D.ymbk-idr-bgp-eotr-policy] can be used to detect accidental route [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect
leaks. While these upgrades to BGP are quite useful, they still rely accidental route leaks. While these upgrades to BGP are quite
on transitive BGP attributes, i.e. AS_PATH, that can be manipulated useful, they still rely on transitive BGP attributes, i.e. AS_PATH,
by attackers. that can be manipulated by attackers.
BGPSec [RFC8205] was designed to solve the problem of AS_PATH BGPSec [RFC8205] was designed to solve the problem of AS_PATH
validation. Unfortunately, strict cryptographic validation brought validation. Unfortunately, strict cryptographic validation brought
unaffordable computational overhead for BGP routers. BGPSec also expensive computational overhead for BGP routers. BGPSec also proved
proved to be vulnerable to downgrade attacks that can nullify all the vulnerable to downgrade attacks that nullify the benefits of AS_PATH
work of AS_PATH signing. As a result, to abuse the AS_PATH or any signing. As a result, to abuse the AS_PATH or any other signed
other signed transit attribute, an attacker merely needs to downgrade transit attribute, an attacker merely needs to downgrade to 'old'
to 'old' BGP-4. BGP-4.
An alternative approach was introduced with soBGP An alternative approach was introduced with soBGP
[I-D.white-sobgp-architecture]. Instead of strong cryptographic [I-D.white-sobgp-architecture]. Instead of strong cryptographic
AS_PATH validation, it was suggested to create an AS_PATH security AS_PATH validation, it created an AS_PATH security function based on
function based on a shared database of ASN adjacencies. While such a shared database of ASN adjacencies. While such an approach has
an approach has reasonable computational cost, the two side reasonable computational cost, the two side adjacencies don't provide
adjacencies don't provide a way to automate anomaly detection without a way to automate anomaly detection without high adoption rate - an
high adoption rate - an attacker can easily up a one-way adjacency. attacker can easily create a one-way adjacency. SO-BGP transported
SO-BGP suggested sharing data about adjacencies using additional BGP data about adjacencies in new additional BGP messages, which was
messages, which is recursively complex thus significantly increasing recursively complex thus significantly increasing adoption complexity
adoption complexity. In addition, the general goal to verify all and risk. In addition, the general goal to verify all AS_PATHs was
AS_PATHs was not achievable given the indirect adjacencies at not achievable given the indirect adjacencies at internet exchange
internet exchange points. points.
Instead of the general goal of checking AS_PATH correctness, this Instead of checking AS_PATH correctness, this document focuses on
document focuses on solving real-world operational problems - solving real-world operational problems - automatic detection of
automatic detection of malicious hijacks and route leaks. To achieve malicious hijacks and route leaks. To achieve this a new AS_PATH
this goal a new AS_PATH verification procedure is defined which is verification procedure is defined which is able to automatically
able to automatically detect invalid (malformed) AS_PATHs in detect invalid (malformed) AS_PATHs in announcements that are
announcements that are received from customers and peers. This received from customers and peers. This procedure uses a shared
procedure uses a shared signed database of customer-to-provider signed database of customer-to-provider relationships using a new
relationships that is built using a new RPKI object - Autonomous RPKI object - Autonomous System Provider Authorization (ASPA). This
System Provider Authorization (ASPA). This technique provides technique provides benefits for participants even during early and
benefits for the participants even in a state of early adoption. incremental adoption.
2. Anomaly Propagation 2. Anomaly Propagation
Both route leaks and hijacks have similar effects on ISP operations - Both route leaks and hijacks have similar effects on ISP operations -
they redirect traffic, resulting in increased latency, packet loss, they redirect traffic, resulting in increased latency, packet loss,
or possible MiTM attacks. But the level of risk depends or possible MiTM attacks. But the level of risk depends
significantly on the propagation of these BGP anomalies. For significantly on the propagation of the anomalies. For example, a
example, a hijack that is propagated only to customers may hijack that is propagated only to customers may concentrate traffic
concentrate traffic in a particular ISP's customer cone; while if the in a particular ISP's customer cone; while if the anomaly is
anomaly is propagated through peers, upstreams, or reaches Tier-1 propagated through peers, upstreams, or reaches Tier-1 networks, thus
networks, thus distributing globally, traffic may be redirected at distributing globally, traffic may be redirected at the level of
the level of entire countries and/or global providers. entire countries and/or global providers.
The ability to constrain propagation of BGP anomalies to upstreams The ability to constrain propagation of BGP anomalies to upstreams
and peers, without requiring support from the source of the anomaly and peers, without requiring support from the source of the anomaly
(which is critical if source has malicious intent), should (which is critical if source has malicious intent), should
significantly improve the security of inter-domain routing and solve significantly improve the security of inter-domain routing and solve
the majority of problems. the majority of problems.
3. Autonomous System Provider Authorization 3. Autonomous System Provider Authorization
As described in [RFC6480], the RPKI is based on a hierarchy of As described in [RFC6480], the RPKI is based on a hierarchy of
skipping to change at page 4, line 25 skipping to change at page 4, line 25
with the public key contained in the resource certificate. The RPKI with the public key contained in the resource certificate. The RPKI
is structured so that each current resource certificate matches a is structured so that each current resource certificate matches a
current resource allocation or assignment. current resource allocation or assignment.
ASPAs are digitally signed objects that bind a selected AFI Provider ASPAs are digitally signed objects that bind a selected AFI Provider
AS number to a Customer AS number (in terms of BGP announcements not AS number to a Customer AS number (in terms of BGP announcements not
business), and are signed by the holder of the Customer AS. An ASPA business), and are signed by the holder of the Customer AS. An ASPA
attests that a Customer AS holder (CAS) has authorized a particular attests that a Customer AS holder (CAS) has authorized a particular
Provider AS (PAS) to propagate the Customer's IPv4/IPv6 announcements Provider AS (PAS) to propagate the Customer's IPv4/IPv6 announcements
onward, e.g. to the Provider's upstream providers or peers. The ASPA onward, e.g. to the Provider's upstream providers or peers. The ASPA
record profile is described in [I-D.azimov-sidrops-aspa-profile]. record profile is described in [I-D.ietf-sidrops-aspa-profile].
4. Customer-Provider Verification Procedure 4. Customer-Provider Verification Procedure
This section describes an abstract procedure that checks that pair of This section describes an abstract procedure that checks that pair of
ASNs (AS1, AS2) is included in the set of signed ASPAs. The ASNs (AS1, AS2) is included in the set of signed ASPAs. The
semantics of its usa are defined in next section. The procedure semantics of its usage is defined in next section. The procedure
takes (AS1, AS2, ROUTE_AFI) as input parameters and returns three takes (AS1, AS2, ROUTE_AFI) as input parameters and returns three
types of results: "valid", "invalid" and "unknown". types of results: "valid", "invalid" and "unknown".
A relying party (RP) must have access to a local cache of the A relying party (RP) must have access to a local cache of the
complete set of cryptographically valid ASPAs when performing complete set of cryptographically valid ASPAs when performing
customer-provider verification procedure. customer-provider verification procedure.
1. Retrieve all cryptographically valid ASPAs in a selected AFI with 1. Retrieve all cryptographically valid ASPAs in a selected AFI with
a customer value of AS1. This selection forms the set of a customer value of AS1. This selection forms the set of
"candidate ASPAs." "candidate ASPAs."
skipping to change at page 5, line 14 skipping to change at page 5, line 14
the output of this procedure with input (AS1, AS2, ROUTE_AFI) may the output of this procedure with input (AS1, AS2, ROUTE_AFI) may
have different output for different ROUTE_AFI values. have different output for different ROUTE_AFI values.
5. AS_PATH Verification 5. AS_PATH Verification
The AS_PATH attribute identifies the autonomous systems through which The AS_PATH attribute identifies the autonomous systems through which
an UPDATE message has passed. AS_PATH may contain two types of an UPDATE message has passed. AS_PATH may contain two types of
components: ordered AS_SEQes and unordered AS_SETs, as defined in components: ordered AS_SEQes and unordered AS_SETs, as defined in
[RFC4271]. [RFC4271].
The value of each AS_SEQ component can be described as set of pairs The value of each concatenated value of AS_SEQ components can be
{(AS(I), prepend(I)), (AS(I-1), prepend(I-1))...}. In this case, the described as set of pairs {(AS(I), prepend(I)), (AS(I-1),
sequence {AS(I), AS(I-1),...} represents different ASNs, that packet prepend(I-1))...}. In this case, the sequence {AS(I), AS(I-1),...}
should pass towards the destination. When a route is received from a represents different ASNs, that packet should pass towards the
customer or a literal peer, each pair (AS(I-1), AS(I)) MUST belong to destination.
customer-provider or sibling relationship. If there are other types
of relationships, it means that the route was leaked or the AS_PATH The bellow procedure is applicable only for 32-bit AS number
attribute was malformed. The goal of the above procedure is to check compatible BGP speakers.
5.1. Upstream Paths
When a route is received from a customer, literal peer or by RS at
IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or
sibling relationship. If there are other types of relationships, it
means that the route was leaked or the AS_PATH attribute was
malformed. The goal of the described bellow procedure is to check
the correctness of this statement. the correctness of this statement.
For 32-bit AS number compatible BGP speakers, if a route from If a route from ROUTE_AFI address family is received from a customer,
ROUTE_AFI address family is received from a customer or peer, its peer ot RS-client, its AS_PATH MUST be verified as follows:
AS_PATH MUST be verified as follows:
1. If the closest AS in the AS_PATH is not the receiver's neighbor 1. If the closest AS in the AS_PATH is not the receiver's neighbor
ASN then procedure halts with the outcome "invalid"; ASN then procedure halts with the outcome "invalid";
2. If in one of AS_SEQ segments there is a pair (AS(I-1), AS(I)), 2. If there is a pair (AS(I-1), AS(I)), and customer-provider
and customer-provider verification procedure (Section 4) with verification procedure (Section 4) with parameters (AS(I-1),
parameters (AS(I-1), AS(I), ROUTE_AFI) returns "invalid" then the AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts
procedure also halts with the outcome "invalid"; with the outcome "invalid";
3. If the AS_PATH has at least one AS_SET segment then procedure 3. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "unverifiable"; halts with the outcome "unverifiable";
4. Otherwise, the procedure halts with an outcome of "valid". 4. Otherwise, the procedure halts with an outcome of "valid".
For BGP speakers that are not 32-bit AS compatible, the above 5.2. Downstream Paths
procedure is slightly different. In point 2 if at least one AS(I-1),
AS(I) is equal to AS_TRANS(23456), the corresponding pair must be When route is received from provider or RS it may have both Upstream
passed without check using the customer-provider verification and Downstream paths. The first pair (AS(I-1), AS(I)) that has
procedure. "invalid" outcome of customer-provider verification procedure
indicates the end of Upstream path. All subsequent reverse pairs
(AS(J), AS(J-1)) MUST belong to customer-provider or sibling
relationship, thus can be also verified with ASPA objects. If there
are other types of relationships, it means that the route was leaked.
Additional caution should be done while processing prefixes that are
received from transparent IXes since they don't add their ASN in the
ASPATH.
If a route from ROUTE_AFI address family is received from a customer
or RS, its AS_PATH MUST be verified as follows:
1. If route is received from provider and the closest AS in the
AS_PATH is not the receiver's neighbor ASN then procedure halts
with the outcome "invalid";
2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) where J
> I, and customer-provider verification procedure (Section 4)
returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and
(AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with
the outcome "invalid";
3. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "unverifiable";
4. Otherwise, the procedure halts with an outcome of "valid".
5.3. Mitigation
If the output of the AS_PATH verification procedure is "invalid" the If the output of the AS_PATH verification procedure is "invalid" the
LOCAL_PREF SHOULD be set to 0 or the route MAY be dropped. If an route MUST be rejected.
"invalid" route has no alternative route(s) and it is propagated to
other ASes despite the above, it MUST be marked with the
GRACEFUL_SHUTDOWN community to avoid possible stable oscillations,
when an unchecked route received from a provider becomes preferred
over an invalid route received from a customer. This also allows
customers to detect malformed routes received from upstream
providers.
If the output of the AS_PATH verification procedure is 'unverifiable' If the output of the AS_PATH verification procedure is 'unverifiable'
it means that AS_PATH can't be fully verified. Such routes should be it means that AS_PATH can't be fully checked. Such routes should be
treated with caution and SHOULD be processed the same way as treated with caution and SHOULD be processed the same way as
"invalid" routes. This policy goes with full correspondence to "invalid" routes. This policy goes with full correspondence to
[I-D.kumari-deprecate-as-set-confed-set]. [I-D.kumari-deprecate-as-set-confed-set].
The above AS_PATH verification procedure is able to check routes The above AS_PATH verification procedure is able to check routes
received from customers and peers. The ASPA mechanism combined with received from customers and peers. The ASPA mechanism combined with
BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin
Validation [RFC6483] provide a fully automated solution to detect and Validation [RFC6483] provide a fully automated solution to detect and
filter hijacks and route leaks, including malicious ones. filter hijacks and route leaks, including malicious ones.
skipping to change at page 7, line 7 skipping to change at page 7, line 38
There are peering relationships which can not be described as There are peering relationships which can not be described as
strictly simple peer-peer or customer-provider; e.g. when both strictly simple peer-peer or customer-provider; e.g. when both
parties are intentionally sending prefixes received from each other parties are intentionally sending prefixes received from each other
to their peers and/or upstreams. to their peers and/or upstreams.
In this case, two symmetric ASPAs records {(AS1, AS2), (AS2, AS1)} In this case, two symmetric ASPAs records {(AS1, AS2), (AS2, AS1)}
must be created by AS1 and AS2 respectively. must be created by AS1 and AS2 respectively.
8. Security Considerations 8. Security Considerations
The proposed mechanism is compatible only with BGP implementations
that can process 32-bit ASNs in the ASPATH. This limitation should
not have a real effect on operations - such legacy BGP routers a rare
and it's highly unlikely that they do support integration with RPKI.
ASPA issuers should be aware of the verification implication in ASPA issuers should be aware of the verification implication in
issuing an ASPA - an ASPA implicitly invalidates all routes passed to issuing an ASPA - an ASPA implicitly invalidates all routes passed to
upstream providers other than the provider ASs listed in the upstream providers other than the provider ASs listed in the
collection of ASPAs. It is the Customer AS's duty to maintain a collection of ASPAs. It is the Customer AS's duty to maintain a
correct set of ASPAs. correct set of ASPAs.
While the ASPA provides a check of an AS_PATH for routes received While the ASPA is capable to detect both mistake and malicious
from customers and peers, it doesn't provide full support for routes activity for routes received from customers, RS-clients or peers, it
that are received from upstream providers. So, this mechanism provides only detection of mistakes for routes that are received from
guarantees detection of both malicious and accidental route leaks and upstream providers and RS(s).
provides partial support for detection of malicious hijacks: upstream
transit ISPs will still be able to send hijacked prefixes with Since upstream provider becomes a trusted point, it will be able to
malformed AS_PATHs to their customers. send hijacked prefixes of its customers or send hijacked prefixes
with malformed AS_PATHs back. While it may happen in theory, it's
doesn't seem to be a real scenario: normally customer and provider
have a signed agreement and such policy violation should have legal
consequences or customer can just drop relation with such provider
and remove corresponding ASPA record.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank authors of [RFC6483] since its text was The authors wish to thank authors of [RFC6483] since its text was
used as an example while writing this document. used as an example while writing this document. The also authors
wish to thank Iljitsch van Beijnum for giving a hint about Downstream
paths.
10. References 10. References
10.1. Normative References 10.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>.
[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 10.2. Informative References
[I-D.azimov-sidrops-aspa-profile] [I-D.ietf-grow-route-leak-detection-mitigation]
Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., Sriram, K. and A. Azimov, "Methods for Detection and
and R. Housley, "A Profile for Autonomous System Provider Mitigation of BGP Route Leaks", draft-ietf-grow-route-
Authorization", draft-azimov-sidrops-aspa-profile-00 (work leak-detection-mitigation-00 (work in progress), April
in progress), June 2018. 2019.
[I-D.ietf-idr-bgp-open-policy] [I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention using Roles in Update and Sriram, "Route Leak Prevention using Roles in Update and
Open messages", draft-ietf-idr-bgp-open-policy-02 (work in Open messages", draft-ietf-idr-bgp-open-policy-05 (work in
progress), January 2018. progress), February 2019.
[I-D.ietf-sidrops-aspa-profile]
Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J.,
and R. Housley, "A Profile for Autonomous System Provider
Authorization", draft-ietf-sidrops-aspa-profile-00 (work
in progress), May 2019.
[I-D.kumari-deprecate-as-set-confed-set] [I-D.kumari-deprecate-as-set-confed-set]
Kumari, W. and K. Sriram, "Deprecation of AS_SET and Kumari, W. and K. Sriram, "Deprecation of AS_SET and
AS_CONFED_SET in BGP", draft-kumari-deprecate-as-set- AS_CONFED_SET in BGP", draft-kumari-deprecate-as-set-
confed-set-12 (work in progress), July 2018. confed-set-12 (work in progress), July 2018.
[I-D.white-sobgp-architecture] [I-D.white-sobgp-architecture]
White, R., "Architecture and Deployment Considerations for White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)", draft-white-sobgp- Secure Origin BGP (soBGP)", draft-white-sobgp-
architecture-02 (work in progress), June 2006. architecture-02 (work in progress), June 2006.
[I-D.ymbk-idr-bgp-eotr-policy]
Azimov, A., Bogomazov, E., Bush, R., and K. Patel, "Route
Leak Detection and Filtering using Roles in Update and
Open messages", draft-ymbk-idr-bgp-eotr-policy-02 (work in
progress), March 2018.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[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>.
skipping to change at page 9, line 21 skipping to change at page 10, line 17
Alexander Azimov Alexander Azimov
Yandex Yandex
Email: a.e.azimov@gmail.com Email: a.e.azimov@gmail.com
Eugene Bogomazov Eugene Bogomazov
Qrator Labs Qrator Labs
Email: eb@qrator.net Email: eb@qrator.net
Randy Bush
Internet Initiative Japan
Email: randy@psg.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
 End of changes. 27 change blocks. 
106 lines changed or deleted 142 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/