idnits 2.17.1 draft-lonvick-sobgp-radius-04.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 13, 2004) is 7378 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) -- Looks like a reference, but probably isn't: 'SPR' on line 181 -- Looks like a reference, but probably isn't: 'SPE' on line 225 -- Looks like a reference, but probably isn't: 'IP4' on line 726 -- Looks like a reference, but probably isn't: 'IP6' on line 726 -- Looks like a reference, but probably isn't: 'AFI' on line 721 -- Looks like a reference, but probably isn't: 'IPV4' on line 329 -- Looks like a reference, but probably isn't: 'IPV6' on line 329 -- Looks like a reference, but probably isn't: 'AS' on line 734 -- Looks like a reference, but probably isn't: 'SN' on line 737 -- Looks like a reference, but probably isn't: 'URL' on line 718 -- Looks like a reference, but probably isn't: 'SgT' on line 729 -- Looks like a reference, but probably isn't: 'Sig' on line 440 -- Looks like a reference, but probably isn't: 'PPO' on line 678 -- Looks like a reference, but probably isn't: 'ECR' on line 479 -- Looks like a reference, but probably isn't: 'ACA' on line 508 -- Looks like a reference, but probably isn't: 'ACR' on line 535 -- Looks like a reference, but probably isn't: 'HDR' on line 705 -- Looks like a reference, but probably isn't: 'SIG' on line 740 == Unused Reference: '5' is defined on line 907, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 916, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 920, but no explicit reference was found in the text -- No information found for draft-white-sobgp-bgp-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-02) exists of draft-ng-sobgp-bgp-extensions-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-04) exists of draft-weis-sobgp-certificates-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2858 (ref. '6') (Obsoleted by RFC 4760) ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '7') -- Duplicate reference: RFC2869, mentioned in '8', was also mentioned in '7'. ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '8') ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 3280 (ref. '10') (Obsoleted by RFC 5280) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick 3 Internet-Draft Cisco Systems 4 Expires: August 13, 2004 February 13, 2004 6 RADIUS Attributes for soBGP Support 7 draft-lonvick-sobgp-radius-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 13, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines a set of RADIUS attributes designed to support 38 the provisioning of the soBGP protocol. A router will encapsulate 39 the components of a soBGP certificate into a profile composed of 40 ordered TLVs and transport them to a centralized server capable of 41 verifying the associated signature. The certralized will respond 42 notifying the client of the validity of the signed information. 44 This draft goes along with other IDs submitted for Secure Origin BGP 45 (soBGP) both of which are edited by James Ng and Russ White. 46 draft-white-sobgp-bgp-deployment-01.txt [1], 47 draft-ng-sobgp-bgp-extensions-01.txt [2] Mostly this work relates to 48 "Extensions to BGP to Support Secure Origin BGP (soBGP)" and is 49 explained in additional detail in "Deployment Considerations for 50 Secure Origin BGP (soBGP)". This draft should also be consistent 51 with the formats of the information exchanged in the "Secure Origin 52 BGP (soBGP) Certificates" ID written by Brian Weis. 53 draft-weis-sobgp-bgp-certificates-01.txt [3] 55 The purpose of this draft is to explain the concept of offloading the 56 validation steps of soBGP certificates, Authcerts, PrefixPolicycerts, 57 and ASPolicycerts. RADIUS may not be the best way to do this but it's 58 the best that I know of at this moment. Once the concepts of soBGP 59 are discussed, the transport to support offload should be reviewed 60 and a proper mechanism should be chosen. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1 Stored-Policy . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.1 Stored-Policy-Request . . . . . . . . . . . . . . . . . . 5 68 2.1.2 Stored-Policy-End . . . . . . . . . . . . . . . . . . . . 6 69 2.2 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.2.1 IPv4-Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2.2 IPv6-Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.2.3 AFI/SAFI . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.2.4 Serial Number . . . . . . . . . . . . . . . . . . . . . . 9 74 2.2.5 URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 2.2.6 Signature Type . . . . . . . . . . . . . . . . . . . . . . 10 76 2.2.7 Autonomous System . . . . . . . . . . . . . . . . . . . . 10 77 2.2.8 Signature . . . . . . . . . . . . . . . . . . . . . . . . 10 78 2.2.9 PP Options . . . . . . . . . . . . . . . . . . . . . . . . 11 79 2.2.10 Entitycert Revocation List . . . . . . . . . . . . . . . . 11 80 2.3 Authcert Validation Responses . . . . . . . . . . . . . . 12 81 2.3.1 Authcert-Accept . . . . . . . . . . . . . . . . . . . . . 12 82 2.3.2 Authcert-Reject . . . . . . . . . . . . . . . . . . . . . 12 83 3. Certificate Profiles . . . . . . . . . . . . . . . . . . . 14 84 3.1 soBGP Certificate Validation Request . . . . . . . . . . . 14 85 3.1.1 Cert-Header . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.1.2 Authcert Profile . . . . . . . . . . . . . . . . . . . . . 15 87 3.1.3 PrefixPolicycert Profile . . . . . . . . . . . . . . . . . 16 88 3.1.4 ASPolicycert Profile . . . . . . . . . . . . . . . . . . . 16 89 4. Table of Attributes . . . . . . . . . . . . . . . . . . . 18 90 5. Useage Notes and Examples . . . . . . . . . . . . . . . . 19 91 5.1 Certificate Validation . . . . . . . . . . . . . . . . . . 19 92 5.2 Usernames and Passwords . . . . . . . . . . . . . . . . . 19 93 5.3 Stored Policy . . . . . . . . . . . . . . . . . . . . . . 19 94 5.4 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 5.5 Authcert Verification . . . . . . . . . . . . . . . . . . 20 96 5.6 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . 20 97 6. Security Considerations . . . . . . . . . . . . . . . . . 21 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 22 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 23 100 9. Changes from Prior Drafts . . . . . . . . . . . . . . . . 24 101 References . . . . . . . . . . . . . . . . . . . . . . . . 25 102 Author's Address . . . . . . . . . . . . . . . . . . . . . 25 103 Intellectual Property and Copyright Statements . . . . . . 26 105 1. Introduction 107 A router participating in soBGP will need to validate received 108 Authcerts, PrefixPolicycerts, and ASPolicycerts. Each of these are 109 validated with the Entitycert named within them. The best way to do 110 this is by having their associated Entitycerts contained on the 111 router and using the information stored in them to perform the 112 necessary validation steps. Unfortunately, this would entail the 113 storage and consistent maintenance of Entitycerts on all 114 participating routers in the AS. One way to centralize this would be 115 for a device to store all of the Entitycerts and then have each of 116 the participating routers submit the pertinent information from each 117 received Authcert, PrefixPolicycert and ASPolicycert to it for the 118 computationally intensive validation steps. This centralized device, 119 henceforth to be known as the sob-server in this document, could then 120 transmit a pass/fail message back to the router. This would reduce 121 the amount of administration of the Entitycert database to one device 122 - with appropriate backup. This document defines a set of RADIUS 123 attributes designed to support the provisioning of the soBGP 124 protocol. The participating routers are expected to form and 125 transmit a RADIUS RFC 2865 [4] Access-Request message with the 126 appropriate pieces of information from a received Authcert, 127 PrefixPolicycert or ASPolicycert. This Access-Request will go to the 128 sob-server which will perform the steps necessary to validate the 129 information. It will then form and transmit an Access-Accept or 130 Access-Reject response to the router. 132 Since many components of the soBGP certs are reused, it seems best to 133 define a profile for each of the certs. Section 2 will define the 134 specific TLVs and Section 3 will define the Profiles for the 135 Authcert, PrefixPolicycert, and ASPolicycert. 137 If Brian goes along with the use of "codes" in his ID, then most of 138 the atributes will be expanded to inclue that concept. Until then, 139 the Types will be static. 141 Discussion of this draft may be directed to the author, or to the 142 mailing list discussing soBGP. sobgp@external.cisco.com 144 More information about soBGP may be found on the web page. ftp:// 145 ftp-eng.cisco.com/sobgp/index.html 147 2. Attributes 149 The Attributes are listed in this section. In all cases, each RADIUS 150 message may only include Attributes pertaining to a single AS. There 151 are useage notes later in this document which should answer any 152 questions outstanding from the Attribute section. 154 2.1 Stored-Policy 156 This set of Attributes requests any policy information stored on the 157 sob-server in an Access-Request message, and delivers the policies 158 through Access-Challenge messages using the Prefix set of of 159 Attributes described below. Each Access-Challenge message will 160 describe a policy associated with a single AS. The router will 161 continue requesting more policies through additional Access-Requests. 162 When there are no additional policies stored on the sob-server, or if 163 there were no policies stored there to begin with, then an 164 Access-Accept message with an appropriate attribute will be sent to 165 the router. 167 2.1.1 Stored-Policy-Request 169 A summary of the Stored-Policy-Request Attribute format is shown 170 below. This format will only be used in the Access-Request message 171 The fields are transmitted from left to right. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Length | Value 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Value Continued | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type - [SPR] for Stored-Policy-Request 183 Length - The length of the Attribute; 6 octets. 185 Value - The Value field is four octets. In an Access-Request 186 message, it contains the request number for the available policies 187 stored on the sob-server. The first value will be 0x00000001. If the 188 sob-server responds with a policy (described next), then the router 189 will send a request with a value of 0x00000002. This will continue 190 until the sob-server has no more policies to send. At that point, the 191 sob-server will respond with an Access-Accept message described 192 below. 194 This Attribute is also used in Access-Challenge messages. In that 195 case, the Value is the AS number of the Authorized Originator. This 196 is the autonomous system number of an entity authorized to advertise 197 the associated IPv4 and IPv6 prefixes. 199 2.1.2 Stored-Policy-End 201 A summary of the Stored-Policy-End Attribute format is shown below. 202 This format will only be used in the Access-Accept message. The 203 fields are transmitted from left to right. 205 The Time component in this attribute is needed due to a concern of 206 RADIUS. In soBGP, a peer will be able to send a notification of a 207 change in the status of an Entitycert. Also a participating soBGP 208 router should have the resources to be able to keep track of the 209 expiration times of certificates. This will not be assumed by 210 routers using the plan detailed in this document. For that reason, 211 some communications should occur periodically so the router may 212 ascertain that the status of the certificates has not changed. It 213 would be best if the sob-server were to contact the router, but that 214 is not a property of RADIUS. Therefore, the router SHOULD contact 215 the sob-server periodically. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | Count | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Time | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Type - [SPE] for Stored-Policy-End 227 Length - The length of the Attribute; 8 octets. 229 Count - The Count field is two octets and contains the number of 230 policies that have been transmitted to the router. The router should 231 verify that the value returned in this message is the same value that 232 was most recently transmitted in the associated request message. 234 Time - The Time field is the number of seconds for which the 235 downloaded policies should be considered valid. The receiver is not 236 obligated to honor this timer. A value of 0 is not valid and MUST 237 NOT be used. 239 2.2 Prefixes 241 Multiple instances of each of the attributes defined in this section 242 may be included in a single RADIUS packet. In all cases, each RADIUS 243 message may only include these Attributes pertaining to a single AS. 245 2.2.1 IPv4-Prefix 247 A summary of the IPv4-Prefix Attribute format is shown below. The 248 fields are transmitted from left to right. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Length | Pref-Length | IPv4 Prefix 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 continued ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Type - [IP4] for IPv4-Prefix. 260 Length - The length of this Attribute; >=4. 262 Pref-Length - In accordance with Section 4 of RFC 2858 [6], this is 263 NLRI information. The Pref-Length decribes the lenth of the prefix 264 used. A special value of 0x00 is reserved to indicate that no IPv4 265 address block announcements should be received from the originating 266 AS. 268 IPv4 Prefix - The non-zero octets of the IPv4 Prefix. A special 269 value of 0x0000 is reserved when the Pref-Length is 0x00. When that 270 value is used in an Access-Accept message in response to a 271 Stored-Policy-Request message, this will denote that no IPv4 address 272 block announcements should be received from that originating AS. 273 Consistent with RFC 2858, unused bits after the Pref-Length bits are 274 considered to be meaningless padding. 276 2.2.2 IPv6-Prefix 278 A summary of the IPv6-Prefix Attribute is shown below. The fields 279 are transmitted from left to right. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Pref-Length | IPv6 Prefix.. 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type - [IP6] for IPv6-Prefix 289 Length - The entire length of this message in octets; >=4 290 Pref-Length - The Pref-Length decribes the lenth of the prefix used. 291 A special value of 0x00 is reserved to indicate that no IPv6 address 292 block announcements should be received from the originating AS. 294 IPv6 Prefix - The IPv6 Address Block represented as a prefix. A 295 special value of 0x00 is reserved when the Pref-Length is 0x00. This 296 will denote that no IPv6 address block announcements should be 297 received from that originating AS. Unused bits after the Pref-Length 298 bits are considered to be meaningless padding. 300 2.2.3 AFI/SAFI 302 This Attribute provides the Adress Family Identifier and Subsequent 303 Address Family Identifier. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | AFI | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SAFI | Context | Count | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Type - [AFI] for AFI/SAFI 315 Length - The entire length of this message is 8 octets. 317 AFI - The Address Family Identifier. 319 SAFI - The Subsequent Address Family Identifier. 321 Context - Since this TLV is reused in different manners, this field 322 will denote the context in which it should be interpreted. The 323 following table will lay out the values of Context and Count. 325 Value of Value of Subsequent TLVs 326 Context Count needed to complete 327 the Context. 329 0x00 0x1 Only ONE [IPV4] or [IPV6] 330 0x01 0x1 or more ONE or MORE [AS] 331 0x02 0x1 or more ONE or MORE [AS] 333 A Context of 0x00 denotes a true AFI/SAFI to be used in the Authcert. 334 The Count MUST be 1 and only one IPv4 or IPv6 NLRI value will be 335 accepted after this TLV. 337 A context of 0x01 denotes the Attached Transit Autonomous Systems. 338 The Count must be 1 more more and only that number of AS's will be 339 accepted after this TLV. 341 A context of 0x02 denotes the Attached Non-transit Autonomous 342 Systems. The Count must be 1 or more and only that number of AS's 343 will be accepted after this TLV. 345 2.2.4 Serial Number 347 This Attribute provides the Serial Number used in all of the soBGP 348 certificates. A summary of the Serial Number Attribute is shown 349 below. The fields are transmitted from left to right. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Serial Number 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 continued | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Type - [SN] for Serial Number 361 Length - The entire length of this message is 6 octets. 363 The Serial Number is 4 octets and identifies the cert. 365 2.2.5 URL 367 A summary of the URL Attribute format is given below. The fields are 368 transmitted left to right. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | URL ... 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Type - [URL] for URL 378 Length - The entire length of this message in octets. 380 URL - A uniform resource locator indicating a location where 381 information about a certificate, key, revocation list, etc., may be 382 found. 384 2.2.6 Signature Type 386 A summary of the Signature Type Attribute format is given below. The 387 fields are transmitted left to right. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | Signature Type | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Number of Issuers | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Type - [SgT] for Signature Type 399 Length - The entire length of this message in octets. 401 Signature Type - A two byte unsigned integer denoting the type of 402 signature (the algorithm used to build this signature). Each 403 possible signing algorithm is assigned a value in this field. 405 Number of Issuers - The number of Entitycert references included in 406 the signature payload. If more than one Entitycert reference 407 follows, all Entitycert MUST contain the same public key for the same 408 authorizing autonomous system. 410 2.2.7 Autonomous System 412 A summary of the Autonomous System Attribute format is given below. 413 The fields are transmitted left to right. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length | Autonomous System 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 continued.. | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type - [AS] for Autonomous System 425 Length - The entire length of this message in octets, 6 octets. 427 Autonomous System - the AS number. 429 2.2.8 Signature 431 A summary of the Signature Attribute format is given below. The 432 fields are transmitted left to right. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length | Signature ... 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Type - [Sig] for Signature 442 Length - The entire length of this message in octets, 6 octets. 444 The signature itself. The signature will be as taken from 445 draft-ng-sobgp-extensions-01.txt [2]. The signature is calculated 446 using the private key of the authorizing entity across all TLV values 447 in the profile in their order. 449 2.2.9 PP Options 451 A summary of the PP Options (for PrefixPolicycert) Attribute format 452 is given below. The fields are transmitted left to right. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | Options... 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 continued | SubTVs... 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Type - [PPO] for PP Options 464 Length - The entire length of this message in octets. 466 The ******************* 468 2.2.10 Entitycert Revocation List 470 A summary of the ECR Attribute format is given below. The fields are 471 transmitted left to right. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type | Length | EC Revocation List 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Type - [ECR] for EC Revocation List 480 Length - The entire length of this message in octets. 482 A list of revoked ECs issued by the AS. This must be in the format 483 specified in RFC 3280 [10]. 485 2.3 Authcert Validation Responses 487 The following Attributes will be sent in response to a group of 488 Authcert Validation Request Attributes. The Authcert-Accept 489 Attribute will be sent in an Access-Accept message while the 490 Authcert-Reject Attribute will be sent in an Access-Reject message. 492 2.3.1 Authcert-Accept 494 A summary of the Authcert-Accept Attribute format is shown below. 495 This format will only be used in the Access-Accept message. The 496 fields are transmitted from left to right. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | Authorized Originator 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Continued.. | Time 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Continued.. | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type - [ACA] for Authcert-Accept 510 Length - The length of the attribute; 10 octets. 512 Authorized Originator - The autonomous system number of an entity 513 authorized to advertise the associated IPv4 and IPv6 prefixes. 515 Time - The Time field is the number of seconds for which the 516 downloaded policies should be considered valid. The receiver is not 517 obligated to honor this timer. A value of 0 is not valid and MUST 518 NOT be used. 520 2.3.2 Authcert-Reject 522 A summary of the Authcert-Reject Attribute format is shown below. 523 This format will only be used in the Access-Reject message. The 524 fields are transmitted from left to right. 526 0 1 2 3 527 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type | Length | Authorized Originator | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Continued.. | Reason Code 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Type - [ACR] for Authcert-Reject 537 Length - The length of the attribute; >=7 octets. 539 Authorized Originator - The autonomous system number of an entity 540 authorized to advertise the associated IPv4 and IPv6 prefixes. 542 Reason Code - The reason for the rejection. It may be a local policy 543 decision on the router to accept the information contained in the 544 received Authcert even if it is rejected by the sob-server. As an 545 example of that, if the URL is not found but the Authcert is 546 validated otherwise, the router may choose to accept the information 547 in the Authcert but at a lower trust level than if the signature is 548 valid and the URL is found and properly processed. The table below 549 gives the Reason Codes and their explanations. 551 Reason Code Explanation 552 0-filled Invalid Code - This value MUST NOT be used. 553 0b10000000 No Entitycert found matching this Authorized Originator. 554 0b01000000 Entitycert found for this Authorized Originator but the 555 Serial Number in the Authcert is out of range. 556 0b00100000 The Signature in the Authcert doesn't match the 557 calculated signature. 558 0b000100000 The Entitycert found on the sob-server has expired. 559 0b000010000 The URL could not be found. 561 0b00000nnnn Reserved for future use. 562 0x00nn and beyond are also reserved for future use. 564 3. Certificate Profiles 566 This section defines the possible profiles that may be sent in an 567 Access-Request packet. At the time of this writing, three profiles 568 are defined in the other soBGP works and will be defined here; 569 Authcerts, PrefixPolicycerts, and ASPolicycerts. The profiles will 570 be composed of a header and then will contain Attributes described in 571 Section 2. The format of these profiles MUST be followed explicity 572 as maintaining the order is vital for the signature to be calculated 573 correctly. 575 3.1 soBGP Certificate Validation Request 577 This Attribute requests that the sob-server validate an soBGP 578 certificate received by a router through soBGP. This will first be 579 requested in an Access-Request message with the pertinent information 580 described in the profile. The sob-server will respond with either an 581 Access-Accept or an Access-Reject message with specific information 582 as described below. 584 3.1.1 Cert-Header 586 A summary of the Cert-Header Attribute format is given below. The 587 fields are transmitted left to right. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | Cert Marker | Type ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Type - [HDR] for Authcert-Header 597 Length - The entire length of this message in octets; 4. 599 Cert Marker - 0xa2 (0d162) identifying this as an SoBGP certificate 600 validation request. 602 Type ID - The specific type of soBGP Certificate as identified in the 603 following table. 605 Type ID Value Denotes this type of soBGP Certificate 606 0x01 Authcert 607 0x02 PrefixPolicycert 608 0x03 ASPolicycert 610 3.1.2 Authcert Profile 612 The following profile displays the order and components required to 613 transport an Authcert validation request. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | [HDR] | Length | 0xa2 | 0x01 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | [AS] | AS-Len | Autonomous System... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | [AS] | AS-Len | Autonomous System... 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | [SN] | SN-Len | Serial Number... 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | [URL] | URL-Len | URL ... 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | [URL] | URL-Len | URL ... 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | [AFI] | Length | AFI | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Reserved | SAFI | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | [IP4] or [IP6]| Length | Pref-Length | IP Prefix 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | [SgT] | Length | Signature Type | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Number of Issuers | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | [AS] | AS-Len | Autonomous System... 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | [SN] | SN-Len | Serial Number... 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | [SIG] | Length | Signature ... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 3.1.3 PrefixPolicycert Profile 660 The following profile displays the order and components required to 661 transport an PrefixPolicycert validation request. 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | [HDR] | Length | 0xa2 | 0x02 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | [AS] | AS-Len | Autonomous System... 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | [URL] | URL-Len | URL ... 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 insert Authcert here 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | [PPO] | Length | Options... 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 continued | SubTVs... 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | [SgT] | Length | Signature Type | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Number of Issuers | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | [AS] | AS-Len | Autonomous System... 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | [SN] | SN-Len | Serial Number... 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | [SIG] | Length | Signature ... 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 3.1.4 ASPolicycert Profile 699 The following profile displays the order and components required to 700 transport an AS Policycert validation request. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | [HDR] | Length | 0xa2 | 0x03 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | [AS] | AS-Len | Autonomous System... 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | [SN] | SN-Len | Serial Number... 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | [URL] | URL-Len | URL ... 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | [URL] | URL-Len | URL ... 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | [AFI] | Length | AFI | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Reserved | SAFI | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | [IP4] or [IP6]| Length | Pref-Length | IP Prefix 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | [SgT] | Length | Signature Type | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Number of Issuers | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | [AS] | AS-Len | Autonomous System... 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | [SN] | SN-Len | Serial Number... 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | [SIG] | Length | Signature ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 4. Table of Attributes 745 The following table provides a guide to which of the above 746 attributes may be found in which kinds of packets, and in what 747 quantity. 749 Request Accept Reject Challenge Acct-Request # Attribute 750 0-1 0 0 0-1 0 SPR Stored-Policy-Request 751 0 0-1 0 0 0 SPE Stored-Policy-End 752 0+ 0+ 0 0 0 IP4 IPv4-Prefix 753 0+ 0+ 0 0 0 IP6 IPv6-Prefix 754 0-1 0 0 0 0 HDR AC-Header 755 0-1 0 0 0 0 SN Serial Number 756 0-1 0 0 0 0 URL URL 757 0-1 0 0 0 0 SIG Signature 758 0-1 0-1 0-1 0 0 AS Autonomous System 759 0 0-1 0 0 0 ACA AC-Accept 760 0 0 0-1 0 0 ACR AC-Reject 762 The following table defines the meaning of the above table entries. 764 0 This attribute MUST NOT be present in packet. 765 0+ Zero or more instances of this attribute MAY be present in packet. 766 0-1 Zero or one instance of this attribute MAY be present in packet. 768 5. Useage Notes and Examples 770 This section describes the expected implementation of the ideas 771 presented in this document. 773 5.1 Certificate Validation 775 Any device receiving an Entitycert can verify it by separating its 776 components into appropriate segments and sending them to the 777 sob-server. The sob-server will return either an accept or reject 778 message. 780 Likewise a router may submit a signed AuthCert or PolicyCert so an 781 sob-server for validation. 783 Note: I need to review Brian's work to ensure that the components of 784 each of these certificates or signed information has an associated 785 RADIUS attribute in this document. 787 5.2 Usernames and Passwords 789 Some latitude is given in this area so that different policies may be 790 enforced on different routers. In the most expected case, all 791 routers will be configured with identical Usernames and Passwords 792 which will be sent in the Access-Request Attributes as described in 793 [1]. 795 While it is not currently expected to be needed, a differentiated 796 policy may be applied through the use of different Usernames on 797 different routers when they initiate the policy download in the 798 Access-Request Attribute. For example, southern-facing routers could 799 be configured with a Username of "South" and northern-facing routers 800 could be given a Username of "North". When the sob-server receives a 801 policy download request from a router using a Username of "North", it 802 will deliver a policy for the northern-facing routers. Similarly for 803 "South" and southern-facing routers. 805 5.3 Stored Policy 807 A router SHOULD attempt to gather the stored policy from the 808 sob-server when it first awakes. It should be a local policy 809 decision of how to proceed if the router cannot obtain the stored 810 policy. 812 If the router can gather policies, then these MAY be enforced above 813 information received in the Authcerts since this will be locally 814 defined and administered policy. If the sob-server replies that it 815 has no policies to deliver then the router should accept routing 816 updates in the manner described in 817 draft-white-sobgp-bgp-deployment-01.txt [1]. 819 5.4 Time 821 Policies - The router should associate a countdown timer with a 822 received policy. Before the timer has reached 0, the router should 823 request a new set of policies. (Note: It may be a problem to 824 associate all of the downloaded policies with a single timer.) 826 Authcert - The router should associate a countdown timer with a 827 validated Authcert. Before that timer reches 0, the router should 828 reaffirm the validity of the Authcert but only if the associated AS 829 is still advertising routes. 831 5.5 Authcert Verification 833 An Authcert will contain all of the policies which must be sent to 834 the sob-server in the order they are placed within the Authcert. It 835 is very important that the elements be kept in order as the signature 836 is calculated over them in that order. (Note: Perhaps XML signing 837 would be better?) 839 5.6 Redundancy 841 As with all RADIUS solutions, it is usually important that the client 842 devices be able to access an authoritative RADIUS server at all 843 times. For this reason, it should be stressed that soBGP devices 844 utilizing the procedure described in this document should have 845 redundant sob-servers in their network with consistent databases of 846 stored policies and certificates. 848 6. Security Considerations 850 The security concerns of the mechanisms described in this document 851 may be separated into two parts: concerns with the transport, and 852 concerns with the content. 854 The security concerns dealing with the transport of this mechanism 855 are described in RFCs 2865 [4] and 2865 [7]. No further discussion 856 is warranted in this document. 858 The security concerns with the contents are identical to the security 859 concerns of the contens of the Authcerts, Entitycerts and Policycerts 860 in the other soBGP IDs. 862 7. IANA Considerations 864 Need stuff here. 866 8. Acknowledgments 868 Glen Zorn suggested using Access-Challenge to convey Stored Policy. 869 This seems to be much better than trying to use a stream of 870 Access-Requests and a finale of an Access-Reject. 872 9. Changes from Prior Drafts 874 -00 : Contained the basics but had poor formatting. 876 -01 : The content was transferred to XML to be used with RFC 2629 877 formatting using "xml2rfc". (Thanks Marshall Rose.) 879 -02 : Restructured the Stored Policy section to utilize 880 Access-Challenges. Added things to the tail-end sections. 882 -03 : tried to harmonize with draft-weis-sobgp-certificates-00.txt 883 This includes a change to the length of the Serial Number. And I 884 fixed some spelling errors. Not many of course. 886 -04 : More harmonization and the introduction of the Profiles. This 887 allows for the reuse of previously defined TLVs. 889 References 891 [1] White, R., "Deployment Considerations for Secure Origin BGP 892 (soBGP)", draft-white-sobgp-bgp-extensions-01.txt (work in 893 progress), June 2003. 895 [2] Ng, J., "Extensions to BGP to Support Secure Origin BGP 896 (soBGP)", draft-ng-sobgp-bgp-extensions-01.txt (work in 897 progress), June 2003. 899 [3] Weis, J., "Extensions to BGP to Support Secure Origin BGP 900 (soBGP)", draft-weis-sobgp-certificates-00.txt (work in 901 progress), June 2003. 903 [4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 904 Authentication Dial in User Service (RADIUS)", RFC 2865, June 905 2000. 907 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 908 Levels", RFC 2119, STD 14, March 1997. 910 [6] Rigney, C., Willats, W. and P. Calhoun, "NLRI stuff - need to 911 work on this", RFC 2858, June 2000. 913 [7] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 914 RFC 2869, June 2000. 916 [8] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA 917 Considerations Section in RFCs", RFC 2869, BCP 26, October 918 1998. 920 [9] Hinden, R. and S. Deering, "IP Version 6 Addressing 921 Architecture", RFC 2373, July 1998. 923 [10] Hinden, R. and S. Deering, "revocation list stuff goes here", 924 RFC 3280, July 1998. 926 Author's Address 928 Chris Lonvick 929 Cisco Systems 930 12515 Research Blvd. 931 Austin, TX 78759 932 US 934 Phone: +1 512 378 1182 935 EMail: clonvick@cisco.com 937 Intellectual Property Statement 939 The IETF takes no position regarding the validity or scope of any 940 intellectual property or other rights that might be claimed to 941 pertain to the implementation or use of the technology described in 942 this document or the extent to which any license under such rights 943 might or might not be available; neither does it represent that it 944 has made any effort to identify any such rights. Information on the 945 IETF's procedures with respect to rights in standards-track and 946 standards-related documentation can be found in BCP-11. Copies of 947 claims of rights made available for publication and any assurances of 948 licenses to be made available, or the result of an attempt made to 949 obtain a general license or permission for the use of such 950 proprietary rights by implementors or users of this specification can 951 be obtained from the IETF Secretariat. 953 The IETF invites any interested party to bring to its attention any 954 copyrights, patents or patent applications, or other proprietary 955 rights which may cover technology that may be required to practice 956 this standard. Please address the information to the IETF Executive 957 Director. 959 Full Copyright Statement 961 Copyright (C) The Internet Society (2004). All Rights Reserved. 963 This document and translations of it may be copied and furnished to 964 others, and derivative works that comment on or otherwise explain it 965 or assist in its implementation may be prepared, copied, published 966 and distributed, in whole or in part, without restriction of any 967 kind, provided that the above copyright notice and this paragraph are 968 included on all such copies and derivative works. However, this 969 document itself may not be modified in any way, such as by removing 970 the copyright notice or references to the Internet Society or other 971 Internet organizations, except as needed for the purpose of 972 developing Internet standards in which case the procedures for 973 copyrights defined in the Internet Standards process must be 974 followed, or as required to translate it into languages other than 975 English. 977 The limited permissions granted above are perpetual and will not be 978 revoked by the Internet Society or its successors or assignees. 980 This document and the information contained herein is provided on an 981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 987 Acknowledgment 989 Funding for the RFC Editor function is currently provided by the 990 Internet Society.