idnits 2.17.1 draft-white-sobgp-bgp-deployment-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SOBGP-CERTIFICATE], [SOBGP-BGP], [SOBGP-RADIUS], [BGP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7613 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: 'BGP' is mentioned on line 42, but not defined == Missing Reference: 'SOBGP-CERTIFICATE' is mentioned on line 45, but not defined == Missing Reference: 'SOBGP-RADIUS' is mentioned on line 136, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'SOBGP-BGP' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Russ White 3 Internet Draft (editor) 4 Expiration Date: November 2003 Cisco Systems 5 File Name: draft-white-sobgp-bgp-deployment-01.txt June 2003 7 Deployment Considerations for Secure Origin BGP (soBGP) 8 draft-white-sobgp-bgp-deployment-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http//www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http//www.ietf.org/shadow.html. 31 1. Contributors 33 A large number of people contributed to this draft; we've tried to 34 include all of them here (but might have missed a few): James Ng, Tim 35 Gage, Alvaro Retana, Dave Cook, Brian Weiss, and Iljitsch van 36 Beijnum. 38 2. Abstract 40 There is a great deal of concern over the security of routing systems 41 within the Internet, particularly in relation to the Border Gateway 42 Protocol [BGP], which is used to provide routing information between 43 autonomous systems. This draft addresses various deployment scenarios 44 and options using the extensions to BGP outlined in [SOBGP-BGP] in 45 conjunction with [SOBGP-CERTIFICATE] (which is not yet completed or 46 published) and [SOBGP-RADIUS]. Each section of this draft discusses a 47 different deployment situation or deployment option. The final 48 section discusses how private key rollovers can be accomplished with 49 no loss of routing information within soBGP deployments. 51 3. Overview of the Deployment Scenarios 53 Each section below discusses a possible deployment option for soBGP; 54 each could be seen as a separate deployment option, or they could be 55 seen as a set of incremental steps from a very simple soBGP 56 deployment in a small network to a large soBGP deployment across an 57 internetwork. 59 4. Deploying soBGP within Single Devices Along Autonomous System Edges 61 In it's simplest form, soBGP can be deployed entirely within BGP 62 speakers at the edge of an Autonomous System (AS). 64 +-(eBGP)-+ +-(eBGP)-+ 65 | | | | 66 v v v V 68 A--------B-----C-----D--------E 70 ^ ^ 71 | | 72 +--(iBGP)---+ 74 In this network, A is sending all the certificates it has learned 75 from other sources to B using the SECURITY message type. It is 76 passing these certificates to D via iBGP, and D is passing these 77 certificates to E via eBGP. 79 5. Deploying soBGP with Certificate Distribution Within the BGP Protocol 80 and Reflection within an AS 82 A slightly more complex deployment would continue to distribute the 83 certificates through the BGP protocol, using the SECURITY message 84 type outlined in [SOBGP-BGP], but would offload the work of 85 validating the information to a locally reachable server running 86 RADIUS. 88 +--(iBGP)--+ 89 +-(eBGP)-+| |+-(eBGP)-+ 90 | || || | 91 v vv vv V 93 A--------B-----C-----D--------E 94 \ / 95 ^ \ / ^ 96 | \ / | 97 | +-F-+ | 98 | (Server) | 99 | ^ ^ | 100 | | | | 101 (iBGP)-+ +-(iBGP) 103 In this network, A is sending soBGP certificates towards B, along 104 with routing updates and other information. While B is peering 105 through iBGP with D, it is not sending soBGP certificates through 106 this iBGP session; it does not negotiate sending the SECURITY message 107 type to D. B is peering through iBGP to F, a server, but only 108 negotiates carrying the SECURITY message type along this session, so 109 that F only receives soBGP certificates, and no routing updates. F 110 reflects these soBGP certificates to D, which then transmits them to 111 E. 113 It is also possible to bypass the edge routers in distributing the 114 soBGP certificates within the SECURITY message type. 116 +--(iBGP)--+ 117 +-(eBGP)-+| |+-(eBGP)-+ 118 | || || | 119 v vv vv V 121 A--------B-----C-----D--------E 122 \ / 123 ^ \ / ^ 124 | \ / | 125 | +-F-+ | 126 | (Server) | 127 | ^ ^ | 128 | | | | 129 +-----(eBGP)-+ +-(eBGP)-----+ 131 Here, A and B are peering using eBGP, but are only exchanging route 132 information, and not the SECURITY message type. A and F are peering 133 over a multihop eBGP session, and exchanging only the SECURITY 134 message type. B and D no longer have any security information at all; 135 they request information on the validity of any received route from F 136 using the method described in [SOBGP-RADIUS]. 138 Since F is relying only on the interior routing within the local AS 139 to reach the edge of the AS (to reach the link between A and B), the 140 eBGP multihop session is not relying on routes learned from BGP 141 itself to secure BGP. 143 The eBGP session which F is learning from could also be multihop to 144 another soBGP server in an adjacent AS, rather than to an edge 145 router. 147 +-(iBGP)-+ +--(iBGP)--+ 148 | |+-(eBGP)-+| |+-(eBGP)-+ 149 | || || || | 150 v vv vv vv V 152 G---------A--------B-----C-----D--------E 153 | \ / 154 | \ / ^ 155 H \ / | 156 (Server) +-F-+ | 157 ^ (Server) | 158 | ^ ^ | 159 | | | | 160 +---------------(eBGP)-+ +-(eBGP)-----+ 162 Now, H, A, B, C, D, and E are all exchanging NLRI information only, 163 while F and G are exchanging only SECURITY messages. In this case, B 164 must be manually configured to trust the route to G learned from A, 165 and A must be manually configured to trust the route to F learned 166 from B (or they must use static routing, or some sort of temporary 167 acceptance of the learned routes until the SECURITY messages are all 168 exchanged), to prevent the circularity problem mentioned above. This 169 is more complex than the previous deployment options discussed above. 171 6. Multihoming Deployment 173 Multihoming presents a special challenge to the deployment of soBGP 174 within a large scale internetwork. 176 (---------) (---------) 177 ( AS65401 ) ( AS65402 ) 178 ( ) ( ) 179 ( ) ( ) 180 (---A---) (---B---) 181 | | 182 \ / 183 \-----+ +-----/ 184 | | 185 (--C------D--) 186 ( ) 187 ( No AS ) 188 (----------) 190 Assume No AS has obtained a block of addresses, 10.1.1.0/24, from 191 AS65401, and would like to advertise that same block of addresses 192 through AS65402. Since NOAS has no AS number, it cannot generate any 193 soBGP certificates, and must rely on its upstream providers to work 194 out the security impact in some way. The simplest solution would be, 195 of course, for NOAS to obtain an AS number, and fully participate in 196 soBGP, but barring that, what other solutions are there? 198 AS65401 could issue a certificate allowing AS65402 to originate just 199 the prefix in question, 10.1.1.0/24, or AS65401 could simply list 200 AS65402 in the certificate covering 10.1.1.0/24 as an authorized 201 originator for this address space (as multiple authorized originators 202 are allowed). 204 Proxy Advertisement of Certificates 206 Note there is no requirement for a given entity which originates 207 routes into the routing system to actually originate the 208 corresponding certificates required for the correct origination of 209 the route to be validated, and the AS Path attached to the route to 210 be verified. 212 (-----------------) 213 ( Other Third Party ) 214 (---------------) 215 / \ 216 / \ 217 (---------) (---------) 218 ( AS65401 ) ( AS65402 ) 220 ( ) ( ) 221 ( ) ( ) 222 (---A---) (---B---) 223 | | 224 \ / 225 \-----+ +-----/ 226 | | 227 (--C------D--) 228 ( ) 229 ( AS65403 ) 230 (----------) 232 In this case, AS65401, AS65402, or some other third part may actually 233 advertise the certificates necessary for AS65403 to originate 234 validated routes. 236 7. Certificate Generation and Private Key Protection 238 There is only one private/public key pair per entity; certificates 239 are generated as determined by local policy and as required to 240 account for changes in the network. Since the entity's private key is 241 not used in any part of the operations verifying received 242 information, or in generating information to transmit to other 243 devices, these certificates could be generated on some secure central 244 system in the AS, and the results, containing only public keys, can 245 be transmitted throughout the network. 247 Securing the private key of each entity should be relatively easy in 248 this environment, since the location of the private key can be 249 carefully constrained; no device other than the system which 250 generates the required certificates needs use of the private key. 252 8. Impact on Performance and Memory Utilization 254 Very little to no research has been done on the actual performance 255 and memory utilization characterisitics of soBGP as outlined in this 256 and other documents. However, as this is an important area of 257 consideration, we present some suggested analysis below. (In other 258 words, this is a guess). 260 In terms of memory, each device running sobGP will need to store: 262 o Each of the Entitycerts Received. The maximum number of 263 Entitycerts within the routing system would be the number 264 participating autonomous systems multiplied by the number 265 of outstanding Entitycerts from each autonomous system. 267 This will probably be, at most, three Entitycerts per AS, 268 with a current maximum of 65,000 autonomous systems. 270 o Each of the ASPolicycerts (and Their Fragments) Received. 271 The number of ASPolicycerts within the system will probably 272 be similar to the number of Entitycerts within the system, 273 possibly twice as many, given there is only one Policycert 274 valid for any given AS at any time. 276 o Each of the PrefixPolicycerts Received. The number of Pre- 277 fixPolicyCerts within the system will depend on the number 278 of address blocks each participant in the routing system 279 advertises, and will double during key rollover. This could 280 grow to some large number, possibly eight or ten times the 281 number of autonomous systems participating in the routing 282 system. 284 Performance will depend on the amount of cryptographic work required 285 and the amount of validation which is done on each route checked. If 286 all the steps taken in validating the various certificates are taken 287 during network convergence, it would slow down convergence, possibly 288 significantly. 290 However, it is possible to deploy soBGP in various other modes, such 291 as: 293 o Receive and prebuild all information needed to validate incoming 294 routes before any routes are received, so that no cryptographic 295 operations need to take place when receiving routes. 297 o Receive and accept all routes, then receive and build the vali- 298 dation information required to check that the information 299 received was accurate. 301 o Allow some secondary device to perform all cryptographic func- 302 tions, building the validation information needed as convergence 303 is taking place. Check the validity of prefixes after conver- 304 gence has occured. 306 Assuming that some combination of optimizations are used, such as 307 precalculating the authorization data, and performing all validation 308 checks after network convergence has occured. Because there are no 309 cryptographic functions which need to be performed while transmitting 310 routes, we anticipate that there will be very little impact on net- 311 work performance through the adoption of these drafts. 313 9. References 315 [BGP]Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 316 RFC 1771, March 1995. 318 [SOBGP-BGP] 319 Ng J (editor), "Extensions to BGP to Support Secure Origin BGP 320 (soBGP)", Draft-ng-sobgp-deployment-01.doc, November 2002 322 10. Editor's Address 324 Russ White 325 Cisco Systems 326 7025 Kit Creek Road 327 Research Triangle Park, NC 27709 328 riw@cisco.com