The Integrated IS-IS Algorithm

Integrated IS-IS uses an algorithm which is similar to but not quite identical to the OSPF Algorithm. Integrated IS-IS uses a different set of route classes, and also differs slightly in its handling of type of service. The algorithm is:

1. Basic Match

2. IS-IS Route Classes 3. Longest Match

4. Weak TOS 5. Best Metric 6. Policy

Although Integrated IS-IS uses Weak TOS, the protocol is only capable of carrying routes for a small specific subset of the possible values for the TOS field in the IP header. Packets

containing other values in the TOS field are routed using the default TOS.

Type of service support is optional; if disabled, the fourth step would be omitted. As in OSPF, the specification does not include the Policy step.

This algorithm has some advantages over the Revised Classic Algorithm:

(1) It supports type of service routing.

(2) Its rules are written down, rather than merely being a part of the Internet folklore.

(3) It (obviously) works with Integrated IS-IS.

However, this algorithm also retains some of the disadvantages of the Revised Classic Algorithm:

(1) Path properties other than type of service (e.g. MTU) are ignored.

(2) As in the Revised Classic Algorithm, the details (or even the existence) of the Policy step are left to the discretion of the implementor.

(3) It doesn’t work with OSPF because of the differences between IS-IS route classes and OSPF route classes. Also, because IS-IS supports only a subset of the possible TOS values, some obvious implementations of the Integrated IS-IS algorithm would not support OSPF’s interpretation of TOS.

The Integrated IS-IS Algorithm also has a further disadvantage (which is not shared by the Revised Classic Algorithm): IS-IS internal (intra-area or inter-area) routes are always considered to be superior to routes learned from other routing protocols, even in cases where the IS-IS route matches fewer bits of the destination address and doesn’t provide the requested type of service. This is a policy decision that may not be appropriate in all cases.

Finally, it is worth noting that the Integrated IS-IS Algorithm’s TOS support suffers from the same deficiency noted for the OSPF Algorithm.

Security Considerations

Although the focus of this document is interoperability rather than security, there are obviously many sections of this document which have some ramifications on network security.

Security means different things to different people. Security from a router’s point of view is anything that helps to keep its own networks operational and in addition helps to keep the Internet as a whole healthy. For the purposes of this document, the security services we are concerned with are denial of service, integrity, and authentication as it applies to the first two. Privacy as a security service is

important, but only peripherally a concern of a router - at least as of the date of this document.

In several places in this document there are sections entitled ...

Security Considerations. These sections discuss specific considerations that apply to the general topic under discussion.

Rarely does this document say do this and your router/network will be secure. More likely, it says this is a good idea and if you do it, it

*may* improve the security of the Internet and your local system in general.

Unfortunately, this is the state-of-the-art AT THIS TIME. Few if any of the network protocols a router is concerned with have reasonable,

built-in security features. Industry and the protocol designers have been and are continuing to struggle with these issues. There is progress, but only small baby steps such as the peer-to-peer authentication available in the BGP and OSPF routing protocols.

In particular, this document notes the current research into developing and enhancing network security. Specific areas of research,

development, and engineering that are underway as of this writing (December 1993) are in IP Security, SNMP Security, and common authentication technologies.

Notwithstanding all of the above, there are things both vendors and users can do to improve the security of their router. Vendors should get a copy of Trusted Computer System Interpretation [INTRO:8]. Even if a vendor decides not to submit their device for formal verification under these guidelines, the publication provides excellent guidance on general security design and practices for computing devices.

Acknowledgments

O that we now had here

But one ten thousand of those men in England That do no work to-day!

What’s he that wishes so?

My cousin Westmoreland? No, my fair cousin:

If we are mark’d to die, we are enow To do our country loss; and if to live, The fewer men, the greater share of honour.

God’s will! I pray thee, wish not one man more.

By Jove, I am not covetous for gold, Nor care I who doth feed upon my cost;

It yearns me not if men my garments wear;

Such outward things dwell not in my desires:

But if it be a sin to covet honour, I am the most offending soul alive.

No, faith, my coz, wish not a man from England:

God’s peace! I would not lose so great an honour As one man more, methinks, would share from me For the best hope I have. O, do not wish one more!

Rather proclaim it, Westmoreland, through my host, That he which hath no stomach to this fight,

Let him depart; his passport shall be made And crowns for convoy put into his purse:

We would not die in that man’s company That fears his fellowship to die with us.

This day is called the feast of Crispian:

He that outlives this day, and comes safe home, Will stand a tip-toe when the day is named, And rouse him at the name of Crispian.

He that shall live this day, and see old age, Will yearly on the vigil feast his neighbours, And say ’To-morrow is Saint Crispian:’

Then will he strip his sleeve and show his scars.

And say ’These wounds I had on Crispin’s day.’

Old men forget: yet all shall be forgot, But he’ll remember with advantages

What feats he did that day: then shall our names.

Familiar in his mouth as household words Harry the king, Bedford and Exeter,

Warwick and Talbot, Salisbury and Gloucester, Be in their flowing cups freshly remember’d.

This story shall the good man teach his son;

And Crispin Crispian shall ne’er go by,

From this day to the ending of the world, But we in it shall be remember’d;

We few, we happy few, we band of brothers;

For he to-day that sheds his blood with me Shall be my brother; be he ne’er so vile, This day shall gentle his condition:

And gentlemen in England now a-bed

Shall think themselves accursed they were not here, And hold their manhoods cheap whiles any speaks That fought with us upon Saint Crispin’s day.

This memo is a product of the IETF’s Router Requirements Working Group.

A memo such as this one is of necessity the work of many more people than could be listed here. A wide variety of vendors, network managers, and other experts from the Internet community graciously contributed their time and wisdom to improve the quality of this memo. The editor wishes to extend sincere thanks to all of them.

The current editor also wishes to single out and extend his heartfelt gratitude and appreciation to the original editor of this document;

Philip Almquist. Without Philip’s work, both as the original editor and as the Chair of the working group, this document would not have been produced.

Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy Wittbrodt each wrote major chapters of this memo. Others who made major

contributions to the document included Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer.

Additional text came from Art Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and others who have been inadvertently overlooked.

Some of the text in this memo has been (shamelessly) plagiarized from earlier documents, most notably RFC-1122 by Bob Braden and the Host Requirements Working Group, and RFC-1009 by Bob Braden and Jon Postel.

The work of these earlier authors is gratefully acknowledged.

Jim Forster was a co-chair of the Router Requirements Working Group during its early meetings, and was instrumental in getting the group off to a good start. Jon Postel, Bob Braden, and Walt Prue also contributed to the success by providing a wealth of good advice prior to the group’s first meeting. Later on, Phill Gross, Vint Cerf, and Noel Chiappa all provided valuable advice and support.

Mike St. Johns coordinated the Working Group’s interactions with the security community, and Frank Kastenholz coordinated the Working Group’s interactions with the network management area. Allison Mankin and K.K.

Ramakrishnan provided expertise on the issues of congestion control and resource allocation.

Many more people than could possibly be listed or credited here participated in the deliberations of the Router Requirements Working Group, either through electronic mail or by attending meetings.

However, the efforts of Ross Callon and Vince Fuller in sorting out the difficult issues of route choice and route leaking are especially

acknowledged.

The previous editor, Philip Almquist, wishes to extend his thanks and appreciation to his former employers, Stanford University and BARRNet, for allowing him to spend a large fraction (probably far more than they ever imagined when he started on this) of his time working on this project.

The current editor wishes to thank his employer, FTP Software, for allowing him to spend the time necessary to finish this document.

Editor’s Address

The address of the current editor of this document is Frank J. Kastenholz

FTP Software 2 High Street

North Andover, MA, 01845-2620 USA

Phone: +1 508-685-4000 EMail: kasten@ftp.com