Layer 3 Accounting (L3A) August 2004 Carl A. Gunter, Alwyn Goodloe, and Matthew Jacobs 1 Objective ----------- To protect the accounting infrastructure used for VPN connections. The problem can be stated as follows. Given a client C that needs to connect to a server S over the network via a network access server(NAS). The client needs to establish a secure connection to the server. The company that owns the NAS will charge the customer for use. Therefore the NAS will only allow authorized traffic to pass. We fully acknowledge that there are existing solutions to the problem. These solutions usually involve a hodge-podge of technology that not only seem unsatisfactory from an aesthetic point of view, but often introduce security vulnerabilities. This document presents a protocol for handling the entire problem at the network layer. 2 Terminology ------------- TBD 3 Assumptions ------------- The protocol will use IP Sec to provide both authentication and confidentially. We assume that there are three parties to our protocol. A client that is physically located outside of the network to which it wants to connect. The server that the client wishes to connect. A Network Access Server (NAS) that the client must connect to in order to gain access to the Internet at large. The client and server will communicate over a virtual private network (VPN) that provides an authenticated and confidential connection between the two parties. The NAS will not allow any traffic to pass from a source that is not authenticated. We assume the existence of a public key infrastructure. Following IKE and JFK we assume that the destination end of a IPSec tunnel generates the SPI. We assume the the client knows the address of the NAS and the server with which it wishes to connect. The NAS has no relationship with the server. The client must pass along to the NAS the server address. The server may not know the address of the NAS or possess any knowledge about the owner of the NAS. On the other hand, the server will only allow connections with authorized parties. Thus the client must authenticate himself to the server. 4. Architecture and Design -------------------------- Overview. TBD 4.1 Architecture --------------------------- The NAS needs to authenticate each incoming message. Hence there must be authentication IP SEC tunnels leading from the client to the NAS and from the server to the NAS. We have also decided to authenticate maintenance traffic exiting the NAS. Thus we shall create Pictorially we represent this as C NAS S <--------------> <----------------> All data exchanged between the client and the server is authenticated and encrypted. The final architecture looks like C NAS S <----------------> <-------------------> <========================================> Note that in reality there are not three bidirectional tunnels, but six unidirectional tunnels. 4.2 Design Decisions --------------------------- There are several options available to us with regards to accounting. We considered the following four. i) Construct a protocol where the NAS will electronically bill the client for a connection and expect payment within some fixed amount of time after which they are cut off from service. This may require some form of electronic payment scheme. ii) Construct a protocol where the client pays for a fixed amount of time in advance. NAS maintains an Access Control List (ACL) of those clients who are "paid up". The client is removed from this list when the amount of time bought is exceed and no additional payments have been made. This option requires that the NAS track the time a client is connected. Many existing NAS boxes already perform such a service. iii) Construct a protocol modeled on CDMA2000 Wireless IP Network standard (3GPP2 X.S0011-006-C).This is a scheme for billing based on volume. We are still investigating the details of this protocol and may use it as a model for a future accounting scheme. iv) Assume that a separate system performs all accounting functions. The NAS only maintains an Access Control List (ACL) that must be consulted before each client is allowed to connect. Clients are added to the list when a relationship with the owner of the NAS is established and the client is removed when that relationship is either terminated by mutual consent or the client has refused to pay the bill. We selected the fourth option for simplicity although any of the other choices could have been made without adding too much complexity to the protocol. In particular, we may choose to design an accounting protocol based on CDMA 2000 if we judge it worthwhile. The standard mechanism for establishing an IPSEC Security Association (SA) is to use a key exchange protocol such as the Internet Key Exchange (IKE) protocol (RFC XXX) or the Just Fast Keying (JFK) protocol (RFC XXX). These protocols ease configuration by generating and exchanging the necessary shared keys. Other information such as the encryption algorithm details are also exchanged. Unfortunately, none of these protocols have been fully implemented. Although most implementations can handle basic IPSEC configurations, we know of no implementation that can handle the nested tunnels employed by our protocol. We considered the following three options. i) Pick one of the better implementations of IKE such as the BSD implementation and hack it to accommodate nested tunnels. ii) Use IKE where possible and write our own simple key exchange mechanism to handle the exchange for tunnels. iii) Write our own key exchange algorithm that we use throughout the protocol. We selected the third option. Further details on the key exchange can be found in the next section. The client and the NAS as assumed to have a relationship. Thus the client simply authenticates itself to the NAS. The client is also assumed to have a relationship with the server. On the other hand, the NAS does not have any relationship with the server. Hence the client must hand the NAS a credential that it gives the server so that the server can authorize the connection. Security polices are reused whenever possible. Whenever possible we send information over an authenticated tunnel. This is a guiding principle in the design of the protocol. 5.0 Security Associations --------------------------- A security association (SA) is established between an initiator I and a responder R; it is negotiated starting with a message from the former to the latter. Two different types of SA are established by this protocol. The first type of SA provides authentication of the client or server to the NAS. This SA consists of an Encapsulated Security Payload (ESP) with null encryption and authentication using a MAC (HMAC-MD5 - rfc2403). The SA is established in tunnel mode and entered into the SA Database (SADB). All traffic between C and S must pass through such a tunnel since the NAS does not allow non-authenticated traffic to pass. The second type of SA provides end-to-end authentication and confidentially between the client and the server. This SA consists of an Encapsulated Security Payload (ESP) with triple-des (rfc 2451) encryption and authentication using a MAC(HMAC-MD5 - rfc2403). The SA is established in transport mode and entered into the SA Database (SADB). Assume all SAs have been established and suppose a tcp packet is being sent from C to S. The protocol will first add an ESP header/trailer that authenticates C to S and encrypts all of the information in the original IP packet including the original headers. A second ESP header is then added which authenticates C to the NAS. Upon arrival at the NAS, the packet is authenticated as originating at C, the outer header/trailer is stripped off, and the packet travels toward S in the inner tunnel. Upon arrival at S, the packet is verified as originating at C, the header/trailer is removed, the original packet is decrypted, and finally the original packet is processed normally. A similar process is performed on packets going from S to C. A packet is ultimately addressed to S if the packet obtained by removing both ESP headers is addressed to S. The policy for applicable SAs is stored in the SA Policy Database (SPDB). Note on notation. We use the notation A-->B:[(A-->B)] to denote the security policy that takes all traffic traveling from A to B and places it in the security association going from A to B. The notation A-->B:[(A-->B)(A--C)] represents the security policy that directs all traffic traveling from A to B into the security association going from A to B that is tunneled through the security association going from A to C. 5.1 Key Exchange Algorithm --------------------------- The key exchange algorithm is specified in related documents. Suppose node A begins a key exchange with node B. We will assume that upon termination of the key exchange protocol the following holds: - There is a shared key for authentication. - If the protocol was called with a flag indicating that encryption will be done, then there is a shared key for encryption. - The security association databases at A and B have entries for a tunnel from A to B and another entry for a tunnel from B to A. More explicitly we say that upon termination of a key exchange the SADBs on A and B have entries (A-->B) and (B-->A). - The security policy databases on both A and B have entries that associate all traffic from A to B and all traffic from B to A with the appropriate security association(s). More explicitly we say that upon termination of a key exchange the SPDBs on A and B have entries A-->B:[(A-->B)] and B-->A:[(B-->A)]. 6.0 Protocol. ------------------- 6.1 Message Types. -------------------- SIKE-Start - Begin the key exchange. SIKE-ACK - An acknowledgment to the party that issued the SIKE-Start that the key exchange is complete. SIKE-Notify - Notification from a daemon process that a key exchange has completed. Req - A message sent from the client to the NAS with the credential that the NAS will send to the SERVER. The req message also contains the address of the server that the client wishes to communicate with. In addition to the server address address and credential, the Req message has a flag that is set to New if the Req message is traveling over a new tunnel. The flag is sent to Reused if the message is traveling over an existing tunnel. ACK - The message sent by the NAS to the Server upon successful termination of the key exchange between C and NAS. The Ack message contains the credential that was sent to the NAS by the client and a flag that is set to New if the Ack message is traveling over a new tunnel. The flag is sent to Reused if the message is traveling over an existing tunnel. Fin - A message sent by the server to the client when it has finished all of its processing. 6.2 Protocol Description ------------------- Consider a network configuration C ---------- ------------ S | | | | |a |b NAS |c |d | | | | C' ---------- ----------- S' where the NAS has four interfaces a,b,c, and d. Suppose that client C wishes to establish a connection to server S via network access server NAS. If there is no existing authentication tunnel between the client and the NAS, then the client begins a key exchange with the NAS (SIKE-Start). The tunnel type flag is set to authenticate. Upon termination of the key exchange (the client receives a SIKE-Ack), the SPDB of the client is updated with the entry C-->S:[(C-->NAS)]. The SPDB of the client should now have the entries: C-->NAS:[(C-->NAS)], NAS-->C:[(NAS-->C)], and C-->S:[(C-->NAS)]. The client then generates a request message containing the server address with which the client wishes to communicate, a credential that the NAS presents to the server on C's behalf, and the tunnel status flag set to New. The client sends the message Msg 1. C-->NAS: req(S,cred,New). If the NAS receives notification from the key exchange daemon (SIKE-Notify) indicating that a key exchange with the client has successfully terminated, then the NAS waits for a message arriving via the C-->NAS tunnel of the form Msg1. Upon receiving this message, the NAS knows that an SA with client has been successfully established. The NAS now updates its SPDB with the entry C-->S: [(C-->NAS)]. If there is no existing authentication tunnel between the NAS and the server, then the NAS begins a key exchange protocol(SIKE-Start) with the server. The tunnel type flag set to authenticate. Upon termination of the key exchange (the NAS receives a SIKE-Ack), the NAS updates its SPDB with an entry S-->C:[(S-->NAS)]. At this point in the execution of the protocol the SPDB of the NAS should have entries NAS-->S:[(NAS-->S)], S-->NAS:[(S-->NAS)], and S-->C:[(S-->NAS)]. The NAS then forms an ACK message containing the credential that it will present to the server, and the tunnel flag is set to New. The NAS now sends the message Msg2. NAS-->S: ACK(Cred, New). If the server receives notification from the key exchange daemon indicating that a key exchange has completed with the NAS (SIKE-Notify), then the server waits for a message arriving via the NAS-->S tunnel of the form Msg2. Upon receiving this message, the server checks the credential. If the credential is valid, the server updates its SPDB with the entry S-->C:[(S-->N)]. At this point in the protocol execution the server's SPDB has entries NAS-->S:[(NAS-->S)], S-->NAS:[(S-->NAS)], and S-->C:[(S-->NAS)]. The server now begins a key exchange with the client (SIKE-Start). The tunnel type flag is set to encrypt. Upon notification that the key exchange with the client is complete (SIKE-ack), the server's SPDB should have been updated with the entries C-->S:[(C-->S)] and S-->C:[(S-->C)(S-->NAS)]. The server now sends a Fin message to the client to indicate that all of the tunnels have been established. Msg3. C-->S: Fin If the client receives notification from its key exchange daemon (the client receives SIKE-Notify) that a key exchange between the server and client has successfully terminated (SIKE-Notify), then the client's SPDB should have entries S-->C:[(S-->C)] and C-->S:[(C-->S)(C-->NAS)]. The client then waits to receive a Fin message from the server. When the client receives a message of the form Msg3 the L3A protocol terminates and the client can proceed to interact with the server. The L3A protocol has terminated after establishing ESP SAs that perform authentication between the client and the NAS and between the NAS and the server. The protocol has also established an ESP transport SA between the client and the server that performs authentication as well as encryption. The three nodes participating in the protocol should have the following SADB entries: C NAS S ----------------------------------------------------------- C-->NAS C-->NAS NAS-->S NAS-->C NAS-->C S-->NAS C-->S S-->NAS S-->C S-->C NAS-->S C-->S The the three nodes participating in the protocol have the following SPDB entries: C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->S)(C-->NAS)] S-->C:[(S-->C)] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->NAS)] NAS-->S:[(NAS-->S)] S-->NAS:[(S-->NAS)] S-->C:[(S-->NAS)] S ----------------------------- S-->NAS:[(S-->NAS)] NAS-->S:[(NAS-->S)] S-->C:[(S-->C)(S-->NAS)] C-->S:[(C-->S)] 6.3 Reuse of Tunnels --------------------- After a client C runs the L3A protocol to establish a connection with server S it may then wish to connect to another server. Given that there is already an authentication tunnel between C and the NAS it makes no sense to establish a second such tunnel when the existing one may be reused. A similar case can be made for reusing an existing authentication tunnel between the NAS and a server if a new client wishes to connect to that server. 6.3.1 Reuse of Client and NAS Tunnel. -------------------------------------- Suppose that the protocol run illustrated above was executed and that client C now wants to communicate with server S'. Since there is already an existing authentication tunnel between the client and the NAS, there is no reason to establish a second tunnel between these two principals. So the protocol skips the key exchange between the client and the NAS and proceeds as above in the other steps. The rules governing the client and NAS actions for the case where the client and NAS tunnel is being reused are given below. If there is an existing tunnel between the client and the NAS, then the client does not perform a key exchange with the NAS. Instead, the client updates its SPDB with the entry C-->S':[(C-->NAS)]. The client then generates a request message containing the address of the server that C wishes to communicate with, the credential that the NAS presents to the server on C's behalf, and the tunnel status flag set to Reuse. The client sends the message Msg1'. C-->NAS: req(S',cred,Reuse). If the NAS receives a message of the form Msg1', then the client is reusing an existing tunnel with the NAS. The NAS then updates its SPDB with the entry C-->S:[(C-->NAS)] and proceeds with the execution of the L3A protocol. Upon termination of this run of the protocol, a new ESP authentication tunnel between S' and the NAS has been established. There is also a new SA between C and S' that performs both authentication and encryption in ESP transport mode. The four principal nodes involved now have the following SADB entries: C NAS S S' ------------------------------------------------------------------------- C-->NAS C-->NAS NAS-->S NAS-->S' NAS-->C NAS-->C S-->NAS S'-->NAS C-->S S-->NAS S-->C S'-->C S-->C NAS-->S C-->S C-->S' C-->S' NAS-->S' S'-->C S'-->NAS The the four nodes nodes now participating in the protocol have the following SPDB entries: C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->S)(C-->NAS)] S-->C:[(S-->C)] C-->S':[(C-->S')(C-->NAS)] S'-->C:[(S'-->C)] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->NAS)] NAS-->S:[(NAS-->S)] S-->NAS:[(S-->NAS)] S-->C:[(S-->NAS)] C-->S':[(C-->NAS)] S'-->C:[(S'-->NAS)] S'-->NAS:[(S'-->NAS)] NAS-->S':[(NAS-->S')] S ----------------------------- S-->NAS:[(S-->NAS)] NAS-->S:[(NAS-->S)] S-->C:[(S-->C)(S-->NAS)] C-->S:[(C-->S)] S' ----------------------------- S'-->NAS:[(S'-->NAS)] NAS-->S':[(NAS-->S')] S'-->C:[(S'-->C)(S'-->NAS)] C-->S':[(C-->S)'] 6.3.2 Reuse of NAS and Server Tunnel. -------------------------------------- Suppose we have completed the protocol runs described in sections 6.2 and 6.3.1, and client C' now wishes to communicate with S. Since there is no authentication tunnel between C' and the NAS, the L3A protocol establishes this as described in section 6.2. There is already an existing authentication tunnel between the NAS and S so there is no need to establish a second tunnel. The protocol rules governing this are described below. If there is an existing authentication tunnel between the NAS and the server, then the NAS updates its SPDB with an entry S-->C:[(S-->NAS)]. The NAS then forms an ACK message containing the credential that it will present to the server, and the tunnel status flag set to Reuse. The NAS sends the message Msg2'. NAS-->S: ACK(Cred, Reuse). Upon receipt of a message of the form Msg2', the server checks the credential. If the credential is valid, then the server updates its SPDB with the entry S-->C:[(S-->NAS)]. The five principal nodes involved now have the following SADB entries: C C' NAS S S' ------------------------------------------------------------------------- C-->NAS C'-->NAS C-->NAS NAS-->S NAS-->S' NAS-->C NAS-->C' NAS-->C S-->NAS S'-->NAS C-->S C'-->S S-->NAS S-->C S'-->C S-->C S-->C' NAS-->S C-->S C-->S' C-->S' NAS-->S' S'-->C S'-->NAS The SPDB entries are as follows: C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->S)(C-->NAS)] S-->C:[(S-->C)] C-->S':[(C-->S')(C-->NAS)] S'-->C:[(S'-->C)] C' ---------------------------- C'-->NAS:[(C'-->NAS)] NAS-->C':[(NAS-->C')] C'-->S:[(C'-->S)(C'-->NAS)] S-->C':[(S-->C')] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->NAS)] NAS-->S:[(NAS-->S)] S-->NAS:[(S-->NAS)] S-->C:[(S-->NAS)] C-->S':[(C-->NAS)] S'-->C:[(S'-->NAS)] S'-->NAS:[(S'-->NAS)] NAS-->S':[(NAS-->S')] C'-->NAS:[(C'-->NAS)] NAS-->C':[(NAS-->C')] C'-->S:[(C'-->NAS)] S-->C':[(S-->C')] S ----------------------------- S-->NAS:[(S-->NAS)] NAS-->S:[(NAS-->S)] S-->C:[(S-->C)(S-->NAS)] C-->S:[(C-->S)] S-->C':[(S-->C')(S-->NAS)] C'-->S:[(C'-->S)] S' ----------------------------- S'-->NAS:[(S'-->NAS)] NAS-->S':[(NAS-->S')] S'-->C:[(S'-->C)(S'-->NAS)] C-->S':[(C-->S)'] 7 Message sequent Chart Representation of L3A. ------------------- We use <~~~~~~~~~~~> to denote a key exchange. Consider a network configuration C ---------- ------------ S | | | | |a |b NAS |c |d | | | | C' ---------- ------------ S' where the NAS has four interfaces a,b,c, and d. Suppose C wishes to communicate with S C NAS S <~~~~~~~~~~~~~~~~~~> C-->S:[(C-->Na)] Req(Sa,cred, New) ------------------> C-->S:[(C-->Na)] <~~~~~~~~~~~~~~~~~~~~> S-->C:[(S-->Nb)] Ack(cred,New) -------------------> S-->:[(S-->Nb)] <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Fin <------------------------------------------------ Suppose C now wishes to communicate with S' In this case the tunnel between the client and the NAS will be reused. Hence there will be no key exchange between the client and the NAS. C aNASd S' C-->S':[(C-->Na)] Req(S'a, cred,Ruse) ------------------> C-->S':[(C-->Na)] <~~~~~~~~~~~~~~~~~~~~~~> S'-->C:[(S'-->Nd)] Ack(cred,New) ----------------------> S'-->C:[(S'-->Nd)] <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Fin <----------------------------------------------- Suppose C' now wishes to communicate with S. In this case the tunnel between the server and the NAS will be reused. Hence there will be no key exchange between the server and the NAS. C' cNASa S <~~~~~~~~~~~~~~~~~~~~> C'-->S:[(C'-->Nc)] Req(Sa,cred,New) -------------------> C'-->S':[(C'-->Nc)] S-->C':[(S-->Nb)] Ack(cred,Reuse) -------------------------> S-->C':[(S-->Nb)] <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> Fin <----------------------------------------------- Section 9.0 ------------------------------------- This document has thusfar been concerned with the creation of security policies and security associations. We now turn our attention to the tear down of SAs created by the L3A protocol. The next section will describe the ISAKAMP Delete message. This is followed by a description of the protocol. 9.1 ISAKAMP Delete Message ---------------------------- Section 9.1.1 is reproduced from RFC 2408 in order to give the reader the precise definition of the delete command. The following section describes how the Delete command is used in this protocol 9.1.1 Definition. --------------------- The Delete Payload contains a protocol-specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 16 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload, however, each SPI MUST be for the same protocol. Mixing of Protocol Identifiers MUST NOT be performed with the Delete payload. Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id of ISAKMP and the SPIs are the initiator and responder cookies from the ISAKMP Header. Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s). NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-Id ! SPI Size ! # of SPIs ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index(es) (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Delete Payload Format The Delete Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this deletion is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B. o Protocol-Id (1 octet) - ISAKMP can establish security associations for various protocols, including ISAKMP and IPSEC. This field identifies which security association database to apply the delete request. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted. o # of SPIs (2 octets) - The number of SPIs contained in the Delete payload. The size of each SPI is defined by the SPI Size field. o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. Values for this field are DOI and protocol specific. The length of this field is determined by the SPI Size and # of SPIs fields. The payload type for the Delete Payload is twelve (12). 9.1.2 ------------------------- The Delete message is intended to be a notification that the sender has deleted the SAs identified in the message. We have assume an alternate semantics for this message. The recipient of the Delete message is to assume that the sender will remove the identified SAs in the immediate future. In fact, the identified SAs may be removed by the time the receiver gets the message. 9.2 The Tear Down Protocol --------------------------- The L3A tear down protocol is always initiated by the client. The client may tear down the connection to any of the servers with whom it is connected. We assume that the client is only connected to only one NAS. The client always removes the end-to-end SAs before proceeding with the authentication tunnels. Invoking the tear down protocol to remove connection to a server will not remove the authentication tunnel between the client and the NAS as long as there are any remaining connections to other servers. If other clients are also connected to the server, then the L3A tear down protocol will not remove the authentication tunnel between the NAS and the server since that would disrupt the other client's connection with the server. Consider the case where a connection has been previously established between client C and server S via a NAS. Illustrated e ------------------------> f <----------------------- C a c S ----------> NAS --------> b d <--------- <-------- where SAs are identified by lower case letters rather than integers. In reality an SA is identified by its SPI. The SADB of each node should have the following entries: C NAS S ----------------------------------------------------------- C-->NAS C-->NAS NAS-->S NAS-->C NAS-->C S-->NAS C-->S S-->NAS S-->C S-->C NAS-->S C-->S The the three nodes participating in the protocol have the following SPDB entries: C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->S)(C-->NAS)] S-->C:[(S-->C)] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->S)] NAS-->S:[(NAS-->S)] S-->NAS:[(S-->NAS)] S-->C:[(S-->NAS)] S ----------------------------- S-->NAS:[(S-->NAS)] NAS-->S:[(NAS-->S)] S-->C:[(S-->C)(S-->NAS)] C-->S:[(C-->S)] The client begins the tear down protocol forming a message to delete SA e and sends this message to S. Msg1. C-->S: Delete(e). Upon receiving a message of the form Msg1, the server removes SA e from its SADB. The server also removes all security policies associated with SA e. The server now forms a delete message for SAs e and f and sends. Msg2. S-->C: Delete(e,f) The server then removes SA f from its SADB as well as all policies in the SPDB associated this SA. Upon receiving a message of the form Msg2, the client removes the SA e from its SADB. The client then deletes all policies in the SPDB associated with SA e. The client now removes SA f from its SADB after which it removes all associated policies from its SPDB. The SADB entries should have the following entries: C NAS S ----------------------------------------------------------- C-->NAS C-->NAS NAS-->S NAS-->C NAS-->C S-->NAS S-->NAS NAS-->S The SPDB entries now look like C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->NAS)] NAS-->S:[(NAS-->S)] S-->NAS:[(S-->NAS)] S-->C:[(S-->NAS)] S ----------------------------- S-->NAS:[(S-->NAS)] NAS-->S:[(NAS-->S)] The client now forms a message directing the NAS to tear down its connection to the server. Msg3. C-->NAS: Remove(server) Upon receipt of message of the form Msg3, the NAS waits 10 seconds and checks if there are any other clients connecting to the server. If there are no other clients connected to the server, the NAS forms a message directing the server to remove SA c. Msg4. NAS-->S: Delete(c) If the server receives a message of the form Msg4, then the server removes SA c from its SADB. The server then removes from its SPDB all policies associated with SA c. The server then forms a message directing the NAS to remove SAs c and d. The server then removes SA d from its SADB as well as all associated policies from its SPDB. Msg5. S-->NAS: Delete(c,d) Upon receipt of a message of the form Msg 5, the NAS removes SA c from its SADB as well as all associated policies from it SPDB. The NAS then removes SA d from its SADB and all policies associated with SA d from its SPDB. The NAS then forms a message to inform the client that all processing of the NAS-server SAs has completed. Msg6. NAS-->C: RemAck(server) The SADBs of each participating node have the following entries: The SADB entries should now have the following entries: C NAS S ----------------------------------------------------------- C-->NAS C-->NAS NAS-->C NAS-->C The SPDB entries now look like C -------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] NAS ---------------------------- C-->NAS:[(C-->NAS)] NAS-->C:[(NAS-->C)] C-->S:[(C-->NAS)] S ----------------------------- Upon receipt of a message of the from Msg6, the client checks to see if there connections to other servers. If there are no connections to other servers, then the client forms a message directing the NAS to remove SA a. Msg7. C-->NAS: Delete(a) If the NAS receives a message of the form msg7, then the NAS deletes SA a from its SADB. The NAS also removes from the SPDB all policies associated with SA a. The NAS from a message directing the client to remove SAs a and b. Msg8. NAS-->C: Delete(a,b) After the message is sent, the NAS removes SA b from its SABD as well as all associated policies from its SPDB. Upon receipt of a message of the form Msg8, the client removes the SA a from its SADB. The client then removes all polices in the SPDB associated with SA a. Finally, the client removes SA b and all associated policies in the SPDB. Upon termination of this protocol, all references to the six SAs should be removes from the SADB and SPDB of each of the three participating nodes. Assertions and Invariants. -----------------------------