Nov 5 00:48:09.095: ISIS-AuthInfo: Packet failed the md5 check, 77 bytes, type 17 Nov 5 00:48:17.059: ISIS-AuthInfo: Packet failed the md5 check, 77 bytes, type 17 From a configuration keyword point of view, the per-level authentication is very similar to the per-interface configuration. The only difference is in what PDU types are authenticated. 13.2.6.2 Per-level Authentication Applying per-level authentication authenticates all SNP and LSP PDUs on a per-level basis. The keywords are similar to the per-interface configuration. The configuration example shows a simple text authentication for Level-1 SNP and LSP PDUs and a HMAC-MD5 authentication for Level-2 SNP and LSP PDUs. IOS configuration Madrid#show running-config [… ] key chain MY-LEVEL1-PASSWD key 100 key-string 0 ObiWanhelpMEyouAREmyLastHope ! key chain MY-LEVEL2-PASSWD key 100 key-string 0 DoITorDONTdoitThereisnoTry ! router isis net 49.0300.1921.6800.3003.00 authentication mode text level-1 authentication mode md5 level-2 authentication key-chain MY-LEVEL1-PASSWD authentication key-chain MY-LEVEL2-PASSWD metric-style wide passive-interface Loopback0 ! [… ] If an incoming LSP does not contain proper authentication then the output of the debug isis authentication information command will report a Packet failed the md5 check message. If you receive PDUs containing no authentication TLV at all then the debug output looks as follows: IOS debug output The No auth TLV found debug message indicates that no Authentication TLV #10 is present in the PDU. Madrid#debug isis authentication information IS-IS authentication information debugging is on 360 13. IS-IS Extensions Nov 5 01:50:25.776: ISIS-AuthInfo: No auth TLV found in received packet Nov 5 01:50:25.848: ISIS-AuthInfo: No auth TLV found in received packet Nov 5 01:50:25.900: ISIS-AuthInfo: No auth TLV found in received packet 13.2.6.3 Suppressing Authentication Checks In the previous migration strategies there was a need to suppress authentication checking. In IOS suppression can be configured using the isis authentication send- only configuration keyword under the interface stanza to suppress IIH checking. For suppressing SNP and LSP checking the authentication send-only command is applicable in the router isis stanza. Note that the command also suppresses gener- ation of errors in the log file. So you may run the risk that you mask a security hole. The configuration of authentication on JUNOS is very similar to IOS. 13.2.7 Running Authentication Using JUNOS JUNOS also has two ways of authenticating IS-IS messages: per-interface and per-level configuration. The basic difference is the set of PDU types authenticated. Per-interface authentication authenticates interface Hellos. 13.2.7.1 Per-interface Authentication Per-interface authentication is applied using the hello-authentication-key and hello-authentication-type configuration keyword in the protocols isis interface level <*> stanza. JUNOS configuration The hello-authentication-key and hello-authentication-type configuration keyword control authentication password and type for IIHs. hannes@Stockholm> show configuration [… ] protocols { isis { interface ge-4/0/0.0 { point-to-point; level 1 { hello-authentication-key “$9$/tjmCu1SyK7NbApRSeW-dk.PQz6pu1”; # ManInTheM00n hello-authentication-type md5; # SECRET-DATA } } interface lo0.0; } } Authenticating Routing Information 361 13.2.7.2 Per-level Authentication Unlike Cisco IOS, JUNOS authenticates all three PDU types by default. (Recall Cisco IOS only authenticates LSPs and SNPs). Because JUNOS per-level authentication also authenticates IIHs, this is also a convenient way to do per-interface authentication on a router with many interfaces. (Why only authenticate Hellos?) JUNOS configuration The authentication-key and authentication-type configuration keyword control Authentication-Key and Type for SNPs and LSPs. hannes@Stockholm> show configuration [… ] protocols { isis { level 1 { authentication-key “$9$3qTB/CuRhrKWxvW”; # ObiWanhelpMEyouAREmyLastHope authentication-type md5; # SECRET-DATA } level 2 { authentication-key “$9$fT390OReK8QFA0IcvMaZUHkPF39”; # DoITorDONTdoitThereisnoTry authentication-type md5; # SECRET-DATA } interface lo0.0; } } If the adjacency does not come up, and you suspect an authentication problem, then you need to set up JUNOS traceoptions. Bogus authentications are logged with an error flag. JUNOS configuration If you want to gather evidence that the authentication is broken you need to configure the traceptions {} stanza hannes@Stockholm> show configuration [… ] protocols { isis { traceoptions { file isis.log; flag error; } } } 362 13. IS-IS Extensions Next you need to check the log file or set up a monitor job that displays any recent additions to the file on the console. JUNOS debug output hannes@Stockholm> show log isis.log Nov 5 04:16:02 trace_on: Tracing to “/var/log/isis.log” started Nov 5 04:16:05 ERROR: LSP authentication failure Nov 5 04:16:10 ERROR: LSP authentication failure Nov 5 04:16:15 ERROR: LSP authentication failure Nov 5 04:16:20 ERROR: LSP authentication failure As you have seen in the migration examples, sometimes suppressing authentication checks is the only transition strategy you have got. 13.2.7.3 Suppressing Authentication Checks JUNOS offers a single knob for suppressing all IS-IS-related authentication checks per routing instance. So in JUNOS the provisions for asymmetric authentication are much more coarse than in IOS, which allows suppression of authentication on a per-interface and per-level basis. JUNOS configuration The no-authentication-check reverts the entire IS-IS process so as to not verify any authentication information. hannes@Stockholm> show configuration [… ] protocols { isis { no-authentication-check; level 1 { authentication-key “$9$3qTB/CuRhrKWxvW”; # ObiWanhelpMEyouAREmyLastHope authentication-type md5; # SECRET-DATA } level 2 { authentication-key “$9$fT390OReK8QFA0IcvMaZUHkPF39”; # DoITorDONTdoitThereisnoTry authentication-type md5; # SECRET-DATA } interface lo0.0; } } Unfortunately JUNOS does not feature chaining of several authentication keys. In order to transition between authentication keys you need to utilize the no-authentication- check knob to turn authentication on and off during a single key transition. Authenticating Routing Information 363 IS-IS was often the routing protocol of choice because of its high multivendor inter- operability, which is no surprise, since the specification was lean and well written. However, in the field of authentication, IOS and JUNOS were once not interoperable at all when it came to authentication. That has changed recently, and the next section explores the remaining interoperability caveats. 13.2.8 Interoperability JUNOS supports MD5 and simple text authentication from the start, when the software shipped as JUNOS 3.0. Back in 1998, there was the conviction that authentication always had to apply for all three PDU types (IIHs, SNPs, LSPs). That behaviour did not match the IOS behaviour at that time, which only authenticated LSPs. Optionally IOS also allowed configuration of interface authentication, but that bought authentication of only two out of the three PDU types involved. JUNOS authenticated symmetrically and expected authen- tication also on those PDU types that it sends as Authenticated PDUs. This led to a prob- lem, as IOS had no provision to authenticate SNPs – The only workaround was to configure no-authentication-check on JUNOS. Juniper Network’s engineers were thinking of changing the behaviour, but that was not an option, because changing a default behaviour is always a dangerous thing, and service provider customers are not very happy if their vendor does change defaults very often. So with JUNOS 5.4, new knobs were introduced that suppress the all-PDU authentication styles. The three knobs are: • no-hello-authentication • no-csnp-authentication • no-psnp-authentication Originally, just a no-hello-authentication and no-snp-authentication knob was planned, but it turned out that there is IOS software deployed in the field that supports authentication of CSNPs. In order to adapt to any environment, three knobs were released. An older-IOS compatible configuration turns on all three knobs which finally sends just authenticated LSPs and also just expects LSPs to be authenticated. JUNOS configuration The no-<*>-authentication knobs are used for adapting any sort of IOS behaviour from past releases. hannes@Stockholm> show configuration [… ] protocols { isis { level 1 { authentication-key “$9$3qTB/CuRhrKWxvW”; # ObiWanhelpMEyouAREmyLastHope authentication-type md5; # SECRET-DATA no-hello-authentication; no-csnp-authentication; 364 13. IS-IS Extensions no-psnp-authentication; } level 2 { authentication-key “$9$fT390OReK8QFA0IcvMaZUHkPF39”; # DoITorDONTdoitThereisnoTry authentication-type md5; # SECRET-DATA no-hello-authentication; no-csnp-authentication; no-psnp-authentication; } interface lo0.0; } } Networking engineers often believe that because IS-IS is still a somewhat “secret” protocol and that this “security by obscurity” works well. Also, no known hacking tools are able to handcraft IS-IS packets. But do not be misled! There are packet injection pro- grams around that can handcraft any IS-IS packet (it’s just that so far hackers have not used them to attack IS-IS). For example, the Nemesis Project is a toolset suite for craft- ing routing protocols of all kinds including IS-IS, RIP and OSPF. To learn more about Nemesis check out the Nemesis homepage at http://sourceforge.net/projects/nemesis/. While tools like this may be a threat to networks, it is the authors’ opinion that they are useful tools to harden and secure existing networks. Deploying MD5 authentication is imperative when running IS-IS. What still needs to be done on the IETF is adding crypto- graphic sequence numbers to be robust against all sort of attacks. • A corrupted CSNP may trigger excessive PSNPs and LSPs because the receiver of the broken CSNP thinks there are lots of unknown LSPs that it has to learn about. See Chapter 8, “Synchronizing Databases” for the dynamics of SNPs requesting LSPs. • About the worst thing that can happen is that the corrupt frame does not get detected for the time being. If routing control traffic gets corrupted, then it is also highly likely that user payload traffic may be corrupted too. Most likely customer complaints about bad throughput will hit your desk. In order to overcome this limitation of the base IS-IS protocol, the IETF has come up with an optional Checksumming TLV which is defined in RFC 3358. The idea of the Checksum TLV is to protect IIHs and SNPs. Figure 13.7 shows the basic structure of the Authenticating Routing Information 365 Type Length 16 Bit “Fletcher” checksum 12 Bytes 1 1 2 2 FIGURE 13.7. The optional Checksum TLV #12 conveys an additional Fletcher Checksum that protects IIHs and SNPs Checksum TLV. The length of the TLV is always two bytes. The payload is a standard “Fletcher” checksum described in ISO 8473 Annex C, which is calculated over the entire PDU. As at December 2003 there is no support of the checksumming TLV in IOS. It is only available on JUNOS. Using the checksum keyword checksum protection can be acti- vated on a per-interface basis. JUNOS configuration The checksum keyword in the protocols isis interface configuration stanza causes to send and verify the contents of TLV #12 on IIHs and SNPs. hannes@Frankfurt# show configuration [… ] isis { interface so-1/2/0.0 { checksum; level 1 { hello-interval 10; hold-time 40; } } [… ] interface lo0.0; } } After configuring and committing your configuration, you should see the additional checksum TLVs in the tcpdump output. Tcpdump output The Checksum TLV #12 augments the missing Checksum field in the IIH and SNP headers. 21:06:57.889875 OSI, IS-IS, length: 78 L2 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1008, holding time: 120s, Flags: [Level 1, Level 2] circuit-id: 0x01, PDU length: 78 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) [… ] Checksum TLV #12, length: 2 checksum: 0xbfb0 (correct) 366 13. IS-IS Extensions 21:17:30.950224 OSI, IS-IS, length: 135 L2 CSNP, hlen: 33, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 0000.0000.0002.00, PDU length: 135 start lsp-id: 0000.0000.0000.00-00 end lsp-id: ffff.ffff.ffff.ff-ff Checksum TLV #12, length: 2 checksum: 0x2d8f (correct) LSP entries TLV #9, length: 96 lsp-id: 1921.6800.1017.00-00, seq: 0x000001a8, lifetime: 63177s, chksum: 0xebb1 13.3 Checksums for Non-LSP PDUs Almost all kinds of networking protocols protect their message content with checksums. Protecting messages through a checksum follows a simple recipe. Both the sender and the receiver of a message have to rely on a common way to build the checksum, the checksum algorithm. Popular checksum algorithms are CRC16, CRC32 and, for IS-IS, the ISO X.233/ISO 8473-1 “Fletcher” checksum. Each of these checksum algorithms has different properties. What they have in common is that all of them can detect at least one bit error. While the primary purpose of checksums is to detect bit errors, some algo- rithms, for example, try additionally to balance the proportion of zeros and ones in a message to help the transmission devices not to lose clock synchronization. Note that all modern communication infrastructure devices have extra payload scramblers before put- ting the bit-stream on the wire, so higher layers do not need to care if the frame contains a healthy proportion of zeros and ones any longer. This section focuses just on the error-detecting properties of checksum algorithms and will not further discuss other applications like zero and one balancing. The checksum procedure works very simply. First, the field in the message where the checksum is stored needs to be initialized to a common value, typically zero. Next, the sender and the receiver need to agree what part of the message needs to be protected. Typically, it is the entire frame excluding Layer-2 encapsulation like MAC addresses or PPP headers. In IS-IS the LSP checksum does not encompass the entire PDU. The checksumming starts at an offset of 12 bytes relative to the beginning of the IS-IS common header. This was done to exclude fields like the LSP Age, which may be subject to local time drift. Finally, the checksum is calculated and inserted at the previously zeroed position. The receiver needs to perform the checksum operation in a similar way: First, save the received checksum for later comparison. Set the original checksum position to zero. Next, calculate the checksum based on the agreed parts of the frame with the same algo- rithms that is typically defined in the protocol’s specification. Finally, compare the self- calculated checksum to the previously saved original checksum that was received with the frame. If the two checksums match, then pass the frame on for further processing. If they do not match, discard the frame and increment a counter telling the operator that Checksums for Non-LSP PDUs 367 there must be something wrong. Not protecting routing protocol messages via check- sums is a bad idea because it does not give the receiver a chance to differentiate between good and corrupted messages. 13.3.1 PDUs Missing Checksum? IS-IS uses a total of five different PDU types (actually, there are nine, but some share the format like dedicated Level 1 and Level 2 PDUs). Take a look at those five PDU headers illustrated in Figure 13.8. Only one PDU type, the LSP, contains a Checksum field. All the other PDU types are not protected by a Checksum field. Serious harm can result if a corrupt message is not recognized as such. Consider (for example) an adjacency between two routers. Now suppose a few bits in the arriving frame got flipped by (for example) a transmission problem. Depending on what TLVs are corrupted, the adjacency could be at best torn down or, worst, corrupted information is conveyed, as these examples show: An adjacency that is reportedly in the Up state could be perceived to be in the Down state due to corruption of the Adjacency State TLV #240. The result is a broken adjacency which will trigger a new LSP which is flooded network-wide. lsp-id: 1921.6800.1012.00-00, seq: 0x0000003c, lifetime: 64166s, chksum: 0x0e2b lsp-id: 1921.6800.1019.00-00, seq: 0x000001a2, lifetime: 62579s, chksum: 0xba03 lsp-id: 1921.6800.1021.00-00, seq: 0x00000d31, lifetime: 63277s, chksum: 0x1dc4 lsp-id: 1921.6800.1008.00-00, seq: 0x00000124, lifetime: 61291s, chksum: 0xb30f lsp-id: 1921.6800.1022.00-00, seq: 0x00000117, lifetime: 63277s, chksum: 0x5acf The use of the Checksum TLV is optional. The only place where the specification is firm is that as soon as a receiver supports the Checksum TLV and the checksum is cor- rupt, it must discard the frame. RFC 3358 also discusses the case of a “checksumming collision”. The collision of checksum occurs if both HMAC-MD5 authentication and checksumming is configured on an interface. HMAC-MD5 is nothing more than a very wide checksum under the inclusion of a shared secret. Which checksumming function should be prioritized? One of the rules of TLV encoding is that each TLV is independent of any other. In the authentication/checksumming case, the order does matter and would be a violation to that requirement. Final consensus was either to suppress or set the value of the Checksum TLV #12 to zero once the router knows that HMAC-MD5 authentica- tion needs to be added to PDU. This is an acceptable behaviour, and is the mindset of many network engineers that HMAC-MD5 is nothing but a big checksum that makes sure that multiple bit flips get detected, which conventional checksumming methods are not capable of, so there is no problem there. A 128-bit checksum is simply stronger than a 16- bit one. The tcpdump output shows occurrence of both an Authentication TLV #10 and a Checksumming TLV #12 in an IIH message. Note that the contents of the Checksum TLV are set to zero, which is an indication that the receiver does not need to attempt to verify it. Also, one interesting side effect of the Fletcher sum is that it can never be zero. Zero is therefore a clear indication of an exception. 368 13. IS-IS Extensions 369 Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0؋83 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 Reserved TLV section LAN IIH PDU 15, 16 27 circuit type 1, 2, 3 Source ID Holding Time PDU Length Priority R Designated IS LAN-ID Bytes 1 1 1 1 1 1 1 1 0–1467 1 ID Length (6) 2 2 1 ID Length (6) ϩ 1 Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0؋83 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 TLV section 18, 20 27 Remaining Lifetime LSP-ID PDU Length Sequence Number Checksum P Bytes 1 1 1 1 1 1 1 1 0–1465 2 2 ID Length (6) ϩ 2 4 2 1 ATT ATT ATT ATT OL IS Type LSP PDU Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0؋83 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 TLV section 24, 25 33 1,2,3 Source ID Start LSP-ID PDU Length End LSP-ID Bytes 1 1 1 1 1 1 1 1 34–1459 2 ID Length (6) ϩ 1 ID Length (6) ϩ 2 ID Length (6) ϩ 2 CSNP PDU Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0؋83 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 TLV section 26, 27 17 1,2,3 Source ID PDU Length Bytes 1 1 1 1 1 1 1 1 18–1475 2 ID Length (6) ϩ 1 PSNP PDU p2p IIH PDU Intra-domain Routing Protocol Discriminator Header Length Indicator Version/Protocol ID Extension 0؋83 Bytes 1 1 1 1 1 1 1 1 1 ID Length PDU Type R 0 R 0 R 0 PDU Version Reserved Maximum Area Addresses 6 (0) 1 3 (0) 0 Reserved TLV section 4–1467 17 20 circuit type 1, 2, 3 Source ID Holding Time PDU Length Local circuit ID 1 ID Length (6) ϩ 1 2 2 1 1, 2, 3 F IGURE 13.8. Only the LSP PDU is protected by a 16-bit Checksum field . need to utilize the no-authentication- check knob to turn authentication on and off during a single key transition. Authenticating Routing Information 363 IS-IS was often the routing protocol. suppress the all-PDU authentication styles. The three knobs are: • no-hello-authentication • no-csnp-authentication • no-psnp-authentication Originally, just a no-hello-authentication and no-snp-authentication knob. contain proper authentication then the output of the debug isis authentication information command will report a Packet failed the md5 check message. If you receive PDUs containing no authentication TLV