Design Principles for Gateway Discovery Protocols - Illinois Security Lab

Design Principles for Gateway Discovery Protocols Alwyn Goodloe University of Pennsylvania

Carl A. Gunter University of Illinois at Urbana-Champaign November 2006

Abstract: Security gateways limit access to parts of an internetwork to enforce policies for the flow of packets. The configuration of tunnels from hosts to gateways is typically done manually or based on information from static configuration files. Protocols to discover gateways and dynamically establish tunnels for enforcing policies are difficult to design because of the complex interactions between the policies on gateways, the protocols needed to discover them, and the setup needed to establish tunnels for efficient bulk communications. This paper describes a set of principles for gateways and tunnels that can be used to analyze design trade-offs for discovery protocols. These principles include authenticated traversal (for both ingress and egress from a domain), origin authentication, gateway recognition, and policy centralization. Policy centralization asserts that distributed policy along a route is equivalent to a centralized policy at the source. We provide a formal foundation for tunnels between security gateways that includes a system for reasoning about credentials and authorizations. This is used to analyze several specific discovery protocols with respect to the design principles. Our analysis shows that it is challenging to satisfy all of the principles at the same time, so trade-offs between desirable but conflicting goals must be made.

1 Introduction Security gateways are network elements that control ingress of packets into and egress of packets out of a protected domain to counter a number of threats. Some gateways authenticate and encrypt packets using tunnel protocols such as SSL, SSH, and IPsec. These tunnels provide efficiency and aid protections against intrusions into the protected domain (in which hosts in the domain are compromised) and extrusions (in which hosts in the domain are used to initiate attacks). Because of these benefits, tunnel gateways have become common, but their use is limited by the need of hosts to find them and configure the necessary tunnels to enable their packets to traverse them. A widespread case is the ‘road warrior’ scenario in which a traveling principal from a domain is able to gain access to his protected network through a gateway from the Internet using a protocol like IKE to establish an IPsec tunnel that will authenticate his packets as they ingress into the protected domain. A dual case commonly used in wireless configurations is to limit access from a wireless network to the Internet by forcing the authentication of packets at link or network layer as they egress from the wireless network into the Internet. The situation becomes more complicated when these types of protections involve multiple domains and combinations of ingress and egress protections. In the simple cases, gateways and tunnels are commonly handled with static configurations that are manually installed and assume advance knowledge of the topology of domains and gateways. However, this is problematic for more complex cases where a more dynamic approach would reduce burdens on configuration. 1

This raises the challenge of developing discovery protocols that are able to find gateways and configure tunnels for them. There have been research efforts to design such protocols for years, but none of the proposed protocols has been adequately analyzed or gained widespread acceptance. We aim to take steps to address short-comings in the design and analysis of discovery protocols by introducing a foundation for this analysis and applying it to a range of possible discovery protocol design strategies. This foundation has two parts. The first is a formalism called the tunnel calculus that can precisely describe tunnel processing, high-level and low-level policies, and protocols for tunnel establishment and discovery. Broadly speaking, the tunnel calculus is a formalization of an idealized form of the IPsec suite of protocols, organized as a collection of layers for forwarding, secure processing, and tunnel establishment. On top of this one can define layers for authorization/credentials and discovery. The second part of our foundation is a collection of design principles for gateways and tunnels. We consider four such principles: authenticated traversal, origin authentication, gateway recognition, and policy centralization. The focus of this paper is on these principles, their formalization in the tunnel calculus, and how they constrain the design of discovery protocols meant to satisfy them. We rely on detailed treatments elsewhere of: the tunnel calculus itself and its use in describing discovery protocols [7], the relation of the tunnel calculus to IKE/IPsec and other efforts to design discovery protocols [11], functional challenges arising in such protocols due to concurrency [10], formal automation [8], and implementing applications [9]. These topics are summarized briefly on a call-by-need basis to keep this paper reasonably self-contained. Aside from developing principles for a foundation capable of analyzing discovery protocols, the main contribution of the current work is to use these principles to analyze a range of specific protocols. The main design trade-off is between authenticated traversal, in which each packet that passes a gateway is authenticated (either ingress, egress or both), and origin authentication, in which each packet is authenticated through a tunnel to its origin. The latter condition leads to well-visited but not well-understood problems with nested tunnels, which are tunnels that encapsulate other tunnels. The tunnel calculus handles nested tunnels with a clear semantics, but their security properties are difficult to analyze. We define and analyze a concatenated discovery protocol that sets up a chain of non-nested tunnels between the gateways that lie between source and destination hosts. This protocol is shown to satisfy authenticated traversal and policy centralization. The latter property asserts that satisfying the policies of the gateways along the route as part of the discovery protocol is equivalent to satisfying all of these policies after they are centralized at the source. Suitable enhancements also enable this protocol to assure the recognized gateways principle, which says that tunnels are used only between gateways that are trusted by the source. However, the concatenated tunnels protocol does not satisfy origin authentication and achieving this entails trade-offs with respect to complexity of the protocol and conditions such as whether the authenticated traversal should be restricted to only ingress traffic. We define and analyze a nested discovery protocol in terms of origin authentication at certain gateways and the other principles. The paper is organized into eight sections. The second section covers some background on tunnels, the threats they address, and discovery protocols. The third section sketches the tunnel calculus and the fourth section describes an associated authorization layer in detail. The principles are described formally in terms of the tunnel calculus in section five; these are used to analyze protocols for concatenated and nested tunnel discovery protocols in sections six and seven respectively. The eighth section summarizes conclusions.

2

2 Background Two broad categories of security gateways are firewalls, which authorize traffic based on the shape of the packets they receive, typically without authenticating the sender, and Virtual Private Network (VPN) gateways, which authorize traffic based on cryptographic authentication, and often also provide encryption. Gateways may also provide a mixture of these types of services. For example, it is common to let most types of packets egress from a protected domain without authenticating them, but to authenticate all packets that ingress into the domain. However, there are also gateways, especially for wireless domains, that authenticate all packets that egress from the domain but allow many types of unauthenticated packets to ingress into it. Whatever approach is taken, efficiency and security require that the sender and gateway establish some shared state so they have complementary policies and cryptographic parameters. This shared state enables the nodes to ‘dig a secure tunnel’ through an insecure communication network. In this section we review, at a high level, the basics about the existing technologies for tunnels, the threats that tunnels and gateways are meant to address, and the challenge of gateway discovery protocols.

2.1 Tunnels Security tunnel protocols are used extensively on the Internet. SSL/TLS [4] is a transport layer tunnel protocol that is ubiquitously used for web security and electronic commerce. Secure Shell (SSH) [17] is widely used as a secure remote login for Unix systems. Perhaps the most interesting and ambitious tunnel protocol is IPsec [14], which was designed by IETF to provide network layer tunnels and is projected to be a fundamental part of IPv6, the next generation of the Internet Protocol (IP). IPsec security associations perform cryptographic transformations to each IP packet flowing in the association and are defined in the Security Association Database (SAD). The mechanisms (low-level policies) that determine which SAs are used with which messages are held in an SP Database (SPD). IPsec establishes tunnels using the Internet Key Exchange (IKE) [13] protocol. This establishment is triggered by a mechanism that indicates that messages from a source to a destination must be in a tunnel: if no such tunnel currently exists, a run of IKE creates a pair of associations between the two nodes and enters them in the SAD. Our work here is based on a formalization of tunnels using the tunnel calculus, so let us review some of the work that has been done on formal analysis of IPsec. Meadows [15, 16] used the NRL protocol analyzer to analyze IKE. Abadi et. al. [1] use the π-calculus [2] to verify the Just Fast Keying (JFK) protocol [3], a protocol that informed the design of IKEv2. These formalizations are at a lower level than the tunnel calculus, which abstracts away from most cryptographic mechanisms such as session keys. Guttman et. al. [12] use an automata-based approach to model IPsec security association processing to prove confidentiality and authentication properties of IPsec tunnels. Neither this work or the others discuss discovery protocols or provide any detailed treatment of the principles involved in their design.

2.2 Threats To illustrate how the threats that gateways can address and the ways they are achitected, consider the situation illustrated in Figure 1. Alice works for ACME Inc. and is located in the domain of the gateway GW1 that protects ACME’s network. She often communicates directly with a server Bob in Coyote accounting domain. The Coyote network is protected by gateway GW2. The machines belonging to Coyote accounting 3

department possess sensitive information about ACME and should not be accessed by Coyote employees located outside of the accounting domain without authenticating through the gateway GW3. Because of her location at ACME, Alice must traverse gateways GW1, GW2, and GW3 in order to gain access to the data she needs. A simple scenario allows Alice to establish an IPsec tunnel to GW3 using a credential that proves her right to talk with Bob in the accounting domain at Coyote. This can be accomplished by allowing IPsec packets between Alice and GW3 to pass without authentication through GW1 and GW2. GW3 confirms that packets entering the accounting domain from Alice in this tunnel are addressed to Bob. This configuration is designed to address intruACME Inc. Accounting sions into the Coyote accounting domain by authenticating and authorizing each packet from each GW1 Alice GW2 GW3 Bob party that wishes to communicate with nodes in that Coyote Co. domain. In general we say that a gateway satisfies ingress authenticated traversal if it authentiFigure 1: Gateway Configuration cates each packet that enters its domain as GW3 does in this example. Suppose now that ACME is concerned about parties that move data out of their domain. This may occur because of concerns about exfiltration, where critical data about ACME is delivered by an insider to outsiders over the network, or concern about extrusions executed by nodes in the ACME domain. To address this, ACME may require nodes to authenticate to GW1 when making connections to nodes outside of the domain. This is an increasingly common practice in sectors where privacy leaks are serious, such as law firms, accounting firms, and medical institutions. It is also a common practice for enterprise wireless networks. We say that a gateway satisfies egress authenticated traversal if it authenticates each packet that exists its domain, as GW1 does in this example. Another type of tunnel configuration occurs when GW1 takes charge of encrypting the packets from Alice as they leave the ACME domain by establishing a tunnel from GW1 to one of the nodes in the Coyote domain such as GW2. This is known as an ‘involuntary’ tunnel because Alice gets it whether she wants it or not based on a policy of the ACME domain. In this case, packets from Alice that enter the Coyote domain authenticated by a key from GW1 rather than Alice. When, by contrast, the packets from Alice are in a tunnel that ends with Alice we say that the gateway traversal satisfies origin authentication. A common example is a tunnel that stretches from Alice to Bob allowing authentication and encryption end-to-end even in the presence of one or more involuntary tunnels along the path. Origin authentication limits dependence on gateways.

2.3 Discovery Protocols Continuing our example from Figure 1, suppose that Alice is part of a coalition of enterprises that share information from servers located in protected domains such as the Coyote accounting domain. This coalition may change over time, and members may have different gateway configurations and different policies about authenticated traversal and origin authentication. How can Alice set up the tunnels needed to do her communication? It is awkward to assume that there will be global knowledge of coalition members, their gateway topologies, and their policies. This information would need to be regularly updated on all clients in the coalition. This might be feasible in some circumstances, perhaps using a globally shared coalition policy repository, but a potentially more attractive option is to allow clients to find the relevant gateways 4

and their policies and set up the necessary tunnels using a dynamic discovery protocol. This could be a kind of signalling protocol similar perhaps to RSVP or traceroute, where a discovery packet is sent toward the destination and is intercepted by the intermediate gateways, which reveal their policies and participate in organizing the tunnels they require. This idea has been explored in various contexts such as the IETF IPSP working group and there is even a protocol from Cisco called Tunnel Endpoint Discovery (TED) [6] which can do this in a limited case (ingress authenticated traversal for one gateway). However, the problem is challenging and there are no widely accepted solutions. There is not sufficient space here to provide an extended treatment of the full state of the art, but at least two principles seem noteworthy and these, along with authenticated traversal and origin authentication, are our focus in this paper. First, if one wishes to avoid a centralized solution, then there is an impetus to work with a decentralized credential and policy system and let the discovery protocol find the policies and pass around the necessary credentials dynamically based on the communication path. Ideally the protocol can do this so that the results are no different form the case in which the policies are held in a central location. We call this equivalence policy centralization. Second, if one is concerned that the communication path may contain bogus gateways, then clients need to provide rules about the gateways they are willing to use, and trusted gateways need to take delegated responsibility for enforcing these rules if they participate in setting up involuntary tunnels. This principle is called gateway recognition.

3 Tunnel Calculus This section contains a brief overview of the tunnel calculus; a more detailed presentation can be found in [7]. The tunnel calculus is structured in layers that form set a of primitives that are composed to form discovery protocols. Each layer is intended to abstractly model a layer or module of the network stack. The lowest layer is the forwarding layer that models the movement of packets. The secure processing layer models the processing associated with secure tunnels. The establishment layer models the actions of a protocol that sets up a pair of security associations. The remainder of this section is devoted to providing an overview of these layers. A fourth layer, the authorization layer, is discussed in the next section. A packet having source address a, destination address b, containing message y, and located at node c is modeled as a term P(a, b, y) @ c. Each node in the system is presumed to maintain a forwarding table that is modeled as a partial function from the destination address to the address of the next hop on the path. When processing an outbound packet, the forwarding layer looks up the next hop in the forwarding table and rewrites the packet to that node. For instance, if the forwarding table at node c had the entry b 7→ d, then P(a, b, y) @ c is rewritten to P(a, b, y) @ d. A packet arriving at a node is passed up for processing by the secure processing layer. A security association is modeled by an S constructor. The constructor is applied to each packet entering the association and a destructor removes the constructor at the other end of the tunnel. We do not model the cryptographic transforms performed by a security association, but instead assume that any term encapsulated in an S constructor has undergone such a transformation. An association is identified by its security parameter index (SPI).To avoid interference among different sessions of a discovery protocol we introduce a syntactic class called a session identifier that uniquely identifies a complex of tunnels set up during the execution of a discovery protocol [10]. The session identifier is similar to a SPI, but rather than identifying a single association it identifies a complex of tunnels established during the session bearing that session iden5

tifier. Associations are assumed to act in IPsec ‘tunnel mode’, meaning that a packet entering the association has the S constructor applied and becomes the payload of a packet traveling from the association’s source to its endpoint. For example, suppose packet P(a, b, y) in session u is to be placed in an association flowing from c to d identified by the SPI ι. The constructor is applied and the result is encapsulated in a packet represented by the term P(c, d, S(u, ι, P(a, b, y))). The main objective of the tunnel calculus is to model the state of the databases of the associations and mechanisms held at secure processing nodes. The association database maintains a set of constructors and destructors defining the associations active at a node. The outbound mechanism database is used to direct traffic into the correct association. The inbound mechanism database is used to verify that traffic arrived in the correct association. A mechanism database entry is a packet filter, a session identifier, and a bundle of association constructors or destructors that are applied to traffic matching the session identifier and packet filter. Secure layer processing works as follows. When a packet is sent to the secure processing layer for outbound processing, the outbound mechanism database is consulted and returns the bundle of associations matching the packet filter and session identifier. The constructor for each association in the bundle is applied to the packet and the result is sent down to the forwarding layer to move the packet to the end of the outermost encapsulating association. When the packet arrives at the other end of the tunnel, it is passed up to the secure processing layer, which first applies the destructors for the associations terminating at that node. The inbound mechanism database is consulted to confirm that the packet arrived in the expected associations. At this point, processing depends on the shape of the decapsulated packet. There are distinguished packets such as discovery and establishment packets that are passed up for processing by higher layers. Other packets that are arriving at their destinations are also passed up for processing. Otherwise, the secure layer outbound processing is invoked to send the packet on toward its destination. The establishment layer defines a protocol that sets up a pair of unidirectional security associations between two participating nodes and installs entries in the association and mechanism databases that define the state of the resulting tunnel. Tunnel establishment is modeled using two messages that contain credentials for authorization, the SPI values identifying the associations, and filter entries for the mechanism database entry. It is assumed that this layer was invoked by a discovery protocol at a newly discovered node a. Establishment is directed to set up a pair of associations with responder b, for session u where the packet filter values are s and d. The tunnel establishment protocol works as follows. The establishment initiator a checks to see if there is an existing association flowing from b to a. If so, the association is reused; otherwise, it generates a SPI ιa to identify the association flowing from the responder to the initiator. The initiator then forms an establishment request message Req(s, d, u, ι a , Ξa , g), where Ξa is a set of credentials identifying the administrative entities to which initiator belongs, and g is a signature of the initiator a. Upon receiving a message of this form, the responder b checks the signature and calls the authorization layer to verify that the newly-discovered gateway belongs to an entity that the protocol considers acceptable. If so, the responder generates checks to see if there is an existing association flowing from the initiator to the responder. If so, the association is reused; otherwise, the protocol generates the SPI ι b to identify the association flowing from a to b. Entries are then made in the association and inbound mechanism databases for this association. The responder then forms an establishment response message Rep(s, d, u, ι a , ιb , CredhKa , Kb , g 0 i∪Ξu , g 00 ), where Ξu is a set of credentials presented to each gateway on the dataflow path that prove that the protocol has permission to set up the tunnel and g 0 and g 00 are signatures from the responder. Once the establishment 6

Table 1: Syntax for Authorization Layer Address Key Sig Pattern Selector Policy Policies Disc Policies Credential Credentials

g

∈ ∈ ∈

ω η θ Θ φ ξ Ξ

::= ::= ::= ::= ::= ::= ::=

a K, K −1

Addr Key Sig a|∗ ω 7→ ω | ω ↔ ω Polh∗ : ηi | PolhK1 , . . . , Kn : ηi Pols[θ, . . . , θ] AdminhK | K1 , . . . , Kn | gi CredhK, K, gi Creds{ξ : ξ, . . . , ξ} a | Creds{ξ, . . . , ξ}u

response message has been sent, the responder adds entries in the association and outbound mechanism database for the association flowing from the responder to the initiator. Upon receiving the establishment response message, the initiator a checks the signature and calls the authorization layer to verify that the gateway will allow the traffic flow. If so, entries for the two associations are added to the association and mechanism databases. The session identifier is the most significant difference between the tunnel calculus and IPsec. It is needed to ensure good functional behavior of the negotiation protocols when authenticated traversal is required, viz. prevention of deadlocks. This topic is discussed in detail in [10] while [11] discusses the relationship between the tunnel calculus and IPsec more broadly. Versions of the algorithms and results on discovery protocols in this paper will also hold for a restricted version of the tunnel calculus that omits the session identifiers essentially models a core portion of IPsec. At a high level the tunneling protocol could be SSL/TLS, or SSH, or something else, and the underlying issues will remain the same.

4 Authorization Recall from the previous section that the two establishment messages carry credentials that must satisfy policies governing gateway discovery and traversal. In this section, we give a precise definition of policies and credentials as well as what it means for a credential set to satisfy a policy. Collectively these definitions determine the tunnel calculus authorization layer. The resulting calculus is similar to SPKI/SDSI [5] in content and objective, but is simplified and specialized to this application to make its description self-contained. The syntax is given in Table 1. The basic types are addresses, keys, and signatures. Address types may be either an individual address or a range of addresses. A naming system similar to the one in SPKI/SDSI could be used to avoid explicit mention of address ranges by binding them to domain names. However, it is essential for policies to be expressed in terms of address ranges ultimately since a packet encrypted from end-to-end shows little else on which policy could be based. A gateway policy θ specifies that a list of principals K 1 , . . . , Kn that may communicate between the 7

address given in the selector η. Policies can restrict communication to be bidirectional a ↔ b or unidirectional a 7→ b. For instance, a policy at a gateway may say that Alice represented as principal K A is allowed to communicate between the address a 1 and an address a2 . This is formalized as PolhKA : a1 ↔ a2 i. A more liberal policy may state that any principal can communicate between these same address ranges, and would be written as Polh∗ : a1 ↔ a2 i. Each gateway maintains a list of policies Θ = Pols[θ 1 , . . . , θn ] that it enforces. For simplicity, we assume that the policies at each gateway have disjoint traffic selectors. Hence, there is at most one policy at a gateway for a given traffic flow. We write Θ η @ a to denote the policy at node a that matches the selector η. Gateway discovery poses the quandary of whether a newly-discovered self-proclaimed gateway should be trusted. To counter the threat of rouge gateways, our discovery protocols verify that a newly discovered gateway is trusted to continue executing the protocol by checking a list of administrative entities trusted by the protocol. These entities are defined by the discovery policy maintained at each host. A discovery policy φ says that principal K is willing to communicate with principals K 1 , . . . , Kn . This is formalized as AdminhK | K1 , . . . , Kn | gK −1 i, where g is a signature. The discovery policy at node a is often denoted φa . A fuller authorization system would allow this to be something more general than a list, which may be inadequate for cases where the trusted gateways would be inferred from a delegation chain, general attributes, or a similar technique, but we choose to avoid that complexity here. Credentials specify a relationship between two principals or delegate authority from one principal to another. For instance, Alice may have a credential that says she belongs to Acme Inc. A signed credential ξ = CredhKS , KI , gK −1 i defines a relation such as: KI ‘delegates’ to KS , or KS ‘is a member of’ KI , or I KS ‘speaks for’ KI . Principal KI is called the issuer and KS the subject. Given a credential that says K S speaks for KI we often write KS ⇒ KI . The credential set for node a is denoted Ξ a . The credential set presented to gateways during an execution of discovery protocol session u is denoted Ξ u . Given a credential set defining Kn ⇒ Kn−1 , Kn−1 ⇒ Kn−2 , Kn−2 ⇒ Kn−3 , Kn−3 ⇒ Kn−4 , . . ., K3 ⇒ K2 ⇒ K1 , K3 ⇒ Km , and K2 ⇒ Km0 , one can from a tree Ξ ` Kn ⇒ Kn−1 ⇒ Kn−2 ⇒ · · · ⇒

⇒ Km K 3 ⇒ K2 ⇒ K1 . ⇒ K m0

The credential tree formed from the credential set Ξ is denoted T (Ξ). Given T (Ξ), a chain is defined as a path from the root of the tree to a leaf. From this we define a satisfaction relation that specifies what it means for a credential set to satisfy a given policy. The case of discovery policies and gateway polices are considered separately. The objective of gateway policy satisfaction is to ensure that a given credential set contains a key listed in the policy. For instance, if the policy at a gateway says K M is allowed to traverse the gateway and Alice produces the credential K A ⇒ KM saying she belongs to principal M , then the policy is satisfied and the gateway allows the requested traversal. We also need to specify that the policy is satisfied by the credentials deriving from a particular principal. Given a policy θ and a credential set Ξ u , we form the tree T (Ξ). We then verify there is a key on a chain matching one in the policy list. In order to specify that the credentials were from a specific host A or derived from those credentials, we say that the key must be on a subchain rooted at KA . This is formalized as follows. Given a set of policies Θ η @ c and a credential set Ξu @ d, we define satisfaction Ξu @ c |=Ka Θη @ d 8

as follows: for every PolhK1 , . . . , Kn : ηi ∈ Θη there exists a chain in T (Ξu ) rooted at Kc containing a subchain rooted at KA that contains one of the keys in {K1 , . . . , Kn }. The satisfaction relation for discovery policies is defined in a similar manor. Given a discovery policy φ b = AdminhKI | K1 , . . . , Kn | gK −1 i and I

a set of credentials Ξb , we define satisfaction Ξa |= φb as follows: T (Ξa ) is a tree rooted at Ka that contains a chain that contains one of the keys in {K 1 , . . . , Kn }.

5 Design Principles In this section, we express the policy and protocol design principles introduced in Section 2. The principles can be expressed formally in terms of the tunnel calculus and those formal expressions are needed for full proofs of the properties in the next two sections, but the results are somewhat technical so those details have not been given here. We have already discussed the threat raised by an attacker placing a gateway on the dataflow path. If the end-to-traffic is encrypted, there remains the threat of an attacker monitoring traffic flow. In addition, organizations increasingly want to monitor the content of the network traffic that enters and leaves their organization and therefore insist that the encrypted tunnel end somewhere short of the end user. In this case, an attacker within an organization may be able to place a malicious gateway on the path that can obtain clear text. Discovery policies are intended to thwart these attacks and the gateway recognition principle says that a discovery protocol should enforce these polices. Design Principle 1 (Gateway Recognition) Each gateway encountered during the execution of a discovery protocol must present credentials that prove it satisfies the discovery policy at the host that initiated the protocol. If a gateway on the path is unable to do this, then the discovery session is terminated. Gateways can prevent many intrusion attacks by authenticating and authorizing each packet that they allow into their protected domain. Similarly, gateways can address extrusion attacks that result from an insider communicating with an unauthorized party located outside their administrative domain by authenticating and authorizing egress traffic. This argument provides the motivation for the ingress and egress authenticated traversal properties. These two principles constrain the gateway policy, the tunnel configuration, and the discovery protocols that set up the tunnels in order to obtain a more secure network. Before giving a definition of these properties, let us illustrate with our example what we mean when we say a packet is authorized for traversal. Consider the case of the the example illustrated in Figure 1. If Alice initiates discovery to Bob, then the protocol will discover and present credentials from Alice to each of the gateways in order to gain authorization to egress GW1 and ingress GW2 and GW3. This suffices if traffic were only flowing from Alice to Bob, but what about the return traffic? It too must be authorized and authenticated to egress GW2 and GW3 and to ingress GW1. Typically the return traffic is only authorized if the upstream nodes can present credentials satisfying a gateway’s discovery policy. So this means that traffic flow from Bob to Alice must prove that it can satisfy the protocol’s discovery policy in order to egress gateways GW2 and GW3 and to ingress GW1. The ingress and egress authenticated traversal properties are defined as follows. Design Principle 2 (Ingress Authenticated Traversal) All packets flowing from outside to inside a gateway’s administrative domain are authenticated and authorized as satisfying either the policy at the gateway governing the requested traffic flow or the discovery policy for that protocol session. 9

Design Principle 3 (Egress Authenticated Traversal) All packets flowing from inside to outside a gateway’s administrative domain are authenticated and authorized as satisfying either the policy at the gateway governing the requested traffic flow or the discovery policy for that protocol session. In order to show that the authenticated traversal properties hold, one must verify that each packet traversing a gateway either arrives in a tunnel or is directly authenticated using the authorization layer. This must be demonstrated for both the discovery protocol and the resulting tunnel complex. As a general rule we would like to satisfy both the ingress and egress authenticated traversal principles; on the other hand, there are useful tunnel configurations where it may be deemed acceptable to relax one of the conditions. Our fourth design principle concerns the credentials needed to satisfy the policy at the gateways on the dataflow path. To understand it, note that a critical aim of a discovery protocol is to ensure that credentials are propagated to the necessary gateways. If this is done, then it is reasonable to expect the policies along the pathway to act like a kind of logical conjunction. In particular, if all of these policies were collected from their distributed locations and evaluated at the source node then this would succeed if, and only if, the discovery protocol receives all necessary authorizations. Here is a more precise statement of this principle. Design Principle 4 (Policy Centralization) Consider a discovery protocol that is initiated at node a 1 to communicate with node an with session identifier u. The nodes on the dataflow path between a 1 and an are b s↔d = S a2 , . . . , an−1 . Let Θ 1