RFC 2154

OSPF with Digital Signatures

📅 published June 1997, from ietf

RFC 2154: OSPF with Digital Signatures 🎀

Okay bestie, this is RFC 2154 💖, and it's called OSPF with Digital Signatures. It's an Experimental doc 🧪, written by S. Murphy, M. Badger, and B. Wellington from Trusted Information Systems, and it's dated June 1997. The title block doesn't list anything it obsoletes or updates.

Status of This Memo 📜

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈. They're asking for discussion and suggestions for improvement, and distribution of the memo is unlimited ✨.

Abstract 🌸

Okay so this is the main idea: it describes the OSPF extensions that are required to add digital signature authentication to Link State data, plus a certification mechanism for router data 🔐. It also details the new LSA processing and key management, and explains how you can migrate from standard OSPF V2 or make it co-exist with it 🦋.

Table of Contents 💜

1 Acknowledgements .............................................   2
2 Introduction .................................................   2
3 LSA Processing ...............................................   4
3.1 Signed LSA .................................................   4
3.2 Router Public Key LSA (PKLSA) ..............................   5
3.3 MaxAge Processing ..........................................   7
4 Key Management ...............................................   8
4.1 Identifying Keys ...........................................   8
4.1.1 Identifying Router Keys and PKLSAs .......................   8
4.1.2 Identifying TE Public Keys ...............................   8
4.1.3 Key to use for Signing ...................................   9
4.1.4 Key to use for Verification ..............................   9
4.2 Trusted Entity (TE) Requirements ...........................  10
4.3 Scope for Keys and Signature Algorithms.....................  10
4.4 Router Key Replacement .....................................  11
4.5 Trusted Entity Key Replacement .............................  12
4.6 Flexible Cryptographic Environments ........................  14
4.6.1 Multiple Signature Algorithms ............................  14
4.6.2 Multiple Trusted Entities ................................  15
4.6.3 Multiple Keys for One Router .............................  16
5 Compatibility with Standard OSPF V2 ..........................  16
6 Special Considerations/Restrictions for the ABR-ASBR .........  17
7 LSA formats ..................................................  18
7.1 Router Public Key LSA (PKLSA) ..............................  18
7.2 Router Public Key Certificate ..............................  20
7.3 Signed LSA .................................................  23
8 Configuration Information ....................................  26
9 Remaining Vulnerabilities ....................................  26
9.1 Area Border Routers ........................................  27
9.2 Internal Routers ...........................................  27
9.3 Autonomous System Border Routers ...........................  28
10 Security Considerations .....................................  28
11 References ..................................................  29
12 Authors' Addresses ..........................................  29

1. Acknowledgements ✨

The idea of signing routing info is not new, babe 💅. The big one is the design Radia Perlman reported in her thesis [4] and in her book [5], for signing link state info and distributing the public keys used in the signing 👑. IDPR [7] also recommends public key based signatures of link state info. Kumar and Crowcroft [2] talk about secret and public key authentication for inter-domain routing protocols. Finn [1] covers secret and public key authentication across several different routing protocols 🧚. This design is closest to the ones reported in [4] and [7]. Also, [4] has techniques for protecting the forwarding of data packets, which this doc doesn't cover, because the authors see that as outside the OSPF working group's scope 🙈.

The authors also want to thank the many members of the OSPF working group they had super fruitful discussions with 🫶. That includes Fred Baker of Cisco Systems, Dennis Ferguson of MCI Telecommunications Corp., John Moy of Cascade Communications Corp., Curtis Villamizar of ANS, Inc., and Rob Coltun of FORE Systems 💖.

2. Introduction 🦋

It's well recognized that routing protocols need way more security 🔒. Right now OSPF has "simple password" authentication, where the password travels "in the clear". There's also work in progress [11] to add keyed MD5 authentication for OSPF protocol packets between neighbors. The simple password thing is so vulnerable because any listener can discover and use the password 💀. Keyed MD5 is super useful for protecting protocol packets passed between neighbors, but it doesn't handle authenticating routing data that gets flooded from source to final destination through routers that might themselves be faulty or subverted 😭.

So the core idea here is to add digital signatures to OSPF LSA data, distribute certified router information and keys, and use a neighbor-to-neighbor authentication algorithm (like keyed MD5) to protect local protocol exchanges 🌈. The content of a Hello packet, Link State Request, Link State Update, or Database Description will be protected by the neighbor-to-neighbor algorithm. The LSAs flooded inside Link State Update packets are each individually protected by a digital signature. Every LSA gets signed by its originator, and the signature stays with the data as it travels through OSPF flooding. That gives you end-to-end integrity and authentication for LSA data ✨. The digital signature on an LSA from the source router shows the data really comes from the advertising router. It also makes sure no other router changed the data while it was being flooded. And if a faulty router originates incorrect routing data, the signature will point to where the problem started 🕵️‍♀️.

Digital signatures are done with public key cryptography 🔑. There are some good books on the subject [6], but here's the high-level version of how this design uses it. Each router has a pair of keys, a public key and a private key. The private key creates a unique signature for a block of data (in this case, the LSA). Each router signs its LSAs by first running a one-way hash algorithm (like MD5 or SHA) on the data, and then using its private key to sign the digest. The signature is appended to the LSA. Any other router can use the public key to verify the signature 💜. The private key must be kept secret by one router, and the public key must be distributed to all the routers that will receive link state information from the signer. The distribution happens by creating a new LSA, the Public Key LSA (PKLSA), and sending it out with the standard OSPF flooding procedure. Flooding makes sure a router's public key gets sent everywhere its signed LSAs go 🌸.

Here's the catch: any router can send out a public key and claim to be a given router, so the public key on its own doesn't prove who the sender really is 😬. That assurance has to come from a Trusted Entity. The Trusted Entity (TE) is a system that generates certificates for routers. A certificate is a packet of info about a router that identifies it and supplies a public key. Certified router info includes the router id, its role, the address ranges the router may advertise, a timestamp, and the router's public key 🎀. The TE signs the certificate. Each router must be configured with a certificate and a TE public key so it can verify other routers' certificates. A router PKLSA contains that router's certificate. When a router gets a PKLSA, it verifies the certificate using the TE public key, and then verifies the whole LSA using the router public key inside the certificate. A successful verification means the PKLSA really is from the correct router and that no other router in the flood path altered it 🏆.

OSPF with Digital Signatures is backward compatible with standard OSPF V2, but only in a limited way 🤷‍♀️. Within an AS you can have "signed" areas and "unsigned" areas. How a mixed AS behaves is discussed in section 5 💅.

Digital signatures for OSPF LSAs can be implemented with the following major functions:

(1) Support for a digital signature algorithm

(2) Support for a signed version of all routing information LSAs

(3) Support for a new LSA: Router Public Key LSA (PKLSA)

(4) A mechanism for key certification and certificate distribution

(5) Extra configuration data (detail in section 7):

  • Trusted Entity (TE) information and key(s)
  • Router certification data and key
  • Area environment flag (signed/unsigned)
  • Timing intervals

An implementation of this design exists, based on the OSPF in Gated version 3.5Beta3 🎉. It's available for use and experimentation, so if you want the info, contact the authors 💖.

3. LSA Processing 🌈

(Part 1 ends here! Section 3 picks up in part 2 ✨)

3.1. Signed LSA ✨

Okay bestie, a signed LSA is basically a normal OSPF V2 LSA (header plus data) with extra stuff tacked on 💅. You get the key identification info, a signature length, and the signature itself. The top bit of the LS type field gets flipped on to say "hey, I'm signed" 🦋. The signature covers the LSA header (starting at the options field), the LSA data, and the key identification info and signature length, which have to be appended to the LSA data. ngl that's a lot of coverage 😭

There are two exceptions though 🙈. First, an LSA created with age=MaxAge has a signature that begins at the age field (see the section on maxage). Second, the LSA header checksum is set to zero when the signature is generated. Now here's the vibe check: the key id info and the signature length fields sit at the end of the LSA, after the signature, so parsing is easier. But the message MUST be signed and verified with those fields immediately appended to the LSA data. You can handle that either by doing the sign and verify "in parts" (RSAREF lets you do this), or by storing the LSA data with the appended fields and the LSA signature separately in the link state database (LSDB) 🎀

When a signed LSA comes in, you check the signature using the public key of the advertising router, which lives in that router's PKLSA 🔑. If the signature verifies, the signed LSA gets stored for routing calculations ✨. If verification fails, the LSA MUST be discarded 💀. If the identified key isn't available (not in a PKLSA from the advertising router), the signed LSA MUST be stored for a period of time set by the configurable MAX_TRANSIT_DELAY interval. If the key shows up within that window, the LSA gets processed then. If it doesn't, the LSA gets discarded. This delay is there so routing info doesn't get lost when LSAs arrive before their PKLSAs. That should not normally be the case, but it could happen 🌸

If the LSA is a Router Links LSA, the router's advertised links MUST be checked against the allowed address ranges stored in the PKLSA for the advertising router. Every network link (link types 2 and 3) MUST have an IP address that fits inside one of the ranges in the list of address ranges in the PKLSA (format 7.2). If a link doesn't fit any range, an error MUST be logged and the LSA MUST be discarded 🚫. Careful subnetting plus matching ranges gives you super tight control over what gets advertised 👑. A much looser (but still useful) level of control comes from defining allowed address ranges for an area, so every router in that area can be configured with the same set 🧚. To trivially satisfy this check, you can define one range with a zero address and mask that covers all IP addresses 🌈

Link State Acknowledgements MUST be sent for all LSAs that get discarded because of verification failures, LSAs stored while waiting for keys, and LSAs discarded because they advertise a link the router isn't allowed to advertise 🫶

3.2. Router Public Key LSA (PKLSA) 🔑

A Router Public Key LSA (PKLSA) gets sent the same way as all other LSAs 📬. It contains the router's public key plus identifying info that's been certified by a Trusted Entity 💜. That public key is what verifies signatures produced by this router. There's only one PKLSA stored per router in the LSDB for an area, so the Router Id and LS type can be used to retrieve a given PKLSA. The Router Id is stored in the PKLSA Link State Id field so you can look it up. The identification info in the certified data (TE Id, Rtr Key Id) can be used to uniquely pin down the current router key (section 7.2) 🦋

Same parsing trick here: the router signature length and certification length fields are at the end of the LSA, after the signature. The message MUST be signed and verified with those fields immediately appended to the LSA data. The router signature of the PKLSA gets verified the same way as other signed LSAs. On top of that, the certification MUST be verified using the referenced TE public key. If either verification fails, for any reason, the PKLSA is discarded 💀

A successfully verified PKLSA is stored for verifying signed LSAs from the advertising router ✨. For every router this router is in contact with, there MAY be one PKLSA stored at any given time. Each PKLSA is uniquely identified by its (TE Id, Rtr Key Id) values in the certified data (format in 7.2). When a PKLSA arrives for a given router and one is already stored for that router, the PKLSA with the most recent "Create Time" is the one that's kept 🍓

Whenever groups of LSAs get sent by a router (like when syncing databases or sending updates), the PKLSAs MUST be sent or requested before the other LSAs. That keeps processing time low for LSAs arriving before their keys 🏃‍♀️. PKLSAs are sent at intervals like all other LSAs, and they're sent immediately if a router gets a new key to distribute 💖. A PKLSA gets flooded via OSPF within an OSPF area. PKLSAs are NOT flooded outside an area, with one exception: an Autonomous System Border Router's PKLSAs MUST be flooded wherever AS external LSAs are flooded 🌍. You can decide whether to flood by checking the router role (Rtr, ABR, ASBR, ABR-ASBR) stored in the certified part of the PKLSA 👑

A router MAY flush its keys from routing tables by flooding a PKLSA for that key with age=MaxAge. This is called premature aging of the PKLSA 🧹. A key can also be removed from routing tables (superseded) by a PKLSA from the same router that contains a valid certificate for a new key with a more recent Create Time. If a key gets superseded by a newer key, you don't need to flush the old one with a "MaxAge" PKLSA. Iykyk 😌

When a new key is received, the LSAs stored in the LSDB that are signed with the old key MUST be replaced within MAX_TRANSIT_DELAY, if the sending router is working properly 🔄. That's because a router distributing a new key sends all of its self-originated LSAs signed with the new key immediately after sending the new PKLSA (see section 4.4 on Router Key Replacement). To make sure data signed with an old (possibly subverted) key doesn't stick around in the LSDB by mistake, all LSAs signed with a flushed or superseded key get aged to within MAX_TRANSIT_DELAY of MaxAge. This gives the new LSAs signed with the new key time to arrive. If new LSAs don't show up, or the key was flushed and never replaced, the old LSA data disappears from the LSDB in a timely fashion 🫧

Link State Acknowledgements MUST be sent for PKLSAs that get discarded due to verification failures, or because the PKLSA was less recent than the one already stored 🫶

3.3. MaxAge Processing ⏳

The age field in the OSPF LSA header keeps track of how long a given LSA has been in the system 🕰️. When the age field hits MaxAge, a router stops using the LSA for routing and floods the MaxAge LSA so that every router stops using it too. In normal OSPF, an LSA always gets replaced by an updated version before its age reaches MaxAge, unless the advertising router fails or changes in the AS make the routing info in the LSA inaccurate 😬. An LSA with age=MaxAge is either:

  1. being intentionally flushed from the AS by the advertising router because the info in it is no longer accurate, or
  2. an orphan LSA that has aged to MaxAge because its originating router hasn't refreshed it at the normal refresh intervals.

The age field generally can't be included in the signature, because it has to be updated by routers other than the originating router. For the same reason, the age field isn't included in the checksum computation 🧠. The age field MUST be protected, though, because if a faulty router started aging out other routers' LSAs, it would effectively deny service to those other routers 🚨

So here's how the protection works 💅. The signature MUST include the age field if and only if the originating router creates an LSA with age=MaxAge. Verification of the signature on a signed LSA MUST include the age field if and only if the age field value is MaxAge. This way, the originating router can flush an LSA, but other routers can't. An LSA that ages to MaxAge in the LSDB of any router still gets discarded by that router, but it isn't synchronously flushed from the AS 🦋

An LSA gets removed from a router's Link State Database in one of two ways: 1) the router receives a version of the LSA with the age field set to MaxAge and a valid signature that covers the age field, or 2) the LSA incrementally reaches MaxAge while it's stored by the router ⭐

If a standard OSPF V2 router goes down, an LSA from that router ages in the LSDBs of each remaining router until it reaches MaxAge somewhere. As soon as it hits MaxAge in some router's LSDB, it gets flooded, and that causes it to be flushed from the AS in a synchronized fashion 🌊. If a router running OSPF with digital signatures goes down, its signed LSAs get aged out by each remaining router individually. This slows down database convergence, but the databases will still converge, and a fairly obvious security hole gets closed 🔒✨

4. Key Management 🗝️

4.1. Identifying Keys 🪪

4.1.1. Identifying Router Keys and PKLSAs 💜

A router key is identified by the Router Id, plus the identifiers associated with that particular key in its certificate: TE Id and Router Key Id. All three of these values are stored in a PKLSA (format in 7.1) 🧾. The Router Id is the standard LSA header Advertising Router. The (TE Id, Rtr Key Id) pair is stored in the PKLSA certified data. The TE Id is a number assigned to a Trusted Entity that MUST uniquely identify one TE in the AS. The TE Id in a certificate identifies the TE that produced the certificate 🏷️. The Rtr Key Id is associated with a key by the Trusted Entity that produced the certificate. The Trusted Entity MUST produce a stream of Rtr Key Ids for one router, so the router won't re-use a key id until all references to the last key having that id are gone from the AS 🔁. If a key is re-played or re-used too soon, the Create Time in the key certification determines which key is current ⏰. Rtr Key Ids don't have to be sequential 🌸

4.1.2. Identifying TE Public Keys 🔑

Okay so every TE public key comes with an associated TE Id and TE Key Id, and the combo of (TE Id, TE Key Id) uniquely identifies one TE public key in the AS 💖 The TE Id is a number given to a Trusted Entity that uniquely identifies that TE in the AS. The TE Key Id has to identify one particular key for a TE at any given time 🦋 It's how you tell a new key apart from an old key for the same TE. It also tells apart keys for different signature algorithms if one TE is serving multiple algorithms. Each TE can have at most one current key per signature algorithm ✨

There can be multiple TE keys stored on each router 🌸 A TE public key is used to verify the certificates issued by other routers, so in an AS with several TEs, any given router might need several TE public keys. TE Key Ids don't have to be used in order, and they can be re-used 🍓 There's no timestamp for TE keys because they aren't certified, so there's no Create Time to lean on here 🙈

It's the job of Configuration Management to make sure that TE Key Ids aren't re-used before all references to a previously used key with the same (TE Id, TE Key Id) are gone from the AS 👑 It also has to make sure that a given (TE Id, TE Key Id) on one router points to the same key as it does on every other router, and that the rules for TE Key Replacement (section 4.5) are followed. Main character energy for Configuration Management, no cap 💅

4.1.3. Key to use for Signing 🖊️

A router is configured with a pair of keys 🗝️ The private key is protected from disclosure and is used for signing. The public key gets flooded in a PKLSA and is used for verifying signatures. A router may have one key per area to use for signing at any given time 🌈 A router may also use the same key for several or all areas. Flexible, iconic 🧚

4.1.4. Key to use for Verification ✅

There are three uses of signature verification in this design, and it's giving organised 💜

  1. The signature in a signed LSA (format in 7.3) can be verified with the public key distributed by the advertising router in a Public Key LSA. A signed LSA contains the (TE Id, Rtr Key Id) of the key used to sign it. The signed LSA's Advertising Router Id is used to retrieve the router's PKLSA, and the (TE Id, Rtr Key Id) shows whether the router key in the PKLSA is the same one used to generate the signature 🦋
  2. The router's signature in a PKLSA (format in 7.1) is verified with the public key contained in that same PKLSA 🌸
  3. The PKLSA contains data certified with a signature generated by a TE. The PKLSA certified data contains the (TE Id, TE Key Id) for the TE key that can be used to verify the certificate (format in 7.2). TE public keys must be configured on each router 🫶

4.2. Trusted Entity (TE) Requirements 🧚‍♀️

This design doesn't specify how the Trusted Entity (TE) must be implemented, where it must live, or how it must talk to routers 🙈 There are lots of very different possible approaches (e.g., an offline system with keys handed over by floppy or secure e-mail, an online automated key distribution center, and so on). The design does set certain requirements for what a Trusted Entity must do 👑

A Trusted Entity must generate a certificate for each signing router. That certificate contains individualised information about that router (format in 7.2) and is signed with the Trusted Entity private key. The Trusted Entity must have a unique TE Id for itself. It must create a Rtr Key Id for each router key that is unique for the given Router for this TE at this time. It must also timestamp certificates with a Create Time that is consistent for itself and for any other Trusted Entities operating in the AS 💅

Note: routers do not have to be time-synched, but TEs do. Create Time is used by routers as a relative measure to determine which key is more recent. ⏰

The TE Public key, TE Id, TE Key Id and Signature Algorithm must be made available to each router that processes certificates from this TE ✨

A TE can theoretically create certificates for more than one signature algorithm 🌈 The TE key and the router public key being certified don't have to use the same signature algorithm.

There can be more than one TE in an AS, but the TE Id must identify a unique TE 🎀

4.3. Scope for Keys and Signature Algorithms 🌍

The concept of "scope" applies to Router Keys, TE Keys, and Signature Algorithms 💖

  1. The scope of a PKLSA, and therefore of a router key, is the set of routers that will receive and store that PKLSA during OSPF flooding. A router produces a PKLSA for each attached area. In a router with more than one area, the PKLSAs for each area may match, or each may contain a different key. The scope of a PKLSA for an internal router is all the routers in that area. An ABR has multiple PKLSAs, each with a scope of one attached area. The scope of an ASBR's PKLSA is the same as the scope of the ASBR's ASEs: all the routers in all the non-stub areas in the AS. An ASBR that is also an ABR produces multiple PKLSAs, each with a scope of all the routers in all the non-stub areas in the AS. (This last case results in some situations that require special management - section 6) 😭
  2. The scope of a TE key is the set of routers that are configured with this key. If a system is configured properly, then a TE public key will be configured on all the routers that will receive PKLSAs certified by that TE key. The minimum scope for a TE key is an area. If one router distributes a key certified with a given TE key, then all the routers in the area must be able to verify the certificate. A TE key certifying an ASBR's key must have a scope of all non-stub areas in the AS. If the TE key is not on some router that receives PKLSAs certified by that TE key, then those PKLSAs and all the LSAs that require them will be discarded. A TE key reaches all the routers in its scope via out-of-band configuration 🚫
  3. The scope of a signature algorithm is the set of routers that are capable of verifying that algorithm's signatures. The minimum scope for a signature algorithm is an area. All routers in an area must be able to verify any signature algorithm used for signing by any router in the area. The algorithm used to certify an ASBR's key must have a scope of all non-stub areas in the AS if the ASEs are to be accessible everywhere (see section 6). If a signature algorithm is not available to verify an LSA, then the LSA must be discarded. If a signature algorithm is not available to verify the certification in a PKLSA, then the PKLSA must be discarded 💀

4.4. Router Key Replacement 🔄

Router keys should be changed periodically, and immediately if a key is found to be compromised 🚨 The regular period for changing a key is some locally determined function of the size of the key and the level of security needed 🍓

Each router can have ONE valid key per area at any given time. Limiting each router to one key per area is what lets key replacement double as key revocation, so there's no need for a revocation list and no need for routers to have synchronised clocks 🧠 Each new key for the router/area revokes the last key, as long as the "new" key has a more recent Create Time than the last one. The Create Time in each certificate is used to stop an old key from being reused. It's only used to compare how old certificates are, though, so the router doesn't have to run a time synchronisation protocol itself ⏳ An ABR can use the same key for all of its attached areas, or it can have a unique key for each area. This lets an AS be managed by area, with each area potentially having a different TE, signature algorithm, key size, and/or key 🌷

When a new key replaces an old key, the router must quickly replace LSAs signed with the old key with LSAs signed with the new key 🏃‍♀️ To change a router key, follow these steps:

  1. A valid certificate for the new key must be obtained for the router.
  2. The router builds and sends a new PKLSA with the new certificate.
  3. The router signs each self-originated LSA with the new key and sends them.

When a PKLSA is received:

  1. If the PKLSA's age = MaxAge, remove the PKLSA from the LSDB and age LSAs signed with this key to be MaxAge - MAX_TRANSIT_DELAY, if they were not already older than this. This is how you get rid of a key that should no longer be used 🗑️
  2. If the PKLSA is a refresh LSA for an existing key, update the LSDB 🔁
  3. If the PKLSA contains a different key than the one currently stored for this router, compare the certificate Create Time. If the PKLSA key is less recent, discard it. If the PKLSA key is more recent, install it in the LSDB and remove the old key from the LSDB. If an old key was deleted from the LSDB, age LSAs signed with this key to be MaxAge - MAX_TRANSIT_DELAY, if they were not already older than this 🥹

4.5. Trusted Entity Key Replacement

Okay so, TE public keys need to be swapped out every so often, bestie 🔑. The move is to make the TE public key pretty big so you don't have to replace it all the time 💪. A router can hold on to multiple TE public keys, and each one is uniquely identified by its TE Id and TE Key Id 🆔. Routers use TE keys to verify the certificates they get from other routers inside their PKLSAs 📜. When a router sends a new certificate signed with a new TE Key, every router that gets that PKLSA needs that new TE Key to verify, store, and use it. Managing TE public keys happens outside OSPF itself. A method is suggested, but this design doesn't mandate one 🤷‍♀️. At the start, every router must be configured with the TE Keys it'll need to verify the certificates it receives 🎀. If a TE Key might be compromised, you have to replace it with a new (possibly null) TE Key that has the same TE Id and signature algorithm 🚨. A compromised or faulty router can keep signing with the old TE key, but none of the properly configured routers will be able to verify those certificates 💀.

Changing a TE public key is a whole design challenge 😭. When the TE Public Key changes, every certificate that depends on it has to change too. The router keys inside those certificates may or may not change at the same time. When the TE key and the certificates change, every PKLSA that depends on them has to be reissued 📨. To verify those new certificates, every router that receives the new PKLSAs must already have the new TE Public Key. That makes the TE key replacement a synchronized event ⏰. Routers don't need synchronized clocks though, so no stress there 💖. The TE public key might get delivered out-of-band, like with a smart-card reader or a good old sneakernet 🧳. It's not reasonable to expect every router to get the TE public key at the exact same moment 🙅‍♀️. There are probably a few ways to hit these requirements. The method tested in the implementation goes like this ✨:

  1. Define a window of time for getting the new TE key onto every router ⏳. This could be minutes, hours, or even days, depending on how the distribution works. The window is a configuration value on each router called TE_KEY_DIST_INT, and it has to be the same for every router sharing a TE 🌸.
  2. Install the new TE key and its associated certificates (if there are any) on each router. Then signal the router code that the new TE key can be accessed now 🔓.
  3. The router starts a timer for TE_KEY_DIST_INT ⏲️. It also sets a flag saying a new TE key is present 🚩.
  4. On each router, when the timer goes off:
    • Access the new TE key.
    • If there are new certificates, build and send a new PKLSA.
    • Age all PKLSAs in the LSDB that were certified by the old TE Key to MaxAge - MAX_TRANSIT_DELAY.
  5. On each router, if a PKLSA certified by a new TE key shows up before the timer goes off:
    • If the new TE key can't be accessed, discard the PKLSA and log an ERROR 🙈.
    • Otherwise, access the new TE key.
    • Process the received PKLSA.
    • If there are new certificates, build and send a new PKLSA.
    • Age all PKLSAs in the LSDB that were certified by the old TE key to MaxAge - MAX_TRANSIT_DELAY.

So the net effect is that changing the TE public key takes a set amount of time 🕰️. That time runs from when the new TE key gets installed on the FIRST router, until the moment that router actually reads the key in 🥹. By the time the first router reads the key, every other router should already have it. If some router doesn't get the new TE key in time, it won't be able to verify any of the new PKLSAs it receives 😱. It'll log error messages and keep routing based on its old database until those LSAs time out 📉. The easy fix for a router in this state is to load the new TE key and restart the router 🔄. If this error is expected to happen, and restarting isn't acceptable, then you'd need some special-purpose code that reads in the TE key after it's been distributed and does database synchronization to catch up with everyone else 🛠️.

The group of routers that need the new TE key is every router in the scope of that Trusted Entity 🌐.

4.6. Flexible Cryptographic Environments

Most of the time, an AS will have one cryptographic setup running everywhere: one trusted entity, one signature algorithm, and one key per router 🧁. For the cases where that isn't true, this design lets you use multiple signature algorithms, multiple trusted entities, and multiple keys per router 🌈.

4.6.1. Multiple Signature Algorithms

Multiple signature algorithms are supported 🎨. Every router key and TE key has a signature algorithm attached to it. Every router that sends a key using a given algorithm must be able to generate signatures of that kind, and every router that receives keys using a given algorithm must be able to verify those signatures 🔐. If a router gets an LSA signed with an algorithm it doesn't support, the LSA must be discarded 🗑️. A router doesn't flood any LSA it can't verify 🚫. When you use multiple signature algorithms, you have to figure out the scope of each one (see section 4.3), and routers have to be configured to support those algorithms to match 📋.

If an Area supports two signature algorithms and needs full connectivity, some routers can sign with algorithm A and others with algorithm B. But every router in that area has to be able to verify both A and B signatures 🤝. In an AS split into areas, each area is allowed to use a different signature algorithm 🗺️. The ABR connecting two areas would need to support both algorithms, but the internal routers in a given area only need to know one algorithm 💅.

ASBRs are the tricky part of this setup 😬. ASEs flood throughout the non-stub areas of an AS. Any router that can't verify an ASE will discard it without flooding it. So, to get to an ASE, a router and every router along the flooding path must support the algorithm the ASBR used 🛤️. One way around this is a lowest-common-denominator algorithm. ASBRs all sign with it, and every router in the AS can verify it, along with whatever other algorithms are in use 🌟. Another approach is to put ASBRs on the backbone, and configure every area that uses a different signature algorithm from the ASBR to have a default route to the backbone 🦋. A combined approach lets an ASBR sit in a non-backbone area as long as it uses an algorithm the backbone supports, and the areas running different algorithms are configured with a default route to the backbone 🧩. A router that's both an ABR and an ASBR has special limitations, so check section 6 for those ⚠️.

Right now there's only one signature algorithm defined for this design: RSA_MD5 🎯. The RSA algorithm is defined in PKCS #1 [9], and the signature and key formats this design uses are defined in RFC2065 [10] 📖.

4.6.2. Multiple Trusted Entities

An AS can have multiple Trusted Entities 🏛️. Each TE gets its own unique TE identifier. Every router that receives PKLSAs certified by a given TE must have that TE's public key 🔑. If a router gets a PKLSA certified by a TE it doesn't have a public key for, the PKLSA must be discarded 🚮. When you use multiple TEs, you have to work out the scope of each TE (see section 4.3), and every router in that scope must be configured with the TE key 🫶.

4.6.3. Multiple Keys for One Router

An ABR can have one key for each attached area 🗝️. Those keys can differ in size, algorithm, and/or certifying TE 📏. Usually, each key's "scope" is the attached area it belongs to, so the keys don't conflict with each other 🙌. A router that's both an ABR and an ASBR has special limitations here too, so see section 6 👑.

5. Compatibility with Standard OSPF V2 ✨

okay so OSPF with Digital Signatures is compatible with standard OSPF V2 inside an autonomous system 💖 Within an AS, there may be "signed" areas and "unsigned" areas. There will never be both signed and unsigned LSAs used in any one area 🎀 Each area has an environment flag saying whether it is "signed" or "unsigned". The environment flag is a per area configuration value for the router. The signed areas must contain all routers running OSPF with Digital Signatures, and the unsigned areas contain routers running standard OSPF V2 code (or OSPF with Digital Signatures with all areas set to be unsigned). An area border router connecting a signed to an unsigned area must be running OSPF with Digital Signatures with one area set to be unsigned 🦋

In order to arrange this limited compatibility, a router running OSPF with Digital Signatures must be able to process both signed and unsigned LSAs. The only router that will actually be processing both kinds of LSAs is an Area Border Router connecting a signed area to an unsigned area. An ABR connecting a signed to an unsigned area will generate signed summaries for one area and unsigned summaries for the other. An ABR must not flood signed LSAs into unsigned areas. An ABR must not flood unsigned LSAs into signed areas. This results in AS External LSAs being dropped if they reach an area with a different environment from the one they were created in 🙈 There are special limitations for a router that is an ABR and also an ASBR, so see section 6 👑

Complete connectivity is still provided within the AS, thanks to the summarization done by ABRs connecting signed and unsigned areas 🌈 There are limitations on connectivity to AS external routes in an AS with a mixture of signed and unsigned areas, depending on where the AS border routers are. An ASBR in a signed area will generate signed ASE LSAs. These LSAs get flooded to every contiguously connected signed area. The connected signed areas are the "scope" of these ASEs. A host located in an area that is not in this scope will not have connectivity to these external routes. An ASBR in an unsigned area will generate unsigned ASE LSAs. These LSAs have a scope of all the contiguously connected unsigned areas, and they are available to hosts in this scope. To arrange complete connectivity to an ASE route in an AS with signed and unsigned areas:

  1. Place the ASBR on the backbone.
  2. Signed Backbone: have some ABR in each unsigned area advertise a default route to the backbone.
  3. Unsigned Backbone: have some ABR in each signed area advertise a default route to the backbone.

Given this design for a mixed AS, routing is available throughout the AS, but the authentication and integrity provided by this design will only be effective for routes that are inside a signed area, or that traverse only signed areas 🥺 There is no mechanism for a data packet to state a preference for signed routes. The basic rules of the OSPF protocol make sure that intra-area routes are preferred to inter-area routes, that routes within the AS are preferred to AS external routes, and that inter-area routes go from area1->backbone->area2. OSPF does not allow looping, or routes of the form area1->area2->area3. Because of these properties of OSPF routing, an AS can contain signed and unsigned areas and still achieve a predictable level of authentication 💜

6. Special Considerations/Restrictions for the ABR-ASBR 💅

okay this part is so important, bestie 😭 There are special restrictions and configuration considerations for a router running OSPF with Digital Signatures that is both an Area Border Router and an Autonomous System Border Router. An ASBR produces AS external LSAs that get flooded throughout the non-stub areas of the AS. An ABR that is generating digital signatures may be using a different key, certifying Trusted Entity, or signature algorithm for each of its attached areas, or it might be signing in some areas and not in others.

An ABR/ASBR with no restrictions on its configuration could produce multiple versions of an ASE that would all be flooded throughout the non-stub areas of the AS. Producing multiple versions of LSAs like this would be detrimental to performance, and could produce unpredictable routing behavior 💀

The PKLSA of an ASBR is also flooded throughout the non-stub areas of the AS. In the case of an ABR/ASBR there could be multiple, distinct PKLSAs for a given router, one per attached area, all being flooded throughout the AS. If two distinct PKLSAs from one ABR/ASBR router were present in one area, the key with the most recent create time would be stored, and all LSAs signed with a less recent key would be unverifiable 😱

The simplest way to deal with this problem, and the method recommended by this document, is the following:

If an ASBR must also be an ABR, then the security configuration (key, signature algorithm, certifying Trusted Entity, environment = signed/unsigned) for all attached areas must be the same. This way the PKLSA and the ASEs produced for each area match, and there is no proliferation of versions of LSAs. 🫶

7. LSA formats 🦋

7.1. Router Public Key LSA (PKLSA) 🔑

okay the Router Public Key LSA is the vehicle for distributing a router public key 🧚 The PKLSA is sent by one router and stored by all the other routers in the flooding scope. The PKLSA contains the public key that other routers will use to verify the signatures created by this router. A Router PKLSA is communicated in the usual database exchange and via flooding mechanisms. The regular period for sending this LSA is LSRefreshTime. The Router PKLSA is also sent when there is a new key, or a key that needs to be flushed from the system 🌸

The flooding scope of a PKLSA is the area, except in the case of ASBRs. The flooding scope of an ASBR's PKLSA is the same as that of the ASEs. The "role" of the router (RTR, ABR, ASBR, ABR-ASBR) is stored in the PKLSA inside the certificate, and it can be checked during flooding ✨

Here's the layout, no cap, it's very pretty 😍

ROUTER PUBLIC KEY LSA

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
   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
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |            LS Age             |   Options     |    LS Type    |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |                        Link State ID                          |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |                     Advertising Router                        |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |                     LS Sequence Number                        |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |         LS Checksum           |            Length             |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |                  Certificate (format in 7.2)                  /
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |                           Signature                           /
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
  |         Cert Length           |         Sign Length           |
  +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

Now the fields, one by one 💅

  • LS AGE: Defined in OSPF RFC [3].
  • OPTIONS: Defined in OSPF RFC [3].
  • LS TYPE: 16 for Router Public Key LSA. First bit set to indicate a signed LSA.
  • LINK STATE ID: Contains the Advertising Router Id (see next field).
  • ADVERTISING ROUTER: Defined in OSPF RFC [3].
  • LS SEQUENCE NUMBER: Defined in OSPF RFC [3].
  • LS CHECKSUM: Defined in OSPF RFC [3]. Checksum does not cover the signature.
  • LENGTH: Defined in OSPF RFC [3]. Length does include the Signature field, Cert Length and Sign Length.
  • CERTIFICATE: Format in section 7.2.
  • SIGNATURE: The advertising router's signature of this LSA. This can be verified using the enclosed Router Public Key. The signature covers the LSA header and message, starting with the LSA header options field and ending with the Trusted Entity certification field. For sign and verify, the last two fields (Cert Length and Sign Length) are appended immediately after the Certificate. When complete, the signature is inserted between the Certification and the Cert Length. There are two exceptions to this coverage:
    1. If the LSA was generated with an age=MaxAge, then the signature begins with the age field (see section 3.3).
    2. The checksum in the LSA Header is set to zero for the computation of the signature.

A pad is added to the end of the signature field to allow the next field to begin on a (4 byte) word boundary. The format used for an RSA-MD5 signature is defined in section 4.1.2 of RFC2065 [10]. 🌈

  • CERT LENGTH: The length in bytes of the Certification inside the Certificate. Does not include pad that may follow Certification.
  • SIGN LENGTH: The length in bytes of the Signature. Does not include pad that may follow Signature.

7.2. Router Public Key Certificate 🎀

okay so a router public key certificate is basically a little package of data that a Trusted Entity signs for the router 💅 It gets included in the router PKLSA and in the router configuration information. If you want to change any of the values in it, you can't just edit them: you have to go get a brand new certificate from a TE 🙈

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                          Router Id                            |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |     TE Id     |   TE Key Id   |   Rtr Key Id  |    Sig Alg    |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                          Create Time                          |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |        Key Field Length       |  Router Role  |  #Net Ranges  |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                          IP Address                           |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                         Address Mask                          |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |           IP Address/Address Mask for each Net Range ...      /
   | ...                                                           /
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                       Router Public Key                       |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                         Certification                         /
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

Here's the field breakdown, bestie. Every one of these matters 🫶

ROUTER ID       Advertising Router.

TE ID           TE Id must uniquely identify one TE in the AS.
                A number between 1-250.  0 reserved for null.
                251-255 reserved for future needs.

TE KEY ID       Must uniquely identify a particular key for a given
                TE at any given time.  A TE Key Id may be re-used
                after all references to it are gone from the AS.  A
                number between 1-250.  0 reserved for null.  251-255
                reserved for future needs.

RTR KEY ID      Must be unique for the TE and Router at any given
                time. The combination of (TE Id, Rtr Id, Rtr Key Id)
                uniquely identifies a particular router key at a
                given time.  A Rtr Key Id may be re-used after all
                references to it are gone from the AS.  Create Time
                resolves any conflict that could be caused by
                replaying old keys.  A number between 1-250.  0
                reserved for null.  251-255 reserved for future
                needs.

SIG ALG         The signature algorithm for the Router Public Key.
                The signature algorithm encompasses the hash
                algorithm used as well.  Currently defined value =
                RSA-MD5(1).  Values 2-252 are available for future
                definition.  Values 0 and 253-255 are reserved.  The
                Sig Alg value is registered with IANA.  Future
                signature algorithms will have to be defined or
                referenced in this document, and registered with
                IANA.

CREATE TIME     Timestamp set by the TE.  An unsigned number of
                seconds since the start of January 1, 1970, GMT,
                ignoring leap seconds.  Used to compare two
                certificates and determine which is more recent.
                Requires that time synchronization for TEs, but not
                for routers.

KEY FIELD LENGTH    The length in bytes of the Router Public Key.
                Does not include pad that may follow Router Public
                Key field.

ROUTER ROLE     Router (R=1), Area Border Router (ABR=2), Autonomous
                System Border Router (ASBR=4), ABR and ASBR (ABR-
                ASBR=6).

#NET RANGES     The number of network ranges that follow.  A network
                range is defined to be an IP Address and an Address
                Mask.  This list of ranges defines the addresses that
                the Router is permitted to advertise in its Router
                Links LSA.  Valid values are 0-255. If there are 0
                ranges the router cannot advertise anything.  This is
                not generally useful.  One range with address=0 and
                mask=0 will allow a router to advertise any address.

IP ADDRESS & ADDRESS MASK
                Define a range of addresses that this router may
                advertise.  Each is a 32 bit value.  One range with
                address=0 and mask=0 will allow a router to advertise
                any address.

ROUTER PUBLIC KEY    A key that can be used to verify the signatures
                produced by this router.  The internal format for the
                Router Public Key is signature algorithm dependent.

                A pad is added to the end of the Router Public Key
                field to allow the next field to begin on a (4 byte)
                word boundary.

                The format used for an RSA-MD5 public key is defined
                in section 3.5 of RFC2065 [10].

CERTIFICATION   The Trusted Entity's signature of the certified data.
                This signature can be verified with the TE public key
                identified by TE Id and TE Key Id given in this
                packet.  The length of the certification depends on
                the key size, and is stored in the PKLSA Cert Length
                field.  A pad is added to the end of the
                Certification to allow the next field to begin on a
                (4 byte) word boundary.

                The format used for an RSA-MD5 signature is defined
                in section 4.1.2 of RFC2065 [10].

7.3 Signed LSA ✨

okay the signed LSA is an OSPF LSA with signature data and a digital signature stuck onto it 🔥 The first bit of the LSA Type field gets set to show that a signature is there. The signature comes right after the LSA Data, and the signature length and id fields chill at the very end of the signed LSA 🦋

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |            LS Age             |   Options     |    LS Type    |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                        Link State ID                          |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                     LS Sequence Number                        |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |         LS Checksum           |            Length             |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                            LSA Data                           /
   / ...                                                           /
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |                            Signature                          /
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
   |  Rtr Key Id   |     TE Id     |         Sign Length           |
   +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

Here's the field rundown for signed LSAs 💖

LS AGE          Defined in OSPF RFC [3].

OPTIONS         Defined in OSPF RFC [3].

LS TYPE         Standard LSA Type with the first bit set to indicate
                the presence of security data and a signature. This
                creates a new signed LSA type for each existing type.

LINK STATE ID   Defined in OSPF RFC [3].

ADVERTISING ROUTER  Defined in OSPF RFC [3].

LS SEQUENCE NUMBER  Defined in OSPF RFC [3].

LS CHECKSUM     Defined in OSPF RFC [3].
                Checksum does not cover the signature.

LENGTH          Defined in OSPF RFC [3].
                Length does include the Signature and security
                related fields at the end of the LSA.

SIGNATURE       The advertising router's signature of this LSA.  The
                signature covers the LSA header and data starting
                with the LSA header options field and ending with the
                Trusted Entity certification field.  For sign and
                verify, the last three fields (Rtr Key Id, TE Id,
                Sign Length) are appended to the Certificate.  When
                complete, the signature is inserted between the
                Certification and the Rtr Key Id.  There are two
                exceptions to this coverage:

                1) If the LSA was generated with an age=MaxAge, then
                the signature begins with the age field (see section
                3.3).

                2) The checksum in the LSA Header is set to zero for
                the computation  & verification of the signature.

                A pad is added to the end of the signature to allow
                the next field to begin on a (4 byte) word boundary.

                The format used for an RSA-MD5 signature is defined
                in section 4.1.2 of RFC2065 [10].

RTR KEY ID      Used to identify the router key used to sign this
                LSA. The combination of (TE Id, Rtr Id, Rtr Key Id)
                uniquely identifies a particular router key at a
                given time, and can be used to look up the PKLSA for
                the router key needed to verify this Signed LSA.  A
                number between 1-250.  0 reserved for null.  251-255
                reserved for future needs.

TE ID           The id of the Trusted Entity that produced the
                certificate.  TE Id must uniquely identify one TE in
                the AS.  A number between 1-250.  0 reserved for
                null. 251-255 reserved for future needs.

SIGN LENGTH     The length in bytes of the Signature.
                Does not include pad that may follow Signature.

8. Configuration Information 🎀

okay bestie, this section is the ultimate setup checklist 🧳 here's everything a router needs to have ready:

Trusted Entity Information Set: (one per Trusted Entity used by this
router)

   Trusted Entity ID - TE Id
        Identifies the Trusted Entity within the AS (defined in 7.2).
   Trusted Entity Key Id - TE Key Id
        Identifies the particular key for this Trusted Entity
        (defined in 7.2).
   Trusted Entity Public Key
        A public key for this Trusted Entity.
        The format used for an RSA-MD5 public key is defined in
        section 3.5 of RFC2065 [10].
   Signature Algorithm < and optional parameters >
        The signature algorithm for the public key (defined in 7.2).

Router Information Set: (at least one for the router)

   Router Private Key
        The router's private key that goes with the public key in the
        certificate following. The format used for the private key
        depends on the crypto package used by your implementation.
        This key is not transmitted as part of this design.  Our
        implementation uses the private key format compatible with
        RSAREF [9].
   Router Certificate (format in 7.2).

Timing Intervals:

   Trusted Entity Key Distribution Interval (TE_KEY_DIST_INT)
        The period of time, in seconds, needed to get a TE public key
        installed on all the routers in the TE's scope.
   Maximum Transit Delay (MAX_TRANSIT_DELAY)
        The maximum period of time, in seconds, that it should take
        for an LSA to reach all the routers in the AS.

Router Information per attached Area:

   Environment flag
        Signed=1, Unsigned=0

9. Remaining Vulnerabilities 💀

okay this part is the honest truth moment 🥺 with this mechanism, one router can still spread incorrect data about the stuff it's responsible for. so an autonomous system using digital signatures here is not totally invulnerable to routing chaos from a single router. the area border routers and autonomous system border routers can still inject wrong routing info, and any single internal router can be wrong about the routing info it originates about its own links.

9.1. Area Border Routers 🌸

even with this design, area border routers can inject incorrect routing info into their attached areas about the backbone and the other areas, using Summary LSA's. they can also inject incorrect routing info into the backbone about their attached area.

here's the tea ☕ all the area border routers in one area work from the same database of LSA's received in their common area, so they could corroborate each other. any area border router for an area could double check the Summary LSA's received over the backbone from other ABR's in the area, and double check the Summary LSA's flooded through the area from the other area border routers. the other routers in the area or backbone should be warned if this check fails. the warning could be a signed message from the area border router that detected the failure, flooded using the usual mechanism.

another option: the area border routers in an area could each originate multiple sets of Summary LSA's, one set for itself with its own information and one set for each of the other area border routers in the area, containing the information each of them should originate. then every router in the area or backbone could figure out for itself whether the area border routers agreed. this split of information with coordinated processing fits the link state paradigm, where information and processing get duplicated in each router 🧠

both options mean a lot of extra processing and extra message transmission, on top of the processing already needed for signature generation and verification. the vulnerability is isolated to a few points in each area, the source of bad info is detectable (when the bad info gets spotted), and the protection is costly. so we have not added this protection to this design 🙈

9.2. Internal Routers 🦋

the internal routers can be wrong about the info they originate themselves.

a router could announce an incorrect metric for a valid link. there's no way to guard against this, but the damage would be small and localized even if the router announces that a link is up when it's down, or vice versa.

a router could announce a connection that doesn't actually exist. if a router announces a non-existent connection to a transit network, the OSPF Dijkstra computation won't consider that connection without a similar announcement from another router at the other "end". so no damage happens (beyond the network impact of transmitting and storing the incorrect info) without another router cooperating. a router could also announce a connection to a stub network or a host route that doesn't exist. the Dijkstra computation can not do the same check against a similar announcement from the other "end", because there is no other end. this is a vulnerability 😬

a faulty router announcing a nonexistent connection to a stub network or host could end up receiving IP packets bound for that network or host. unless the faulty router then forwarded those packets to the correct destination using source routing, the failed delivery could expose the incorrect routing. to exploit this deliberately, the faulty router would have to be able to handle and pass on the traffic received for the wrongly announced destination. plus, if the incorrect routing got discovered, the signatures on the routing info would identify the faulty router as the source of the wrong info. and finally, this design checks router advertisements against allowed address ranges certified by a trusted entity. a faulty router could announce nonexistent host or stub network routes, but only to addresses within its allowed ranges ✨

9.3. Autonomous System Border Routers 👑

the autonomous system boundary routers can produce incorrect routing info in the external routes information they originate. there's no way to double check or corroborate this info the way there is with area border routers. no authority inside an autonomous system exists to authorize the networks an autonomous system boundary router could announce, the way one does for the internal networks an internal router could announce. so the autonomous system boundary routers remain an unprotected vulnerability. with that in mind, special care should be taken to protect the autonomous system boundary routers using other means 🚨

10. Security Considerations 🔐

this entire memo is about security considerations, bestie 💅 every bit of this document is about keeping routing safe, so take it all super seriously 💀

11. References 📚

  • [1] Finn, Gregory G., "Reducing the Vulnerability of Dynamic Computer Networks," ISI Research Report ISI/RR-88-201, University of Southern California Information Sciences Institute, Marina del Rey, California, June 1988.
  • [2] Kumar,B and Crowcroft,J., "Integrating Security in Inter-Domain Routing Protocols", Computer Communications Review, Vol 23, No. 5, October 1993.
  • [3] Moy, J., "OSPF Version 2," RFC 1583, Proteon, Inc., March 1994.
  • [4] Perlman, R., "Network Layer Protocols with Byzantine Robustness", Ph.D. Thesis, Department of Electrical Engineering and Computer Science, MIT, August 1988.
  • [5] Perlman, R., "Interconnections: Bridges and Routers", Addison-Wesley, Reading, Mass., 1992.
  • [6] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C," John Wiley & Sons, Inc., New York, 1994.
  • [7] Steenstrup, M., "Inter-Domain Policy Routing Protocol Specification: Version 1", RFC 1479, BBN Systems and Technologies, July 1993.
  • [9] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., June 1991, Version 1.4.
  • [10] Eastlake D. & Kaufman C., "Domain Name System Security Extensions", RFC2065, January 1997.
  • [11] Moy J., "OSPF Version 2", Cascade Communications Corp, Work In Progress.

12. Authors' Addresses 💌

Sandra Murphy  murphy@tis.com
Madelyn Badger  mrb@tis.com
Brian Wellington  bwelling@tis.com

Trusted Information Systems
3060 Washington Road
Glenwood, MD  21738

that's the whole doc, bestie 🌈🫶 you made it through!

📦 where this page comes from