idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2016) is 2853 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4271' is defined on line 174, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ietf-sidr-route-server-rpki-light-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR P. Mohapatra 3 Internet-Draft Sproute Networks 4 Intended status: Standards Track K. Patel 5 Expires: December 29, 2016 Cisco 6 J. Scudder 7 Juniper Networks 8 D. Ward 9 Cisco 10 R. Bush 11 Internet Initiative Japan, Inc. 12 June 27, 2016 14 BGP Prefix Origin Validation State Extended Community 15 draft-ietf-sidr-origin-validation-signaling-09 17 Abstract 19 This document defines a new BGP opaque extended community to carry 20 the origination AS validation state inside an autonomous system. 21 IBGP speakers that receive this validation state can configure local 22 policies allowing it to influence their decision process. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 29, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Origin Validation State Extended Community . . . . . . . . . 2 61 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 3 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 7.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 This document defines a new BGP opaque extended community to carry 73 the origination AS validation state inside an autonomous system. 74 IBGP speakers that receive this validation state can configure local 75 policies allowing it to influence their decision process. 77 1.1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 2. Origin Validation State Extended Community 85 The origin validation state extended community is an opaque extended 86 community [RFC4360] with the following encoding: 88 0 1 2 3 89 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | 0x43 | 0x00 | Reserved | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Reserved |validationstate| 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 The value of the high-order octet of the extended Type Field is 0x43, 97 which indicates it is non-transitive. The value of the low-order 98 octet of the extended type field as assigned by IANA is 0x00. The 99 Reserved field MUST be set to 0 and ignored upon the receipt of this 100 community. The last octet of the extended community encodes the 101 route's validation state [RFC6811]. It can assume the following 102 values: 104 +-------+-----------------------------+ 105 | Value | Meaning | 106 +-------+-----------------------------+ 107 | 0 | Lookup result = "valid" | 108 | 1 | Lookup result = "not found" | 109 | 2 | Lookup result = "invalid" | 110 +-------+-----------------------------+ 112 If the router is configured to support the extensions defined in this 113 draft, it SHOULD attach the origin validation state extended 114 community to BGP UPDATE messages sent to IBGP peers by mapping the 115 computed validation state in the last octet of the extended 116 community. Similarly on the receiving IBGP speakers, the validation 117 state of an IBGP route SHOULD be derived directly from the last octet 118 of the extended community, if present. 120 An implementation SHOULD NOT send more than one instance of the 121 origin validation state extended community. However, if more than 122 one instance is received, an implementation MUST disregard all 123 instances other than the one with the numerically-greatest validation 124 state value. If the value received is greater than the largest 125 specified value (2), the implementation MUST apply a strategy similar 126 to attribute discard [RFC7606] by discarding the erroneous community 127 and logging the error for further analysis. 129 By default, implementations SHOULD drop the origin validation state 130 extended community if received from an EBGP peer, without further 131 processing it. Similarly, by default an implementation SHOULD NOT 132 send the community to EBGP peers. However it SHOULD be possible to 133 configure an implementation to send or accept the community when 134 warranted. An example of a case where the community would reasonably 135 be received from, or sent to, an EBGP peer is when two adjacent ASes 136 are under control of the same administration. A second example is 137 documented in [I-D.ietf-sidr-route-server-rpki-light]. 139 3. Deployment Considerations 141 In deployment scenarios where not all the speakers in an autonomous 142 system are upgraded to support the extensions defined in this 143 document, it is necessary to define policies that match on the origin 144 validation extended community and set another BGP attribute [RFC6811] 145 that influences the best path selection the same way as what would 146 have been enabled by an implementation of this extension. 148 4. Acknowledgements 150 The authors would like to acknowledge the valuable review and 151 suggestions from Wesley George, Roque Gagliano and Bruno Decraene on 152 this document. 154 5. IANA Considerations 156 IANA has assigned the value 0x00 from the "Non-Transitive Opaque 157 Extended Community Sub-Types" registry. The value is called "BGP 158 Origin Validation State Extended Community". 160 6. Security Considerations 162 This document introduces no new security concerns beyond what is 163 described in [RFC6811]. 165 7. References 167 7.1. Normative References 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, 171 DOI 10.17487/RFC2119, March 1997, 172 . 174 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 175 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 176 DOI 10.17487/RFC4271, January 2006, 177 . 179 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 180 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 181 February 2006, . 183 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 184 Austein, "BGP Prefix Origin Validation", RFC 6811, 185 DOI 10.17487/RFC6811, January 2013, 186 . 188 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 189 Patel, "Revised Error Handling for BGP UPDATE Messages", 190 RFC 7606, DOI 10.17487/RFC7606, August 2015, 191 . 193 7.2. Informative References 195 [I-D.ietf-sidr-route-server-rpki-light] 196 King, T., Kopp, D., Lambrianidis, A., and A. Fenioux, 197 "Signaling Prefix Origin Validation Results from a Route- 198 Server to Peers", draft-ietf-sidr-route-server-rpki- 199 light-00 (work in progress), June 2016. 201 Authors' Addresses 203 Pradosh Mohapatra 204 Sproute Networks 206 Email: mpradosh@yahoo.com 208 Keyur Patel 209 Cisco 210 170 W. Tasman Drive 211 San Jose, CA 95124 213 Email: keyupate@cisco.com 215 John Scudder 216 Juniper Networks 217 1194 N. Mathilda Ave 218 Sunnyvale, CA 94089 220 Email: jgs@juniper.net 222 Dave Ward 223 Cisco 224 170 W. Tasman Drive 225 San Jose, CA 95124 227 Email: dward@cisco.com 229 Randy Bush 230 Internet Initiative Japan, Inc. 231 5147 Crystal Springs 232 Bainbridge Island, Washington 98110 234 Email: randy@psg.com