CA2045931C - Encryption with selective disclosure of protocol identifiers - Google Patents

Abstract

ENCRYPTION WITH SELECTIVE
DISCLOSURE OF PROTOCOL IDENTIFIERS

A method for selective disclosure of the identity of a communication protocol under which an information packet originated, but without incorrectly identifying the protocol in a header accompanying the packet. If there is a need to conceal the identity of the underlying source protocol, a special anonymous protocol identifier is used, instead of the real proto-col identifier, in the header of an encrypted informa-tion packet. Network monitors can then still provide accurate information concerning traffic on the network, without having this information distorted by the use of incorrect communication protocols. If there is a desire to reveal the underlying protocol, a subnetwork proto-col frame format is used to store the protocol identity and signify whether the packet is encrypted. A packet that is of a non-subnetwork protocol can be encapsu-lated with a subnetwork header containing a special code signifying that there is an encapsulated packet and containing the original protocol identifier.

Description

` ` 2~4~931 ENC~YPTION WITH SELECTIVE
DI~LOSURE OF PBOTOCOL I~ RS

~CKGROUND OF TH~ INVENTION

This invention relates generally to computer networks and, more specifically, to techniques for en-crypting and decrypting messages transmitted over net-works. The following background material, under the subheadings "Computer Network Background" and "Crypto-graphy Background," introducec various computer network and cryptography concepts and definitions. Those fami-liar with computer networks and cryptography may wish to skip these two sections.
15 Computqr Network ~ackg~ound- -A computer network is simply a collection of autonomous computers connected together to permit shar-ing of hardwar~ and software resources, and to increas~
overall reliability. The term "local area network"
20 (LAN) is usually appli~-d to computer networks in which the computers are located in a single building or in nearby buildings, such as on a college campus or at a single corporate site. When the computers are further apart, the terms "wide area network" or "long haul 25 network" are used, but the disti~ction is one of degree b and the definitions sometimes overlap.
A bridg~ is a device that is connected to at least two LANs and serves to pass message frames be- ~
tween LANs, such that a source station on one LAN can ~ -30 transmit data to a destination station on another LAN, without concern for the location of the destination.
Bridges are useful ~nd necessary network components, principally becaus~ the total number of stations on a single LAN is limited. Bridges can be implemented to 35 operat~ at a selected layer of protocol of the network.

A detailed knowledge of network architecture is not needed for an understanding of l:hi~ invention, but a brief description foll~ws by way of further background.
As computer networks have developed, various approaches hava been used in the choice of communica-tion medium, network topology, message format, proto-cols for channel access, and so forth. Some of these approaches have emerged as de facto standards. Several models for network architectures have been proposed and widely accepted. The most widely accepted model is known as the International Standards Organization (ISO) Open Systems Interconnection (OSI) reference model. The OSI reference model is not itsel~ a network architec-ture. Rather it specifies a hierarchy of protocol lay-ers and defines the ~unction of each layer in the net-work. Each layer in one computer of the network carries on a conversation with the corresponding layer in anoth-er computer with which communication is taking place, in accordance with a protocol defining the rules of this communication. In reality, information is trans-ferred down from layer to layer in one computer, then through the channel medium and back up the successive layers of the ot~er computer. However, for purposes o~
design of the various layers and understanding their ~unctions, it is easier to consider each of the layers as communicating with its counterpart at the same level, in a "horizontal" direction The lowest layer defined by the OSI model is called the physical layer, and is concerned with trans-mitting raw data bits over the communication channel,and making sure that the data bits are received without error. Design of the physical layer involves issues of electrical, mechanical or optical engineering, depend-ing on the medium used for the communication channel.
The layer next to the phy~ical layer is called the data .
:

-` 2~93~

link layer. The main task of the data link layer is to transform the physical layer, which interfaces directly with the channel medium, into a communication link to the next layar above, known as the network layer. This channel may losa whole packets, but will not otherwise corrupt data. The data link layer performs such func-tions as structuring data into packet~ or ~rames, and attaching control information to the packets or frames, such as checksums for error detection, and packet num-bers.
Although the data link layer is primarily inde-pendent of the nature of the physical transmission me-dium, certain aspects o~ the data link layer function are more dependent on the transmission medium. For this reason, the data link layer in some network architec-tures is divided into two sublayers: a logical link con-trol (LLC) sublayer, which per~orms all medium-indepen-dent functions of the data link layer, and a media ac-cess control ~MAC) sublayex. The M~C sublayer deter-mines which station should get access to the communica-tion channel when there are conflicting requests for access. The functions of the MAC sublayer are more likely to be dependent on the nature of the transmis-sion medium.
Bridges may be designed to operate in the MAC
sublayer. Further details may be found in "MAC Brid-ges," P802.1D/D6, Sept. 1988 (and later versions~, a draft publication of IEEE Project 802 on Local and Metropolitan Area Network Standards.
The basic function of a bridge is to listen ~"promiscuously," i.e. to all message traffic on all LANs to which it is conn~cted, and to forward some of the message-Q it hears onto LANs other than the one from which the me~sa~e was heard. Bridges also maintain a database of station locations, derived from th~e content ~:: --~ 20~593~

of the messaqes bei~g forwarded. Bridges are connected to LANs by paths known as "links." After a bridge has been in operation for some time, it can associate prac-tically every station with a particular link connecting the bridge to a LAN, and can then forward messages in a more efficient manner, transmitting snly over the appro-priate link. The bridg~ can also recognize a message that does not need to be forwarded, because the source and destination stations are both reached through the same link. Except for its function of "learning" sta-tion locations, or at least station directions, the bridge operates basically as a message repeater and for-wards messages from one LAN to another until they reach their destinations. Other devices, known as routers, are also used to intercon~ect LANs.
A router, like a bridg~, is a device connected to two or more LANs. Unli~e a bridge, however, a router operates at the network layer level, instead of the data link layer level. Addressing at the network layer level makes use of a large (e.g. 20-byte) address field for each host computer, and the address field includes a unique network identifier and a host identifier with-in the network. Routers make use of the destination network identifier in a message to determine an optimum path from the source network to the destination net-work. Various routing algorithms may be used by routers to determine the optimum paths. Typically, routers ex~
change information about the identities of the networks to which they are connected.
When cryptography is used to protect data tran-smitted over a computer network, some network devices, such as bridges and routers, may require special treat-ment. For example, an encrypted message should, in general, not be decryp~ed by a router that is mexely ~;~ 35 ~orwarding the message to an adiacent LAN. As will also `.:
~'. ~, :

=~ 20~5931 become apparent as this description proceeds, crypto-graphy as applied to networks poses some problems that do not arise in a more conventional application of cryp-tography in point-to-point communication. When a mes-sage passes down throu~h the various protocol layers ofa transmitting station, each layer add its own header to the message, which may be segmented into standard-size frames of data. The headers added at various proto-col levels include addressing and other informa~ion that is used to route a message frama to its intended destination and to recreate the message at the destina-tion. Encryption must usually be applied only to the message content and not to the various message headers.
While this is not a dif~icult concept, in practice complexities arise because dif~erent network protocols may be employed at any of the protocol levels. There- -fore, a hardware-implemented cryptographic system for networks must be capable of handling mPssage frames originating from these different pro~ocols, and having necessarily different frame formats. In addition each of these frames may get seg~ented in~o smaller fram~s as it passes through several intermediate network links.

Cryptoaraphy ~çkground:
The principal goal of encryption is to render communicated data secure from unauthorized eavesdrop-ping. This is generally referred to as the "secrecy" or "confidentiality" requirement of cryptographic systems.
A related requirement is the "authenticity" or "integri-ty" requirement, which ensures that the communicated information is authentic, i.e. that it has not been tampered with, eith~r deliberately or inadvertently.
For purposes of further discussion, some definitions are needed.

;: - :
: ~ --- .
.

-^` 2~931 "Plaintext" is used to refer to a message be-fore encrypting and after decrypting by a cryptographic system. "Ciphertext" is the form that the encrypted part of the messaqe taXes during transmission over a s communications channel. "Encryp~ion" or "encipherment"
is the process of transformation ~rom plaintext to ci-phertext. "Decryption" or "deciph~rment" is the process of transformation from ciphertext to plaintext. Both encryption and decryption are controlled by a "cipher key," or keys. Without knowledge of the encryption key, a message cannot be encrypted, even with knowledge of the encrypting process. Similarly, without knowledge of the decryption key, the message cannot be decrypted, even with knowledge of the decrypting process.
More specifically, a cryptographic system can be thought of as having an enciphering transformation Ek, which is defined by an enciphering algorithm E
that is used in all enciphering operations, and a key K
that distinguishes Ek from other operations using the algorithm E. The transformation Ek encrypts a plain-text message M into an encrypted message, or ciphertext C. Similarly, the decryption is per~ormed by a transfor-mation Dk de~ined by a decryption algorithm D and a key X.
Dorothy E.R. Denning, in "Cryptography and Data Security," Addison-Wesley Publishing Co. 1983, suggests that, for comple~e secrecy of the transmitted messa~e, two requirements have to be met. The first is that it should be computationally infeasible for anyone to systematically determine the deciphering transforma-tion Dk from intercepted ciphertext C, even if the corresponding plaintext M is known. The second is that it should be computationally infeasible to systematical-ly determine plaintext M from intercepted ciphertext C.
The authenticity requirement is satisfied if no-one can .','. ' ' -:- ., .. :~:.. ..

2~5~3~

substitute false ciphertext C' for ciphertext C without detection.
By way of further background, cryptographic systems may be classified as either "symmetric" or "asymmetric." In symmetric systems, the enciphering and deciphering keys are either the same or are easily determined from each other. When two parties wish to communicate through a symmetric cryptographic system, they must first agree on a key, and the key must be transferred from one party to the other by some secure means. This usually requires that keys he agreed upon in advance, perhap3 to be changed on an agreed time-table, and transmitted by courier or some other secure method. Once the keys are known to the parties, the ex-change of messages can proceed through the cryptogra-phic system.
An asymmetric cryptosystem is one in which the enciphering and deciphering keys differ in such a way that at least one key is computationally infeasible to determine from the other. Thus, one of the transforma tions Ek or Dk can be revealed without endangering the other.
In the mid-1970s, the concept of a "public keyl' encrypticn system was introduced. In a public key system, each user has a public key and private key, and two users can communicate knowing only each other's pub-lic keys. This permits the establishment of a secured communication channel between two users without having to exchange "secret" keys before the communication can ` 30 begin.
In general, asymmetric cryptographic systems require more computational 'lenergy" for encryption and ; ~ decryption than symmetric systems. Therefore, a co~mon development has been a hybrid system in which an asym-metric system, such as a public key system, is first : .

' ;.

2~593~

used to establish a~ "session key" for use between two parties wishin~ to communicate. Then this common ses-sion key is used in a conventional symmetric crypto-graphic system to transmit messaqes from one user to the other.

Cryptoqraphy ~n Networks:
Although cryptographic principles may be con-ceptually simple when point-to-point communications are involved, additional problems arise when the communica-tion is over a complex computer network. A single mes-sage communicated from one station to another may pass through multiple stations and multiple LANs be~ore reaching its final destination. A basic design question is whether the encryption should be "end-to-end" encryp tion, i.e. with one encryption process at the source station and one decryption pxocess at the ~inal destina-tion station, or "link" encryption, i.e. with encryp-tion and decryption taking place before and after trans-mission "hop" over each intermediate communication linkthrough which the message is passed. Various combina-tions of end-to-end encryption and link encryption are also possible. Standardization in the area of crypto-graphic processing for networks is still evolving. One effort directed toward standardization is the Standard for Interoperable LAN Security (SILS), an ongoing ef-fort of an IEE~ 802.10 subcommittee aimed at standardi-zing 'idatalink layer" encryption for a LAN.
In general, end-to-end encryption is preferred because it provides a higher level o~ data security and authenticity, since messages are not deciphered until they reach their final destinations. However, any ad-dressing information, or the early par~s of the frame that contain network addresses, cannot be encrypted in end-to-end encryptlon, because intermediate stations or . .

-` 20~59~

g nodas need them for message routing. One of the practi-cal difficulties of using cryptography in computer net-works is that a received message packet will contain both plaintext data, such as frame headers added by the various layers of network protocol, and encrypted data, which is usually the largest part of the packet. Anoth-er complication is the possible existence of multiple protocols at some levels. Ideally, a network crypto-graphy system must be capable of handling these differ-ent protocols without modification of the hardware orsoftware performing the encrypting or decryptin~ opera-tions.
A related problem is that ~he network proto-cols of the upper layers are subject to occasional revision, by manufactuxers or by industry standards committees. Therefore, an ideal network cryptography system is one that is relatively immune to changes in upper layer protocols, specifically the network layer and above.
Still another difficulty is that network archi-tectures without cryptography are already well estab-lished. The addition of the cryptographic functions must ideally be made without impact on the continued operation sf these existing architectures. In other words, cryptography should be implemented as a simple hardware solution that fits within current architec-tures with as little change as possible.
In the past, cryptographic processing has been performed in the network environment in a mode that can best be characterized as "store-process-forward." A
packet of data to be encrypted or decrypted is stored in a packet buffer, is subsequently retrieved for cryp-tographic processing, and is ultimately forwarded after processing. In some designs, the packet buffer is mul-ti-ported, to allow incoming data to be stored while ':
" :

-" 2 ~ 3 1 other data in the buff~r is processed by ncryption/de-cryption software in a host computer system. In other designs, there are two packet buffers, one of which is filled with incoming data while the other is b~ing emp-tied and cryptographically processed. These require-ments for multiple buffers or enlarged packet buffers necessarily introduce cost and performance restrictions on the host processor. In addition there is a necessary dalay in the processing of each packet at both the send-ing and receiving ends.
As used in this speci~ication, the term encryp-tion is intended to encompass cryptographic processing that provides either "con~identiality and integrity" or '~integrity only" protection to the data~ In the ~ormer case, the message and a checksum are encrypted hefor2 appending networX and MAC headers. In the latter case, the message is in plaintext but a cryptographic check-sum is appended to the message. Similarly, the term de-cryption is used for cryptographic processing encompass-ing both the recovery of plaintext along with recoveryand verification of a checksum from encrypted data, and the verification of the integrity of an "integrity only" protected message.
It will be appreciated from the foregoing that there is a still a need for improvement in cryptogra-phic processing for computer networks. Ideally, crypto-graphic procisssing should place no special demands on ,: -. . ..
the packet m~mory storag@ at a station, should not in-troduce any substantial delay or iatency in the process-ing of each packet, and should be convenient to add toexisting network architectures that do not have crypto-graphic pro essing. Thé present invention is directed to these ends.

~ 2~93~

~ 11 --SUMMARY OF THE INVENTION
The present invention resides in an encryption method in which an underlying communication protocol at the source of an encrypted information packet need not be identified in a cleartext header accompanying the packet. In the past, if there has been a need to conceal the identity of the communication protocol, it has been incorrectly identified in the header.
This is undesirable because it distorts infoxmation obtained by network monitors that observe traffic flow in the network.
The invention in its broad form resides in an automatic method for encryption of information packets for transmission over a communication network, the method comprising. determining whether or not to encrypt an information packet prior to transmittal ovor a communication network; if an lnformation packet is to be encrypted, deciding whether or not to conceal the identity of an underlying~network protocol by means of which the information packet was generated; if the underlying network protocol is to be concealed, using a special protocol identifier in a plaintext portion of a header in the information packet, to indicate that the underlying network protocol is to remain anonymous; and subsequ ntly identifying the underlying network protocol within an encrypted portion of a header in the :
information packet, whereby monitoring of encrypted network ~25 ~ traffic will not be distorted by the use of incorrect protocol ~ -identifiers~. ~

~: , . . .

`- 204~5~31 - 11 a The method of the invention includes the steps of determining whether or not to encrypt an information packet prior to transmittal over a communication network; then, if an information packet is to be encrypted, deciding whether or not to conceal the identity of an underlying network protocol by ~-means of which the information packet was generated. If the underlying network protocol is to be concealed, the method provides for using a special protocol identifier in the clear text part of the header in the information packet, to indicate that the underlying network protocol is to remain anonymous;
thus identifying the information packet as one that has been transmitted with an anonymous protocol identifier. In this way, monitoring of encrypted network traffic will not be distorted by the use of incorrect protocol identifiers.
I~ networ~ user wishes to disclose the underlying network protocol, the method provides for using a SNAP/SAP protocol in such a way that frames originally addressed to a SNAP/SAP proto-col in such a way that frames originally addressed to a SNAP
/SAP will contain a bit or combination of bits in the protocol identifier (PID) field signifying whether or not the frame is encrypted. Original non-SNAP/SAP frames can be encapsulated using SNAP/SAP frames such that a subfield o~ the PID ~ield will : ' .' , .

: .
. .

:

2~9~

contain the original SAP value.
It will be understood from the foregoing that the present invention provides a simple but previously undiscovered solution to an ongo:ing difficulty in the operation of communication networks in which encrypted inforn~ation packets may be transmitted. Although there is often a legitimate need to conceal the identity of an underlying communication protocol associated with an encrypted message, there is also a need to obtain accu- -rate information concerning n~twork operation, by means of network monitors. The provision of an anonymous net-work protocol identifier satisfies both these needs. In a converse situation, there is sometimes a desire to disclose the underlying protocol but existing datalink encryption standards may prevent its disclosure. Anoth-er feature of the invention permits the selective dis-closure of th~ underlying protocol for ~oth SNAP/SAP
frames and non-SNAP/SAP frames.

' : :
.

; ~ ~
: ~ ,,.. .-.

:~;
: ~
~ 35 -: :- - .

204~931 }3RIEF DESCRIPTION OF THE DRAWINGS
A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example only, and to be understood in conjuntion with the accompanying drawing wherein:
FIGURES la-lc are block diagrams of various prior implementations of cryptographic processing in a networking environment;
FIG. Z is a block diagram showing how cryptographic processing is implemented in accordance with one aspect of the present invention;
FIG. 3 is block diagram of a cryptographic processor incorporating thi~ claimed invention;
FIGS. 4, 5, 6a, 6b, 7 and 8 are flowcharts showing functions performed by the cryptographic processor in parsing a received information packet;
FIGS. 9a-9b are diagrams of two types of S~AP/SAP packet formats;
FIG. 10 is a diagram of ISO end-to-end packet format;
FIG. 11 is a diagram o~ a packet format applicable to this invention that conforms to a draft 802.1 SILS standard as of June 2, 1990;
FIG. 12 i~ a diagram showing in more detail the format of - . .
a security control field within the packet formats of FIGS. --~

9a-9b,~10 and 11;
--:
:

- 2~93~

- ~3a - -FI&S. 13a and 13b together constitute a flowchart showing functions pexformed by the cxyptographic process in parsing an outbound or looped back information packet;
FIGS. 14a-14c are diagrams of three types of outbound or loopback packet formats; and FIG. 15 is a flowchart showing abort processing in accordance with one aspect o~ the invention. ~-.~,--. :--- 20~93~

DESCRIPTION OF THE PREFERFtED EMBODIMENT

As shown in the drawings for purposes of illus-tration, the present invention is concerned with crypto-graphic processing in the context of interconnected com-puter networXs, referredi to in ~his specification as local area networks or LANs. There are many applica-tions of networks in which confidentiality or the inte-grity of transmitted data are important to safeguard.
Confidentiality ensures that, for all practical pur poses, it is impossible for an eavesdropper connected to the network to convert the transmitted data from its encrypted form to its original plaintext form. The "in-tegrity" of the data refers to its protectlon against unauthoriæed or inadvertent modi~ication.
In accordance with one of the protocols des-cribed in this specification, encryption is performed at a transmitting or source node and decryption is per-formed at a destination node. This is known as end-to-end encryption, as contrasted with link encryption, inwhich decryption and re-encryption are performed at each intermediate node between the source and the desti-nation. The manner in which encryption is per~ormed, or the encryption algoxithm, is of no particular conse-quence to the present invention. Nor is it o~ any conse-quence whether encryption and decryption keys are ex-changed in advanc~ between the sending and receiving nodes, or whether a public key system is used ~or the es~ablishment of keys. As will be noted later in this description, one implementation of the invention uses an encryption algorithm known as the Data Encryption Standard ~DES), as defined by FIPS-46 (Federal Informa-tion Precessing Standard - 46) published by the Nation-al Institute o~ Standards and Technology (formerly the National Bureau of Standards). However, the invention - .

`` 2~5~

is not limited to this, or any ol:her encryption algo-rithm.
Typical token ring networks use optical fiber, coaxial cable, or twisted pair cable a~ a transmission medium. One such network using the token ring protocol i9 known as the fiber distributed data interface (FDDI). The description in this specification .is based on FDDI interfaces and frame forma~s, but with minor modifications would also apply to a wide variety sf network interfaces.
Encryption may be performed, at least in theory, at any of a number of protocol layexs in a network architecture. In practice, it is conveniently performed at the data link layer. FIG. la is a block diagram showing data flow within th~ data link layer.
Data packets arriving from the physical layer (not shown) are processed by the ~AC proce~sor, indicated by reference numeral 10, and then passed *o a memory controller 12, which controls operations on two packet buffers 14a, 14b.
In one prior art approach, cryptographic pro-cessing is perfor~ed, as indicated at 16, on data re-trieved from the packet ~uffers 14a, 14b. For incoming data, from the physical layer, data packets are stored in alternate packet buffers, retrieved for decryption by the cryptographic processor 16, and forwarded in decrypted form to the next higher protocol layer. out-going data frames are similarly stored in the packet buffers 14a, 14b, retrieved for encryption by the cryp-tographic processor 16, and then forwarded by thememory controller 12 to the MAC processor 10.
FIG. lb shows a similar arrangement, except that there i8 only one packet buffer ~4, which must be large enough to provide storage ~or multiple data pac-; 35 kets, and may require two ports for simultaneous access . -, ..
:~ ,.
:

2 ~ 3 1 to the cryptographic processor 16 and the MAC processor lo. FIG. lc shows another arrangement, similar to FIG.
lb except that the cryptographic processor 16 is not connected in series with the data paths to higher proto-col layers.
In accordance with the present invention, and as shown by way of example in FIG. 2, cryptographic pro-cessing is performed in an in-line or "pipelined" or - -~cu~-through~' fashion by a cryptographic processor 16' which, in this exemplary embodiment, is locateal between the MAC processor 10 and the memory controller 12. The cryptographic processor operates at network speeds on data streamed ~rom or to the MAC processor 10, and re-quires no additional packet buf~er bandwidth, addi~ion-al packet buffers, or additional processing capabili-ties. ~ :
~y~toqraphic proQ~ssor hardwa~e. ~:-As shown in FIG. 3, the cryptographic proces-sor o~ the invention provides a full-duplex path be- ~:
tween the MAC sublayer, through a MAC interface 20, and the RMC (ring memory controller) module, through an RMC
inter~ace 22. The receive data path is normally via ~-.
input-receive data lines (designated IRPATH~ to the MAC
interface 20. The M~C interface 20 checks the parity o~
data received from the MAC processor, monitors control lines for end-of-data signals, to keep track of packets being processed. Processing and routing of the incoming data are controlled largely by a receive control state : -machine 24, the functions of which will be described in ;.
30 some detail. Basically, the receive control state ..
machine 24 examines incoming packets of data as they arrive from the MAC interface, and determines what action should be takenj including whethsr or not an : incoming packet should be decrypted. --The receiYe data path also includes a DES
-. -2 ~

(data encryption standard) function module 26 of conven-tional design, a multiplexer 28 at the output of the DES module 26, a receive FIFO (first-in-first-out) memory 30, and another multiplexer 32, the output of which is connected to the RMC interface. ~or decryption operations, data signals recaived from the MAC inter-face 20 are input to the DES module 26, and the decryp-ted signals then pass through the multiplexer 32 to the RMC interface 22. The multiplexer 32 selects its input either from the DES module 26, the receive FIFO 30, or from a third line 34 through which data may be looped back to the RMC interface 22 from a transmit data path to be described. Parity, and other check codes to be de-scribed, may be added to the decrypted data output from the DES module 26. Data being processed in ~he receive data path is finally output through the RMC interface 22, over output-receive lines designated ORPATH.
The transmit data path is similar in structure to the receive data path. Data packets for ~ransmi~sion are received at the RMC interface over input-transmit lines designated ITPATH, checked for parity, and trans-mitted to a transmit FIFO memory 40 and a second DES
function module 42, outputs from these two paths being selected by another multiplexer 44 for forwarding to the MAC interface and output over output-transmit lines, designated OTPATH. Insertion of a cyclic redun-dancy code (CRC) requires ths addition of a C~C genera~
tor and checker module 4~, another multiplexer 48 to select between data from the ~MC interface 22 and data fed back over line 50 from the DES module 42 output, and yet another multiplexer 54 to select between output rom the CRC generator and inpu~ data from ~he RMC
interface. Control of data flow in the transmi~ data path is ef~ected by a loopback/transmit con~rol state machine 60. It will be observed that multiplexer 44 .....
. .,: . .

20~93~ .

provides its output to three possible paths: to the MAC
interface for transmission of an outbound data packet, to multiplQxer 32 (over line 34) ~or the loopback of a data packet to the RMC interface, and over another line 62 to a nod~ processor interface 64, for loopback o~ a data packet to the node procPssor, or host processor (not shown).
The basic function of the receive control state machine 24 is to parse or analyze each incoming 10 data packet received from the MAC interface 20, and to -determine how to process that packet. The most impor-tant decision to be made in this regard is whether or not an incominy packet needs to be decrypted. Based on its analysis of header information in an incoming pac-ket, the receive control state machine 24 conditions the receive data path to process the incoming paoket appropriately. An important aspect o~ the parsing of incoming data packets is that it must be performed as the packet is streaming in from the MAC inter~ace 20.
By the time the first byte of possibly encrypted data arrives, it should be known whether or not decryption is needed.
A similar process is followed for transmitted data packets received from the RMC interface 22. The loopback/transmit control state machine must determine from header information in the transmitted packet wheth-er encryption is required, and must then condition the transmit data path to perform the appropriate transfor-mation and routing of data that ~ollow the header infor-3Q mation. The transmit data path handles not only packetsthat are outbound through the MAC interface 20, but also packets that are bein~ looped back through the cryptographic processor for various reasons. Loopback may be used by the node procesisor to encrypt a cipher key or keys, prior to encryption of data, or may be ' 2~9~

used to encrypt or decrypt data and pass th~ trans-formed packet back to node proce~;sor, either directly or throu~h the RMC interface 22. An important function of loopback processing is in handling false decryp-tions. A false de~ryption occurs when an incoming pac-ket is decrypted, but should not have be~n. Upon disco-very of the mistake, the falsely decrypted packet is looped back to the cryptographic processor so that the erroneous transformation of data can be reversed.
The receive data path:
The process of parsing an incoming data packet is shown diagrammatically in the flowcharts of FIGS.
4-8. There are a variety of packet formats, correspon-ding to different network protocols used at higAerlevels in the hierarchy of network architecture. Pars~
ing of an incoming packet involv~s the basic steps of identifying the protocol that was used to generate the packe~, and extracting sufficient information ~rom the packet headers to determine whether decryption is needed and, if so, what type of decryption and where in the packet it should begin.
The identification of every conceivable packet format would be complex and time-consuming. Moreover, the present invention is not limited to parsing logic capable of identi~ying particular packet formats. By way of example, several types of formats are identified in the receive data path of a presently preferred em-bodiment of the invention. These formats are shown dia-grammatically in FIGS. 9a-9b, 10 and 11. FIGS. 9a-9b show two variants of the packet format known as SNAP/
SAP, including a Data Link encryption format defined by Digital Equipment Corporation (YIG. 9a), and the DOD-IP
encryptio~ format (FIG. 9b). FIG. 10 shows the ISO
endwto-end encryption packet format, and FIG. 11 shows . .
" -:- 2 ~ 3 1 a third format, known as SILS, which is still in the process of being defined in the industry.
All of the packet formats have in com~on a MAC
header, an LLC header, and a security control field (referred to as SE CTRL). Parsing the incoming packet involves first checking the MAC header to determine if the packet is of the type that should be decrypted, then checking the LLC header to identify the protocol, and finally skipping to the appropriate field of the packet to extract information needed to perform the decryption process. At multiple points in the parsing process, a decision may be made not to decrypt the packet, in which case it i5 simply forwarded through the RMC interface 22.
The first step in parsing an incoming packet is to examine the MAC header, as shown in FIG. 4. The frame control field of the MAC header contains a ~ield identifying the packet as using a long address type or a short address type. If long addresses are not speci-fied (as determined in block 40) no decryption is per-formed and the packet is forwarded to the RMC interface 22 (as indicated in block 42). Similarly, if the frame class identi~ied in the frame control field is not iden-tified as LLC (block 44), no decryption is performed.
Further, if either th~ MAC destination address multi-cast bit (block 46) or the MAC source address routing information indicator bit (block 48) is set, no decryp-tion is performed.
LLC parsing includes examining the first two bytes of the LLC header to identify the protocol, as indicated in block 54 and the multiple paths emanating from this block. In the ase of the SNAP/SAP packet ~ormat, the first two bytes o~ the LLC header wil} each have a hexadecimal value of AA, i.e. a binary value of lOlO 1010. In the case of the ISO end-to-end packet 2~5~31 format, the first two bytes of the LLC header will each have a hexadecimal value QP FE, i.e. a binary value of 1111 1110. In all cases, the secon~ byte need not neces-sarily be checked, bUt the third byte (CONTROL field) has to be 03 hexadecimal (unnumbered in~ormation3.
If, in parsing the LLC header, the cryptogra-phic processor does not recognize a SNAP~SAP packet (block 56, continued in FIG. 6a), or an ISO end-to-end packet (block 58, continued in FIG. 6b), or a SILS
packet (block 60, continued in FIG. 7), then a decision is made not to decrypt (block 42) and the packet is passed to the RMC interface 22 without further crypto-graphic processing.
What this specification refers to as a SILS
packQt does not necessarily represent a format that tha IEEE 802.10 (SILS) standards committee will eventually agree on as a standard. As will shortly be appreciated, the disclosed embodiment of the present invention is readily adaptable to handle the eventual SILS standard.
However, at the time of preparing this specification a firm standard does not exist and any attempt at com-... .
pliance would be speculative. i In further parsing a SNAP/SAP p~cket (FIG.
6a~, processing continues with a check (in block 62~ of 25 the proto~ol identification (PID) bytes to determin~ -the SNAP/SAP packet type. The packet types recognized in the presently preferred embodiment of the invention are given in the following table:
. :.

3 0 Packet PID Byte Typa ~ 1 2 3 4 5 _ Dig~ tal 0000 1000 0000 0000 0010 1011 x~cxx xxxl xs~ xx :
Data Link : .' .:

`` 2 ~ 3 1 If the packet type is recognized as ~eing of the Digital Data Link type, thP next field to be ana-lyzed is the security control field, as indicated at 64. For a DOD-IP packet type, the IP header length 5 (from the next byte in the packet) is saved for future -use as an offset, as indicated in block 66. Then the next five bytes are skipped and a flag/offset field is examined (block 68). The flag/offset field has the following format:
0000 0000 0000 OrDM, where O is an o~fset, r is a reserved bit position, D means Do not fragment, and M means More fragments. ~-,... . - .
If there are no more fragments (M=O) and the offset is zero (0=0), as determined in block 70, proces-sing continues. Otherwise, decryption is not performed (block 42). As processing continues, it i5 next deter- .
mined (in block 72) whether the protocol identification byte, which follows the flag/offset field by one byte, contains the correct protocol value. The correct proto-col identification for the DOD-IP protocol is initially stored in a register (designated the DOD_IP PID regis-ter) asso iated with the cryptographic processor. If the identification is correct, processing continues : with SE_CNTRL parsing (64).
ISO end-to end parsing, as shown in FIG. 6b, : ~ ~ cont:lnues~with confirmation of the ISO-IP format, by checking the PID fi~ld for an expected identifying value ~block 76). If confirmation is not found, no : ~ decryption is performed (block 42). If an ISO end-to~
end pacXet ~ormat is confirmed, the network header ; length is~saved (block 78), and the flay byte is exami-ned (blocX 80). The flag byte contains the following ` 35 in~ormation: --- `

~: : . - . .

2~4~931 .
SMeT TTTT, where s means Segmentation is permitted, M means ~ore segments will follow, e indicates and Error report, and TTTTT indicates the packet type.
If sQgmentation is not permitted (S-0~, as de-termined in block 82, decryption may or may not be required. Segmentation could not have occurred so the transport layer header is checked to see if decryption is appropriate. The remaining portion o~ the network header is skipped (block 84), and a length iden-tification and security identification from the pacXet are compared (in block 86, FIG. 8) with "~ingerprint"
values. If there is a fingerprint match (block 88, FIG.
8), cryptographic processing continues with SE_CTRL par-sing. If there is no fingerprint match, as determined in block 88, no decryption is performed (block 42).
If segmentation is permitted (S=l), decryption may still be appropriate. If there are no more se~mants (M=o) and the packet type is lC (hexadecimal), then the current packet may be the entire unfragmented packet or could be the last ~ragment (or segment) of a set of segments. The remaining portion of the network header is then skipped (block 84) and security processing will be effected, subject to further checks tblock 88~. If there are more segments (M=1), then the current packet is a fragmsnt of a larger (possibly encrypted) packet and must ~ be decrypted.
Parsing for a SILS packet ~FIGo 7) is a speci-3a al case because the SILS ~ormat is not yet defined. Allthat is known with certainty is that a SILS identifica-tion code will be transaitted at some designated field o~ the packet, and that security control field SE_CTRL
will begin at another designated location of the pac-ket. Therefore, to test a SILS packet the parsing pro-2~4~3~

cess first skips (block 100) by a programmed offset number of bytes to a location in the packet where it is known that a SILS identificatisn field will be stored.
This field is compared with a programmed SILS finger-print value (block 102). If there is a match (block104), processing skips by a programmed offset to the start of the SE_CTRL fiel~ (block 106). If there is no match, decryption is not performed (block 42).
Once the parsing of a received packet has con-cluded that decryption is required, the parsing processcontinues with an analysis of the SE_CTRL field of the pac~et. As shown in PIG. 8, the integrity ~lag is first checked (block 110) to make sure that cryptographic pro-cessing with integrity checking has been selected. If not, or if an unavailable encryption algorithm is selec-ted (block 112), no decryption is performed (block 42).
If the test in block 112 is passed, however, appro-priate flags are set ~block 114) to condition the cryp-tographic apparatus for decryption, and decryption is Z0 initiated (block 116).

~he loopback/transmit data pat~:
As discussed earlier with reference to FIG. 3, a packet received from the RMC interface 22 may be either an outbound packet for transmission through the MAC interface 20, with or without encryption, or may be : a packet: that i5 not transmitted to the MAC interface, but is instead subject to loopback for further proces-sing by the node processor. Although these alternatives complicate thin~s to some degree, processing in the loopback~transmit data path is made easier by the exls-tence of a cryptographic preamble in those packets for : which crypt~graphic processing is being requested. De-tails of the cryptographic preamble are discussed in a ~: 35 later descriptive section, but for now it need only be . ' .

20~31 understood that one field of the preamble contains a ::
processing mode field, where the modes are:
000 - outbound transmission, ~ -001 - loopback key encryption, 010 - loopback encryption, 011 - loopback decryption, and .-lOo - loopback encryption with only ICV
returned.
FIG. 13 is a flowchart showing the outbound lo and loopback processing, and FIGS. 14a-14c are the packet formats for three possible types of packets re- .
ceived from the R~C inter~ace 22. As shown in FIG. 13, .
the parsing of an outbound or loopback packet begins with two preliminary tests on packet request header 15 bytes at the beginning of the packet. If an FCS field : ;
. .
i present in the packet (block 120) or a cryptographic~. -preamble is not present in the packet (block 122), there is no further cryptographic processing, and the packet is forwarded directly to the MAC interface 20, 20 as indicated in block 124. Next, the mode field of the -cryptographic preamble is examined (block 126), and a :
selection is made from alternative processing paths, depending on the mode value in the preamble. I~ the ~ .:
mode is other than one of the permitted values, the ~ .
25 ~ransmission is aborted (block 128~. .. .
If the mode value is 00, indicating a~ out-bound encryption, an internal flag is set (TX_ENCR) to ~ .
in~icate this mods is in e~fect (block 130), an offset.:- . .
is loaded to indicate the starting point of the encryp- :
tion (block 132), and procesRing continues with parsing of the SE_CTRL field (bloc~ 134). Processing of the SE ~ :
: CTRL field is practically identical with the processing ~:
of this ~ield in the receive data path (as shown in , FIG. 8). The only differences are that, if the various : ~35 validity checks are passed, ~lags and values are set; `
. .
. .

~ 2~593~

for encryption rather than decrypt:ion (block 114), and instead of decrypting the key and data in block 116 there is encrypting of the key and dataO Furth~r, if the validity tests are failed, there is a decision to abort packet transmission, rather than a decision not to encrypt.
If the mode value is 01, indicating a loopback key encryption, a flag is set to indicate this (the LPBK_KEY flag), as indicated in block 136, offset and the SE_CTRL field are loaded (block 138), and proces-sing skips packet fields to the encryption key or keys (block 140). In this mode o~ processing, the keys (as shown in FIG. 14c) are found at an offset distance after the cryptographic preamble. They are encrypted using a previously stored master key (block 142)~ The cryptographic preamble is looped back with the encryp ted keys. The loopback path, either to the node proces~
sor interface 64, or to the RMC interace 22, is deter-mined by a mode register that is set to indicate in one of its fields which loopback path is to be taiken.
If the mode value is 10, indicating that loop-back encryption processing is required, two flags are set to so indicate: a TX_ENCRYPT flag and a LPBK flag, as indicated in block 144. An offset v~lue is loaded to indicate the starting point of the d~ta to be encrypted (block 146), and processing continues with the SE_CTRL
t~ansmit parsing (block 134). Data in the packet is subject to the encryption process defined in the SE
CTRL field, and the entire p~cket is looped back along the designated path to the node processor.
; If the moda value is llj indicating that loop-back decryption processing is required, the flags set :are a TX_DECRYPT flag and the LPBK flag, as indicated in block 148. Processing then continues in block 146, and the loopback process is similar except that the ' :, '' ,.. .

2 ~ 3 ~ -data are subject to decryption instead of encryption.
It will be noted from FIGS. 14a-14c that there are three possi~le pac~et formatc; for information re-ceived from the RMC interface 22. The first (FIG. 14a) S is that of an outbound packet for which no encryption services are re~uired, as indicated in the packet re-guest header at the beginning of the packet. The second format (FIG. 14b) is that of an outbound or loopback data packet for which encryption services are required.
The packet includes a cryptographic preamble, which is used to simplify transmit/loopback processing, is stripped from the packet prior to outbound transmis-sion, but is left with the packet if loopback is called for. The third format (FIG. 14c) is the one used to en-crypt a cipher key or keys. Its cryptographic preamblecontains a flag/offset field and security control (SE_CTRL) field, but no transmit (X~T) key, since a master key is used to encrypt the keys that follow in the packet~ Again, since this is a loopback operation the preamble is returned with the packet.
This concludes an overview of how the crypto-graphic processor of the invention operates to process packets received from the MAC interface 20 for possible decryption, and packets received from the RMC interface 22 for either encryption and transmission, or for loop-back to the node processor after encryption or decryp-tion. In~the following subsections, more specific as-pects of the invention are further discussed.

P~obabilistic Decryption:
For various reasons, not all received data pac-kets should be decrypted in the cryptographic processor 16' (FIG. 2). It is possible to determine from the pac-ket headers added at various protocol leYels whether the data in the packet must be decrypted. However, a : -2Q~593~

thorough analysis of the headers adds significantly to the- complexity of the parsing algorithm and might require that thP cryptographic processor maintain a database of protocol identifiere;. Moreover, slight S changes in header standards would require corresponding changes in the cryptographic processing to datermine whether decryptio~ was needed.
To avoid exhaustive header analysis or parsing time, and to minimize the need for continually updating the cryptographic processor, the processor decides whether or not to decrypt on a probabilistic basis, after a less than complete analysis o~ the packet head-ers. Basically, checks are made for a limited number of protocol formats, and decryption is either initiated or bypassed as a result of these and other relatively simple tests on the header information. If the decision is made erroneously, either the packet data will be decrypted when it should not have been decrypted, or the packet data will not be decrypted when it should have been decrypted. The falsely decrypted packet is forwarded to the next-higher protocol level and is eventually recognized as being falsely decrypted. The packet is then "looped back" through the cryptographic processor, which reverses the decryption and ~orwards the data packet back through the R~C interface 22 again.
The loop-back process obviously represents an inefficiency in cryptographic processing, but this is not a significant d~triment to the overall process be-cause the probability of such loop-backs is kept to a very low level. In the specific implementation des-cribed, and given current protocols, the probability i5 expected to be of the order of one in 224.
one di~ficulty with this approach is that, as can be seen ~rom the specific packet formats (FIGS.

; 2~931 6~061-97 9-12), the format o* an encrypted packet of data not only begins with header inormation, but ends with a special field referred to as an integrity check value (ICV), depending on the type of encryption required.
This field is a specially computed value, analogous to a checksum, that is computed at th~ encrypting end of the transmission, and i~ recomputed at the receiving end. Therefore, an encrypted pacXet will contain the ICV field at the end o~ the encrypted data, but a non-encrypted packet will not have this field. In the case of a false decryption, the entire packet of data must be recoverable, including the portion erroneously interpreted as the ICV ~ield.
To make the cryptographic processing of the packet entirely reversible, special ha~dling o~ the ICY
is required to assure that no information is lost dur-ing a mistaken decryption. The present invention, dur-ing decryption, does an exclusive-OR between the com-puted ICV and the received ICV and places the resul~ in the ICV field of the decrypted packet. Subsequent node processing can check that the ICV field is zero, to verify that the ICV in the encrypted packet was cor-rect.
If the decryption was mistaken, the packet will be looped back through the encryption device. The encryption algorithm is defined to include the steps of computing the ICV value and exclusive-ORing the result with the data present in the ICV field of the cleartext packet~ In an outbound packet, that data will always be ; ~ 30 zero, so ~he I~Y in the transmitted packet will always be the computed ICV. But in a pacXet which is }ooped back, that data will be the exclusive-OR o~ the origi-nal data and the computed ICV, so the encryption opera-tion wil} exactly reverae the mistaXen decryption opera-3~ tion.

: ~ :

~59~

-30~

Handlin~ short blno~cks ~n decryption:
Cryptographic processing using the data encryp-tion standard (DES) requires that data be presented to the DES processor in blocks of eight bytes each for the preferred mode of this embodiment: cipher block chain-ing (C~C). Therefore, a transmitted packet that is sub-ject to encryption should contain multiples of eight bytes. At the encryption end of transmission, it is relatively easy to meet this requirement. However, at the decryption end it is not possible to know thelength o~ an incoming packet at the time decryption is started. Since the principal goal of this invention is to provide for real-time encryption and decryption, decryption cannot be delayed until an entire packet of data is received.
There are two situations in which decryption may b started on a packet where the decrypted portion is not a multiple of eight bytes in length. One is a false decryption situation, where decryption i~ started on the basis of a false probabilistic determination that the incoming packet was encrypted. On reaching the end of the packet, it is then determined that a block of nonstandard size remains to be processed. The other situation is one in which an encrypted message has been segmented by an intermediate router in~o smaller pac-kets to meet network constraints, and the encrypted portion of the resluting fragments is not a multiple of the block size. A message encrypted for confidentiality and integrity, or for integrity alone, must be decrypt-~0 ed as a single entity, since the message contains atits end an integrity check value (ICV) that is gener~
ated from the content of the entire message. Subseguent segmentation o~ the encrypted message separates the ICV
field from some of the encrypted data, and integrity checking cannot be completed until the ICV field is . . .

-` ~0~593~

received in the last segment of the message. Therefore, segmented messages should not be decrypted as separate segments, and any attempt to decrypt such a message seg-ment is another ~orm o~ false decryp~ion.
According to this aspec:t of the invention, when a nonstandard block sizP is encountered during d2-cryption, the nonstandard block is ~orwarded without de-cryption. The node processor recognizes that a nonstan-dard block has been received, either by the status of a specific flag for this purpose or by performing length checking on the received blocks Or data. The node pro-cessor must then take corrective action, using the loop-back feature of the cryptographic processor, to trans-form the entire received packet back to the form in which it was received before false decryption. Initial~
ly, then, the falsely decrypted packet is looped back to the cryptographic processor for re-encryption of the entire packet except the last nonstandard block ~which was not decrypted~. If this re-encrypted packet is one segment of a segmented message, the node processor must combine this re-encrypted segment with others arriving before or after this one, and loop back the entire mes-sage as a single entity, for decryption and integrity checking in the cryptographic processor.
It may be observed that this relatively com-plex use of the loop-back procedure could be avoided if segmented messages could be reliably recognized upon receipt in th~ cryptographic proces or. Unfortunately, processing of each message to include exhaustive segmen-tation checking would introduce too much complexity to ~he design and introduce unacceptable dependencies on changes to the protocol standards. The invention in-stead relies on the use of ~ast but incomplete segmenta~
tion checXing, with the probability of non-detection of segmented messages being kept relatively low.
.
.
,;; . .

,: . ., i . ' ~' !

2~931 Frame status encodina:
In many communication protocols, a status byte is included in the trailing pa:rt of the packet, to carry status information specific to the particular 5 protocol. For example, in FDDI the frame status in- -cludes an Error Detected bit (E), an Address Recognized bit (A) and a Frame Copied bit (C). Other protocols may need other protocol specific status bits in the frame status byte. In some cases involving pipelined communi- -:
cation architectures, th~re is a need to convey addi-tional information with the frame, and it is desirable to do so without using any additional frame status bytes, or otherwise reformatting the frame of data. A
typical frame status byte has a count field indicating ~.
15 the number of status bits that are includad, and a .
status bit field. For example: ::

STATUS BYTE BIT POSITIONS
7 6 5 4 3 2 1 0 # OF PROTOCOL
2 O STATUS (:OUNT
. . _ .~.,, _ O O O _ _ _ _ O . :' 0 0 1 PSl - - - - 1 . .
0 1 0 PSl PS2 - - - 2 0 1 1 PSl PS2 PS3 - - 3 . .
2 5 L 0 0 PSl PS2 PS3 PS4 - 4 - : .
_~
In this status byte, bits 5-7 contain a count of the number of protocol specific status bits that are con~
tained in bits 4, 3, 2 and 1 of the status byte. As indicated in the tabl~, for example, a count of 1 in bits 5-7 mean that there is a protocol specific status bit PSl in bit position 4. A count of 4 (100~ in bits 5-7 indicates that bits 4~1 contain protocol specific status bits PSl, P52, PS3 and PS4, respectively. In this status byte format, there is room for one addi-,::
''' :'.

2~5~31 tional bit, in bit position 0, which may be us~d for additional status information. One aspect of the pre-sent invention provides a way o~ storing two bits of -additional status information without altering the format of the status byte and without using additional status bytes. .
Two additional status bits, obtained in the ;~
manner described below, are used in the cryptographic processor of the invention to convey the followi.ng mean-10 ings to the node processor: -00: No decryption performed, 01: ISO_IP decryption performed, no errors, 10; Non-ISO_IP decryption performed, no errors, 11: Decryption (end-to-end or datalink) per~ormed and errors datected.
._ _ ., STATU~; BYI~ BIT POSITIONS
7 ~; 54 3 2 1 0 # OF PROTOCOL
2 O STATUS COI~NT
.__ _ O O O- - - ASl ASO O :
O O 1PSl - - AS} kSO 1 O 1 0 PSl PS2 - ASl ASO 2 0 1 1 PSl PS2 PS3 ASl ASO 3 1 O ASl PSl PS2 PS3 PS4 ASO 4 . .
''. :' :
: ~ AS0 is an additional status bit stored in bit position O o~ the status byte. ASl is a second addition~
:al status bit, which is stored in two bit positions of --: . :
30 the status word, depending on the value in the count .-. ~ -; field ~bits 5-7). When the count is less than 4, as .~
:indicated by a zero in bit position 7, the ASl status :~- .. :
; is stored in bit position l of the status byte. But :when the count is 4 or greater, as indicated by a 1 in :: . -~: 35 bit position 7, bit l is used ~or the PS4 status and ~.
~, : , , .
- - -.

2~931 the ASl status is then stored in bit position 5 of the count, which is not needed when the count is ~.
This revised status byte format provides for the storage of two additional status bits in tha fram~
sta~us byte, without the need for additional status bytes, and with only minimal change in the manner in which the status byte is decoded. For protocol specific status information, the byte is decoded much as before, except that counts between 4 and 7 are all interpreted as indicating the presence of four protocol specific status bits. Decoding of the additional status bits is also relatively simple. Status bit ASo is always lo-cated in bit position 0, and status bit AS1 is located in bit position 1 if the count is 0-3 and is located in bit position 5, or alternatively in bit position 6, if the count is 4-7.

Abort processina_in pipelined communication:
When cryptographic processing is performed in real time, in series with MAC processing and packet memory processing, there is a "pipeline" of three or more processing modules or devices. In instances where one of the devices aborts processing, a critical ques-tion in tAe operation of the devices is whether the abort condition should be propagated to other adjacent processing devices in the same pipeline. A typical approach is to propagate the abort condition to up-stream devices.
In accordance with this aspect of the inven-tion, the abort condition is propagated to an upstreamdevice if, and only if, a packet of data associated with the origin of the abort condition is still being processed by the upstream device. In other words, if the packet being processed by the device that initiated the abort condition has already been completely pro~

2~93~

cessed by the upstream device, then there is no point in propagating the abort condition upstream.
Consider, for example, three devices desig-nated device #1, device #2 and device #3, coupled in sequential fashion to process inbound communication packets received by device #l and passed to devices #2 and #3 in turn. Outbound packets pass from device #3 to device ~2 to device #1. During inbound or receive opera-tion, suppose that devices #2 and #3 are processing the same data packet. If device #3 generat2s an abort condition and transmits it to device #2, device #2 will a}so abort processing the current packet. But if device #1 is currently processing a different packet, the abort signal will not be passed to device #1.
Abort processing in a device therefore follows these procedural steps, as illustrated in FIG~ 15 1) Has an abort signal been received from the next downstream device? If so go to step 2~.
2) Abort processing. Is the next upstream device currently processing the same packet as this device?
3~ If, and only if, the answer in step 2) is affirmative, propagate the abort signal to the next upstream device.
This method of handling the propagation of abort conditions improves network performance because it avoids retransmission of data packets that would be aborted unnecessarily without use of the invention. --.

:
~-' ,,'',, , ,' ,' ~ ~ 35 :: :

2~931 ' , , :
Encryption mechanism usinq_a cryptc?araphic preamble:
As already noted, there are several packPt formats for different layers of protocols in networX
communication. The cryptographic processor ~aces a significant problem, at both transmitting and receiving ends of a massage, in that the portion of a message packet that is to be encrypted or decrypted has to be located. One way to do this wou}d be to provide the cryptographic processor with complete definitions of all of the packet formats that would be encountered.
This approach has two major drawbacks. First, the pro-cessing time required to analyze the packet formats at each phase of processing would be unacceptably long.
Second, such a solution would require continual revis-ion to accommodate new or revised protocol packet for~mats.
At the receiving or decrypting end of a trans- -mission, this problem has been solved in part by employ-ing a probabilistic approach, wherein the format of an incoming data packet is analyzed quickly but to a limit-ed degree, and decryption is started only if the proba-bility is such that it is needed. False decryptions are handled by a loopback procedure in which a packet de-crypted in error is re-encrypted back to the form in which it was received. Another feature of the inven-:: -: .
tion, now to be described, addresses this problem at the sending end of a transmission.
The solution for outward bound message packets is to employ a special cryptographic preamble that is attached to the message packet when encryption is de-sired. The cryptographic preamble contains encryption key information and an offset (i.e. a pointer) indica- :
ting the ~starting point in the packet at whic~ encryp- ~ -tion is to begin. Thus the cryptographic processor can skip intervening header in~ormation, regardless of its .. . .
:: -:' . .
- - .

2 ~ 3 1 format and protocol, and begin encryption at the loca- -tion indicated by the cryptographic header. The header does not affect packet formats transmitted on a net-work, because it ~the cryptographi.c header) is stripped s off the packet prior to transmission, Basically, this featuxe of the invention pre- -.-vents the transmission o~ falsely encrypted packets onto the network. It also greatly simplifies the imple-mentation of the cryptographic proc~ssor, since each packet does not have to be completely parsed or ana-lyzed to find the location of the data to be encrypted.
The cryptographic preamble in a presently pre-ferred embodiment of the invention is in the ~ollowing format:
2 2 8 (bytes) ¦ FI.AG/OFFSET ¦ SE- CTRL ¦ X~T ~Y ¦ ~ ~ -The flag/offset ~ield consists of 4 bits of flag information and a 12-bit offset that indicates the number of bytes to sXip before starting the cryptograph-ic operation. The flag bits include a device specific bit that will be zero in most cases, and a three-bit mode field that indicate the type of encryption opera- ~ .
25 tion bei~g performed. The mode may be: .
0: Outbound encryption (not a loopback);
1: Loopback KEY encryptio~; :.
2: Loopback encryption; - --3: Loopback decryption;

4: Loopback ICV only. . .
The SE-CTRL field defines the type of crypto-graphi~ process, and has fields to indica~e confidentia~
; lity enrryption, integrity encryption, the type of cryp- : -tographic algorithm (DES or other), the specific cryp- :-tographic algorithm mode used (such as ECB, CF8 or ~-: ~ :

2~593~

-3g-CBC~, and the size o~ the cyclic redundancy code (CRC) to be used. The transmit Xey is an 8-byte field that defines the cryptographic key used for encryption.
The cryptographic prea~le contains all the information needed to locate the. data that is to be encrypted and to determine the type of encryption that is required, regardless of the packet format that is used by various protocols. Use of the cryptographic preamble prevents the transmission of falsely encrypted packets onto the network. In addition, the presence of the prea~ble simplifies the hardware needed for encryp-tion, since the entire packet does not need to be parsed.

Use of_lE~ le reqisters ~-o facilitate decryption~
In the cryptographic processing of received packets, the basic information needed includes the lsca-tion of the decrypted data within ~he packet, and con-trol for the decryption to be performed, such as the de~
cryption key and the mode of encryption. The cryptogra phic preamble discuss~d above is not available at the receiving end of a transmission, since it is stripped pxior to transmission onto the network.
This situation is complicated by the fact that standards relating to cryptography in networks are still developing. Yet there is an immediate need for . . .
cryptographic hardware. A packet encrypted at the data- - -link layer will necessarily contain a field of infor- : -mation that identifies the packets as one that requires ~ -cryptographic procassing. However, for at least one developing protocol (SILS) the location of this identi- - -fying field within the packat is not yet fixed with ~--: - -certainty. Another uncertainty is ~he location of the --;-start of the encrypted data in the packet. ~ --To overcome these problems, one feature of the ': ~;`." ' :'' . ,. - .
: - .

2~93~

present invention provides that the cryptographic pro-cessor includes three programmable registers, contain-ing: (a) an offset from the beginning of the datalink header (or from the beginning of the MAC header~ to a field that contains the cryptogrclphic identifier, (b) the value of the identifier that should be present to identify the packet as requiring cryptographic proces-sing for a particular protocol, and (c) an ofset value indicative of the beginning of the encrypted data (the offset being with respect to the identifier field to some other point o~ reference in the packet).
The three hardware registers are initialized with offset and identifier values needed to satisfy an anticipated standard for encryption, but may be conve-niently changed as necessary if the standard is re-vised. Thus the cryptographic hardware is readily adapt-able to a variety of encryption standards.
, .
~ mode:
In integrity-only encryption, a pacXet of data is transmitted in plaintext, i.e. without encryption, but an integrity check value (ICV) is included in the transmitted packet to ensure the integrity or authen-ticity of the data. When such a packet is the subject of a loopback procedure, the plaintext data will be unnecessarily looped back. In accordance with this feature of the invention, only the ICV field and the headers preceding the data will be looped back in ; i~tegrity-only loopback procedures. This reduces the amount of data that is looped back and improves system performance.
The mechanism used to implement this feature is the cryptographic preamble, which is generated for any outward bound packet of looped back packet. The cryptographic preamble contains a status ~field, one 20~93~

possible value of which indicate~s that the packet is for integrity-only encryption and for loopback. This involves a slight modification to the outbound and loopback processing flowchart of FIG. 13. In addition to the four types of operations described with refer-ence to this figure, a fifth mode value (0100) is also valid, and has the meaning that integrity-only loopback encryption i~ called for. When this mode valuP is present in the preamble, the cryptographic processor is conditioned to loop back only the headers and the ICV
value. The data field is used only to compute the ICV
value to loop back, but is not itself looped back to the node processor.

Encryption with selective disclosure of protocol_identifiers:
At the datalink layer level, a header is added to each m~ssage packet and contains fields normally referred to as DSAP (destination service access point) and SSAP (source service access point) addresses. These ordered pairs at the beginning of the logic link layer PDU (protocol data unit) identify an LLC (logical link control) "client" of the network. The DSAP/SSAP pair is followed immediately by a control field whose contents are interpreted by the LLC sublayer. If the frame is an unnumbered information frame, it contains user data that is passed up to the LLC client. If not, it is a control frame that is processed inside the LLC sublay-er. The ontrol ~ield value is 03 hexadecimal for un-n-lmbered information.
If the DSAP and SSAP fields contain a special value of A~ (hexadecimal~, this identifies a subnetwork protocol, generally known as a SNAP/SAP protocol. In this case, the five bytes following the control field ~35 are redefined as a protocol identifier (PID) field, as indicated below:
.: :

2~9'31 1 byte 1 byte 1 byta 5 bytes ~DSAP AA¦SSAP MICTRL 031 PID
-The PID contains three bytes o~ unique organi-zational identifier (OUI), which is unique to a partic~
lar company or othsr organization, followed by two bytes for protocol information assigned by that organi-zation. Since these headers are in the plaintext regionof each information packet, they are accessible by net-work monitors to monitor all network activities. There are three cases o~ interest in which problems are posed in datalink layer encryption. In one case, a network user may not wish to reveal the encryption protocol used in encrypting a packet. The other two cases in-volve a converse problem, where the user may want to reveal the encryption protocol but may not be able to do so. This situation may arise when one uses the data-link encryption standard as defined by the Standard ~orInteroperable LAN Security (SILS), an ongoing effort of an IEEE 802.10 subcommittee aimed at standardizing data-link layer encryption for networks.
Some network users who do not wish to make this protocol information available to others may deli-berately falsify the DSAP/SSAP and PID fields in their encrypted messages. When this happens, to any signifi-cant degree, statistical information gathered by net-work monitors is distorted and unreliable, at least as to the communication protocols being employed.
This problem is avoided in the present inven-tion by assigning a special SNAP/SAP protocol identi-ier to signify that the real protoco~ is to remainhidden or anonymous. More speci~ically, a special value of one of th~ PID bytes is used to slgnify anonymity of ~ ~

2~4~3~

the PID. Although network monitors still cannot deter mine the true protocols being employed in those packets carrying the special SNAP/SAP PID value, the packets can at least be categorized as u~;ing an anonymous or unknown communication communication protocol, rather than being mistakenly recognized as using a real protocol.
The converse situation arises when a network user would prefer to disclose the encryption protocol being executed, but is prevented ~rom doing so because the message has to be encapsulated to indicate encryp-tion. In the case of SILS, which is not yet completely defined, it appear~ that there will be a reserv~d value of DSAP or SSAP for the purpose o~ identifying a pacXet encrypted in the datalink layer.
There are two categories o~ information pac-kets for which the user might want to disclose the en-cryption protocol. One is that o~ an origi~al frame addressed to a SNAP/SAP, an~ the other is that of an oriqinal frame tha~ is addressed to a SAP other than a SNAP/SAP.
For the case of a SNAP/SAP frame in which the protocol is to be disclosed, the original protocol is stored in the last two bytes of the PID field. (It will be recalled that the first three bytes of the PID field are the OUI, which uniquely identifies the subnetwork organization.) For an encrypted frame, a selected bit in the last two bytes of the PID field is set to a "1", or a selected combination of bits in the same two bytes is set to a preselected value. The selected bit or com-bination of bits must not be already used in defining th protocol. For example, the least ~ignificant bit of the next to last byte of the PID field could be used to indicate encryption. ~henev~r the last two bytes of the PID field has the value xxxx xxxl xxxx xxxx, this would ... . -.

2OL~

indicate that the frame was encrypted. If the value is xxxx xxxO xxxx xxxx, this indicates no encryption. The bit used for this purpose would have to be one that was not used to define a protocol. In this example, there-fore, protocol identifiers having an odd number in thesecond hexadecimal position of the two-byte field could not be used. Since the PID field is completely under the control of the subnet organization, it is not diffi-cult to define a bit or combination of bits that does not conflict with the possible values of protocol iden-tifier.
The third case of interest also arises when a network user wishes to reveal the protocol and would be prevented from doing so by the SILS datalink encryption standard, but the ori~inal fra~e is addressed to a non-SNAP/SAP destination. This case is handled by ~irst encapsulating the non-SNAP/SAP frame with an additional plaintext header of the SNAP/SAP type. As previously discussed, this header has a PID field of which the first three bytes are a unique organization identifier and the last two bytes may be used for protocol identi-fication. This case requires the use of another special code as one of the last two bytes in the PID field. For example, the last two bytes may be 1000_0011 orig_sap~
The byte containing 1000_0011 is a special code (83) in-dicating that the next following byte "orig_sap" con-tains the original SAP for the encapsulated frame. In general, any predefined subfield could ba used to con-tain the s~ecial code and any other predefined subfield could be used to contain the original SAP.
From the foregoing, it will be appreciated that the invention provides th~ flexibility to disclose the und~rlying protocol i~ desired, or to keep the pro~
tocol hidden without distortion of network statistics.
.: . -~ 35 .:' ~.-: - .

2~5931 Such flexibility for selective disclosure of the proto-col can be of great importance in security and network management.
.. ~

It will be understood that the foregoin~ des-cription includPs, by way of illustration, details of implementation that are specific to a particular net~
work architecture, namely FDDI. Those skilled in the network communications art will also understand that the principles described may be readily adapte~ for use with other network architectures, with possibly differ-ent interfaces and frame formats. For example, the in-vention may be readily adapted for use in an Ethernet network architecture. Fuxther, although the cryptogra-phy processing described above is best implemented in an "on-board" processor that is integrated physically with other conventional network processing co~ponents, the principles of the invention still apply when the cryptographic processing is performed by an "off-board"
processor or device added to a conventional network pro-cessor or node tha~ did not previously have cryptograph-ic capability.
It will be appreciated from the foregoing that the provision of a special anonymous protocol identify-ing code in the header of an encrypted information packet satisfies two competing needs: the need for complete anonymity and the need to obtain accurate information by monitoring network traffic. Further, this invention also provides the network user with the capability of selectively revealing the underlying network protocol in both SNAP/SAP frames and non-SNAP/
SAP frames. It will also be appreciated that, although an embodiment of the invention has ~been described in detail for purposes ~of illustration, various modifica~
-2~931 tions may be made without departing from the spirit and scope of the invention.

':

. ' ' ~;.

. :
.
,! , . : .
3 0 ~

-~ ~ ~ 3 5 - .
: : .`" ~ '

Claims (6)

1. An automatic method for encryption of information packets for transmission over a communication network, the method comprising:
determining whether or not to encrypt an information packet prior to transmittal over a communication network;
if an information packet is to be encrypted, deciding whether or not to conceal the identity of an underlying network protocol by means of which the information packet was generated;
if the underlying network protocol is to be concealed, using a special protocol identifier in a plaintext portion of a header in the information packst, to indicate that the underlying network protocol is to remain anonymous; and subsequently identifying the underlying network protocol within an encrypted portion of a header in the information packet, whereby monitoring of encrypted network traffic will not be distorted by the use of incorrect protocol identifiers.

2. An automatic method for encryption of informtion packets for transmission over a communication network, the method comprising:
determining whether or not to encrypt an information packet prior to transmittal over a communication network;
if an informtion packet is to be encrypted, deciding whether to conceal or reveal the identity of an underlying network protocol by means of which the information packet was generated; and if the underlying network protocol is to be revealed, storing the identity of the protocol in a protocol identifier field in a plaintext portion of a header of the information packet.

3. A method as defined in claim 2, wherein:
if the information packet has a subnetwork packet format, setting a special code in a subfield of at least one bit of the protocol identifier field to a preselected value to signify datalink encryption of an information packet.

4. A method as defined in claim 3, and further comprising the step of:
subsequently identifying the special code sig-nifying datalink encryption; and obtaining the identity of the underlying proto-col from the protocol identifier field.

5. A method as defined in claim 2, wherein the method further comprises the steps of:
encapsulating the information packet with an additional plaintext header appended to the beginning of the packet and having a protocol identifier field:
placing a special code in a subfield of the protocol identifier field of the additional plaintext header to signify that the information packet is encap-sulated; and storing the underlying protocol identity in another subfield of the additional plaintext header.

6. A method as defined in claim 5, and further including the steps of:
subsequently identifying the special code sig-nifying an encapsulated information packet; and obtaining the identity of the underlying proto-col from the protocol identifier field of the addition-al plaintext header.