The Complete IS-IS Routing Protocol- P13 doc

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.. In IS-IS the rule s

hannes@Frankfurt> show isis database extensive

IOS command output

London#show isis database verbose 1921.6800.1047.00-00

IS-IS Level-2 Link State Database:

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 ably running older software that does not support the Hostname TLV

prob-If the hostnames made their way into the hostname cache, then all IS-IS occurrences of theSystem-ID are replaced using their respective name See Table 13.1 for how Pennsauken’sSystem, 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 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

engin-or logging functions make use of a System-ID to hostname translation cache and displaySystem-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 theirimplementation

13.2 Authenticating Routing Information

Authenticating routing protocol messages is a basic building block for every networksecurity 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 justanother 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 errorsintroduced by, for example, unskilled NOC personnel One application is that new IS-ISadjacencies 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 thePDU Figure 13.2 shows the structure of this TLV

The Authentication TLV uses a field called Authentication Type to further indicatehow 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 TextAuthentication is used The password is a free-form string that can be between 1 and 254bytes in size On the right-hand side there is the formatting of TLV #10 if HMAC-MD5Authentication is used The size is fixed to 16 bytes and contains a MD5 sum of the entirepacket

1–254

Type Length Authentication Type

10

Bytes 1 1

F IGURE 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 LANinfrastructure 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 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, toflood it out on all ports Ultimately all ports on the LAN switch see the Hello with the cleartext password, which makes it far too easy for eavesdroppers to get hold of the password

sig-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.

13.2.2 HMAC-MD5 Authentication

The second encoding scheme is to use HMAC-MD5 hashes for securing the routingupdates 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 functionmeans 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 16bytes The following tcpdump output shows the 16-byte output of the hash Note the TLVlength 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

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

to the forwarding planes Even if the router OS supports protection techniques like cency hold down, the attack disrupts adjacencies for a period of time.

adja-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 232

IS-IS packets in order to repeat an attack Depending on the implementation-specificprotection 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 notgenerate more than one IS-IS PDU per second in order not to cycle too fast through thesequence space This assumption is absolutely valid, as most of the IS-IS PDU types arerate-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, adevelopment 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 Thebasis 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 useMD5 authentication when deploying an IS-IS network Most of the harm that can be donebased on replay attacks can be avoided by network design techniques, such as not usingbroadcast circuits in the core Using replay attacks, an attacker can create some moderatestress 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

Ethernet

IIH Amsterdam AllL1IS

Up

IIH Stockholm AllL1IS

Up

IIH Stockholm AllL1IS

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 tem he wants to in the network and cause network-global stress that is not easily detected

sys-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 PDUtype also has implications for authentication Authentication in IS-IS always applies to theentire PDU If the PDU type is shared between levels, then a single password needs to beshared for both levels as well There is a potential for conflict in the configuration too, as (forexample) 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 isused 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 levelsusing 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

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

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 authenticationmigrations have network-wide impact and require a strategy for gradually transitioningthe network

13.2.5 Migration Strategy

There are three main authentication-related migration scenarios All three migration narios have one assumption in common: it is not possible to change the entire network inone “flag day” and there must not be any outage longer than (to cite a common example)

sce-a single sce-adjsce-acency reset

13.2.5.1 General Decisions and Routing Software Selection

Before starting to implement authentication in an IS-IS, two questions need to beanswered:

• 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 methodfor 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 manycaveats 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 fullauthentication support for all PDU types and both authentication methods Full supporthas been available in versions equal or higher than IOS:

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 willdiscuss 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 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

“asymmet-way routers can be configured gradually to send their PDUs augmented with

authentica-tion informaauthentica-tion But they do not verify if the password is correct upon receipt Once allthe 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

• Multiple key verification

Asymmetrical key verification is the panacea that works for all migration scenarios Thismay even be a viable solution for the Greenfield scenario; however, for the key migrationmethod, 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 Thatway, 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 thenetwork intact IOS supports keychains with their initial support for HMAC-MD5 JUNOS6.2 has no multiple keys available which means that as soon as JUNOS is introduced intothe network, the network must fall back to asymmetrical authentication schemes and hopethat 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 inthe 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 est common denominator (simple text authentication) is what both IOS and JUNOS has

low-deployed Network operators feel increasingly concerned about the non-existent securitythat simple text authentication provides and desperately want to switch to HMAC-MD5.From a protocol perspective, nothing would prohibit the encoding of two versions ofthe Authentication TLV #10 The first one would carry the authentication key using MD5authentication and the second would carry the same authentication key using simple textauthentication The biggest problem is that the deployed code only expects oneAuthentication TLV and there is little research into how the installed base of softwarewould react to multiple occurrences of Authentication TLVs The IETF has so far notcoped 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 cation on IOS and JUNOS

authenti-13.2.6 Running Authentication Using IOS

In Cisco IOS there are two general forms of authentication for IS-IS: interface cation and per-level authentication Interface configuration applies to a specific interfaceonly, and authenticates IIH PDUs Per-level authentication authenticates LSP and SNPPDUs 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 givenlevel to share the same password

authenti-13.2.6.1 Per-interface Authentication

We use a simple networking scenario such as that illustrated in Figure 13.6 for the tication examples Two routers are connected via a Gigabit Ethernet interface Pseudonodesuppression is turned on The following configures an interface authentication betweenMadrid and Rome All IIHs between the two routers on their Gigabit Ethernet interface are authenticated using MD5 authentication Note that because the isis networkpoint-to-pointkeyword has been configured, only Level-1 passwords are sent

authen-In IOS you first need to define a key chain Key chains are generic IOS functionsused 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 keychainusing 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 takesthe key chain for authenticating both IS-IS levels

Ethernet

isis authentication mode md5

isis authentication key-chain MY-INTF-PASSWD

isis network point-to-point

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

authentica-tion informaauthentica-tionon, 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: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 areauthenticated

authentication mode text level-1

authentication mode md5 level-2

authentication key-chain MY-LEVEL1-PASSWD

authentication key-chain MY-LEVEL2-PASSWD

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

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 only configuration keyword under the interface stanza to suppress IIH checking Forsuppressing SNP and LSP checking the authentication send-only command isapplicable 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

send-13.2.7 Running Authentication Using JUNOS

JUNOS also has two ways of authenticating IS-IS messages: per-interface and per-levelconfiguration The basic difference is the set of PDU types authenticated Per-interfaceauthentication authenticates interface Hellos

13.2.7.1 Per-interface Authentication

Per-interface authentication is applied using the hello-authentication-key andhello-authentication-typeconfiguration keyword in the protocols isisinterface level <*>stanza

13.2.7.2 Per-level Authentication

Unlike Cisco IOS, JUNOS authenticates all three PDU types by default (Recall CiscoIOS only authenticates LSPs and SNPs) Because JUNOS per-level authentication alsoauthenticates IIHs, this is also a convenient way to do per-interface authentication on arouter with many interfaces (Why only authenticate Hellos?)

Next you need to check the log file or set up a monitor job that displays any recentadditions 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 authenticationchecks 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 perrouting instance So in JUNOS the provisions for asymmetric authentication are muchmore coarse than in IOS, which allows suppression of authentication on a per-interfaceand per-level basis

Unfortunately JUNOS does not feature chaining of several authentication keys In order

to transition between authentication keys you need to utilize the checkknob to turn authentication on and off during a single key transition

no-authentication-IS-IS was often the routing protocol of choice because of its high multivendor 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 atall when it came to authentication That has changed recently, and the next sectionexplores the remaining interoperability caveats.

inter-13.2.8 Interoperability

JUNOS supports MD5 and simple text authentication from the start, when the softwareshipped as JUNOS 3.0 Back in 1998, there was the conviction that authentication alwayshad to apply for all three PDU types (IIHs, SNPs, LSPs) That behaviour did not match theIOS behaviour at that time, which only authenticated LSPs Optionally IOS also allowedconfiguration of interface authentication, but that bought authentication of only two out of

the three PDU types involved JUNOS authenticated symmetrically and expected tication also on those PDU types that it sends as Authenticated PDUs This led to a prob-

authen-lem, as IOS had no provision to authenticate SNPs – The only workaround was toconfigure no-authentication-check on JUNOS Juniper Network’s engineerswere thinking of changing the behaviour, but that was not an option, because changing adefault behaviour is always a dangerous thing, and service provider customers are notvery happy if their vendor does change defaults very often So with JUNOS 5.4, new knobswere introduced that suppress the all-PDU authentication styles The three knobs are:

finally sends just authenticated LSPs and also just expects LSPs to be authenticated.