NLSP

NLSP, like TLSP, is the direct descendant of the corresponding SDNS document (SP3). But, unlike TLSP, NLSP has evolved into a much more complicated protocol that incorporates facilities for key management and synchronization between NLSP peers.

At its inception, NLSP was supposed to be at the top of layer 3 and to provide support for a functionality virtually identical to the TLSP functionality. Initially, this caused several parties (such as the UK) to ask that a single Lower Layer be developed and be placed between layers three and four. Nevertheless, since NLSP was supposed to run in conjunction with X.25 (which necessitated a different NLSP placement) this approach was abandoned.

At this point NLSP is quite a complicated protocol. To start, those in favor of a single security protocol must accept the fact that the connectionless NLSP and the connection-oriented NLSP are different protocols. In addition, NLSP includes multiple functional areas, not the least of which is key management. Key management forces NLSP to reinvent transport-like mechanisms within layer three.

NLSP supports cryptographic protection either between End Systems (and in this case resembles TLSP) or between Intermediate Systems that are located at the borders of security domains. This latter aspect makes NLSP quite appealing to those who would like to provide security services not by securing each and every system in a domain but by forcing all external communications to transit through a small set of secure systems (assuming that communications within the domain need no security services). In this sense, one can see NLSP as supporting (at the domain level) administrative policies (mandatory security) while TLSP is more tuned towards discretionary communication policies. The problem nevertheless is that the requirement that NLSP be deployable in Intermediate Systems (ISs) causes considerable complications which cannot be addressed seamlessly and without considerable architectural constraints.

NLSP advanced to DIS in July of 1992. Nevertheless, it seems that there may be additional difficulties ahead for the following reasons:

• NLSP is a fairly complex protocol;
• Work on an NLSP look-alike has been initiated in IETF. The experts who reviewed NLSP for possible adoption were less than enthusiastic. Thus, an NLSP competitor may emerge within IETF.
• The OSI model appears to consist of a set of protocol stacks. Within each stack, the protocols used are entered in a fixed succession. Nevertheless the complexities of NLSP within ISs results in a complex model which appears suboptimal and at odds with OSI practice up to now.

  Indeed, there may be recursive calls to NLSP and the forwarding protocol (e.g., CLNP) in order to handle alternating sequences of encryption and fragmentation.

• Criticisms are mounting on the aspects of NLSP that pertain to the connection oriented forwarding.

Thus, it appears that NLSP will be challenged before it advances to IS.