idnits 2.17.1 draft-murphy-ospf-signature-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. ** There are 21 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([3]), 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 393: '...1) SHALL be not less than 512 bits and...' 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 1996) is 10175 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'NETSEC' on line 384 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1583 (ref. '3') (Obsoleted by RFC 2178) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Historic RFC: RFC 1479 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sandra Murphy 3 INTERNET DRAFT Madelyn Badger 4 draft-murphy-ospf-signature-02.txt Trusted Information Systems 5 June 1996 7 OSPF with Digital Signatures 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet Drafts as reference material or to cite 19 them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow 23 Directories on ds.internic.net (US East Coast), venera.isi.edu (US West 24 Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 26 Abstract 28 This memo describes the extensions to OSPF required to add digital 29 signature authentication to Link State data. The augmented design is 30 backward compatible with standard OSPF V2 [3]. Routers supporting 31 digital signatures will be able to use the authenticated routing 32 information as an IP TOS or by source routing. 34 1. Acknowledgements 36 The idea of signing routing information is not new. Foremost, of 37 course, there is the design that Radia Perlman reported in her thesis 38 [4] and in her book [5] for signing link state information and for 39 distribution of the public keys used in the signing. IDPR [7] also 40 recommends the use of public key based signatures of link state 41 information. Kumar and Crowcroft [2] discuss the use of secret and 42 public key authentication of inter-domain routing protocols. Finn [1] 43 discusses the use of secret and public key authentication of several 44 different routing protocols. The design reported here is closest to 45 that reported in [4] and [7]. It should be noted that [4] also presents 46 techniques for protecting the forwarding of data packets, a topic that 47 is not considered here, as we consider it not within the scope of the 48 OSPF working group. 50 The authors would also like to acknowledge many fruitful discussions 51 with many members of the OSPF working group, particularly Fred Baker of 52 Cisco Systems, Dennis Ferguson of MCI Telecommunications Corp., John Moy 53 of Cascade Communications Corp., and Curtis Villamizar of ANS, Inc. 55 2. Introduction 57 It is well recognized that there is a need for greater security in 58 routing protocols. OSPF currently provides "simple password" 59 authentication where the password travels "in the clear", and there is 60 work in progress to provide keyed MD5 authentication for OSPF protocol 61 packets between neighbors. The simple password authentication is 62 vulnerable because any listener can discover and use the password. 63 Keyed MD5 authentication is very useful for protection of protocol 64 packets passed between neighbors, but does not address authentication of 65 routing data from its source to its eventual destination, through 66 routers which may themselves be faulty. 68 The basic idea of this proposal is to add digital signatures to OSPF LSA 69 data, and to recommend the use of a neighbor-to-neighbor authentication 70 algorithm (like keyed MD5) to protect all protocol exchanges. Link 71 State information will be signed by the originator of that information 72 and the signature will stay with the data in its travels via OSPF 73 flooding. This will provide end-to-end integrity and authentication for 74 LSA data. Routers providing digital signatures will be "authenticated 75 routers", and can be mixed with non-authenticated routers. An 76 application will be able to specify authenticated routing as an IP TOS, 77 and have packets forwarded accordingly. 79 A digital signature attached to an LSA by the source router provides 80 assurance that the data really does come from the advertising router. 81 It will insure that the data has not been modified in transit. In the 82 case where incorrect routing data is distributed by a faulty router, the 83 signature provides a way to trace the problem to its source. 85 Digital signatures for OSPF LSAs can be implemented with the following 86 major functions: 88 (1) Support for a digital signature algorithm in authenticated routers. 90 (2) Support for a signed version of all routing information LSAs 92 (3) Support for a new LSA: Router Public Key LSA 94 (4) Addition of an IP TOS for Authenticated Routing. 96 (5) Support TOS routing and forwarding in Authenticated Routers. 98 (6) A mechanism for Key Certification and Distribution. 100 (7) A router will need to be configured with, or supplied with: 102 Trusted Entity Information Set: (can be one set, or one per 103 supported Signature Algorithm) 105 Trusted Entity Public Key 106 Signature Algorithm and Parameters 108 Router Information Set: (can be one set, or one per attached area 109 and/or per supported Signature Algorithm) 111 Router Private Key 112 Router Certified Public Key and Data: 114 Key Id 115 Router Id 116 Router Role 117 Signature Algorithm and Parameters 118 Router Public Key 120 Router Information per attached Area: 122 Environment flag (authenticated, non-authenticated, mixed) 124 3. Overview 126 Authenticated OSPF routers perform all the normal functions of a 127 standard OSPF router. In addition to the standard functionality, an 128 authenticated OSPF router generates signed routing information LSAs, 129 sends a new key information LSA, manages key and signature algorithm 130 information, and verifies signatures received. An authenticated OSPF 131 router must support TOS routing, specifically for TOS=authenticated 132 routing. 134 Authenticated OSPF routers can send out a signed and an unsigned version 135 of each LSA. The unsigned version is for backward compatibility with 136 non-authenticated routers. The signed LSAs contain the same routing 137 information, and are flooded, aged, and used in routing calculation like 138 unsigned LSAs. There is an environment flag per area that tells the 139 router whether to send signed LSAs, unsigned LSAs, or both. If all 140 routers in an AS are authenticated then only signed LSAs must be sent. 141 If authentication is turned off, then only unsigned LSAs are sent. If 142 authenticated and non-authenticated routers are mixed in an area, then 143 signed and unsigned versions of the same LSAs must be sent out. This 144 design works best if all the routers in an AS are authenticated, but it 145 can still be useful in a mixed environment. 147 Standard OSPF routers will discard the unfamiliar LSAs containing key 148 and signature data, so, in a mixed environment there will be "islands" 149 of authenticated routers. Authenticated routing will function on each 150 "island", which might be an OSPF area, as follows: Each authenticated 151 router builds an SPF tree for TOS=Authenticated Routing using metrics 152 from the signed LSAs, and stores the paths that result in the routing 153 table. To take advantage of the routes supplied, an application must 154 set the TOS=Authenticated Routing bit in the IP header, and the IP 155 forwarding code must use the TOS routes from the routing table. 156 Alternatively, source routes could be generated using the TOS routing 157 information. TOS 0 routing will function normally throughout the AS. 159 4. LSA Processing 161 4.1. Signed LSA 163 When the router builds a routing information LSA for an area, the 164 environment for that area must be checked. In a mixed environment the 165 router must build a signed and an unsigned version of the LSA. In an 166 authenticated environment only the signed version of the LSA must be 167 sent. In a non-authenticated environment only the unsigned version of 168 the LSA must be sent. The unsigned version of the LSA will be the 169 standard OSPF V2 [3] LSA. The signed LSAs will have the top bit of the 170 LSA type field set to indicate the presence of a signature, the metrics 171 (if present) will include TOS = Authenticated Routing, and the LSA will 172 have a Key Id, Signature and Signature Length in it. The signature is 173 computed on the LSA header and data, starting with the Options field and 174 continuing to the end of the message, with two exceptions. First, an 175 LSA created with age=MaxAge has a signature that begins with the age 176 field (see section on MaxAge). Second, the LSA Header Checksum is set 177 to zero for the generation of the signature. 179 When the router receives a routing information LSA, the type field is 180 examined. Unsigned LSAs are handled in the standard OSPF V2 [3] way. 181 When a signed LSA is received, the signature should be verified using 182 the public key of the advertising router having the indicated Key Id. 183 If there is no such key stored for the advertising router, then the 184 signed LSA must be discarded. If the missing key has a Key Id greater 185 than that of the currently stored key, then an LS Request packet should 186 be sent requesting both the missing key and a retransmission of the LSA 187 signed with that key. If the signature verification fails, the LSA must 188 be discarded. If the signature verifies, then the signed LSA is stored 189 for use in the routing calculations. The TOS = Authenticated Routing 190 metrics in the signed LSA will be used in the construction of an SPF 191 tree for this TOS, and these routes will be put into the OSPF routing 192 table. 194 4.2. Public Key LSA 196 An authenticated router sends a Router Public Key LSA (PKLSA)in the same 197 manner as all other LSAs. This LSA contains the router's public key and 198 identifying information that has been certified by a Trusted Entity. 199 The router public key is used to verify signatures produced by this 200 router. When forming an adjacency or synchronizing databases, the 201 Router PKLSAs should be sent/requested before other LSAs. The Router 202 PKLSA is sent at intervals like all other LSAs, and it is sent 203 immediately if a router obtains a new key to distribute. A PKLSA is sent 204 via OSPF flooding within an OSPF area. PKLSAs are not summarized 205 outside an area with the exception of the Autonomous System Border 206 Router's PKLSAs which must be flooded wherever AS external LSAs are 207 flooded. 209 When an authenticated router receives a Router PKLSA it must check both 210 the Trusted Entity certification and the Router's signature. The 211 Signature Algorithm must be the same for both signatures. If either 212 verification fails, for any reason, the PKLSA is discarded. If the 213 PKLSA verifies successfully, it must be stored for use in verifying 214 signed LSAs from the advertising router. For every authenticated router 215 that this router is in contact with, there may be one or more Router 216 Public Key LSAs stored at any given time. These PKLSAs are 217 differentiated by Key Id. Each router may have one PKLSA for each 218 Algorithm supported in a given area. The current key is defined as the 219 key with the largest Key Id having the desired Signature Algorithm. A 220 key can be flushed from routing tables by a properly signed MaxAge 221 version of the Router Public Key LSA sent by the originating router (see 222 section on MaxAge). A key can also be flushed (superseded) by a 223 correctly certified Router PKLSA giving a larger Key Id and the same 224 Signature Algorithm as a prior PKLSA. 226 5. LSA formats 228 5.1. Options Field 230 There is an Options Field in LSAs, Hellos, and Database Description 231 Packets. This field describes the optional capabilities supported by 232 the advertising OSPF router. The TOS bit must be set in the Options 233 field of all LSAs/packets sent by an Authenticated Router. 235 5.2. LSA Type Field 237 This proposal requires a new LSA type for the Router Public Key LSA. 239 The top bit of the LSA Type field will be set to indicate that an LSA is 240 signed. This creates a new signed LSA type for each existing type. 242 5.3. Router Public Key LSA (PKLSA) 244 This LSA is the vehicle for an authenticated router to provide a public 245 key to other authenticated routers. This public key is what other 246 routers use to verify the signatures created by this router. A Router 247 PKLSA will be communicated in the usual database exchange and via 248 flooding mechanisms. The regular period for sending this LSA should be 249 LSRefreshTime. The Router PKLSA will also be sent when there is a new 250 key, or a key to be flushed from the system. 252 This LSA contains the advertising router's public key, identifying 253 information, and a certification of that key and information by a 254 Trusted Entity. The certification is a signature of the key and 255 information created by the Trusted Entity. This certification signature 256 can be verified using the Trusted Entity's public key which must be 257 known to all authenticated routers. If there are multiple signature 258 algorithms and therefore more than one Trusted Entity public key, the 259 signature algorithm for the router public key and the Trusted Entity 260 public key must be the same. 262 ROUTER PUBLIC KEY LSA 263 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 264 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 2 265 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 266 | LSA Header (Standard OSPF - RFC 1583) / 267 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 268 | Signature Length | Certification Length | 269 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+-->> 270 | Router Id | Cert 271 | Key Id | Router Role | Sig Algorithm | Data 272 | Signature Parameters (May be void) / .. 273 | Router Public Key / .. 274 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+--<< 275 | Certification / 276 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 277 | Signature / 278 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 280 The LSA Header is standard as defined in RFC 1583. 281 LS Type: X for Router Public Key LSA. Top bit set to indicate a 282 signed LSA. 283 Link State ID: Key Id. This is the Identifier of the Router 284 Public Key. This Id will differentiate between multiple 285 keys supplied by the same router. 287 Signature Length: the length of the Signature field. 288 Certification Length: the length of the Certification field. 289 Router Id: Advertising Router. 290 Key Id: This is the Identifier of the Router Public Key. This 291 Id will differentiate between multiple keys supplied by 292 the same router. 293 Rtr Role: Router (R=1), Area Border Router (ABR=2), 294 Autonomous System Border Router (ASBR=3), ABR and 295 ASBR (4). 296 Sig Algorithm: Signature Algorithm to be used. Identifies the type 297 of the Router Public Key, the Certification, and the 298 Signature. The Signature Algorithm encompasses the hash 299 algorithm used as well. Currently defined value = RSA-MD5(1). 300 Signature Parameters: These parameters are unique to the given 301 Signature Algorithm. The Signature Parameters for RSA-MD5 302 are void. 303 Router Public Key: A key that can be used by other routers to 304 verify the signatures produced by this router. The internal 305 format for the Router Public key is Signature Algorithm 306 dependent. RSA-MD5 given below. 308 Certification: The Trusted Entity's signature of the certified 309 data. 310 Signature: The advertising router's signature of this message using 311 the private key identified by the Key Id. This signature 312 can be verified using the enclosed certified public key. 313 The signature covers the LSA header and message starting 314 with the LSA header options field and ending with the Trusted 315 Entity certification field. There are two exceptions to this 316 coverage: 317 1) If the LSA was generated with an age=MaxAge, then the 318 signature begins with the age field. 319 (See the section on MaxAge). 320 2) The checksum in the LSA Header is set to zero for the 321 computation of the signature. 323 5.4. Signed LSA 325 A signed LSA can be any OSPF LSA with signature data and a digital 326 signature attached. The top bit of the LSA Type field is set to 327 indicate the presence of a signature. A Signature length and Key Id 328 follow the LSA header. The metrics in the LSA must include metrics for 329 TOS = Authenticated Routing. The actual signature follows the LSA Data. 330 Signed LSAs are sent via OSPF reliable flooding, like other LSAs. 332 SIGNED LSA 333 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 334 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 2 335 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 336 | LSA Header (standard OSPF - RFC 1583) / 337 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 338 | Signature Length | Key Id | 339 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 340 | LSA Data / 341 / ... / 342 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 343 | Signature / 344 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 346 The LSA Header format is standard as defined in RFC 1583. 347 LS Type: Standard LSA type + the top bit set to indicate the 348 presence of a signature 349 Sig Length: The length in bytes of the Signature field. 350 Key Id: This is the Identifier of the router public/private key 351 pair used in signing this LSA. 352 Signature: Digital signature of the signed LSA. 353 The signature covers the LSA header and data starting 354 with the LSA header options field. There are two exceptions 355 to this coverage: 356 1) If the LSA was generated with an age=MaxAge, then the 357 signature begins with the age field. 358 (See the section on MaxAge). 359 2) The checksum in the LSA Header is set to zero for the 360 computation of the signature. 362 5.5. RSA-MD5 Signature Algorithm 364 RSA-MD5 is the signature algorithm that all authenticated routers must 365 support. Other algorithms may be supported; their formats will have to 366 be recorded here in future versions of this document. 368 RSA-MD5 Signature Algorithm 370 Sig Alg value = 1 371 Sig Parms = void 373 For the MD5/RSA algorithm, the signature is as follows 375 hash = MD5 ( data ) 377 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) 379 where MD5 is the message digest algorithm documented in RFC 1321, "|" is 380 concatenation, "e" is the private key exponent of the signer, and "n" is 381 the public modulus of the signer's public key. 01, FF, and 00 are fixed 382 octets of the corresponding hexadecimal value. "prefix" is the ASN.1 BER 383 MD5 algorithm designator prefix specified in PKCS1, that is, 384 hex 3020300c06082a864886f70d020505000410 [NETSEC]. 385 This prefix is included to make it easier to use RSAREF or similar 386 packages. The FF octet is repeated the maximum number of times such 387 that the value of the quantity being exponentiated is one octet shorter 388 than the value of n. 390 (The above specifications are Public Key Cryptographic Standard #1 [9].) 392 The size of n, including most and least significant bits (which will be 393 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e 394 SHOULD be chosen such that the public exponent is small. 396 Leading zeros bytes are not permitted in the MD5/RSA algorithm 397 signature. 399 A public exponent of 3 minimizes the effort needed to decode a 400 signature. Use of 3 as the public exponent may be weak for 401 confidentiality uses since, if the same data can be collected encrypted 402 under three different keys with an exponent of 3 then, using the Chinese 403 Remainder Theorem, the original plain text can be easily recovered. 404 This weakness is not significant for OSPF because we seek only 405 authentication, not confidentiality. 407 Router Public Key for RSA-MD5 408 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 409 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 2 410 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 411 | Bits | Exponent / 412 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 413 | Modulus / 414 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 416 Bits: The number of bits in the Exponent 417 Exponent: RSA public key exponent 418 Modulus: RSA public key modulus 420 6. Processing Max Age 422 The age field in the OSPF LSA header is used to keep track of how long a 423 given LSA has been in the system. This, along with the sequence number, 424 allows a router to decide which LSAs are current, and allows old or 425 inaccurate LSAs to be flushed from the system. When the age field 426 reaches MaxAge, routers stop using the LSA for routing, and they flood 427 the MaxAge LSA to make sure that all routers stop using this LSA. When 428 a router fails, eventually its LSAs age out of the system in this way. 429 If a router wants to flush its own LSA from the system it can set the 430 age to MaxAge and flood the LSA. 432 This element of the protocol is difficult to protect using digital 433 signatures. The age field cannot generally be included in the 434 signature, because it must be updated by routers other than the 435 originating router. For the same reason, the age field is not included 436 in the checksum computation. The age field should be protected, because 437 if a faulty router started to age out other router's LSAs, it would 438 effectively deny service to those other routers. 440 To protect the age field, the signature should include the age field 441 when, and only when, the age field value is MaxAge. Verification of the 442 signature on a signed LSA should include the age field when, and only 443 when, the age field value is MaxAge. 445 The processing of MaxAge will also change slightly for authenticated 446 routers. An LSA will be removed from any router's Link State Database 447 in one of two ways: 1) the router receives a version of the LSA with the 448 age field set to MaxAge, or 2) the LSA incrementally reaches MaxAge 449 while it is stored by the router. A received LSA with the age field set 450 to MaxAge could have been sent by the originating router or by any other 451 router which had aged the LSA to MaxAge in its database. But for 452 authenticated routers, only the MaxAge LSA sent by the originating 453 router would be recognized as valid, as only the originating router can 454 generate a signature covering the age field. A signed LSA with age 455 MaxAge flooded by a router that is not the LSA's originating router will 456 be ignored by all authenticated routers. In this way, the originating 457 authenticated router can prematurely age an LSA, but other routers 458 cannot. It is also true that a non-originating router's flooding of 459 signed LSAs that have reached MaxAge in its database will be ignored. 460 If an authenticated router goes down, its signed LSAs will be aged out 461 by each remaining router individually. This will slow database 462 convergence when an authenticated router goes down, but the databases 463 will still converge, and a fairly obvious security hole will be closed. 465 7. Of Cryptography and Keys 467 This design relies on Public Key cryptography. The common examples are 468 RSA and DSA. All authenticated routers must support RSA with an MD5 469 hash as a signature algorithm. There are some good books on the subject 470 of cryptography [6], but the high level view of how this design uses 471 Public-Key cryptography is as follows: 473 Each router has a private key that must be secret, and a public key that 474 everyone may know. A signature can be generated with the private key, 475 and verified using the public key. This verification ensures that the 476 data signed has not been altered in transit, and that it was signed by 477 the router having the correct private key. There is a Trusted Entity 478 somewhere that has a secret private key, and a public key that all 479 routers must know. A router must be configured with it's own pair of 480 keys (public and private), and with the public key of the Trusted 481 Entity. It must obtain a copy of its own public key plus identifying 482 data signed by the Trusted Entity. The signature by the Trusted Entity 483 is its certification that it has verified, according to autonomous 484 system policy, the binding between the identifying data (including 485 Router Id) and the public key. 487 An authenticated router sends its certified public key in a Router 488 Public Key LSA via OSPF flooding. All authenticated routers receiving 489 this key store it to use in verifying the advertising router's 490 signatures. The certification can be checked using the Trusted Entity's 491 public key, which, again, all routers must know. 493 Each router signs its LSAs by first running a one-way hash algorithm 494 (like MD5 or SHA) on the data, and then using its private key to sign 495 the digested data. The signature for an LSA is appended to the LSA. 497 Periodically, keys will have to be changed, and the new router public 498 keys will have to be certified by the Trusted Entity. A router could 499 generate its new key pair, or could receive them via a key distribution 500 scheme. Certification could be done out-of-band, or via an encrypted 501 exchange of information with the Trusted Entity. Original distribution 502 of certified keys is beyond the scope of this memo. 504 Each router must be able to store several keys for each authenticated 505 router in the area and each ASBR. 507 8. Remaining Vulnerabilities 509 Note that with this mechanism, one router can still distribute incorrect 510 data in the information for which it itself is responsible. 511 Consequently, an autonomous system employing digital signatures with 512 this mechanism will not be completely invulnerable to routing 513 disruptions from a single router. For example, the area border routers 514 and autonomous system border routers will still be able to inject 515 incorrect routing information. Also, any single internal router can be 516 incorrect in the routing information it itself originates about its own 517 links. 519 8.1. Area Border Routers 521 Even with the design proposed here, the area border routers can inject 522 incorrect routing information into their attached areas about the 523 backbone and the other areas in Type 3 and 4 LSA's. They can also 524 inject incorrect routing information into the backbone about their 525 attached area. 527 Because all the area border routers in one area work from the same 528 database of LSA's received in their common area, it would be possible 529 for the area border routers to corroborate each other. Any area border 530 router for an area could double check the Type 3 and 4 LSA's received 531 over the backbone from other ABR's from the area, and could double check 532 the Type 3 and 4 LSA's flooded through the area from the other area 533 border routers. The other routers in the area or backbone should be 534 warned of any check failure. The warning could be a signed message from 535 the area border router detecting the failure flooded in the usual 536 mechanism. 538 Another possibility would be that the area border routers in an area 539 could originate multiple sets of Type 3 and Type 4 LSA's -- one for 540 itself containing its own information and one for each of the area 541 border routers in the area containing the information each of them 542 should originate. Each router in the area or backbone could then 543 determine for itself whether the area border routers agreed. This 544 distribution of information but coordination of processing is in keeping 545 with the paradigm of link state protocols, where information and 546 processing is duplicated in each router. 548 The two alternatives mean much additional processing and additional 549 message transmission, over and above the additional processing required 550 for signature generation and verification. Because the vulnerability is 551 isolated to a few points in each area, because the source of incorrect 552 information is detectable (in those situations where the incorrect 553 information is spotted) and because the protection is costly, we have 554 not added this protection to this design. 556 8.2. Internal Routers 558 The internal routers can be incorrect about information they themselves 559 originate. 561 A router could announce an incorrect metric for a valid link. There is 562 no way to guard against this, but the damage would be small and 563 localized even if the router is announcing that the link is up when it 564 is down or vice versa. 566 A router could announce a connection that does not in fact exist. If a 567 router announces a non-existent connection to a transit network, the 568 OSPF Dijkstra computation will not consider the connection without a 569 similar announcement from another router at the other "end". Therefore, 570 no damage would result (above network impact to transmit and store the 571 incorrect information) without the cooperation of another router. A 572 router could also announce a connection to a stub network or a host 573 route that does not exist. The Dijkstra computation can not perform the 574 same check for a similar announcement from the other "end", because no 575 other end exists. This is a vulnerability. 577 A faulty router announcing a nonexistent connection to a stub network or 578 host could result in the faulty router receiving IP packets bound for 579 that network or host. Unless the faulty router then forwarded the 580 packets to the correct destination by source routing, the failure of 581 packet delivery could expose the incorrect routing. To exploit the 582 vulnerability deliberately, the faulty router would have to be able to 583 handle and pass on the received traffic for the incorrectly announced 584 destination. Furthermore, if the incorrect routing were discovered, the 585 signatures on the routing information would identify the faulty router 586 as the source of the incorrect information. 588 Even so, there may be reason to protect against one faulty router 589 disrupting routing by announcing these unsubstantiated connections. In 590 the worst case, a faulty router could announce nonexistent host routes 591 to a large number of addresses in the area or autonomous system. (Note 592 that announcing a large number of incorrect routes would raise the 593 probability that the incorrect routing would be detected, leading to 594 detection of the faulty router as the source of the error.) To guard 595 against this vulnerability would require that there be some 596 substantiation of the connections a router could announce. 598 One way to produce a substantiation of announced connections would be to 599 have an authority in the autonomous system that would produce signed 600 authorizations of the networks that a router would be allowed to 601 announce. This means that before a router could be part of the OSPF 602 exchanges it would need to communicate, either on-line or off-line, with 603 the authority. When an existing connection disappears permanently or a 604 new connection comes into being, a new authorization from the authority 605 would be needed. As the existence of connections a router has with 606 networks, hosts, and other routers is not as dynamic as the state of 607 those connections, this would not be a hardship for network management 608 for one router. 610 This authorization could be made part of the Router Public Key LSA and 611 therefore distributed as part of the normal OSPF flooding mechanism, as 612 follows: 614 ROUTER PUBLIC KEY LSA 615 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 2 618 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 619 | LSA Header (Standard OSPF - RFC 1583) / 620 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 621 | Signature Length | Certification Length | 622 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+-->> 623 | Router Id | Cert 624 | Key Id | Router Role | Sig Algorithm | Data 625 | Signature Parameters (May be void) / .. 626 / / 627 | # Allowed Networks / 628 | Allowed Network / 629 | Link Data / 630 / / 631 | Router Public Key / .. 632 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+--<< 633 | Certification / 634 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 635 | Signature / 636 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+-+ 638 The new Router Public Key fields are: 639 # Allowed Network: The number of network ranges that follow 640 in this advertisement 641 Allowed Network: An network address that this router is 642 authorized to announce. 643 Link Data: The network's IP address mask. 645 (Note that the internal router vulnerability applies only to one-sided 646 connections, but the protection could be applied to all connections a 647 router may announce.) 649 As the connections that would require authorization should not change 650 frequently, distributing the authorization with the speed of the OSPF 651 flooding mechanism may be unnecessary. Some other authorization 652 distribution mechanism could be employed. 654 8.3. Autonomous System Border Routers 656 The autonomous system boundary routers can produce incorrect routing 657 information in the external routes information they originate. There is 658 no way to double check or corroborate this information, as there is with 659 area border routers. No authority within an autonomous system exists to 660 authorize the networks an autonomous system boundary router could 661 announce, as is the case for the internal networks an internal router 662 could announce. Consequently, the autonomous system boundary routers 663 remain a unprotected vulnerability. With this in mind, special care 664 should be taken to protect the autonomous system boundary routers with 665 other means. 667 9. Security Considerations 669 This entire memo is about security considerations. 671 10. References 673 [1] Gregory G. Finn, "Reducing the Vulnerability of Dynamic Computer 674 Networks," ISI Research Report ISI/RR-88-201, University of 675 Southern California Information Sciences Institute, Marina del Rey, 676 California, June 1988. 678 [2] Kumar,B and Crowcroft,J., "Integrating Security in Inter-Domain 679 Routing Protocols", Computer Communications Review, Vol 23, No. 5, 680 October 1993. 682 [3] Moy, J., "OSPF Version 2," RFC 1583, Proteon, Inc., March 1994. 684 [4] Perlman, R., "Network Layer Protocols with Byzantine Robustness", 685 Ph.D. Thesis, Department of Electrical Engineering and Computer 686 Science, MIT, August 1988. 688 [5] Perlman, R., "Interconnections: Bridges and Routers", Addison- 689 Wesley, Reading, Mass., 1992. 691 [6] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and 692 Source Code in C," John Wiley & Sons, Inc., New York, 1994. 694 [7] Steenstrup, M., "Inter-Domain Policy Routing Protocol 695 Specification: Version 1", RFC 1479, BBN Systems and Technologies, 696 July 1993. 698 [9] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 699 1991, Version 1.4. 701 11. Author's Address 703 Sandra Murphy 704 Trusted Information Systems 705 3060 Washington Road 706 Glenwood, MD 21738 707 EMail: murphy@tis.com 708 Madelyn Badger 709 Trusted Information Systems 710 3060 Washington Road 711 Glenwood, MD 21738 712 EMail: mrb@tis.com 713 Table of Contents 715 Status of this Memo .............................................. 1 716 Abstract ......................................................... 1 717 1 Acknowledgements ................................................ 1 718 2 Introduction .................................................... 2 719 3 Overview ........................................................ 3 720 4 LSA Processing .................................................. 4 721 4.1 Signed LSA .................................................... 4 722 4.2 Public Key LSA ................................................ 5 723 5 LSA formats ..................................................... 6 724 5.1 Options Field ................................................. 6 725 5.2 LSA Type Field ................................................ 6 726 5.3 Router Public Key LSA (PKLSA) ................................. 6 727 5.4 Signed LSA .................................................... 8 728 5.5 RSA-MD5 Signature Algorithm ................................... 9 729 6 Processing Max Age .............................................. 10 730 7 Of Cryptography and Keys ........................................ 11 731 8 Remaining Vulnerabilities ....................................... 12 732 8.1 Area Border Routers ........................................... 12 733 8.2 Internal Routers .............................................. 13 734 8.3 Autonomous System Border Routers .............................. 15 735 9 Security Considerations ......................................... 16 736 10 References ..................................................... 16 737 11 Author's Address ............................................... 16