idnits 2.17.1 draft-borchert-sidrops-bgpsec-validation-signaling-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '... Reserved field MUST be set to 0 and ...' RFC 2119 keyword, line 127: '... document, it SHOULD attach the BGPs...' RFC 2119 keyword, line 131: '...d on local data, SHOULD derive a valid...' RFC 2119 keyword, line 134: '...n implementation SHOULD NOT send more ...' RFC 2119 keyword, line 136: '..., an implementation MUST disregard all...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 175 has weird spacing: '... to the valid...' -- The document date (March 26, 2019) is 1858 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) == Missing Reference: 'RFC8205' is mentioned on line 178, but not defined == Missing Reference: 'RFC2119' is mentioned on line 92, but not defined == Missing Reference: 'RFC8174' is mentioned on line 92, but not defined == Missing Reference: 'RFC4360' is mentioned on line 100, but not defined == Missing Reference: 'RFC7606' is mentioned on line 140, but not defined == Missing Reference: 'RFC4272' is mentioned on line 171, but not defined == Missing Reference: 'RFC4593' is mentioned on line 174, but not defined == Missing Reference: 'RFC7454' is mentioned on line 186, but not defined == Outdated reference: A later version (-04) exists of draft-borchert-sidrops-bgpsec-state-unverified-00 -- Possible downref: Normative reference to a draft: ref. 'BORCHERT' == Outdated reference: A later version (-02) exists of draft-ietf-sidrops-route-server-rpki-light-01 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) O. Borchert 3 Internet-Draft D. Montgomery 4 Intended status: Standards Track USA NIST 5 Expires: September 27, 2019 March 26, 2019 7 BGPsec Validation State Signaling 8 draft-borchert-sidrops-bgpsec-validation-signaling-00 10 Abstract 12 This document defines a new BGP opaque extended community to carry 13 the BGPsec path validation state inside an autonomous system. 14 Internal BGP (IBGP) speakers that receive this community string can 15 use the embedded BGPsec validation state and configure local policies 16 that allow it being used to influence their decision process. This 17 is specially helpful because (Section 5) of [RFC8205] specifically 18 allows putting BGPsewc path validation temporarily on hold. This 19 would allow to reduce the load of validation especially from IBGP 20 learned routes. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright Notice 45 Copyright (c) 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 63 3. BGPsec Validation State Extended Community . . . . . . . . . . 3 64 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 This document defines a new BGP opaque extended community to carry 76 the BGPsec path validation state inside an autonomous system. 77 Internal BGP (IBGP) speakers that receive this community string can 78 use the embedded BGPsec validation state and configure local policies 79 that allow it being used to influence their decision process. This 80 is specially helpful because (Section 5) of [RFC8205] specifically 81 allows putting BGPsewc path validation temporarily on hold. This 82 would allow to reduce the load of validation especially from IBGP 83 learned routes. 85 1.1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in 90 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2. Suggested Reading 95 It is assumed that the reader understands BGPsec [RFC8205]. 97 3. BGPsec Validation State Extended Community 99 The origin validation state extended community is an opaque extended 100 community [RFC4360] with the following encoding: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | 0x43 | TBD | Reserved | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Reserved |validationstate| 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 The value of the high-order octet of the extended Type field is 0x43, 111 which indicates it is non-transitive. The value of the low-order 112 octet of the extended Type field as assigned by IANA is TBD. The 113 Reserved field MUST be set to 0 and ignored upon the receipt of this 114 community. The last octet of the extended community is an unsigned 115 integer that gives the BGPsec route's validation state [RFC8205] and 116 [BORCHERT]. It can assume the following values: 118 +-------+------------------------------+ 119 | Value | Meaning | 120 +-------+------------------------------+ 121 | 0 | Lookup result = "unverified" | 122 | 1 | Lookup result = "valid" | 123 | 2 | Lookup result = "invalid" | 124 +-------+------------------------------+ 126 If the router is configured to support the extensions defined in this 127 document, it SHOULD attach the BGPsec path validation state extended 128 community to BGP UPDATE messages sent to IBGP peers by mapping the 129 validation state in the last octet of the extended community. 130 Similarly, a receiving BGP speaker, in the absence of a validation 131 state set based on local data, SHOULD derive a validation state from 132 the last octet of the extended community, if present. 134 An implementation SHOULD NOT send more than one instance of the 135 BGPsec path validation state extended community. However, if more 136 than one instance is received, an implementation MUST disregard all 137 instances other than the one with the numerically greatest validation 138 state value. If the value received is greater than the largest 139 specified value (2), the implementation MUST apply a strategy similar 140 to attribute discard [RFC7606] by discarding the erroneous community 141 and logging the error for further analysis. 143 By default, implementations MUST drop the BGPsec validation state 144 extended community if received from an External BGP (EBGP) peer, 145 without processing it further. Similarly, by default, an 146 implementation SHOULD NOT send the community to EBGP peers. However, 147 it SHOULD be possible to configure an implementation to send or 148 accept the community when warranted. An example of a case where the 149 community would reasonably be received from, or sent to, an EBGP peer 150 is when two adjacent ASes are under control of the same 151 administration. A second example is documented in [SIDR-RPKI]. 153 4. Deployment Considerations 155 As specified in (Section 5) of [RFC8205] "a BGPsec speaker MAY 156 temporarily defer validation of incoming BGPsec UPDATE messages. The 157 treatment of such BGPsec UPDATE messages, whose validation has been 158 deferred, is a matter of local policy". Furthermore one can envision 159 that the operator of a BGPsec router decides to defer BGPsec 160 validation learned via IBGP (including a trusted EBGP peer for 161 instance controlled by the same operator as lined out in Section 3) 162 when already validated by the peer. The router then will use the 163 validation result learned via the community string and apply it the 164 the route. In case the peer did send the validation state 165 unverified, the receiving router SHOULD apply the validation state 166 "unverified" and perform BGPsec path validation as described in 167 (section 5.2) of [RFC8205]. 169 5. Security Considerations 171 Security considerations such as those described in [RFC4272] continue 172 to apply. Because this document introduces an extended community 173 that will generally be used to affect route selection, the analysis 174 in Section 4.5 ("Falsification") of [RFC4593] is relevant. These 175 issues are neither new nor unique to the validation extended 176 community. 178 The security considerations provided in [RFC8205] apply equally to 179 this application of BGPsec path validation. In addition, this 180 document describes a scheme where router A outsources validation to 181 some router B. If this scheme is used, the participating routers 182 should have the appropriate trust relationship -- B should trust A 183 either because they are under the same administrative control or for 184 some other reason (for example, consider [SIDR-RPKI]). The security 185 properties of the TCP connection between the two routers should also 186 be considered. See Section 5.1 of [RFC7454] for advice regarding 187 protection of the TCP connection. 189 6. IANA Considerations 191 IANA shall assign a new value from the "BGP Opaque Extended 192 Community" type registry from the non-transitive range, to be called 193 "BGPsec Validation State Extended Community". 195 6. References 197 6.1. Normative References 199 [BORCHERT] Borchert, O., Montgomery, D., "BGPsec Validation State 200 Unverified", draft-borchert-sidr-bgpsec-validation-state- 201 unverified, 204 8.2. Informative References 206 [SIDR-RPKI] King, T., Kopp, D., Lambrianidis, A., and A. Fenioux, 207 "Signaling Prefix Origin Validation Results from a Route- 208 Server to Peers", Work in Progress, 209 draft-ietf-sidrops-route-server-rpki-light-01, January 210 2017. 212 Acknowledgements 214 The authors would like to acknowledge the valuable review and 215 suggestions from K. Sriram on this document. 217 Authors' Addresses 219 Oliver Borchert 220 National Institute of Standards and Technology (NIST) 221 100 Bureau Drive 222 Gaithersburg, MD 20899 223 United States of America 225 Email: oliver.borchert@nist.gov 227 Doug Montgomery 228 National Institute of Standards and Technology (NIST) 229 100 Bureau Drive 230 Gaithersburg, MD 20899 231 United States of America 233 Email: dougm@nist.gov