A Flow-Based Approach to Datagram Security

Home , Datagram

Suvo Mittra Thomas Y.C. Woo

Stanford University Bell Lab oratories

[email protected] [email protected]

Abstract Datagram services have b een widely adopted. Their

success has b een mainly attributed to their simplicity,

Datagram services provide a simple, exible, robust, and

exibility, robustness and scalability. For example, many

scalable communication abstraction; their usefulness has

of the most imp ortant networking proto cols, suchasIP

b een well demonstrated by the success of IP, UDP, and

[22 ], UDP [21 ], and RPC [6], make use of an underlying

RPC. Yet, the overwhelming ma jority of network security

datagram service mo del.

proto cols that have b een prop osed are geared towards

Recently, much attention has b een paid to securing

connection-oriented communications. The few that do

network communications, esp ecially those based on data-

cater to datagram communications tend to either rely on

grams. This can b e seen most apparently in the many

long term host-pair keying or imp ose a session-oriented

prop osals for IP security [4 , 11 , 18 ]. In addition, b oth

(i.e., requiring connection setup) semantics.

IPv4 and IPv6 [8 ], nowhave built-in provisions for secu-

Separately, the concept of ows has received a great deal

rity in the form of an Authentication Header (AH) and an

of attention recently, esp ecially in the context of routing

Encapsulating SecurityPayload Header (ESPH) [1, 2, 3].

and QoS. A owcharacterizes a sequence of datagrams

Unfortunately, existing prop osals are neither satisfac-

sharing some pre-de ned attributes. In this pap er, we

tory nor completely address the problem of datagram

advo cate the use of ows as a basis for structuring secure

security. For example:

datagram communications. We supp ort this by prop os-

They tend to adopt a connection-based session mo del

inganovel proto col for datagram security based on ows.

for adding security. That is, they require extrane-

Our proto col achieves zero-message keying, thus preserv-

ous message exchange for setting up security as-

ing the connectionless nature of datagram, and makes use

so ciations and the creation of \hard" state for se-

of soft state, thus providing the p er-packet pro cessing e-

curity pro cessing in the two communicating prin-

ciency of session-oriented schemes. Wehave implemented

cipals. The key advantages of a connection-based

an instantiation for IP in the 4.4BSD kernel, and we

mo del are its well-de ned unit of protection based

provide a description of our implementation along with

on a connection, and the p ossible eciency gain

p erformance results.

from the use of \hard" state. We b elieve, however,

that the sacri ce of datagram semantics (and its de-

1 Intro duction

sirable features as a result) may b e to o exp ensivea

price to pay. In addition, as we shall describ e, it is

A datagram service is one in which self-contained mes-

not necessary for providing security.

sages, or datagrams, are transmitted from one principal

to another, and whereby each datagram is transmitted

They fo cus only on sp eci c proto col layers, e.g., IP,

and received atomically and indep endently, in isolation

instead of presenting general solutions that apply

of others. No prior setup is needed b etween the source

across proto col layers or stacks. We b elieve that se-

and destination principals, nor is there any required state

curity solutions are subtle enough to get righteven

maintained b etween the two.

once, thus any solution that we design should be

We use the term principal here to avoid referring to a sp eci c

consistently applicable across proto col layers. In

proto col layer. In general, a principal can b e a host, a pro cess or a

addition, there is a great deal of debate regarding

user. The term principal is commonly used in security literature.

the correct placement of security functions in a pro-

App ears in Proceedings of the ACM SIGCOMM '97, Septemb er 14-18, 1997, Cannes, France.

to col stack. A solution committed to any particular

layer or stackmay b ecome obsolete b efore it ever

copies of part or all of this work for p ersonal or classro om use is granted without fee provided that copies

gains p opularity.

are not made or distributed forpro t or direct commercial advantage and that copies b ear this notice and

the full citation on the rst page. Copyrights for comp onents of this work owned by others than ACM must

b e honored. Abstracting with credit is p ermitted. To copy otherwise, to republish, to p ost on servers, orto

They concentrate mostly on sp eci c mechanisms

redistribute to lists, requires prior sp eci c p ermission and/or a fee. Request p ermissions from Publications

Dept., ACM Inc., fax +1 (212) 869-0481, or [email protected].

without reference to p olicy issues. Separation of

mechanism and p olicy is go o d system practice; but 1

the design of certain mechanisms are heavily in- 2.1 Session-based Keying

uenced by the typ es of p olicies that are to be

Session-based keying takes many forms, some rely on a

enforced. We b elieve it is critical to make explicit

third party suchasakey distribution center (KDC) and

and investigate the coupling b etween the two.

others agree on a key b etween the two corresp onding prin-

cipals.

What is needed is a unifying abstraction that o ers

In a KDC-based approach, b efore a source sends a

a unit of protection and eciency similar to that of a

datagram, it contacts the KDC to request a session key

connection-based mo del, is meaningful across di erent

and an authentication ticket. The ticket, encrypted with

proto col layers, and is amenable to p olicy control. A par-

the destination's secret key, allows the destination (and

ticularly tting candidate for this is the notion of ows.

only the destination) to authenticate and decrypt trans-

Lo osely sp eaking, a ow is a sequence of datagrams

missions from the source. To send a datagram, the source

satisfying some pre-de ned attributes. It characterizes

encrypts the payload with the session key and sends the

communications that are b etween that of datagram and

encrypted payload together with the ticket. The destina-

connection. That is, a ow is neither datagram nor con-

tion recovers the session key from the ticket, and uses it

nection | it has the avor of b oth.

to decrypt the payload. Proto cols that use this approach

The ow notion can b e applied across di erent proto-

include Kerb eros [25 ], Sun RPC [26 ] and DCE [24 ].

col layers. At the application layer, datagrams b elonging

In session-based keying without a third party, a dy-

to the same application \conversation" constitute a ow.

namic key exchange is p erformed b etween the source and

At the transp ort layer, datagrams in a connection can b e

destination principals. This establishes a shared secret,

considered a ow.

which can be used to derive a session key. The ses-

The b oundary of a ow is dynamically adjustable, by

sion key is stored as part of the security asso ciation, and

varying the set of attributes of interest. A p olicy can b e

is used in securing ensuing communications. Proto cols

used to sp ecify the set of attributes of interest and the

supp orting this metho d include Oakley [18 ] and Photuris

corresp onding security requirements.

[11 ].

In this pap er, we prop ose a new proto col for datagram

The key advantage of session-based keying is the p os-

security, called the Flow-Based Security Proto col (FBS),

sible eciency gain with explicit state setup, esp ecially

based on the concept of ows. FBS makes use of zero-

in case of long-lived communications. However, this is

message keying and soft states. The former allows it to

achieved at the exp ense of datagram semantics.

maintain datagram semantics, while the latter makes its

eciency comparable to a connection-based approach.

FBS is not de ned for any sp eci c proto col layer. It

2.2 Host-Pair Keying

assumes only the availability of an underlying (insecure)

The basic idea b ehind host-pair keying is that each pair

datagram transp ort. As an example of its application,

of hosts have an implicit key, called the pair-based mas-

wehave de ned a mapping to IP and implemented the

ter key, that can be computed only by that host pair.

mapping in the 4.4BSD kernel.

The implicit key exists a priori, thus allowing a message

The balance of this pap er is organized as follows. In

encrypted using this key to be sent without arranging

the next section, we give a brief overview of existing work.

anything in advance. An immediate consequence of this

In Section 3, we present the requirements and constraints

is that proto cols based on host-pair keying supp ort data-

for the design of our proto col. In Section 4, we elab orate

gram semantics. That is, no extra message exchange is

on the concept of the ow and its application to security.

required to set up secure communication, nor is there a

In Section 5, we describ e our prop osed FBS proto col. In

need for hard state to b e maintained.

Section 6, we discuss features and vulnerabilities of FBS

When using host-pair keying, the precise meaning of

against sp eci c attacks. In Section 7, we present a map-

host must be prop erly understo o d. Otherwise, \unex-

ping of the FBS proto col to the IP layer. We also describ e

p ected" vulnerabilities can result. As an example, con-

our implementation of this mapping and the p erformance

sider the application of host-pair keying to a network

results. In Section 8, we conclude.

layer proto col (e.g., IP). A host here would mean a net-

work layer entity, such as a host with an IP address.

2 Existing Approaches

Under host-pair keying, all trac from di erent connec-

tions and users would b e encrypted by the same implicit

The challenge of providing secure datagram services is not

key. In other words, security is only provided at the host

new. Many approaches have b een prop osed. These ap-

level; this mayor may not b e what is intended. Some

proaches can b e broadly classi ed into two basic paradigms,

of the problems with IP level host-pair keying are dis-

namely, session-based and host-pair keying. The former

cussed in [5 ]. In particular, the compromise of a master

has an explicit notion of session, and sets up explicit se-

key exp oses all trac (past and future) b etween the two

curity asso ciation prior to data exchange. The latter,

hosts.

on the contrary, do es not require explicit state setup nor

Basic host-pair keying can su er from a \cut-and-

security negotiation prior to data exchange.

paste" attack. That is, the encrypted payload from one

This classi cation is not intended to b e comprehensive or ex-

datagram can b e cut and inserted into another datagram

act. Manyschemes have the avor of b oth.

without b eing detected. A simple countermeasure is to

extend host-pair keying with p er-datagram keys. Instead 2

of using the master key to directly encrypt data, the mas- ows. At the transp ort layer, data going from one trans-

ter key is used to encrypt a p er-datagram key, which p ort end p oint (e.g., TCP/UDP p orts) to another can b e

is used to actually encrypt the data. A subtle prob- considered a ow.

lem with this is that the p er-datagram keys should be The concept of ow subsumes b oth datagram and

cryptographically random, so that the compromise of one connection-oriented communications, thus sidestepping

datagram key should not reveal past or future keys. Cry- the debate b etween the two paradigms. From a security

tographically secure random numb er generators suchas p ersp ective, the mo del of datagram as a unit of protec-

the quadratic residue generator [7 ] can b e a p erformance tion is ner than necessary. This is b ecause successive

b ottleneck. datagrams often b elong to the same high-level communi-

cations and can b e pro cessed in a similar manner, making

it inecient to treat them as autonomous, indep endent

3 Requirements and Constraints

units. The mo del of connection-oriented communication

provides a well-de ned unit of protection, i.e., all the

The basic requirementofany security proto col is to pro-

datagrams in a connection should b e protected the same

vide a prescrib ed set of security prop erties. In this case,

way. Its main drawbackis the fact that it is often en-

it is to enforce separation b etween datagrams b elonging

cumb ered with notions of connection setup and teardown,

to di erent ows. That is, datagrams sentina owmust

which are not necessarily required nor desired for security

only b e \readable" by the intended recipient, and data-

purp oses. Flows o er the connectionless nature of data-

grams accepted in a owmust have b een originated by

gram communication, while retaining the natural unit of

the claimed source and have not b een mo di ed in tran-

protection of connection-oriented communication.

sit. The precise \b oundary" of a ow is de ned byan

The key challenge in basing securityon ows is ow

application or user.

identi cation. The ability to di erentiate and isolate

Apart from the ab ove, we have the self-imp osed re-

ows is as imp ortantas the actual security mechanism

quirement that the proto col should preserve datagram

used to protect them. Dep ending on which layer the

semantics. That is, it should not require state set up

datagram service is implemented, this mayor may not

messages nor the maintenance of hard state in the two

b e easy. At the application layer, this can b e easy if the

corresp onding parties.

ow semantics is built into an application. At the trans-

Note that the standard \features" of datagram com-

p ort layer, it could b e based on the available connection

munication, such as lack of sequencing and ow control,

information. At the network layer, the requisite connec-

p ossibility of omission and duplication, are not changed

tion information may not b e readily available and may

with the addition of the security proto col.

need to b e \deduced."

The main constraint in our proto col design is that it

should be layer- and proto col stack-indep endent. That

is, it should not assume that it will op erate in a particu-

5 The FBS Proto col

lar stack (e.g., TCP/IP) or a sp eci c proto col layer (e.g.,

In this section, we provide a detailed description of our network layer). We accommo date this by rst developing

prop osed proto col. The discussion b elow is delib er- an abstract proto col, and then de ne mappings for di er-

ately kept generic. Sp eci cally,weavoid stipulating the ent instantiations of the proto col. In this way, the system

use of sp eci c cryptographic algorithms (e.g., encryption and implementation sp eci c details are all encapsulated

and hash functions) and the exact size of the security in the mappings only.

parameters (e.g., encryption key and confounder). The

determination of these is often based on implementation

4 The Flow Concept

choices, desired level of security, patent and exp ort is-

sues. As an example of a realization of our proto col, a

The concept of ow is not new. It has received much

mapping to IP is presented in Section 7.

attention lately, esp ecially in relationship to routing (e.g.,

in IPv6 [19 ]) and quality of service (e.g., RSVP [29 ]).

Broadly sp eaking, a ow is a sequence of datagrams

5.1 Overview

satisfying some pre-de ned attributes of interest [20 ]. This

The core of the FBS proto col consists of two mecha-

de nition could b e very general. But, typically, ows are

nisms, namely,a ow association mechanism (FAM) and

used to refer to groups of datagrams that are to receive

a zero-message keying mechanism. The former separates

similar treatment in their network transp ort. For ex-

outgoing datagrams into ows, while the latter estab-

ample, datagrams in an QoS ow are exp ected to enjoy

lishes the security parameters for a ow without incurring

similar quality of service.

end-to-end message exchange.

Indeed, ows are a natural and exible way to struc-

These two mechanisms work tightly together. Sp ecif-

ture proto col data units at di erentlayers of the proto col

ically, the output of the ow asso ciation mechanism is

architecture. For example, at the application layer, ap-

an opaque ow identi er, called security ow label (s in

plication data with di erent semantics (e.g., video, audio,

short), which feeds into the zero-message keying mecha-

and whiteb oard data) could b e separated into their own

nism to pro duce the p er- owkey.

Except some malicious form of duplication | so called replay

For generality, the FAM should b e p olicy driven; this

attacks (see Section 6).

presents a signi cant design challenge. On one hand, the

mechanism should b e cleanly separated from p olicies. On 3

outgoing datagram

master key and the s for the ow. Knowledge of the ow

header

ey,however, do es not allow one to recover the pair-based

Flow State Table k

master key,orany other owkeys.

. Sweeper

us, by including s in the datagram header, the . Module Th

. w

Mapper correct destination principal can easily compute the o

ey without incurring end-to-end message exchange. In

Module k

addition, by caching the ow key as soft state at b oth

wkey can b e amortized

sﬂ state info ends, the computation of the o

over all datagrams in the ow (see Section 5.3).

. Proto col Description . 5.2

Notation and Basic Parameters

Figure 1: The Flow Asso ciation Mechanism

The proto col description makes use of a numb er of basic

parameters. Their meaning and notation are explained

the other hand, it should b e general enough to b e able to

here.

supp ort most p olicies, which could sometimes b e proto col

Let S and D denote, resp ectively, the source and des-

layer or op erating system sp eci c.

tination principals. A minimal requirementof S and D

In our current design, p olicies are expressed by policy

is that they are uniquely addressable within the data-

modules (e.g., the mapp er and sweep er mo dules in Fig-

gram services. In a sp eci c realization of the proto col,

ure 1) which plug into the FAM, whose structure is shown

the principals could b e network interfaces on hosts, the

in Figure 1. The design has three key elements:

hosts themselves, network proto col layers, applications,

or end users.

Flow state table | Eachentry in this table stores in-

Let s and d b e the private values, as de ned in the

formation ab out an active ow. In particular, each

Die-Hellman key exchange scheme, of S and D resp ec-

entry contains the s fora ow and the necessary

tively. The corresp onding public values of S and D would

state information required for the op eration of the

s d

then be g mo d p and g mo d p where g and p are re-

mapp er and sweep er mo dules b elow.

sp ectively the (common and well-known) generators and

prime mo dulus in the Die-Hellman key exchange scheme.

Mapper mo dule | This takes as input a set of

The con dentiality of the private values and the au-

attributes (e.g., destination principal address) of

thenticity of the public values are assumed. However, the

a datagram and p ossibly other system parameters

mechanisms for ensuring these are outside of the scop e of

(e.g., pro cess id, time), and pro duces an index into

the proto col sp eci cation. Typically, the private value

the ow state table. If the indexed entry is \valid,"

is kept by a principal; while the public values are made

the datagram is deemed to b elong to the corre-

available and authenticated via a distributed certi cation

sp onding ow, and s contained therein is used as

hierarchy (e.g., X.509 certi cates [28 ]) or a secure DNS

the security ow lab el for the datagram. Otherwise,

service [10 ].

a new ow with a new s is created, and installed

We denote by

into the entry. The validity of an entry is deter-

mined by insp ecting its state information.

K = g mo d p

S;D

Sweeper mo dule | This is resp onsible for expiring

the implicit pair-based master key between S and D .

ows. It removes ows that are no longer \active."

Note that K can b e computed by either S or D (but

S;D It op erates by scanning the entries in the ow state

no others) using their own private value and the other

table and examining their state information.

principal's public value.

In this approach, the desired security is enco ded in

The owkey for a ow f , identi ed by security ow

the mapp er and sweep er mo dules. Dep ending on the

lab el s , going b etween S and D is denoted by K . It is

p olicy, a mapp er, or a sweep er or b oth may b e needed.

de ned to b e

Note also that although the ow asso ciation mechanism

K = H(s j K j S j D )

S;D

is stateful, the state is not distributed b etween the source

and destination principals. Sp eci cally, the source prin-

where j is the concatenation op erator and H a one-way

cipal actively assigns the ow for a datagram, while the

cryptographic hash function. S and D are included to

destination principal passively demultiplexes a datagram,

explicitly tie the owkey K to that of a owbetween S

based on its ow assignment, into the individual ows.

and D ; K also implicitly provides a similar function.

S;D

No state synchronization is needed between the source

Candidates for H are MD5 [23 ], SHS [17 ] or even DES

and destination principals.

[15 ]. The derivation of K could p otentially be highly

The zero-message keying mechanism is based on the

exp ensive, esp ecially if K is not already known. In

S;D

basic Die-Hellman key exchange scheme [9 ]. It makes

sucha case, communication (hence roundtrip delay) to

use of the Die-Hellman scheme to obtain a pair-based

obtain the values for computing K is required. Ideally,

S;D

master key, and further derives from it a owkey. The

the computation of K should b e done only once p er ow,

derivation of the owkey is easy knowing the pair-based 4 Secure Flow Message Proto col Op eration Confounder Authentication Timestamp Label

Code The basic structure and op eration of the FBS proto col is

shown in Figure 3. As shown, the proto col consists of two

Figure 2: Security Flow Header Format

communicating halves, namely, the send and the receive

sides. The actions p erformed on the receive side is the

thus amortizing the cost over all datagrams in the ow.

\inverse" of that on the send side.

To accomplish this, wehaveintro duced several levels of

We describ e the op eration of the proto col b elow, and

caching (see Section 5.3).

defer the discussion of implementation considerations to

Section 5.3. In particular, the various caches as shown

Security Flow Header

in Figure 3 are critical for proto col implementation, but

strictly sp eaking, they are not part of the proto col.

To maintain datagram semantics, our proto col requires a

The FBS proto col op eration is shown in Figure 4. We

security ow header or FBS header to b e added to each

rst describ e the convention. The op eration of the un-

datagram. The elds in this header are shown in Figure 2.

derlying (insecure) datagram transp ort is abstracted in

Most of these elds should b e self-explanatory,we brie y

the two functions: Send() on the send side and Receive()

explain them here:

on the receive side.

Each datagram P entering the FBS proto col layer

security ow lab el | s for the datagram.

is assumed to have a uniform structure. Sp eci cally,

confounder | a statistical ly random value gener-

it contains: (1) a header, denoted by P .header, which

ated on a p er-datagram basis for use in the compu-

in turn includes elds indicating the source (P .source)

tation of MAC (see b elow) and as the initialization

and destination (P .destination) principals; (2) a body,

vector (IV) for encryption. Typically, encryption

denoted by P .body, that carries the higher-layer proto-

is p erformed using a blo ck cipher such as DES [15 ].

col payload; and (3) an FBS proto col header, denoted

The confounder is used as the IV in the CBC, CFB,

by P .FBSheader. From the p oint of view of Send() and

or OFB mo des [16 ]. In case of ECB mo de, the

Receive(), P .FBSheader may be treated as part of the

confounder is XOR'ed with every blo ck of plaintext

datagram header or body, dep ending on the datagram

prior to encryption.

transp ort format.

A confounder helps to hide the presence of identical

datagrams in the same ow, as the knowledge of

Send Pro cessing. FBSSend() in Figure 4 shows the op-

suchmay b e useful to an attacker. In general, the

eration of sending a datagram P from S to D . The secret

size of the confounder should match the blo ck size

ag, if set, indicates that data con dentiality, i.e., en-

of the encryption algorithm used.

cryption, is desired for the datagram b o dy.

message authentication co de (MAC) | a keyed mes-

The pseudo co de should be fairly self-explanatory.

sage authentication co de for the datagram. It should

The key steps are: (S1) classify the datagram into a ow

be keyed on the ow key and calculated over the

using the ow asso ciation mechanism. To p erform the

confounder, timestamp and payload. The MAC

classi cation, the ow asso ciation mechanism can insp ect

serves two purp oses: (1) it ensures the integrityof

the whole packet (the argument P ) and other system

the datagram b o dy and the other elds in the se-

parameters (denoted by \. . . "), such as time and pro-

curity ow header; (2) it provides a form of \ ow"

cess id. The precise input is determined by the p olicy

authentication, i.e., the datagram do es b elong to

mo dule plug-ins; (S2{3) generate the ow key. Note

the ow indicated in the s .

that this is only a logical step. In a practical imple-

In our current design, the MAC is de ned as:

mentation, the owkey is computed once p er ow, and

cached in a so called transmission ow key cache (TFKC)

HMAC (K j confounder j timestamp j payload)

(see Section 5.3); (S4{7) generate and insert the security

ow header into the datagram; (S8{9) optionally encrypt

where HMAC is some one-way cryptographic hash

the datagram b o dy if data con dentiality is desired; and

function. Note that the function HMAC need not

(S10) forward the resulting datagram to the lower layer

be the same as the hash function H used in the

for transp ort.

computation of owkeys.

timestamp | a time value for countering replay

Receive Pro cessing. FBSReceive() in Figure 4 shows

attacks.

the op eration D undertakes to receive a datagram P from

The chosen size of these elds is generally a tradeo

S . The key steps are: (R1) receive a datagram from the

between proto col overhead and security. An example set

lower layer; (R2) retrieve the security ow header from

of choices is given in Section 7. The placement of these

the datagram; (R3{4) check the timestamp for freshness.

elds is an implementation choice.

The checking should b e based on a sliding window cen-

For generality, the security ow header should also in-

tered on the current time; (R5{6) recover the ow key

clude an algorithm identi cation eld, which sp eci es the

based on the s . Again, this is only a logical step. The

cryptographic algorithms used (e.g., for MAC computa-

In general, the value of secret is determined by the security

tion, encryption). It is straightforward, and we omit its

ow p olicy for the datagram. Wehave omitted the details here.

description here.

Though typically P .header should b e sucient. 5 Flow Payload Policy Association Processing Mechanism Module (optional)

MKC

Secure Flow Secure Flow Header TFKC RFKC Header Generation Veriﬁcation

Payload Processing Flow (optional) Demultiplexing data ﬂow control ﬂow

Send Side Receive Side

Figure 3: FBS Proto col Architecture and Op eration

function FBSSend (Datagram P , b o olean secret ) f function FBSReceive(b o olean secret ) f

(S1) Flow s =FAM (P ,...); (R1) Datagram P = Receive ();

(S2) Principal D = P .destination; (R2) (s , c, m, t)=P.FBSHeader;

(S3) K = H(s j K j S j D ); (R3) if (: Fresh (t))

S;D

(S4) Confounder c = Random (); (R4) return error ;

(S5) Timestamp t = Time (); (R5) Principal S = P .source;

(S6) MAC m = HMAC (K j c j t j P .b o dy); (R6) K = H(s j K j S j D );

S;D

f f

(S7) P .FBSHeader = (s , c, m, t); (R7) MAC m = HMAC (K j c j t j P .b o dy);

(S8) if (secret ) (R8) if (m 6= m )

(S9) P .b o dy = Encrypt (K , c, P .b o dy); (R9) return error ;

(S10) return Send (P ); (R10) if (secret )

g (R11) P .b o dy = Decrypt (K , c, P .b o dy);

(R12) return P ;

Figure 4: FBS Proto col Pro cessing

actual owkey may b e retrieved from a receive ow key be changed. The lifetime of an encryption key de-

cache (RFKC) (see Section 5.3); (R7{9) verify the MAC p ends on the encryption algorithm, the length of

eld; (R10-11) optionally decrypt the datagram b o dy if time it has b een used, and the amount of data that

data con dentialitywas indicated; and (R12) forward the has b een encrypted with it. With FBS, rekeying

datagram to the upp er layer for pro cessing. can b e easily accomplished via the FAM bychang-

ing the s . Rekeying decisions, though, are made

by p olicy mo dules.

Observations. The following observations can b e made

ab out the FBS proto col:

5.3 Implementation Considerations

Flows are unidirectional. This is a direct result

Generating the Security Flow Lab el

of the asymmetric roles played by the source and

destination of a datagram. The source principal dic-

The FAM, and in turn the p olicy mo dules, is resp onsible

tates the ow assignment of a datagram, while the

for \starting" new ows. Generating the value of s it-

destination principal \accepts" it. Thus, a duplex

self is not dicult. The essential requirement is that the

proto col will havetwo ows, one in each direction.

same value of s not b e assigned to two di erent ows.

It requires no hard state in either side for its op er-

This can b e done by simply keeping a large (at least 64-

ation, thus maintaining datagram semantics. Each

bit) counter that serves as the value of the next s and

datagram is self-contained, and can be pro cessed

incrementing the counter each time an s is allo cated.

indep endently.Aswe will show in the next subsec-

The initial value of the counter should b e randomized to

tion, key caching can b e used to sp eed up proto col

prevent attackers who try to exploit reuse of s values

pro cessing, but the contents of the cache represent

by continuously reseting the proto col subsystem (e.g., by

only soft state.

bringing the machine down). It is assumed that the pair-

The owkey is used to directly encrypt data. With

based master key will b e changed (e.g., bychanging the

use, an encryption key will \wear out" and should

private value of a principal) b efore this counter wraps 6

around. Note that s need not b e random, b ecause it is Public values cache (PVC). This is a cache of the

fed into a one-way, pseudorandom hash function. public value certi cates of the corresp ondent principals.

Caching of public value certi cates, instead of the public

values themselves, is preferred b ecause the former need

Generating the Timestamp

not b e secure; a certi cate can b e veri ed each time it is

The main purp ose of the timestamp is to ensure that

used.

datagrams from an earlier ow can not b e replayed and

In case of a cache miss, the public value certi cate

accepted. The value of the timestamp should b e based

must b e fetched from some certi cate authority on the

on real time. For example, it could be enco ded as the

network. The fetch request should not and need not b e

numb er of minutes elapsed since some xed time in the

secure. It should not b e secure b ecause this will otherwise

past. The use of minute resolution is sucient as the

create a circularity problem, i.e., generating new fetch

timestamp is only intended as a coarse protection against

requests that themselves need to b e secured. It need not

replays.

be secure b ecause the certi cates are to be veri ed on

The use of timestamps also implies lo ose time syn-

receipt. The secure ow bypass in Figure 5 allows such

chronization is needed across machines. The precise syn-

requests to bypass FBS. An alternative is to \pin" certain

chronization requirement dep ends on the nature of the

certi cates in the cache up on initialization.

freshness check and the level of acceptable risk.

PVC cache misses are served by the master key dae-

mon (MKD) and are extremely exp ensive. It incurs at

Generating the Confounder

the minimum a round trip communication delay. There-

fore, the minimum size of PVC should be at least the

Although a confounder is required on a p er-datagram ba-

average numb er of corresp ondent principals that a prin-

sis, its generation is not computationally exp ensive. This

cipal can concurrently communicate with.

is b ecause a confounder needs only b e statistically ran-

dom, as opp osed to cryptographically random. For ex-

Master key cache (MKC). This is a cache of pair-

ample, the confounder can b e generated using the highly

based master keys, indexed by names of principals. These

ecient linear congruential generators [12 ]. Of course,

master keys are computed using entries in the PVC and

the seed for the generator must b e randomized in each

installed by the MKD.

initialization of FBS.

Pair-based master key computation is fairly exp en-

sive, b ecause it involves mo dular exp onentiation.

Computing the MAC

The size of MAC is dep endent on the algorithm used.

Transmission owkey cache (TFKC). This a cache of

For example, MD5 pro duces 128-bit hashes while SHS

transmission owkeys indexed by a combination of s ,

pro duces 160-bit hashes. To reduce header overhead, it

D and S . With TFKC, a ow key is computed once

is p ossible though, with reduced security, to use only part

and installed in the TFKC at the start of a new ow.

of these hashes as the MAC.

Subsequent datagrams in the same ow can b e pro cessed

The MAC computation is an exp ensive op eration. It

by the stored owkey, as long as it remains in the cache.

requires touching all the data in the datagram. An e-

Figure 6 shows the mo di cation of the FBS send side

cient implementation should try to combine all such data

op eration with the use of TFKC. Sp eci cally, the co de

touching op eration into a single pass. For example, if

in Figure 6 replaces line (S3) in FBSSend() in Figure 4.

data con dentiality is desired, then the MAC computa-

The expression e 2 C and C [e] denote resp ectively the

tion and encryption should b e rolled into one lo op. To

op eration to verify the existence of entry mapp ed to e in

take this one step further, an in-kernel implementation

cache C and the op eration to retrieve the entry mapp ed

of FBS can combine this with other data touching op era-

to e in cache C . Up call() is an OS primitive that allows

tions suchaschecksumming or user space-kernel crossing

kernel functions to directly call a user-level function.

data transfer.

A TFKC cache miss is not as exp ensiveasanMKC

cache miss. Sp eci cally, a ow key can b e recomputed

Key Caching

from the s and pair-based master key (from MKC). To

minimize cache miss, the TFKC cache size should b e at

Besides the MAC computation and the optional encryp-

least the average numb er of active ows.

tion, the ma jor proto col overhead of FBS are: (1) com-

putation of the owkeys; (2) computation of pair-based

Receive ow key cache (RFKC). This is a cache of

master keys; and (3) fetching of the public values of the

receive owkeys indexed by a hash of s , S and D . It

corresp ondent principal. Ideally, (1) should b e p erformed

can b e understo o d as the analogue of the TFKConthe

once p er ow, while (2) and (3) should b e p erformed once

receive side. Thus, its structure and use is very similar

p er corresp ondent principal. Key caching can b e used to

to TFKC. We omit the details here.

approximate this, hence amortizing the cost over all data-

grams. Indeed, many levels of key cache can b e used, we

With prop er caching, the overhead of the FBS proto-

describ e them b elow (see Figure 5 ).

col can b e reduced to the bare minimum, i.e., only MAC

The gure is drawn for an in-kernel implementation of FBS.

The inclusion of S is for \multi-homed" principals, i.e., prin-

The structure for a user-level implementation is similar, except for

cipals with more than one addresses.

the user space-kernel b oundary. 7

User Space

((s ,D ,S ) 2 TFKC) f

Public Values Master Key if

= TFKC[(s ,D ,S )].key; Cache K

Daemon f

else f

secure g

(D 2 MKC) f

ﬂow if

K =MKC[D ].key; ;D

bypass S

g else f

K = Up call (MKDaemon, D );

S;D

MKC[D ].key = K ;D

Kernel Space S

K = H(s j K j S j D );

S;D

TFKC MKC RFKC f

TFKC[(s ,D ,S )].key = K ; f

Secure Flow Mechanism g

Figure 6: FBS Send Pro cessing using Cache

Network

Figure 5: Key Cache

computation and encryption. Thus, it is critical to un- 6.1 Perfect Forward Secrecy and Back Trac Protec-

derstand the factors a ecting the cache p erformance. tion

Cache misses can b e divided into three typ es: com-

A proto col has perfect forwardsecrecy if the compromise

pulsory (cold), capacity, and collision misses. Cold misses

of any long-term keying material do es not compromise

can not b e avoided, they are necessary for the initializa-

future session keys or trac. Back trac protection is

tion of the cache entries. Capacity misses can b e curtailed

a similar idea but it relates to the compromise of past

by making the cache size at least the average number

session keys or trac. These protections are typically

of simultaneously active cache entries. A cache entry is

accomplished by not using any long-term keys to encrypt

considered active if it may be referenced again. This

session keys or trac, but using them only for authenti-

is generally not a problem b ecause the number of ows

cation.

into a given principal is not very large compared to the

However, it can b e seen that no zero-message keying

amount of memory available to store the ow information

proto cols can provide these protections. This is b ecause

in a mo dern kernel.

in such a proto col, the sender must generate the session

Care, however, must be taken to not delete active

key and make it known to the receiver while keeping it

ow information b ecause of collision misses. Collision

private from other parties. There is no other secure chan-

misses can b e avoided by increasing the asso ciativityof

nel, though, b etween the sender and the receiver except

the cache, by using a b etter replacement p olicy, or by

the one protected by the long-term key.

indexing the cache with a b etter hash function that dis-

FBS do es, however, provide b etter protection than a

tributes entries uniformly. Because it is imp erative that

scheme based on host-pair keying. Under host-pair key-

these caches are implemented in software and b ecause

ing, easy access to the master key is available as it is used

they must exhibit quick access time, the asso ciativityof

to directly encrypt the trac. Under FBS, the master key

the caches can not be to o great. In turn, low degrees

is never used for encryption, and breaking a owkey do es

of asso ciativity reduce the in uence of the replacement

not help in recovering the master key nor compromising

p olicy. Therefore, wemust lo ok to b etter hash functions.

other owkeys.

Simple hash functions, such as mo dulo and XOR'ing,

are fast but have the disadvantage that they provide little

6.2 ReplayAttacks

randomness unless the input to the hash function is al-

ready random. The input for all our cache could b e highly

Replay attacks can be used to trick a receiver into ac-

correlated, e.g., lo cal network addresses and sequential

cepting the same data twice. It can also be used to

s s. Therefore, the hash function for these caches must

compromise the con dentiality of data (see Section 7.1).

randomize the input to a numb er whose mo dulo can then

FBS uses a window-based timestamp scheme to counter

b e used to index the cache. An example of such a hash

replay attacks. The key advantage of such a scheme

function is CRC-32. Using such a hash function and a

is that it do es not require maintenance of hard state

reasonable size direct-mapp ed cache, we can reduce cache

information. The drawback is the need for lo ose time

lo okup time to O (1) time in most cases.

synchronization.

Many other security proto cols use a nonce-based scheme

to protect against replay. This, however, requires extra

6 Analysis

communication for the initial nonce agreementaswell as

This section examines the features and vulnerabilities of

hard state information, thereby violating datagram se-

the FBS proto col with resp ect to a numb er of common

mantics.

attacks. The discussion is by no means exhaustive; it is

In any case, the replay protection a orded by a data-

intended to highlight some of the design rationale b ehind

gram security proto col can not b e p erfect. If an attacker

FBS. 8

struct FSTEntry {

mapper (saddr, sport, daddr, dport, proto-num)

boolean valid; /* valid flag */

{

byte proto-num; /* protocol number */

i = CRC-32 (saddr, sport, daddr, dport,

uint64 sfl; /* security flow label */

proto-num) mod FSTSIZE;

uint32 saddr; /* source ip address */

e = FST[i];

uint16 sport; /* source port # */

if (e.valid &&

uint32 daddr; /* destination ip address */

(e.proto-num == proto-num) &&

uint16 dport; /* destination port # */

(e.saddr == saddr) &&

uint32 last; /* last packet arrival time */

(e.sport == sport) &&

} FST[FSTSIZE];

(e.daddr == daddr) &&

sweeper ()

(e.dport == dport))

{

return e.sfl;

i=0;

e.sfl = sfl++;

do {

e.proto-num = proto-num;

if (FST[i].valid &&

e.saddr = saddr; e.sport = sport;

(curtime - FST[i].last) > THRESHOLD)

e.daddr = daddr; e.dport = dport;

FST[i].valid = FALSE;

e.valid = TRUE;

i = (i + 1) mod FSTSIZE;

FST[i] =e;

} while (i != 0);

return e.sfl;

}

Figure 7: Security FlowPolicy Mo dules

is able to replay a datagram within the allowable \fresh- Strictly sp eaking, this also violates layering, b ecause it

ness" window, the attack will succeed. For wide-area requires IP to lo ok at information from higher layers.

A ow is de ned by its s .To approximate conversation- networks, the \freshness" windowmay b e large (on the

level security,we need to allo cate s s such that the same order of minutes) to account for transmission delays and

lab el is not shared among di erent conversations. The unsynchronized machines.

challenge is how to detect when a conversation b egins Ultimately, complete replay protection can only be

and ends. achieved in high-layer proto cols. Fortunately, most clients

In FBS, the extent of a conversation is de ned by of datagram services already have some form of replay

the FAM. A rst approximation to a conversation can protection in terms of built-in sequencing, for dealing

be obtained by considering the sequence of datagrams with o ccasional omission and duplication of datagrams.

sharing the same 5-tuple of

7 A Mapping to IP

< proto col number; source ip address ; source p ort number;

destination ip address ; destination p ort number >

There has b een a lot of controversy regarding the ap-

propriateness of IP security. A complete discussion of

This p olicy separates di erent\typ es" of application

the pros and cons of this debate is (fortunately) b eyond

communication into individual ows, but fails to cap-

the scop e of this pap er. Whatever one's view is on IP

ture the time variant nature (hence ownership changes)

security, the mapping in this section is useful for under-

of such communications. Sp eci cally, datagrams senton

standing FBS. In particular, (1) it provides a concrete

the same host-p ort pairs b elonging to di erent incarna-

demonstration of how FBS can be applied in practice;

tions of high-level communications are classi ed into the

(2) it presents a sp eci c security p olicy that could b e of

same ow.

general interest; (3) it lls in some implementation de-

To tighten this p olicy, some element of time should b e

tails not covered earlier in the generic description. For

intro duced. One p ossibility is enco ded in the ow state

concreteness, we have implemented our IP mapping as

table (FST) de nition, mapp er and sweep er mo dules in

part of the IP co de [27 ] in the 4.4BSD kernel [14 ].

Figure 7. This is also the security ow p olicy we have

used in our implementation. We emphasize that these

7.1 Security FlowPolicy

de nition and mo dules are intended as illustrations, and

express a sp eci c example p olicy that we b elieve captures

At the IP level, host/gateway to host/gateway security

our notion of conversation.

can b e easily provided. This can b e done by encrypting

The de nition and mo dules in Figure 7 should be

all datagrams going from one host/gateway to another.

fairly self-explanatory. In words, they enco de the fol-

A more ambitious goal of IP security,however, is to

lowing security ow p olicy:

provide some form of \conversation"-level security. This

clearly can only be an approximation b ecause IP do es

This is not uncommon in security.For example, it is routinely

not have access to all the necessary system and proto col

practiced in packet-level rewalls. Also, the implementation of

TCP/IP in 4.4BSD already p erforms this sort of layer violation

information for determining the extent of a conversation.

for the sake of eciency.

Conversation here means a sequence of datagrams b elonging

These de nition and mo dules do not handle raw IP (including

to the same high-level communication. For example, a TCP con-

ICMP and IGMP) packets. For brevity,we do not discuss the issue

nection is typically a conversation, and so is a sequence of UDP

of raw IP in this pap er. Essentially,raw IP can b e considered as

datagrams in a whiteb oard session.

host-level ows. 9

a secure ow is de ned as a sequence of data- 64-bit quantity. The timestamp is enco ded as the number

grams of the same transp ort layer proto col of minutes since 00:00 GMT January 1, 1996 GMT. With

(mostly either TCP or UDP) going from a 32 bits, the timestamp will not wrap around in the next

p ort on a host to another p ort on another 8000 years.

(not necessarily distinct) host such that the In our current implementation, the FBS header is

datagrams do not arrive more than THRESHOLD placed in between the normal IPv4 header and the IP

apart payload. This is unusual but can be understo o d as a

short-cut form of IP encapsulation. An alternativeisto

This p olicy nicely separates most of the interactive (e.g.,

implement it as an IP option, but the 40 byte maximum

TELNET, X-window) and sustained or p erio dic data trans-

is fairly limiting.

fer (e.g., FTP, NFS) conversation into individual ows.

A ow under this example p olicy is orthogonal to a

Proto col Co de. Our FBS implementation was done

connection. Sp eci cally, a connection may b e broken up

in FreeBSD 2.1.5, a PC-variant of 4.4BSD. The whole

into multiple ows, and a ow may span multiple con-

FBS implementation consists of a numb er of program and

nections.

header les. Most of the FBS proto col pro cessing co de is

An example of the former is a long TELNET session

contained within the le ip fbs.c. The implementation

with large quiet p erio ds. Interestingly, the partitioning of

mostly follows the pseudo-co de presented in Sections 5.2,

a long duration conversation into multiple ows is b etter

5.3 and 7.1 with a few exceptions p ointed out b elow.

from a security p ersp ective.

On the send side, IP output pro cessing as implemented

An example of the latter o ccurs when a pro cess quickly

in 4.4BSD can b e thoughtofashaving three logical parts.

b egins (within a time of THRESHOLD) using a p ort that was

In the rst part, it p erforms the bulk of the output pro-

just freed up by another pro cess. The FAM would fail to

cessing, including options pro cessing and route selection.

detect the change of conversation and continue to use the

In the second part, it fragments the packet, if necessary.

same s . This can p otentially p ose a security problem.

In the last part, it sends the packet(s) out on the interface

Sp eci cally, an attacker can recover the encrypted data

chosen in the rst part. We mo di ed the co de to include

sentina owby (1) recording the datagrams in the ow;

ahooktoourFBSSend() function b etween the rst and

(2) reallo cating the same p ort used for the ow right af-

second parts. This allows FBS send pro cessing to b e ba-

ter the original destination principal exited; (3) replaying

sically transparenttoIP, while receiving the b ene ts of

the recorded datagrams to itself at this p ort. FBS would

IP fragmentation and reassembly.

gladly decrypt the datagrams and hand them to the at-

For eciency reasons, wehave combined the ow as-

tacker if they are still \fresh." One way to counter this

so ciation mechanism and the owkey generation. More

problem is to imp ose a wait of THRESHOLD on p ort reallo-

sp eci cally, FBSSend() hashes on the 5-tuple as describ ed

cation. This x is, strictly sp eaking, outside the scop e of

in Section 7.1 and uses the result as an index into the

FBS, as it requires changes in the networking co de out-

TFKC. If the indexed entry is \active" (last use is less

side of FBS (e.g., the in pcballoc function in 4.4BSD

than THRESHOLD ago), it uses the stored owkey. Oth-

TCP/IP implementation).

erwise, it b egins a new owby assigning a new s and

calculating the new ow key. In this way, the mapp er

7.2 Our Implementation

mo dule and the key cache lo okup are combined (by com-

bining the FST and the TFKC), thus saving an extra

Crytographic Op erations. The CryptoLib library [13 ] is

lo okup. The job of the sweep er mo dule also b ecomes

used for all cryptographic op erations. It includes most of

implicit as it is absorb ed into the mapping phase.

the commonly used cryptographic primitives, e.g., Die-

After creating the FBS header, FBSSend() inserts it

Hellman key exchange, DES, RSA, MD5, etc. The key

between the IP and the transp ort layer headers. It xes

reasons for its choice are its general availability and p orta-

the IP header to account for the increase in the packet

bility (Sparc and Intel, Solaris and NT).

size. ToIP, the FBS header is simply a part of the higher

When data con dentiality is desired, we use DES for

layer header. A forwarding router also will not see any-

encryption and MD5 for MAC computation. Other-

thing \strange" ab out FBS pro cessed IP packets.

wise, keyed MD5 is used to compute the MAC. The p er-

Similar to the output pro cessing, IP input pro cess-

formance numb ers for CryptoLib on a Pentium 133 with

ing in 4.4 BSD can also be thought of as having three

512kB L2 cache are: 549kB/s for DES in CBC mo de and

logical parts. The rst part p erforms the bulk of the in-

7060kB/s for MD5.

put pro cessing except for reassembly. Then, if the packet

is not b eing forwarded, the second part reassembles the

FBS Header. For our implementation, the FBS header

packet, if necessary. Finally, the third part dispatches it

eld sizes are as follow: s is 64 bits, confounder is 32

to the correct higher-layer proto col. The ho ok to our

bits, timestamp is 32 bits, and MAC is 128 bits. For DES

FBSReceive() is between the second and third parts.

encryption, the confounder is rst duplicated to provide a

Thus, as in output pro cessing, FBS receive pro cessing is

A hash collision can prematurely terminate a ow. This do es

basically transparenttoIP. The op eration of FBSReceive()

not a ect security though. Also, almost no collision is observed

is similar to what was describ ed in Section 5.2. It removes

with a reasonable FSTSIZE, e.g., 32 or ab ove.

For eciency, DES could have b een used for b oth encryption

This is as it should be given that FBS is an end-to-end

and MAC computation.

proto col. 10 10000 512 FBS DES+MD5 FBS NOP 256 GENERIC 8000 128

64 6000 32

16 4000 8

Transfer Time (in seconds) 4 FBS DES+MD5 Transfer Rate (in Kbits/second) 2000 FBS NOP 2 GENERIC

0 1 64 128 256 512 1024 2048 4096 8192 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M 128M

Payload Size (in bytes) File Size (in bytes)

(a) ttcp (b) rcp

Figure 8: FBS Performance Results

100% 100%

90% 90%

80% 80%

70% 70%

60% 60%

50% 50% file server

% of Flows 40% WWW server % of Flows 40% compute server 30% desktop 30%

20% 20% file server WWW server 10% 10% compute server desktop 0% 0% 1 4 16 64 256 1024 4096 16384 65536 16 64 256 1K 4K 16K 64K 256K 1M

Number of Packets Number of Bytes

(a) Flow Size in Packets (b) Flow Size in Bytes

Figure 9: Flow Size

100%

the FBS header, p erforms pro cessing on the header, and

ket back to IP for dispatch. We omit the

hands the pac 90%

details here.

implementation required only minor mo di ca-

Our 80%

tions to the rest of the 4.4BSD networking co de. In par-

input.c, hanged: ip

ticular, only three les had to b e c 70%

output.c, and tcp output.c. Files ip input.c and ip

60% file server

ip output.c each required two lines of changes to pro-

% of Flows WWW server

FBSSend() and FBSReceive() func- vide the ho oks to our compute server

50% desktop

tions. tcp output.c was changed b ecause of a dep en-

tation. Sp eci cally,

dency unique to the BSD implemen 40%

tcp output(), for the sake of p erformance, attempts to

wmuch data it can place in a packet calculate exactly ho 30%

1 4 16 64 256 1024 4096 16384

tation. It then places exactly

without triggering fragmen Duration (in seconds)

this much data in the packet and sets the DF (Don't

Figure 10: Flow Duration

Fragment) ag when lling in the IP header. This breaks

when we insert our FBS header. We mo di ed its calcu-

for understanding the suitability and general dynamics

lation to include the FBS header size.

ofa ow-based approach to datagram security.

7.3 Exp erimental Results

Setup. Our exp erimental setup consists of a number of

Pentium 133s with 512 L2 cache running FreeBSD 2.1.5.

Wehave p erformed twotyp es of exp eriments. The rst

For timing measurements, these machines are put on a

typ e measures the raw p erformance of FBS. The use of

dedicated 10M Ethernet segment. We measure through-

any security proto col will incur a p erformance p enalty.

put using b oth ttcp and regular rcp.

This provides an idea on the cost of using FBS. The sec-

For ow measurements, we use the Pentium 133s as

ond typ e collects data on owcharacteristics in a typical

network sni ers (using tcpdump) on our workgroup wide

server-based campus LAN environment. This is useful 11 50% 50% MKC MKC TFKC TFKC RFKC RFKC 40% 40%

30% 30%

Miss Rate 20% Miss Rate 20%

10% 10%

0% 0% 1 4 16 64 256 1024 1 4 16 64 256 1024

Cache Size (in lines) Cache Size (in lines)

(a) Cache Miss in a File Server (b) Cache Miss in a Web Server

Figure 11: Cache Miss Results

LAN, which has a number of le and compute servers semantics. The graphs also show that there are a few

in addition to individual users' desktops. Separately,we long-lived ows (e.g., for NFS) that carry the bulk of the

also collected packet-level traces for a lightly hit (ab out trac. Our approach also correctly captures and handles

10,000 hits p er day) WWW server. The collected traces these long-lived ows with minimal overhead.

are fed into a number of ow simulation programs to gen-

100

wcharacteristics. These characteristics

erate the nal o file server

vide an idea on the dynamics of ows had every ma- pro 90 WWW server

compute server

hine on the LAN implemented FBS and the security ow c 80 desktop p olicy de ned in Section 7.1. 70

Results. The timing results are shown in Figure 8. FBS

DES+MD5, FBS NOP, and GENERIC represent resp ec-

ely FBS with data con dentiality and MAC compu-

tiv 40

ulli ed" encryption and MAC com- tation, FBS with \n 30

Number of Active Flows

putation (i.e., b oth encryption and MAC returns imme-

diately), and regular 4.4BSD IP. As can be seen, FBS

10 incurs very little overhead outside of the cryptographic

A heavy p enalty (7,700kb/s op erations, as it should b e. 0 10AM 11AM 12PM 1PM 2PM 3PM 4PM 5PM 6PM

reduced to 3,400kb/s) is paid though when cryptographic Time

op erations are included. The extent of the p enalty is

Figure 12: Numb er of Active Flows

mostly a function of the quality of the crypto implemen-

tation and howitisintegrated with the networking co de.

To answer (2), consider Figures 11(a){(b). The cache

To evaluate the e ectiveness of our ow-based ap-

miss rate drops o sharply even with reasonably small

proach for IP security,we consider the following asp ects:

cache sizes. This could indicate a packet train nature of

(1) Is our approach suitable for IP security? That is,

datagrams in a ow. Figure 12 shows that the number

do es our formulation of ow-based security match well

of simultaneous active ows in a host are not exceedingly

with IP? (2) Is our approach feasible for IP security?

high, and can b e easily handled by a mo dern op erating

That is, can it b e applied to IP and achieve reasonable

system kernel.

p erformance? (3) How should ows b e de ned for IP se-

To answer (3), consider Figure 13. As THRESHOLD in-

curity? This may b e to o general to have a single answer.

creases from 300s to 600s, it shows the exp ected increase

A more concrete question would b e what do es the p olicy

in the numb er of active ows, as ows are taking longer

prop osed in Section 7.1 capture in our environment?

to expire. Interestingly though, the p olicy b ecomes rel-

Due to space limitation, we can not present all the

atively insensitive to the THRESHOLD value when it gets

details of our exp erimental results. Instead, we will high-

higher than 900s. Similarly, Figure 14 shows that the

light only a few key observations. We emphasize that

number of rep eated ows, i.e., di erent ows with the

this represents only a preliminary study of owcharac-

same 5-tuple as de ned in Section 7.1, drops o quickly

teristics. We also caution that the owcharacteristics are

as THRESHOLD increases. One waytointerpret this is that

very much dep endent on the typ e of trac and network

THRESHOLD values of 300s or 600s provide go o d di erentia-

environment.

tion b etween ows, while maintaining reasonable stability

To answer (1), consider Figures 9(a){(b) and 10. We

in the ow dynamics (e.g., numb er of active ows).

observe that the ma jorityof ows are short, consist of few

packets and transfer only a small amount of data. This

strongly argues for the b ene ts of maintaining datagram 12 320 300 280 Threshold = 300 260 Threshold = 600 240 Threshold = 900 Threshold = 1200 220 Threshold = 1500 200 Threshold = 1800 180 160 140 120

Number of Active Flows 100 80 60 40

10AM 11AM 12PM 1PM 2PM 3PM 4PM 5PM 6PM

Time

Figure 13: Active Flows for Di erent Thresholds

30%

or (2), FBS makes use of zero-message keying and

WWW server F

explicit security ow lab el. SKIP [4] also provides file server an

compute server

keying based on Die-Hellman. The key

desktop zero-message

advantage of FBS is that it provides security based on

20%

the unit of ows rather than hosts. This results in im-

proved security b ecause a compromised ( ow) key only

a ects datagrams within that ow | it do es not provide

access to the master key which can b e used to \unlo ck"

ween a pair of hosts. FBS also provides 10% all datagrams b et

% of Repeated Flows

b etter p erformance b ecause key generation need only b e

done on a p er- ow basis rather than a p er-datagram basis.

300 600 900 1200 1500 1800 Conclusion

Threshold Value (in seconds) 8

Figure 14: Rep eated Flows

The concept of ow o ers a natural waytocharacterize

network communications. On one hand, a ow recognizes

7.4 Comparison with IP SecurityWork

the fact that individual datagrams may be correlated

Strictly sp eaking, a comparison of FBS with IP security

(e.g., b elonging to the same high-level communication).

work is not appropriate. First, FBS is designed for gen-

On the other hand, a ow is not sub ject to the rigid

eral datagram security; it is not sp eci cally targeted for

b oundary structure (delimited by explicit setup and tear-

IP. Second, the motivation for the design of FBS is dif-

down) of a connection.

ferent. FBS is concerned with how to structure secure

The exibilityof ow makes it ideal as a base for de n-

communications as muchashow the communications are

ing security. Using ow as the unifying base, our FBS

secured. Most existing IP security work, on the other

proto col is able to marry the b ene ts of a connectionless

hand, fo cuses only on the proto col and mechanism as-

scheme (no extraneous message exchange and hard state)

p ects.

with the eciency of a connection-oriented scheme.

If one must compare, there are two key asp ects of

Our implementation of the mapping of FBS to IP

FBS: (1) the notion of ow-based security and FAM; and

demonstrates b oth the feasibility and suitability of our

(2) the sp eci c proto col and mechanism of FBS. (1) can

ow-based approach for providing security to a datagram

be directly applied to most IP security work. It deals

service suchasIP.

with p olicy issues and is complementary to proto col and

In some cases, our notion of ow coincides with other

mechanisms. Sp eci cally, the FAM de nes the unit of

notions of ow that have b een prop osed, e.g., QoS ows,

protection that should b e enforced by the underlying IP

while in other cases, it is orthogonal, e.g., ows for high-

security mechanism.

sp eed routing. A more thorough study of the relationship

among these di erent notions of ow and the dynamics of 13

[16] National Bureau of Standards, U.S. Department of Com- ows for di erent trac typ es and network environments

merce, Washingtion, D.C. DES Modes of Operations.

is needed.

FIPS Pub 81, Decemb er 1980.

[17] National Institute of Standards, U.S. Department of

Acknowledgments

Commerce, Washingtion, D.C. Secure Hash Standard.

FIPS Pub 180, April 1993.

Wewould like to thank Craig Partridge and the anony-

mous referees for their very helpful comments. We are

[18] H.K. Orman. The OAKLEY Key Determination Proto-

col. Internet Draft, May 1996.

also grateful to the Distributed Systems Group at Stan-

ford for providing us with access to their systems. Finally,

[19] C. Partridge. Using the Flow Label Field in IPv6. RFC

we thank Scott Miller and the systems sta at Bell Lab-

1809, June 14 1995.

oratories for their help in setting up our testb ed and

[20] L.L. Peterson and B.S. Davie. Computer Networks | A

collecting packet traces.

Systems Approach. Morgan Kaufmann Publishers, 1996.

Suvo Mittra was partially supp orted by a National

[21] J. Postel. User Datagram Protocol. RFC 768, August 28

Defense Science and Engineering Graduate (NDSEG) Fel-

1980.

lowship sp onsored by the U.S. Air Force.

[22] J. Postel. Internet Protocol: DARPA Internet Program

Protocol Speci cation. RFC 791, Septemb er 1981.

References

[23] R. Rivest. The MD5 Message-Digest Algorithm. RFC

[1] R. Atkinson. Security Architecture for the Internet Pro-

1321, April 16 1992.

tocol. RFC 1825, August 1995.

[24] W. Rosenb erry, D. Kenny, and G. Fisher. Understanding

[2] R. Atkinson. IP Authentication Header. RFC 1826, Au-

DCE. O'Reilley & Asso ciates, Inc., 1992.

gust 1995.

[25] J.G. Steiner, C. Neuman, and J.I. Schiller. Kerberos :

[3] R. Atkinson. IP Encapsulating Security Payload (ESP).

An authentication service for op en network systems. In

RFC 1827, August 1995.

Proceedings of USENIX Winter Conference, pages 191{

202, Dallas, TX, February 1988.

[4] A. Aziz, T. Markson, and H. Prafullchandra. Simple

Key-Management For Internet Protocols (SKIP). Inter-

[26] Sun Microsystems, Inc. Remote Procedure Cal l Protocol

net Draft, August 14 1996.

Speci cation Version 2. RFC 1057, June 1988.

[5] S. Bellovin. Problem areas for the IP security proto cols.

[27] G.R. Wright and W.R. Stevens. TCP/IP Il lustrated,

In Proceedings of 6th USENIX Security Symposium, San

Volume 2 | The Implementation. Addison-Wesley Pub-

Jose, California, July 22{25 1996.

lishing Company, 1995.

[6] A. Birrell and B. Nelson. Implementing remote pro cedure

[28] CCITT Recommendation

calls. ACM Transactions on Computer Systems, 2(1):39{

X.509 The Directory|Authentication framework, 1988.

59, February 1984.