IS-IS authentication

[nathanmonteyne0]

Hi All,

So currently I am studying for my ENSLD and watching the CBT course for this.
As I stumble upon ISIS authentication I was wondering when would you use what.
Because you can have it on an interface, area and domain.
For me it seems like area is the best thing to do.
But can you also mix them up as I can assume that you want different passwords for different areas.
But for a level1-2 I can assume you want to have the int to a different area to be interface protected and also have an Area password for where the router is located. 

Or am I missing something?

Kind regards,

Nathan

[M02@rt37 · Accepted solution]

Hello @nathanmonteyne0,

IS-IS authentication provides an additional layer of security for IS-IS routing protocol by requiring authentication before routers can exchange routing information. The authentication can be applied at different levels: interface, area, and domain (also known as level 2).

Interface-Level Authentication:

Use interface-level authentication when you want to secure the communication between directly connected routers on a specific link. This is useful when you have a single link that needs to be secured, regardless of the area it belongs to. It's particularly useful for point-to-point links where you want to ensure that only authorized routers can participate in IS-IS exchanges.

Area-Level Authentication:

Use area-level authentication when you want to secure communications within a specific IS-IS area. This means that all routers within the same area must use the same authentication credentials to communicate with each other. Area-level authentication is suitable when you want to ensure that only authorized routers within a given area can exchange routing information.

Domain (Level 2) Authentication:

Use domain-level authentication when you want to secure communications between routers in different areas of the IS-IS network. This type of authentication ensures that only routers that share the same authentication credentials can communicate between different areas. It's particularly useful in large-scale networks where different areas might be controlled by different administrative entities.

You can use different authentication methods simultaneously in different parts of your IS-IS network.

--You might use interface-level authentication on point-to-point links where you want strong security between two specific routers.

--You can use area-level authentication within an area to ensure that only routers within that area communicate securely.

--Domain-level authentication can be used to secure communications between routers in different areas, especially when areas are controlled by different administrative teams.

[balaji.bandi]

most use case ISIS for the flat network underlay in SD-Access

authentication required in case any unknown device come in to network and join ISIS

its all use case where you using ?

[Joseph W. Doherty]

How to use these various password domains depend on how and if you have partitioned zones of administrative control.  Basically, in concept how you might manage administrative access using Tacacs.

For example, your network has regional divisions.  Corporate network engineers know all IS-IS passwords, but regional engineers only know of their region's IS-IS passwords.

[Peter Paluch · Accepted solution]

Nathan,

Please allow me to add a few additional thoughts.

Authentication in IS-IS feels odd, compared to other interior routing protocols. In OSPF, EIGRP, even RIPv2, you simply enable authentication on a per-interface basis and voila - all packets of the routing protocol exchanged over that interface will be subject to the authentication.

The key to understanding the apparently cumbersome authentication in IS-IS is to dive deeper into the nature of the IS-IS packet types. As you know, there are four basic IS-IS packet types: IS-IS Hellos (IIHs), Partial Sequence Number PDUs (PSNPs), Complete Sequence Number PDUs (CSNPs), and Link State PDUs (LSPs). The first three - IIHs, PSNPs, CSNPs - are neighbor-to-neighbor packets; they are always confined to the scope of the single link that interconnects adjacent routers together and they are never relayed across routers. However, the LSPs are different: LSPs as complete packets are relayed (flooded) unchanged and in their entirety through routers within their flooding scope - an area for Level-1 LSPs, and the whole Level-2 subdomain for Level-2 LSPs.

This is something that the other protocols don't do. Whenever EIGRP and RIPv2 routers need to send out a message, they reconstruct it from scratch; they do not relay any received EIGRP or RIPv2 packets unchanged. Not even OSPF gets close: While LSAs in OSPF are indeed flooded unchanged, they are not packets on their own - rather, they must be packaged into an LSU to be transmitted to another neighbor, and the LSU is again constructed from scratch by the sending router as far as the particular included LSAs and their order is concerned.

So notice the difference: We always do per-packet authentication in all IGP protocols, including IS-IS, but all packets in OSPF, EIGRP and RIPv2 are strictly neighbor-to-neighbor. There is no packet type in OSPF, EIGRP and RIPv2 that would be relayed across a router unchanged. Even though the internal information carried by those packets may be relayed, the entire packets never are. The nature of messaging in OSPF, EIGRP and RIPv2 is always limited to neighbor-to-neighbor communication. In IS-IS, we have the strictly neighbor-to-neighbor packets (IIH, CSNP, PSNP), too, but we also have the LSPs that are flooded in their entirety and without any modification inside an area or the Level-2 subdomain, depending on their originating level.

And exactly because the only router that is ever allowed to modify the contents of an LSP is its originating router, it is not possible for other routers to receive an LSP over one interface and authenticate it using one password, and then flood it out another interface and authenticate it using another password - that would mean that they would need to overwrite the authentication TLV contents in the LSP which they are not allowed to do.

This is why in IS-IS, the authentication of LSPs in particular needs to be handled separately from other packet types because other packet types are neighbor-to-neighbor, and you may want to use different passwords on different interfaces, but LSPs are per-area or per-L2-subdomain communication where they need to be authenticated using a common password and algorithm across their entire flooding scope.

And if you count in that IS-IS strictly differentiates between its Level-1 packets and Level-2 packets (with the only exception being the IIHs on point-to-point network types where only a single Hello is sent out for both levels), then you end up with interface authentication for Level-1 neighbor-to-neighbor packets (IIH, PSNP, CSNP), interface authentication for Level-2 neighbor-to-neighbor packets (IIH, PSNP, CSNP), authentication of Level-1 LSPs ("area-password" or better "authentication ... level-1") and authentication of Level-2 LSPs ("domain-password" or better "authentication ... level-2").

So IS-IS authentication is not really a showcase of flexibility gone crazy but rather a necessity which stems from the nature of IS-IS packet types and their handling.

This being said, I would not expect to see different passwords configured for interface and area/domain authentication. It is possible, yes, it is even possible to omit the authentication for interface or area or domain, but that would make the configuration quite awkward to understand and cumbersome to troubleshoot. The simplest approach is often one that works the best, and that would be using the same password and algorithm for all packet types. You can get more fancy and use a different password for LSPs than for the rest of the packets (and even start using different passwords for different levels) but it should not come at the price of ease of management.

Please feel welcome to ask further!

Best regards,
Peter

[Joseph W. Doherty]

---

@Peter Paluch wrote:

Nathan,

Please allow me to add a few additional thoughts.

---

Nathan, tell Peter, no, nyet, never, etc.!!!

Just kidding - Peter's responses are almost, if not always, a treasure trove of wonderful information.

The reason I'm adding a reply to Peter's, as usual, excellent reply, he used the word "crazy"!

Peter, may well be 100% correct, but just as in the saying "Although I may be paranoid, doesn't mean the whole world isn't against me", from someone (yours truly) often considered "crazy", for consideration . . .

Honestly, Peter, from what you wrote, I do not personally know whether "those" who drafted IS-IS, in fact, never intended, at all, "IS-IS authentication is not really a showcase of flexibility gone crazy", well maybe not the "crazy" part, or that it's just "a necessity which stems from the nature of IS-IS packet types and their handling."  This because, first, I haven't studied any documentation on IS-IS's design intents, but second, even if there's no documentation for "flexibility" in addition to "necessity", having been part of design "groups", there is a reason why "design by committee" is often considered a pejorative.  Further, IS-IS, is an IGP designed much for flexibility, i.e. I have in mind its design supporting TLVs.

That said, it seems you agree IS-IS authentication support might be used to support some (crazy?) security policy designs, but you would not recommend such as good practice.  If so, to that, I whole heartily agree!  Personally, I prefer the simplest possible effective solution.  However, also personally, some problems are complex, and sometimes, if to be solved at all, do require complex, even "crazy", solutions.  I find, the best way to decide how crazy you might want to solve something, is via the classic cost vs. benefit analysis.

I also want to mention, if IS-IS design really only intended this authentication approach strictly for "necessity" (even if that's the case, i.e. no one anticipated the possible craziness that might be done), subsequence users sometimes do use something in a way not intended by the designers, but that doesn't, alone, make such usage "bad", "wrong" or "crazy".  (BTW, I'm not saying Peter is saying that.)

As an example, of follow on users, perhaps not doing something as envisioned by the original designers . . .

Years ago (actually decades, but who is counting), I was asked to work on a banking program, that was written in the '60s.  One usage I found, hmm, "surprising" (readers can determine whether "crazy") the account number (9 digits) and sub-account number (5 digits) were stored in the on-line files in "packed decimal" (IBM System 360) format.  Basically, rather than storing a digit character, per byte, you can store two decimal digits per byte.  The hardware, has machine instructions to quickly convert digits from digit characters, to packet decimal, and the reverse.  The computer could not do mathematically operations on character digits, but could on packed decimal.  However, no need to do arithmetic on account numbers.  So, why was this done?

As noted, two digits could be stored where only one character digit would be.  Keep in mind, in current dollars, one byte of on-line storage would cost about a $1,000 dollars!  So, there was keen interest on minimizing storage costs.

Anything "crazy" so far?  I didn't think so, although at the time I was working on this program, on-line storage was much less expensive.  I recall, at that time, 300 MB disk drives only cost about $250,000 (in '80s dollars).

(BTW, way, way back [late '40s?]], IBM did a study, is there a market for computer systems?  They determined, yes there was, but it wasn't worth pursuing, because you might only be able to sell about 10 computer systems, as they would cost so much.)

Anyway, the program in question didn't just stop at storing the account number and sub account number as packed decimal.  Someone considered, actual packed decimal use the last nibble (4 bits - half byte) to store the number's sign.  Well, of course, account and sub account numbers aren't going to be negative numbers, that's wasting storage.  Hmm, but what can we do?

Ready for potential "crazy"?

What they did was, discard the account and sub accounts numbers sign nibble, join the two numbers, without the signs (which worked well as the two number were both odd number of digits)

Simple example, where character digits become packed decimal, and then (in their code) convert to combined account, sub-account number storage.

Conceptional example account number and sub account number:

Character bytes: "1" "2" "3" "4" "5" and "6" "7" "8"  (8 bytes, in all, used)

Packed decimal, byte pairs: 12 34 5+ and 67 8+ (5 bytes, in all, used)

Non-machine understandable, byte pair: 12 34 56 78 (4 bytes, in all, used [in on-line disk storage])

Did what was done, make the program more difficult to understand, and maintain?  (I thought it did.)

Did IBM designers every expect the computer to be flexible in the "crazy" manner?  (I suspect not.)

Did what this original programmers do, was it really "crazy", considering the cost of on-line storage, at that time?

Ah, the last question is the 64-bit question.  What say you?

Is Peter correct, about what was the IS-IS design intent?  I, personally, don't know.

Is using this IS-IS, by design (?), failure/feature "crazy"?

Well, I would say that "it depends".

I will say, very, very carefully consider the pros and cons if making such a decision.  I definitely am generally against using technology just because you can.

One more story (sorry), on the topic of "crazy".  Was what I was doing at the time, "crazy"? -  (maniacal) laugh.

So I was working in one place, and my manager's boss, the director comes directly to me, to tell me, I had a call from operations, about you.

I said, "oh?"  (While hoping operations didn't actually figure out what I've been doing on their mainframe.  I thought that very unlikely, because what I was doing, most would consider "impossible".)

Director said, they asked what kind of person I was.

Again, "oh?"

Director told them, he's amazing in the amount of programming he does.  Why do you ask?

Operations said, well, we noticed he's running the same job, again, and again, and again, and each time it aborts after exceeding its CPU time usage limit.

I suspect, they heard the saying "Insanity is doing the same thing over and over again and expecting different result."?

Well, I resemble that remark.  ; )

In any case, operations left well enough alone.  As far as they could tell, I wasn't causing any operational problems.  Director was pleased with my worked.  (And, truly, I wasn't doing anything, illegal, immoral, unethical [?], etc.  I was just doing an amazing amount of work, compared to all my peers, let's say by way of "feature" of IBM's OS design, which, perhaps, most hadn't noticed.)

[Peter Paluch]

Hi Joe,

I think that we both are in fact in agreement. I used the word "crazy" as a term (admittedly a little spiced-up in my writer's license : ) ) that may reflect on many people's opinion of authentication in IS-IS - and then stated that it is an inevitable conclusion of its inner workings and not a mere display of flamboyance. Does it permit some rather "creative" scenarios? Sure it does : ) But when I can trace back a trait (or an idiosyncrasy) of a protocol to a real and reasonable technical need, I give the benefit of doubt that the primary motivation was the technical need and not a motivation to be fancy.

Best regards,
Peter

[Joseph W. Doherty]

"I think that we both are in fact in agreement."

Yes, I believe we almost are.

"But when I can trace back a trait (or an idiosyncrasy) of a protocol to a real and reasonable technical need, I give the benefit of doubt that the primary motivation was the technical need and not a motivation to be fancy."

I agree, I don't recall any designs I was involved with being done just to be fancy.

What might happen though, there's a real technical need to do something, like your explanation of IS-IS's LSPs.  So, a design is done for that.

Then, perhaps, the discussion turns to authentication.  We need/want that too, but how might we piggy back it onto what we've already decided for LSPs?

Well, possibly, one argument might have been, just let each LSP type have it's own authentication, i.e. we don't want to bother trying to define/design some logically/unified approach; we don't see a need to (we have enough other design issues).

Or, someone says, should we have a logically/unified authentication approach?  Does it matter to us?  Let those using IS-IS do whatever they think best with the LSP authentication IS-IS can easily provide.

Two paths to the same end-result, but each slightly different.  I.e. again, we see no need for us (to use our time) to further define/design some overall IS-IS authentication architecture vs. we see no need to restrict IS-IS authentication to some overall authentication architecture.

Two (possible) different lines of thought for how/why IS-IS authentication is what it is.

Another alternative might be, the pros and cons of an authentication architecture, might have been never thought about.  Although possible, I think that's unlikely.

It's also possible, someone said, do you see what our authentication architecture might allow?  There too, if everyone said yes, there might be some said, "not our problem", vs. "why shouldn't we allow it".  Another case, where same end-result, but for different reasons.

Unless someone was keeping transcripts of all design meetings, one may never know why something like IS-IS authentication works as it does.  I.e. "fancy" likely wasn't a primary requirement, but conversely, someone may have pushed it as a feature, more so, to not limit how IS-IS authentication might be done.

For a personal example . . .

In the mid '80s, I was on design team where one design question was, do we store years with two or four digits?  At that time, traditionally, years were stored as just two digits, unless year needed dates not 19xx.

Even then, the cost of storing "19", as two characters, for every date, wasn't considered inconsequential.

Conversely, though, the counter argument was, the year 2000 is only 15 years away!

Basically, the upcoming year 2000 issue wasn't overlooked, but considered a, pay me now or pay me later, issue.

Which would you choose?  Why?

As it turned out, the decision was to go with the two digit years, because we knew what's the additional cost, at that time, would be.

Versus, is this software still going to be used in 15 years?  (Actually, for application software, it's often not, but data often is used longer.)

If the software and/or data is still needed in 2000, and later, it can be mitigated, say starting in 1998 or so.

(As one of those who lived through 1999 to 2000, all the world's systems didn't crash 1/1/2000, because there was a lot of mitigation being done in 1998 and 1999, as we assumed/expected/predicted 15 years earlier.)

In hindsight, was the above decision right or wrong?

Again, this was a, pay me now or pay me later, case.

From a financial perspective, if you knew for sure the pay me later cost, and the interest rates for 15 years, you could tell which would be lower actual cost, but the further you look into the future, predicting comes with greater and greater inaccuracy.  (Even worse than predicting weather - laugh.)

I remember, as we approached the year 2000, many questioned, systems don't store the century!!!  Was everyone crazy 10 or more years ago!  Was this even considered a possible problem when designing software 10 or more years ago!

Well, in one case, re: the year 2000, the issue was very seriously considered.  Yet, it's certainly possible, the company next door, truly didn't think about it at all and just went with using two digits years.

So, all the above is saying, looking at the end product, like IS-IS, and trying to figure out design motivations, without the designers saying we did what we did because, often isn't anything more than an guess, perhaps a very educated/informed guess, but still a guess.

With all the above in mind, I suspect Peter is only making an educated guess regarding how "fancy" IS-IS is vis-à-vis authentication, but, personally, I also believe, that he's likely correct.

The only reason I've made a big "to-do" about this, is because, as a developer for years, I've so often seen folk make assumptions about something being "stupid" (or "crazy") without any benefit of doubt, that there may have been some real thought about what you see as "stupid" (or "crazy").  Mind you, sometimes, indeed, design decisions were "stupid" or ("crazy"), even then.  But sometimes, or even perhaps, not, even if they are, in fact, "stupid" (or "crazy") by today's standards.