idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-02.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 (December 8, 2012) is 4156 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 192, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 195, 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 K. Patel 4 Intended status: Standards Track Cisco Systems 5 Expires: June 11, 2013 J. Scudder 6 Juniper Networks 7 D. Ward 8 Cisco Systems 9 R. Bush 10 Internet Initiative Japan, Inc. 11 December 8, 2012 13 BGP Prefix Origin Validation State Extended Community 14 draft-ietf-sidr-origin-validation-signaling-02 16 Abstract 18 As part of the origination AS validation process, it can be desirable 19 to automatically consider the validation state of routes in the BGP 20 decision process. The purpose of this document is to provide a 21 specification for doing so. The document also defines a new BGP 22 opaque extended community to carry the validation state inside an 23 autonomous system to influence the decision process of the IBGP 24 speakers. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 11, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 62 2. Origin Validation State Extended Community . . . . . . . . . . 3 63 3. Changes to the BGP Decision Process . . . . . . . . . . . . . . 4 64 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 71 8.2. Informational References . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 As part of the origination AS validation process, it can be desirable 77 to automatically consider the validation state of routes in the BGP 78 decision process. The purpose of this document is to provide a 79 specification for doing so. The document defines a new BGP opaque 80 extended community to carry the validation state inside an autonomous 81 system to influence the decision process of the IBGP speakers. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Origin Validation State Extended Community 91 The origin validation state extended community is an opaque extended 92 community [RFC4360] with the following encoding: 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | 0x43 | TBD | Reserved | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Reserved |validationstate| 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 The value of the high-order octet of the extended Type Field is 0x43, 103 which indicates it is non-transitive. The value of the low-order 104 octet of the extended type field for this community is TBD. The last 105 octet of the extended community encodes the route's validation 106 state([I-D.ietf-sidr-pfx-validate]. It can assume the following 107 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. Note that routers do not 124 perform prefix origin validation (compute the validation state as 125 defined in [I-D.ietf-sidr-pfx-validate]) for IBGP learnt routes. 127 3. Changes to the BGP Decision Process 129 If a BGP router supports prefix origin validation and is configured 130 for the extensions defined in this document, the validation step MUST 131 be performed prior to any of the steps defined in the decision 132 process of [RFC4271]. The validation step is stated as follows: 134 When comparing a pair of routes for a BGP destination, the route 135 with the lowest "validation state" value is preferred. 137 In all other respects, the decision process remains unchanged. 139 3.1. Policy Control 141 It MUST be possible to enable or disable the validation step as 142 defined in Section 3 through configuration. The default SHOULD be 143 for the validation step to be disabled. 145 4. Deployment Considerations 147 In deployment scenarios where not all the speakers in an autonomous 148 system are upgraded to support the extensions defined in this 149 document, it is necessary to define policies that match on the origin 150 validation extended community and set another BGP attribute 151 [I-D.ietf-sidr-pfx-validate] that influences the best path selection 152 the same way as what would have been enabled by an implementation of 153 this extension. 155 5. Acknowledgements 157 The authors would like to acknowledge the valuable review and 158 suggestions from Wesley George and Roque Gagliano on this document. 160 6. IANA Considerations 162 IANA shall assign a new value from the "BGP Opaque Extended 163 Community" type registry from the non-transitive range, to be called 164 "BGP Origin Validation State Extended Community". 166 7. Security Considerations 168 This document introduces no new security concerns beyond what is 169 described in [I-D.ietf-sidr-pfx-validate]. 171 8. References 173 8.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 179 Protocol 4 (BGP-4)", RFC 4271, January 2006. 181 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 182 Communities Attribute", RFC 4360, February 2006. 184 8.2. Informational References 186 [I-D.ietf-sidr-pfx-validate] 187 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 188 Austein, "BGP Prefix Origin Validation", 189 draft-ietf-sidr-pfx-validate-10 (work in progress), 190 October 2012. 192 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 193 Secure Internet Routing", RFC 6480, February 2012. 195 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 196 Origin Authorizations (ROAs)", RFC 6482, February 2012. 198 Authors' Addresses 200 Pradosh Mohapatra 201 Cisco Systems 202 170 W. Tasman Drive 203 San Jose, CA 95134 204 USA 206 Email: pmohapat@cisco.com 207 Keyur Patel 208 Cisco Systems 209 170 W. Tasman Drive 210 San Jose, CA 95134 211 USA 213 Email: keyupate@cisco.com 215 John Scudder 216 Juniper Networks 217 1194 N. Mathilda Ave 218 Sunnyvale, CA 94089 219 USA 221 Email: jgs@juniper.net 223 David Ward 224 Cisco Systems 225 170 W. Tasman Drive 226 San Jose, CA 95134 227 USA 229 Email: dward@cisco.com 231 Randy Bush 232 Internet Initiative Japan, Inc. 233 5147 Crystal Springs 234 Bainbridge Island, Washington 98110 235 USA 237 Email: randy@psg.com