draft-ietf-idr-bgp-open-policy-01.txt   draft-ietf-idr-bgp-open-policy-02.txt 
Network Working Group A. Azimov Network Working Group A. Azimov
Internet-Draft E. Bogomazov Internet-Draft E. Bogomazov
Intended status: Standards Track Qrator Labs Intended status: Standards Track Qrator Labs
Expires: January 4, 2018 R. Bush Expires: July 5, 2018 R. Bush
Internet Initiative Japan Internet Initiative Japan
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
K. Sriram K. Sriram
US NIST US NIST
July 3, 2017 January 1, 2018
Route Leak Prevention using Roles in Update and Open messages Route Leak Prevention using Roles in Update and Open messages
draft-ietf-idr-bgp-open-policy-01 draft-ietf-idr-bgp-open-policy-02
Abstract Abstract
Route Leaks are the propagation of BGP prefixes which violate Route Leaks are the propagation of BGP prefixes which violate
assumptions of BGP topology relationships; e.g. passing a route assumptions of BGP topology relationships; e.g. passing a route
learned from one peer to another peer or to a transit provider, learned from one peer to another peer or to a transit provider,
passing a route learned from one transit provider to another transit passing a route learned from one transit provider to another transit
provider or to a peer. Today, approaches to leak prevention rely on provider or to a peer. Today, approaches to leak prevention rely on
marking routes according to operator configuration options without marking routes according to operator configuration options without
any check that the configuration corresponds to that of the BGP any check that the configuration corresponds to that of the BGP
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 January 4, 2018. This Internet-Draft will expire on July 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 5, line 8 skipping to change at page 5, line 8
o Type - <TBD1>; o Type - <TBD1>;
o Length - 1 (octet); o Length - 1 (octet);
o Value - integer corresponding to speaker' BGP Role. o Value - integer corresponding to speaker' BGP Role.
+--------+----------------------+ +--------+----------------------+
| Value | Role name | | Value | Role name |
+--------+----------------------+ +--------+----------------------+
| 0 | Undefined | | 0 | Sender is Peer |
| 1 | Sender is Peer | | 1 | Sender is Provider |
| 2 | Sender is Provider | | 2 | Sender is Customer |
| 3 | Sender is Customer | | 3 | Sender is Internal |
| 4 | Sender is Internal |
+--------+----------------------+ +--------+----------------------+
Table 1: Predefined BGP Role Values Table 1: Predefined BGP Role Values
6. Role correctness 6. Role correctness
Section 4 described how BGP Role is a reflection of the relationship Section 4 described how BGP Role is a reflection of the relationship
between two BGP speakers. But the mere presence of BGP Role doesn't between two BGP speakers. But the mere presence of BGP Role doesn't
automatically guarantee role agreement between two BGP peers. automatically guarantee role agreement between two BGP peers.
skipping to change at page 5, line 44 skipping to change at page 5, line 43
| Sender Role | Receiver Role | | Sender Role | Receiver Role |
+--------------+----------------+ +--------------+----------------+
| Peer | Peer | | Peer | Peer |
| Provider | Customer | | Provider | Customer |
| Customer | Provider | | Customer | Provider |
| Internal | Internal | | Internal | Internal |
+--------------+----------------+ +--------------+----------------+
Table 2: Allowed Role Capabilities Table 2: Allowed Role Capabilities
In all other cases speaker MUST send a Role Mismatch Notification In case of any other pair of roles, speaker MUST send a Role Mismatch
(code 2, sub-code <TBD2>). Notification (code 2, sub-code <TBD2>).
6.1. Strict mode 6.1. Strict mode
A new BGP configuration option "strict mode" is defined with values A new BGP configuration option "strict mode" is defined with values
of true or false. If set to true, then the speaker MUST refuse to of true or false. If set to true, then the speaker MUST refuse to
establish a BGP session with peers which do not announce the BGP Role establish a BGP session with peers which do not announce the BGP Role
capability in their OPEN message. If a speaker rejects a connection, capability in their OPEN message. If a speaker rejects a connection,
it MUST send a Connection Rejected Notification [RFC4486] it MUST send a Connection Rejected Notification [RFC4486]
(Notification with error code 6, subcode 5). By default strict mode (Notification with error code 6, subcode 5). By default strict mode
SHOULD be set to false for backward compatibility with BGP speakers, SHOULD be set to false for backward compatibility with BGP speakers,
skipping to change at page 8, line 30 skipping to change at page 8, line 28
The authors wish to thank Douglas Montgomery, Brian Dickson, Andrei The authors wish to thank Douglas Montgomery, Brian Dickson, Andrei
Robachevsky and Daniel Ginsburg for their contributions to a variant Robachevsky and Daniel Ginsburg for their contributions to a variant
of this work. of this work.
14. References 14. References
14.1. Normative References 14.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-
<http://www.rfc-editor.org/info/rfc2119>. 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-
<http://www.rfc-editor.org/info/rfc4271>. editor.org/info/rfc4271>.
[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease
Notification Message", RFC 4486, DOI 10.17487/RFC4486, Notification Message", RFC 4486, DOI 10.17487/RFC4486,
April 2006, <http://www.rfc-editor.org/info/rfc4486>. April 2006, <https://www.rfc-editor.org/info/rfc4486>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>. 2009, <https://www.rfc-editor.org/info/rfc5492>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-grow-bgp-reject] [I-D.ietf-grow-bgp-reject]
Mauch, J., Snijders, J., and G. Hankins, "Default EBGP Mauch, J., Snijders, J., and G. Hankins, "Default EBGP
Route Propagation Behavior Without Policies", draft-ietf- Route Propagation Behavior Without Policies", draft-ietf-
grow-bgp-reject-08 (work in progress), May 2017. grow-bgp-reject-08 (work in progress), May 2017.
[I-D.ietf-grow-route-leak-problem-definition] [I-D.ietf-grow-route-leak-problem-definition]
Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
skipping to change at page 9, line 24 skipping to change at page 9, line 24
Route Leaks", draft-ietf-idr-route-leak-detection- Route Leaks", draft-ietf-idr-route-leak-detection-
mitigation-03 (work in progress), May 2016. mitigation-03 (work in progress), May 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-15 (work Specification", draft-ietf-sidr-bgpsec-protocol-15 (work
in progress), March 2016. in progress), March 2016.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
Authors' Addresses Authors' Addresses
Alexander Azimov Alexander Azimov
Qrator Labs Qrator Labs
Email: aa@qrator.net Email: aa@qrator.net
Eugene Bogomazov Eugene Bogomazov
Qrator Labs Qrator Labs
 End of changes. 12 change blocks. 
20 lines changed or deleted 19 lines changed or added

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