hannes@Frankfurt> show isis database extensive [… ] TLVs: Area address: 49.0001 (3) Speaks: IP, IPv6 IP router id: 192.168.1.18 IP address: 192.168.1.18 Hostname: Stockholm IS neighbor: Frankfurt.00, Metric: 1 IP address: 172.16.33.45 [… ] IOS command output London#show isis database verbose 1921.6800.1047.00-00 IS-IS Level-2 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL 1921.6800. * 0x00000040 0xD323 491 0/0/0 1047.00-00 Area Address: 49.0001 NLPID: 0x81 IS neighbor: Vienna.02, Metric: 63 [… ] The LSP shown in the IOS command output does not contain the Hostname TLV. As it does not list any IP-related TLVs it may be that this is a CLNS-only router that is prob- ably running older software that does not support the Hostname TLV. If the hostnames made their way into the hostname cache, then all IS-IS occurrences of the System-ID are replaced using their respective name. See Table 13.1 for how Pennsauken’s System, Node and LSP-IDs are represented using the new name resolution service. Today IS-IS is one of the most convenient routing protocols. It aids the network engin- eer and troubleshooter by offering a kind of distributed name service. All of the IS-IS- related display functions like displaying adjacencies, examining the link-state database or logging functions make use of a System-ID to hostname translation cache and display System-IDs, Node-IDs and LSP-IDs with their name rather than their hexadecimal rep- resentation. The next extension to IS-IS will cover the authentication scheme of LSPs and their implementation. 350 13. IS-IS Extensions 13.2 Authenticating Routing Information Authenticating routing protocol messages is a basic building block for every network security strategy. Some people argue that authentication is pushing the envelope for IS-IS since all the messages run natively on Layer 2, which means that the protocol cannot be exposed to a remote attack from the Internet because there is simply no possi- bility for transporting a Layer-2 frame over the Layer-3 infrastructure. This is just another way to say “you can’t route a frame”. An attacker needs to have local, physical access to inject malicious information. Others argue that an additional barrier like authentication helps to keep out the errors introduced by, for example, unskilled NOC personnel. One application is that new IS-IS adjacencies cannot be created on an interface without knowing the password beforehand (this is just one example). Both attacks and errors are cases where the use of authenticating PDUs makes sense. ISO 10589 defines a dedicated Authentication TLV for confirming the authenticity of the PDU. Figure 13.2 shows the structure of this TLV. The Authentication TLV uses a field called Authentication Type to further indicate how the password is encoded. Currently there are two encoding methods defined: • Simple Text Authentication • HMAC-MD5 The left-hand side of Figure 13.2 shows the formatting of the TLV if Simple Text Authentication is used. The password is a free-form string that can be between 1 and 254 bytes in size. On the right-hand side there is the formatting of TLV #10 if HMAC-MD5 Authentication is used. The size is fixed to 16 bytes and contains a MD5 sum of the entire packet. Authenticating Routing Information 351 Type Length Authentication Type 10 Bytes 1 1 1–254 Type Length Authentication Type 10 Bytes 1 1 16 Plain Text Password HMAC-MD5 Password 11 17 171 FIGURE 13.2. The Authentication TLV #10 supports two different authentication types 13.2.1 Simple Text Authentication Code point 1 indicates simple text encoding of the password. Simple text encoding means that the password is encoded clear text. The following tcpdump output shows that the password contained in the IIH is transported clear text over the circuit. Tcpdump output 11:35:23.248504 OSI, IS-IS, length: 52 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1009, holding time: 27s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 52 Point-to-point Adjacency State TLV #240, length: 1 Adjacency State: Up (0) Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.33.6 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Authentication TLV #10, length: 11 simple text password: LeiaOrgana The dilemma of clear text passwords is obvious, and more so if routers are connected via broadcast circuits. Consider Figure 13.3 – routers and servers are connected over a LAN infrastructure like, for example, Ethernet Switches. Recall from Chapter 4, “IS-IS Basics”, that all the IS-IS messages on LANs are sent using functional MAC addresses AllL1ISs (0180:c200:0014) for Level 1 PDUs and AllL2ISs (0180:c200:0015) for PDUs aimed at Level 2. Note that these functional MAC addresses have the lowest bit of their most sig- nificant byte (MSB) set. The lowest bit of the MSB of the Destination MAC Address is also the “Broadcast Bit” which makes LAN switches treat it like a broadcast, that is, to flood it out on all ports. Ultimately all ports on the LAN switch see the Hello with the clear text password, which makes it far too easy for eavesdroppers to get hold of the password. If a hacker gets access to a server, all they have to do is run a network analyzer such as tcpdump to sniff the IS-IS passwords and then the hacker has all they need: direct network access and the password used for authenticating network updates. Now it is easy to inject malicious routing updates and to take down the entire network. Therefore sim- ple text authentication provides just a marginal additional protection. 352 13. IS-IS Extensions Ethernet Amsterdam.00 Stockholm.00 IS-IS PDU Broadcast Server Server F IGURE 13.3. Each device connected to the LAN infrastructure receives IS-IS-related messages because the Destination MAC address has the Broadcast Bit set 13.2.2 HMAC-MD5 Authentication The second encoding scheme is to use HMAC-MD5 hashes for securing the routing updates. By using MD5 hashes the password does not travel clear text over the circuit. The HMAC-MD5 algorithm is documented in RFC 2104. It describes a one-way opera- tion to get a hash based on a bit field and a shared secret password. One-way function means that, based on the hash and the bit field, the password cannot be reconstructed. The authentication type for HMAC-MD5 is 54 and it is always using a fixed length of 16 bytes. The following tcpdump output shows the 16-byte output of the hash. Note the TLV length is 17 bytes because the first byte is reserved for the Authentication Type field. Tcpdump output 11:35:27.216425 OSI, IS-IS, length: 58 p2p IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1008, holding time: 27s, Flags: [Level 2 only] circuit-id: 0x01, PDU length: 58 Point-to-point Adjacency State TLV #240, length: 1 Adjacency State: Up (0) Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.33.6 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Authentication TLV #10, length: 17 HMAC-MD5 password: a933242e676df1275e323b648ab5e387 13.2.3 Weaknesses In contrast to OSPF, IS-IS lacks cryptographic sequence numbers. This means IS-IS is not prone to so-called “replay attacks”. A replay attack means that an attacker is recording messages and replaying them at a later time in order to do something harmful. Using replay attacks it is quite easy to tear down an existing adjacency. Consider Figure 13.4. The hacker is constantly eavesdropping on a LAN and trying to record IS-IS IIH (Hello) messages in order to launch a replay attack. The first set of packets for adjacency estab- lishment are of particular interest. Consider the adjacency finite state machine mentioned in Figure 5.16 in Chapter 5, “Neighbour Discovery and Handshaking”. The idea is to catch the message when the router is transitioning from the New to the Init state and to replay that message at a later time. Replaying a pre-recorded Hello that reports an Init state when the adjacency is already established immediately moves it to the Down state. The receiver has no chance of detecting that this is an attack, as the IIH is properly authenticated. Of course, a few packet exchanges after the attack, the adjacency would move again to the Up state as the periodic Hellos from both Amsterdam and Stockholm declare the adjacency Up again. However, flapping adjacencies have a severe impact on the rest of the network because new LSPs need to be generated; they need to get flooded throughout the network, SPF calculations need to be scheduled and finally the new FIB state needs to get propagated Authenticating Routing Information 353 to the forwarding planes. Even if the router OS supports protection techniques like adja- cency hold down, the attack disrupts adjacencies for a period of time. The way to prevent replay attacks is to add an element that is changed for every Hello that is transmitted. By including a counter or Sequence Number (not to be confused with the Sequence Number of the LSP) in the hashing, a replay attacker needs to wait 2 32 IS-IS packets in order to repeat an attack. Depending on the implementation-specific protection timers, an attacker needs to wait more than a hundred years before he can suc- cessfully repeat a pre-recorded message. The assumption here is that a router does not generate more than one IS-IS PDU per second in order not to cycle too fast through the sequence space. This assumption is absolutely valid, as most of the IS-IS PDU types are rate-limited by the specification, like the LSP-min-generation-, CSNP- or Hello-Interval. Up until now, no such sequencing mechanism has been deployed. Naiming Shen, a development engineer with Redback, came up with a proposal for a new TLV on the IS- IS-WG list in the IETF. Figure 13.5 illustrates the proposed Sequence Number TLV. The basis structure of the TLV is to wrap a 32-bit number that is monotonically increasing. Even if IS-IS is lacking in robustness against replay attacks, it is recommended to use MD5 authentication when deploying an IS-IS network. Most of the harm that can be done based on replay attacks can be avoided by network design techniques, such as not using broadcast circuits in the core. Using replay attacks, an attacker can create some moderate stress in other parts of the network. After all, modern routers have enough processing power to withstand such moderate attacks. So the most impacted place in the network will 354 13. IS-IS Extensions Ethernet Amsterdam.00 Stockholm.00 IIH Amsterdam AllL1IS Up IIH Stockholm AllL1IS Up IIH Stockholm AllL1IS Init Server Server FIGURE 13.4. An attacker replays a previously recorded message where the adjacency was in Init state to tear it down Type Length Sequence Number 241 Bytes 1 1 4 4 F IGURE 13.5. A monotonically increasing Sequence Number makes sure that the MD5-hash varies for each transmitted Hello be where the hacker is trying to cycle adjacencies through the Down state, which puts the hacker on the spot because he needs to have a direct link to that network. However, not using authentication may put a hacker in the position to attack any sys- tem he wants to in the network and cause network-global stress that is not easily detected in the first place. A nightmare for any NOC team. 13.2.4 Point-to-point Interfaces Running authentication on point-to-point interfaces requires some explanation and caveats. First, point-to-point interfaces are different from LAN interfaces regarding their PDU types. Hello PDUs from the two levels need to share the point-to-point PDU type rather than hav- ing their own, like LAN IIHs do. Those constraints were further explained in Chapter 5, “Neighbour Discovery and Handshaking”. The fact that both levels need to share a PDU type also has implications for authentication. Authentication in IS-IS always applies to the entire PDU. If the PDU type is shared between levels, then a single password needs to be shared for both levels as well. There is a potential for conflict in the configuration too, as (for example) if two passwords (one for each level) are configured, then the router needs to make a decision. In IS-IS the rule set is simple: for Hello authentication, the Level-1 password is used. If there is no Level-1 password configured, then no Hello authentication is performed. In the configuration example authentication for Hellos is turned on for both levels using different passwords. JUNOS configuration The authentication-key HanSolo is configured for Level 2 and LeiaOrgana for Level 1 interface authentication. Because JUNOS scrambles all passwords, in the example we have written down the password as commentary. hannes@Frankfurt> show configuration [… ] protocols { isis { [… ] interface so-0/1/2.0 { level 2 { hello-authentication-key “$9$dyVgJiHmTF/.P”; # HanSolo hello-authentication-type simple; # SECRET-DATA } level 1 { hello-authentication-key “$9$c-PSvLdVYoZjs25Q”; # LeiaOrgana hello-authentication-type simple; # SECRET-DATA } } interface lo0.0; } } The tcpdump output reveals that only the Level-1 authentication key is used. Authenticating Routing Information 355 Tcpdump output For point-to-point IIH authentication the Level-1 password is used. 20:10:22.699068 OSI, IS-IS, length: 61 point-to-point IIH, hlen: 20, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1008, holding time: 27s, Flags: [Level 1, Level 2] circuit-id: 0x01, PDU length: 61 [… ] Restart Signaling TLV #211, length: 3 Flags [none], Remaining holding time 0s Authentication TLV #10, length: 11 simple text password: LeiaOrgana Authentication is today imperative for securing routing protocols. Most authentication migrations have network-wide impact and require a strategy for gradually transitioning the network. 13.2.5 Migration Strategy There are three main authentication-related migration scenarios. All three migration sce- narios have one assumption in common: it is not possible to change the entire network in one “flag day” and there must not be any outage longer than (to cite a common example) a single adjacency reset. 13.2.5.1 General Decisions and Routing Software Selection Before starting to implement authentication in an IS-IS, two questions need to be answered: • What IS-IS PDU types need to be authenticated? • What authentication type should be used? The most likely answer is that HMAC-MD5 should be used as the authentication method for all PDU types. Unfortunately, there are some restrictions in older routing software. Particularly in IOS, IS-IS authentication has been neglected in the past. There are many caveats as to what PDUs are authenticated and which authentication types are supported in older releases of the IOS software. That has recently changed – as of 2004 there is full authentication support for all PDU types and both authentication methods. Full support has been available in versions equal or higher than IOS: • 12.0(21)ST • 12.2(11)S • 12.0(22)S • 12.2(13)T • 12.2(14)S 356 13. IS-IS Extensions If you do not have the choice, and are tied for some reason to a particularly IOS software release, then please proceed to Section 13.2.7, “Interoperability”, which will discuss an approach for making authentication work using older IOS releases. Here are three authentication migration scenarios for an IS-IS network. The first of the three migration scenarios is the “Greenfield” approach: transition from an entirely unauthenticated IS-IS network to an authenticated one. 13.2.5.2 Greenfield Migration The Greenfield migration strategy uses asymmetric authentication. The term “asymmet- ric” refers to the ways how and if authentication information is sent and verified. Asymmetric authentication sends authentication information, but does not verify it. That way routers can be configured gradually to send their PDUs augmented with authentica- tion information. But they do not verify if the password is correct upon receipt. Once all the routers in the network send the correct authentication information, the routers can gradually switch to symmetric authentication that does check to see if the supplied authentication string is correct. If it is not, then the PDU is discarded. The second migration scenario covers the case of changing an authentication key in a live network. 13.2.5.3 Key Migration Any good security policy can change passwords over time. A core network – which is admittedly a cumbersome environment for any change – should change the authentication on a periodic basis as well. For authentication key migration there are two possibilities: • Asymmetrical authentication • Multiple key verification Asymmetrical key verification is the panacea that works for all migration scenarios. This may even be a viable solution for the Greenfield scenario; however, for the key migration method, the drawback is that a door is opened during the migration phase. An implementation can decide to store many authentication keys on the router. One of those keys is used for sending authenticated PDUs. The remaining keys represent older versions of the authentication string and each one is used against an incoming PDU. That way, network operators do not need to open the security gates for migrating keys. Multiple key verification is clearly the preferred option to keep the security level of the network intact. IOS supports keychains with their initial support for HMAC-MD5. JUNOS 6.2 has no multiple keys available which means that as soon as JUNOS is introduced into the network, the network must fall back to asymmetrical authentication schemes and hope that during password migration there is no attack on the infrastructure (as slight as this vul- nerability might be, it is nonetheless real). The last migration scenario is presented for completeness. It is not even discussed in the IETF, but is still relevant. 13.2.5.4 Authentication Type Migration Older IOS software only supports simple text authentication. For the time being this low- est common denominator (simple text authentication) is what both IOS and JUNOS has Authenticating Routing Information 357 deployed. Network operators feel increasingly concerned about the non-existent security that simple text authentication provides and desperately want to switch to HMAC-MD5. From a protocol perspective, nothing would prohibit the encoding of two versions of the Authentication TLV #10. The first one would carry the authentication key using MD5 authentication and the second would carry the same authentication key using simple text authentication. The biggest problem is that the deployed code only expects one Authentication TLV and there is little research into how the installed base of software would react to multiple occurrences of Authentication TLVs. The IETF has so far not coped with the problem, and typically refers inquiring parties to asymmetrical authenti- cation for solving problems of that kind. In the next two sections there are practical examples of how to turn on IS-IS authenti- cation on IOS and JUNOS. 13.2.6 Running Authentication Using IOS In Cisco IOS there are two general forms of authentication for IS-IS: interface authenti- cation and per-level authentication. Interface configuration applies to a specific interface only, and authenticates IIH PDUs. Per-level authentication authenticates LSP and SNP PDUs. A pair of routers only needs to share the same password to successfully run inter- face authentication. Per-level authentication makes it necessary for all routers in a given level to share the same password. 13.2.6.1 Per-interface Authentication We use a simple networking scenario such as that illustrated in Figure 13.6 for the authen- tication examples. Two routers are connected via a Gigabit Ethernet interface. Pseudonode suppression is turned on. The following configures an interface authentication between Madrid and Rome. All IIHs between the two routers on their Gigabit Ethernet interface are authenticated using MD5 authentication. Note that because the isis network point-to-point keyword has been configured, only Level-1 passwords are sent. In IOS you first need to define a key chain. Key chains are generic IOS functions used for holding several authentication keys that can be configured for key rollover. Next, you need to configure the isis authentication mode and point to a key chain using the isis authentication key-chain command. Optionally, you can con- figure a level after the two commands. If you omit the level keyword then IOS takes the key chain for authenticating both IS-IS levels. 358 13. IS-IS Extensions Ethernet Madrid.00 Rome.00 FIGURE 13.6. The simple setup will be used throughout the configuration examples IOS configuration Madrid#show running-config [… ] key chain MY-INTF-PASSWD key 100 key-string 0 ManInTheM00n [… ] interface GigabitEthernet4/0 ip address 172.16.34.5 255.255.255.252 ip router isis isis authentication mode md5 isis authentication key-chain MY-INTF-PASSWD isis network point-to-point ! ! router isis net 49.0300.1921.6800.3003.00 [… ] Now, you need to verify that your IIHs are properly authenticated. If you see debug messages like IIH no change, use the same hmac value then an Authentication TLV #10 containing a HMAC-MD5 value is applied to your outgoing IIHs. IOS debug output If the router emits periodical messages like this after turning debug authentica- tion information on, then authenticated Hellos are sent. Madrid#debug isis authentication information IS-IS authentication information debugging is on Madrid# Nov 5 00:48:07.233: ISIS-AuthInfo: IIH no change, use the same hmac value Nov 5 00:48:16.781: ISIS-AuthInfo: IIH no change, use the same hmac value Nov 5 00:48:24.609: ISIS-AuthInfo: IIH no change, use the same hmac value If your adjacency does not come up due to bogus authentication information then the output of the debug isis authentication information reveals what the problem is. IOS debug output The output of the debug isis authentication information command reveals if there is a password mismatch. Madrid#debug isis authentication information IS-IS authentication information debugging is on snail# Nov 5 00:48:01.011: ISIS-AuthInfo: Packet failed the md5 check, 77 bytes, type 17 Authenticating Routing Information 359 . of the Authentication TLV #10. The first one would carry the authentication key using MD5 authentication and the second would carry the same authentication key using simple text authentication. The. their name rather than their hexadecimal rep- resentation. The next extension to IS-IS will cover the authentication scheme of LSPs and their implementation. 350 13. IS-IS Extensions 13.2 Authenticating. then the router needs to make a decision. In IS-IS the rule set is simple: for Hello authentication, the Level-1 password is used. If there is no Level-1 password configured, then no Hello authentication