NCP Packet Signature Performance Considerations
Articles and Tips: article
Consulting Software Engineer
Systems Engineering Division
KEN NEFF
Principal Technical Writer
Systems Engineering Division
01 Dec 1992
A potential security threat recently discovered at Lieden Unversity in the Netherlands has prompted Novell to release a security enhancement to eliminate this security hole for NetWare. This AppNote describes the packet forging problem and explains the solution Novell is now providing with the NCP Packet Signature enhancement. It also discusses some performance factors to consider when using NCP Packet Signature.
Introduction
Recently, some students and professors at Lieden University in the Netherlands discovered a security threat that affects network operating systems. The threat involves breaking into a network by forging requests on the wire in the name of a more privileged user. Using this technique, a person could, for instance, send a request to change the supervisor's password and thus gain access to the entire system.
To address this network security loophole, Novell has released a security enhancement for NetWare v3.11. The enhancement is called NCP Packet Signature. The software consists of several NetWare Loadable Modules (NLMs), new DOS client shells, an update for the OS/2 requester, and various rewritten utilities. This AppNote gives a brief technical overview of this security enhancement and discusses some performance factors to consider when using NCP Packet Signature.
How Big a Threat?
Thus far, the only documented instance in which this packet forging technique has been used successfully to breach NetWare's security is in a laboratory setting at Lieden University. Due to the complexity of the procedure, it has not been seen in actual commercial environments. This potential threat is believed to exist for other operating systems besides NetWare, including Microsoft's LAN Manager, IBM's LAN Server, Banyan's VINES, Digital's DECnet, and UNIX.
Novell has verified the existence of this threat for servers and clients using the NetWare Core Protocol (NCP). An interim security patch for NetWare v3.11, NetWare v2.2, and NetWare for UNIX was placed on NetWire shortly after the mechanism for intrusion was discovered in September 1992.
NetWare v3.11 customers should use the latest security enhancement software that became available on November 16, 1992. The enhancement is free and is available from NetWare resellers, on NetWire and NetWare Express (minimal connection charges apply), or by calling 1-800-NETWARE (1-800-638-9273). A similar enhancement for NetWare v2.2 customers will be available soon. The enhancement will also be given to Novell's NetWare for UNIX (Portable NetWare) partners so that they can make the solution available to their customers.
Technical Overview of NCP Packet Signature
In the traditional Novell network environment, servers provide file and print services to clients by using the NetWare Core Protocol (NCP). When a client program needs network services (for example, to read a file from the NetWare server), it formats the request as an NCP packet. The request packet is then sent to the server, which returns the requested information in an NCP reply packet.
In this environment, it is theoretically possible to write code that allows an existing network client to pose as a more privileged user and send a forged NCP request to a NetWare server. By forging the proper NCP request, an intruder could gain SUPERVISOR rights and thus have access to all network resources (see Figure 1).
Figure 1: In theory, an intruder can gain access to the network by posing as another user and forging an NCP request packet.
To the uninitiated, this break-in procedure may appear simple, but in reality it is extremely difficult to forge NCP packets. To be successful (without NCP Packet Signature protection), a person must acquire the following information:
The 12-byte network address of a workstation at which a more privileged user is currently logged in
That workstation's connection number
The proper sequence number for the next packet in that workstation's NCP communication with the server
While the network address and connection number of logged in users are readily available, the proper NCP sequence number is difficult to arrive at. Even if a person wishing to forge an NCP packet does guess (or otherwise obtain) the correct sequence number for a given packet, it is only valid for that packet. The server increments the sequence number with each packet received from the same client. If a packet arrives from that client without the correct sequence number, the packet is discarded.
Forging packets is an unreliable method of compromising standard NetWare security measures. There is a random element involved with the forging method which renders it unsuccessful most of the time.
How Packet Signature Works
Novell's NCP Packet Signature security enhancement requires the client and the server to "sign" each NCP packet. This signature is unique for each packet exchanged between the client and server. Moreover, the packet signature changes with every packet. The server discards any packets it receives that do not have the correct signature (see Figure 2)
Figure 2: NCP Packet Signature prevents packet forging by requiring the client and server to "sign" each packet.
Here's how NCP packet signing works:
When a client logs in with the LOGIN command, the server and the client determine a shared, secret key known as the session key.
When the client is ready to send a request to the server, the server and the client calculate a unique signature based on the session key, a "fingerprint" algorithm, and the signature used for the previous packet.
The unique signature is appended to the NCP packet before it is sent to the server.
When the server receives the request, it checks the packet's signature. If the signature is correct, the server processes the request. Before sending the reply, the server generates a new unique signature and appends that to the NCP reply packet.
If the request signature is invalid, the packet is discarded, but the client's connection with the server is maintained. An alert message containing the LOGIN name and station address of the client in question is sent to the server console, to the server error log file, and to the affected client.
If NCP Packet Signature is installed correctly on the server and all its clients, it is virtually impossible to forge a valid NCP packet. Because the contents of each signature are factored into the calculation of the next packet's signature, a person would need to obtain a complete history of the NCP session in addition to the secret session key. The chances of any party successfully forging an NCP packet with Packet Signature are less than 1/264. Even if a party successfully forges one NCP packet, the likelihood of successfully forging a second NCP packet remains the same as for the first packet. Brute-force methods for forging an NCP packet are thus computationally infeasible.
Packet Signature Options
NCP Packet Signature is not required for every installation. Some may choose not to use Packet Signature because they can tolerate certain security risks. Calculating the NCP packet signatures does consume CPU resources at both the client and the server. This overhead can slow performance in certain configurations. Packet Signature is therefore optional.
To provide the greatest flexibility and allow network administrators to individually determine the level of protection they need, several signature options are available. NetWare servers and clients each have four settable signature levels ranging from never signing NCP packets to always signing NCP packets.
Figure 3 summarizes the various possible combinations of these configuration options. For more information, refer to the SECURITY.DOC file that accompanies the enhancement software.
In most instances, the default settings (server level=2 and client level=1) provide the most flexibility while still offering protection from forged packets. To implement a greater level of protection, you can change either the server level, the client level, or both.
Figure 3: Table of Packet Signature options.
|
Server Level Client Level |
0 Server does not sign packets (regardless of client level) |
1 Server signs only if client requests it (client level = 2 or 3) |
2 DEFAULT Server signs if client is capable of signing (client level = 1, 2 or 3) |
3 Server always signs and requires all clients to sign (or login will fail) |
|
0 Client does not sign packets |
No packet signature |
No packet signature |
No packet signature |
No logging in |
|
1 DEFAULT Client signs only if server requests it (server option = 2 or 3) |
No packet signature |
No packet signature |
PACKET SIGNATURE |
PACKET SIGNATURE |
|
2 Client signs if server is capable of signing (server option = 1,2 or 3) |
No packet signature |
PACKET SIGNATURE |
PACKET SIGNATURE |
PACKET SIGNATURE |
|
3 Client always signs and requires server to sign (or login will fail) |
No logging in |
PACKET SIGNATURE |
PACKET SIGNATURE |
PACKET SIGNATURE (maximum protection) |
Performance Considerations
Some combinations of server and client packet signature levels may slow performance. However, low CPU-demand systems may show little noticeable performance degradation. Depending on numerous other factors such as network traffic, packet size, client and server CPU speed, and so on, users may not notice any degradation in performance when running applications on a Packet Signature-enabled network. Network administrators can choose the packet signature level that meets both their performance needs and their security requirements.
Performance Tests
Performance and degradation of performance are difficult to measure. First, there is a big difference between real performance loss and how that loss is perceived by the user. In many cases, degradation caused by Packet Signing will be unnoticeable. Second, because Packet Signing is CPU intensive, both real and perceived degradation will be greatly impacted by CPU resources at the server and the client.
To get some idea of the performance implications of using Packet Signature, the Systems Engineering Performance Lab did some preliminary testing to assess the amount of overhead involved. The goals of these tests were as follows:
Measure the total impact of Packet Signing on the IPX/NCP request-response conversation.
Differentiate the Packet Signing overhead at the client from that at the server, and measure both.
Determine the effect of different CPU types and speeds on Packet Signing performance degradation.
Measurements. We used a LANalyzer to record request and response events on the wire and to calculate the elapsed time (delta) between packet events. The LANalyzer refers to the delta as the inter-packet time.
As shown in Figure 4, the overall request-response delta is calculated by adding the inter-packet times between a and b, and between b and c. The server delta is equal to the inter-packet time between a and b; the client delta is equal to the inter-packet time between b and c.
Figure 4: Points of measurement within the IPX/NCP request-response process.
We used the same methodology for testing with and without Packet Signing. When the two sets of results are compared, the difference can be attributed to Packet Signing overhead.
Workload. For a test workload, we chose PERFORM3, set to request packets equal to the maximum physical packet size of the media access protocol (Ethernet = 1514, Token-Ring = 4202). We focused on the read request-response conversation, since read requests make up 80 to 99 percent of production workloads.
The read request sizes we used eliminated the need for Burst Mode. This was done purposefully because Burst Mode is used so intermittently by production workloads. Although Burst Mode can improve performance, we designed our tests to omit it and focus on the measurement of Packet Signing overhead.
Test Bed Description. We tested Packet Signing on two media access protocols: 10Mbps Ethernet with a 1514 maximum packet size, and 16Mbps Token-Ring with a 4202 maximum packet size; two server platforms: a 386/33 ISA server, and a 486/50 EISA server; and four client platforms: an 8088 client, an 80286/16 client, an 80386/25 client, and an 80486/33 client. The results are shown in Figure 5.
Figure 5: Packet Signature performance study results.
Ethernet Test Results on ISA 386/33 Server Platform (Times given are in milliseconds)
|
Client
|
Without Packet Signing
|
With Packet Signing
|
Overall Degradation
|
||||
|
Overall |
Server |
Client |
Overall |
Server |
Client |
||
|
8088 |
20.22 |
2.05 |
18.17 |
30.17 |
2.17 |
28.00 |
33.0% |
|
286 |
3.62 |
2.05 |
1.57 |
5.17 |
2.18 |
3.55 |
36.8% |
|
386 |
3.13 |
2.05 |
1.08 |
3.58 |
2.17 |
1.41 |
12.6% |
|
486 |
2.91 |
2.06 |
0.85 |
3.15 |
2.15 |
1.00 |
7.6% |
Token-Ring Test Results on ISA 386/33 Server Platform (Times given are in milliseconds)
|
Client
|
Without Packet Signing
|
With Packet Signing
|
Overall Degradation
|
||||
|
Overall |
Server |
Client |
Overall |
Server |
Client |
||
|
8088 |
n/a |
n/a |
n/a |
n/a |
n/a |
n/a |
notavailable |
|
286 |
12.40 |
9.60 |
2.80 |
12.98 |
9.70 |
3.28 |
4.5% |
|
386 |
10.00 |
9.60 |
0.40 |
10.31 |
9.70 |
0.61 |
3.0% |
|
486 |
10.00 |
9.60 |
0.40 |
10.02 |
9.60 |
0.42 |
0.2% |
Interpreting the Results
As with all benchmark results, the results from these tests can be useful only if they're interpreted correctly. Since we measured individual round-trip packet times, the results apply more to unusually intense conversations such as file transfer where round-trip packet times are critical. The results apply less to more common delay-burst types of traffic indicative of normal user traffic. Although the degradation caused by Packet Signing is real, it is much more difficult for a user to notice during normal delay-burst types of transactions.
The following conclusions can be drawn from the test results:
Packet signing overhead at the server was measured at .100ms on the 386 platform and .055ms on the 486 platform. Therefore, by migrating from a 386/33 platform to a 486/50 platform, you can improve the performance of a Packet Signing server by 45 percent.
Packet signing overhead at the workstation was measured at .150ms on a 486 client, .330ms on a 386 client, 1.970ms on a 286 client,and 9.828ms on an 8088 client. We view the 486 and 386 results to be minimal and acceptable. However, the 286 and 8088 results are significant and should be considered seriously before enabling Packet Signing on older workstations (unless the issue of security outweighs performance).
With Packet Signing enabled, users requesting queries, reports, file transfers, and other intense workloads, will experience slowdowns similar to the results of our tests.
With Packet Signing enabled, users performing word processing and other kinds of light workloads on 386- and 486-based workstations should not notice any slowdowns.
The results from the Ethernet tests should not be compared to the Token-Ring test results. Although the Token-Ring results may seem slower, the packet sizes in the Token-Ring tests were almost four times those of the Ethernet tests. For comparison between the two media protocols, you would either have to rerun the tests with comparable packet sizes, or gather throughput results.
Compensating for Performance Loss
In some situations, the performance degradation created by using Packet Signature may be noticeable, especially when the server is already servicing a heavy workload. If your security requirements are such that you need Packet Signature protection, there are a number of other techniques you can employ to make up for the packet signing overhead.
Tailoring the Packet Signature Options. One obvious way to compensate for any performance degradation is to adjust the packet signature levels so that only those servers and clients that really need to are participating in the packet signing process. Network administrators should carefully evaluate their security needs and tailor the settings accordingly.
For example, if only a few workstations are publicly accessible, set the level on those workstations to 0 and set any servers that contain sensitive data to level 3. This arrangement prevents someone from logging in to the sensitive server from the public workstation, without affecting legitimate users on other workstations.
Disable the packet signature option on workstations and servers where it is unnecessary.
Enabling Burst Mode. Novell's Burst Mode protocol enhances NetWare's request-response communications architecture to include multiple-packet transmissions. With Burst Mode enabled, the server or client can send a "burst" of packets to the receiving client or server without any confirmation in between transmissions. This improves NetWare's performance when reading and writing large files, especially over wide area networks.
The NCP Packet Signature security enhancements are included in the latest version of PBURST.NLM, which must be loaded on a NetWare v3.11 server in order for packet signing to work. However, using the Burst Mode protocol is optional. The server is ready once PBURST.NLM is loaded; for DOS clients, you must load the BNETX.EXE shell and include the "PB BUFFERS=x" line in the NET.CFG file (x is a value between 2 and 10). Burst mode is not supported by the expanded and extended memory DOS shells, or by OS/2 workstations.
The latest version of Burst Mode has been modified to work better with the NCP Packet Signature software. Instead of requiring a signature to be calculated for every packet in a burst, the protocol has been modified so that only the first packet in a burst requires a signature.
Using Large Internet Packet (LIP). Novell's Large Internet Packet module (formerly known as LIPX.NLM) allows workstations and servers to exchange packets larger than the 512-byte data size which NetWare defaults to when it detects an intermediate router. LIP increases performance on networks where clients communicate with servers across routers. It is compatible with Novell's regular and multiprotocol routers, and with routers made by Cisco, 3Com, Wellfleet, Proteon, and others. LIP can also be used along with Burst Mode.
Conclusion
NCP Packet Signature is only one piece in the overall NetWare security picture. In addition to installing Packet Signature when necessary, network administrators should use NetWare's extensive security features and other protective measures to guard their network data from unauthorized access. The SECURITY.DOC file contains a list of twenty guidelines for securing your network. We recommend that you read and implement these suggestions.
The November 1992 security enhancement package represents the first phase of Novell's ongoing effort to strengthen network security. NCP Packet Signature will be built in to future releases of NetWare v.3x as well as NetWare v4.0.
Additional Reading
For more information about NetWare security and other concepts discussed in this Appnote, refer to the following documents:
"NetWare Security: Configuring and Auditing a Trusted Environment", Novell Research Report, part number 164-000030-015.
"An Introduction to Novell's Burst Mode Protocol," March 1992 NetWare Application Notes, part number 164-000031-003.
"Increasing NetWare Throughput with Large Internet Packet Exchange (LIPX.NLM)," July 1992 NetWare Application Notes, part number 164-000031-007.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.