idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-04.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 (February 14, 2014) is 3724 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: 'RFC6480' is defined on line 183, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 186, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Mohapatra 3 Internet-Draft Sproute Networks 4 Intended status: Standards Track K. Patel 5 Expires: August 18, 2014 Cisco Systems 6 J. Scudder 7 Juniper Networks 8 D. Ward 9 Cisco Systems 10 R. Bush 11 Internet Initiative Japan, Inc. 12 February 14, 2014 14 BGP Prefix Origin Validation State Extended Community 15 draft-ietf-sidr-origin-validation-signaling-04 17 Abstract 19 As part of the origination AS validation process, it can be desirable 20 to automatically consider the validation state of routes in the BGP 21 decision process. The purpose of this document is to provide a 22 specification for doing so. The document also defines a new BGP 23 opaque extended community to carry the validation state inside an 24 autonomous system to influence the decision process of the IBGP 25 speakers. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 63 2. Origin Validation State Extended Community . . . . . . . . . 2 64 3. Changes to the BGP Decision Process . . . . . . . . . . . . . 3 65 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . 3 66 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 72 8.2. Informational References . . . . . . . . . . . . . . . . 4 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 As part of the origination AS validation process, it can be desirable 78 to automatically consider the validation state of routes in the BGP 79 decision process. The purpose of this document is to provide a 80 specification for doing so. The document defines a new BGP opaque 81 extended community to carry the validation state inside an autonomous 82 system to influence the decision process of the IBGP speakers. 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Origin Validation State Extended Community 92 The origin validation state extended community is an opaque extended 93 community [RFC4360] with the following encoding: 95 0 1 2 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | 0x43 | TBD | Reserved | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Reserved |validationstate| 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 The value of the high-order octet of the extended Type Field is 0x43, 104 which indicates it is non-transitive. The value of the low-order 105 octet of the extended type field for this community is TBD. The last 106 octet of the extended community encodes the route's validation 107 state[RFC6811]. It can assume the following values: 109 +-------+-----------------------------+ 110 | Value | Meaning | 111 +-------+-----------------------------+ 112 | 0 | Lookup result = "valid" | 113 | 1 | Lookup result = "not found" | 114 | 2 | Lookup result = "invalid" | 115 +-------+-----------------------------+ 117 If the router is configured to support the extensions defined in this 118 draft, it SHOULD attach the origin validation state extended 119 community to BGP UPDATE messages sent to IBGP peers by mapping the 120 computed validation state in the last octet of the extended 121 community. Similarly on the receiving IBGP speakers, the validation 122 state of an IBGP route SHOULD be derived directly from the last octet 123 of the extended community, if present. 125 3. Changes to the BGP Decision Process 127 If a BGP router supports prefix origin validation and is configured 128 for the extensions defined in this document, the validation step 129 SHOULD be performed prior to any of the steps defined in the decision 130 process of [RFC4271]. The validation step is stated as follows: 132 When comparing a pair of routes for a BGP destination, the route 133 with the lowest "validation state" value is preferred. 135 In all other respects, the decision process remains unchanged. 137 3.1. Policy Control 139 It MUST be possible to enable or disable the validation step as 140 defined in Section 3 through configuration. The default SHOULD be 141 for the validation step to be disabled. 143 4. Deployment Considerations 145 In deployment scenarios where not all the speakers in an autonomous 146 system are upgraded to support the extensions defined in this 147 document, it is necessary to define policies that match on the origin 148 validation extended community and set another BGP attribute [RFC6811] 149 that influences the best path selection the same way as what would 150 have been enabled by an implementation of this extension. 152 5. Acknowledgements 154 The authors would like to acknowledge the valuable review and 155 suggestions from Wesley George and Roque Gagliano on this document. 157 6. IANA Considerations 159 IANA shall assign a new value from the "BGP Opaque Extended 160 Community" type registry from the non-transitive range, to be called 161 "BGP Origin Validation State Extended Community". 163 7. Security Considerations 165 This document introduces no new security concerns beyond what is 166 described in [RFC6811]. 168 8. References 170 8.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 176 Protocol 4 (BGP-4)", RFC 4271, January 2006. 178 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 179 Communities Attribute", RFC 4360, February 2006. 181 8.2. Informational References 183 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 184 Secure Internet Routing", RFC 6480, February 2012. 186 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 187 Origin Authorizations (ROAs)", RFC 6482, February 2012. 189 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 190 Austein, "BGP Prefix Origin Validation", RFC 6811, January 191 2013. 193 Authors' Addresses 195 Pradosh Mohapatra 196 Sproute Networks 198 Email: mpradosh@yahoo.com 200 Keyur Patel 201 Cisco Systems 202 170 W. Tasman Drive 203 San Jose, CA 95134 204 USA 206 Email: keyupate@cisco.com 208 John Scudder 209 Juniper Networks 210 1194 N. Mathilda Ave 211 Sunnyvale, CA 94089 212 USA 214 Email: jgs@juniper.net 216 David Ward 217 Cisco Systems 218 170 W. Tasman Drive 219 San Jose, CA 95134 220 USA 222 Email: dward@cisco.com 224 Randy Bush 225 Internet Initiative Japan, Inc. 226 5147 Crystal Springs 227 Bainbridge Island, Washington 98110 228 USA 230 Email: randy@psg.com