`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`June 1998
`
`Volume 1, Number 1
`
`A Quarterly Technical Publication for
`Internet and Intranet Professionals
`
`F r o m T h e E d i t o r
`
`In This Issue
`
`From the Editor .......................1
`
`What Is a VPN?–Part I ............2
`
`SSL: Foundation for
`Web Security..........................20
`
`Call for Papers .......................30
`
`Book Reviews ........................31
`
`Fragments ..............................35
`
`To reserve your complimentary
`copy of the next issue of
`The Internet Protocol Journal,
`
`please complete and return the
`attached postage-paid card.
`
`Internet Protocol Journal (IPJ).
`
`The
`
`Welcome to the first edition of
`This publication is designed to bring you in-depth technical articles on
`current and emerging Internet and intranet technologies. We will
`publish technology tutorials, as well as case studies on all aspects of
`internetworking.
`
`Virtual Private Networks (VPNs).
`
`Our first article is a detailed look at
`Many organizations are turning to VPNs as a cost-effective way to
`implement enterprise networking, but the industry has not yet settled
`for a single approach, nor even a single definition of the VPN concept.
`The article by Paul Ferguson and Geoff Huston is in two parts. Part II
`will follow in our second issue, due out in September.
`
`When the Internet Protocol suite (TCP/IP) was first designed, security
`was not a major consideration. Indeed, the primary goal in the early
`days of networking was sharing of information among academics and
`researchers. Today, TCP/IP is being used for mission-critical appli-
`cations and for the emerging area of electronic commerce. As a result,
`security mechanisms are being added at all levels of the protocol stack.
`In this issue, we take a closer look at the
`
`Secure Sockets Layer (SSL),
`which is used for Web transactions. William Stallings explains how
`SSL works and how it is becoming the standard for Web security.
`
`If you want to learn about computer networks, many options are
`available, including conferences, journals, standards documents, Web
`
`Fragments page gives you
`sites, glossaries and, of course, books. Our
`some pointers for further reading, and every issue will include at least
`one book review.
`
`A detailed description of the scope of this journal can be found on page
`30 in our
`
`Call for Papers. We want your input in this new publication.
`.
`Please send comments, suggestions or questions to
`
`You may also use this address to request a complimentary copy of the
`next issue of IPJ. If you would like to write an article, send me e-mail
`and I will send you author guidelines.
`
`—Ole J. Jacobsen, Editor and Publisher
`
`
`Petitioner RPX Corporation - Ex. 1068, p. 1
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`What Is a VPN? — Part I
`by Paul Ferguson, Cisco Systems
`and Geoff Huston, Telstra
`
`T
`
`Virtual Private Network, has become
`
`he term “VPN,” or
`almost as recklessly used in the networking industry as has
`“QoS” (Quality of Service) to describe a broad set of problems
`and “solutions,” when the objectives themselves have not been
`properly articulated. This confusion has resulted in a situation where
`the popular trade press, industry pundits, and vendors and consumers
`of networking technologies alike generally use the term VPN as an
`offhand reference for a set of different technologies. This article
`provides a common-sense definition of a VPN, and an overview of
`different approaches to building one.
`
`“The wonderful thing about virtual private networks is that its myriad
`definitions give every company a fair chance to claim that its existing
`product is actually a VPN. But no matter what definition you
`choose, the networking buzz-phrase doesn’t make sense. The idea is
`to create a private network via tunneling and/or encryption over the
`public Internet. Sure, it’s a lot cheaper than using your own frame
`relay connections, but it works about as well as sticking cotton in
`your ears in Times Square and pretending nobody else is around.”
`[1]
`
`A Common-Sense Definition
`As
`
`Wired Magazine notes in the quotation, the myriad definitions of a
`VPN are less than helpful in this environment. Accordingly, it makes
`sense to begin this examination of VPNs to see if it is possible to
`provide a common-sense definition of a VPN. Perhaps the simplest
`method of attempting to arrive at a definition for VPNs is to look at
`each word in the acronym individually, and then tie each of them
`together in a simple, common-sense, and meaningful fashion.
`
`Let’s start by examining the word “network.” This term is perhaps the
`least difficult one for us to define and understand, because the
`commonly accepted definition is fairly uncontroversial and generally
`accepted throughout the industry. A network consists of any number
`of devices that can communicate through some arbitrary method.
`Devices of this nature include computers, printers, routers, and so
`forth, and they may reside in geographically diverse locations. They
`may communicate in numerous ways because the electronic signaling
`specifications, and data-link, transport, and application-layer protocols
`are countless. For the purposes of simplicity, let’s say that a “network”
`is a collection of devices that can communicate in some fashion, and
`can successfully transmit and receive data among themselves.
`
`The term “private” is fairly straightforward, and is intricately related
`to the concept of “virtualization” insofar as VPNs are concerned, as
`we’ll discuss in a moment. In the simplest of definitions, “private”
`means communications between two (or more) devices is, in some
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`2
`
`Petitioner RPX Corporation - Ex. 1068, p. 2
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`fashion, secret—that the devices that are not participating in the
`“private” nature of communications are not privy to the com-
`municated content, and that they are indeed completely unaware of
`the private relationship altogether. Accordingly, data privacy and
`security (data integrity) are also important aspects of a VPN that need
`to be considered when implementing any particular VPN.
`
`Another means of expressing this definition of “private” is through its
`antonym, “public.” A “public” facility is one that is openly accessible,
`and is managed within the terms and constraints of a common public
`resource, often via a public administrative entity. By contrast, a
`private facility is one where access is restricted to a defined set of
`entities, and third parties cannot gain access. Typically, the private
`resource is managed by the entities who have exclusive right of access.
`Examples of this type of private network can be found in any
`organizational network that is not connected to the Internet, or to any
`other external organizational network, for that matter. These net-
`works are private because there is no external connectivity, and thus
`no external network communications.
`
`Another important aspect of privacy in a VPN is through its technical
`definition. For example, privacy in an addressing and routing system
`means that the addressing used within a VPN community of interest is
`separate and discrete from that of the underlying shared network, and
`from that of other VPN communities. The same holds true for the
`routing system used within the VPN and that of the underlying shared
`network. The routing and addressing scheme within a VPN should, in
`general, be self-contained, but this scenario degenerates into a
`philosophical discussion of the context of the term “VPN.” Also, it is
`worthwhile to examine the differences between the “peer” and
`“overlay” models of constructing VPNs—both of which are discussed
`in more detail later under the heading “Network-Layer VPNs.”
`
`“Virtual” is a concept that is slightly more complicated.
`The New
` defines
`
`Hacker’s Dictionary (formerly known as the Jargon File)
`[2]
`virtual as:
`
`virtual /adj./ [via the technical term “virtual memory,” prob. from
`the term “virtual image” in optics] 1. Common alternative to
`{logical}; often used to refer to the artificial objects (like addressable
`virtual memory larger than physical memory) simulated by a
`computer system as a convenient way to manage access to shared
`resources. 2. Simulated; performing the functions of something that
`isn’t really there. An imaginative child’s doll may be a virtual
`playmate. Oppose {real}.
`
`Insofar as VPNs are concerned, the second definition is perhaps the
`most appropriate comparison for virtual networks. The “virtual-
`ization” aspect is one that is similar to what we briefly described
`previously as private, but the scenario is slightly modified—the private
`communication is now conducted across a network infrastructure that
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`3
`
`Petitioner RPX Corporation - Ex. 1068, p. 3
`
`

`

`
`
`
`
`
`
`
`
`
`What Is a VPN? — Part I:
`continued
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`4
`
`is shared by more than a single organization. Thus, the private
`resource is actually constructed by using the foundation of a logical
`partitioning of some underlying common, shared resource rather than
`by using a foundation of discrete and dedicated physical circuits and
`communications services. Accordingly, the private network has no
`corresponding private physical communications system. Instead, the
`private network is a virtual creation that has no physical counterpart.
`
`The virtual communications between two (or more) devices is because
`the devices that are not participating in the virtual communications are
`not privy to the content of the data, and they are also altogether
`unaware of the private relationships between the virtual peers. The
`shared network infrastructure could, for example, be the global
`Internet and the number of organizations or other users not
`participating in the virtual network may literally number into the
`thousands or even millions.
`
`A VPN can also said to be a discrete network
`
`:
`[3]
`
`(discrete \dis*crete"\, a. [L. discretus, p.p. of discernere. See Discreet.]
`1. Separate; distinct; disjunct).
`
`The discrete nature of VPNs allows both privacy and virtualization.
`Although VPNs are not completely separate, intrinsically, the distinc-
`tion is that they operate in a discrete fashion across a shared
`infrastructure, providing exclusive communications environments that
`do not share any points of interconnection.
`
`The combination of these terms produces VPN—a private network,
`where the privacy is introduced by some method of virtualization. A
`VPN could be built between two end systems or between two
`organizations, between several end systems within a single organi-
`zation or between multiple organizations across the global Internet,
`between individual applications, or any combination.
`
`It should be noted that there is really no such thing as a nonvirtual
`network, if the underlying common public transmission systems and
`other similar public infrastructure components are considered to be
`the base level of carriage of the network. What separates a VPN from
`a truly private network is whether the data transits a shared versus a
`nonshared infrastructure. For instance, an organization could lease
`private line circuits from various telecommunications providers and
`build a private network on the base of these private circuit leases, but
`the circuit-switched network owned and operated by the tele-
`communications companies are actually circuits connected to their
` (DACSs) network and sub-
`Digital Access and Crossconnect Systems
`sequently their fiber-optics infrastructure. This infrastructure is shared
`by any number of organizations through the use of multiplexing
`technologies. Unless an organization is actually deploying private fiber
`and layered transmission systems, any network is layered with
`“virtualized” connectivity services in this fashion.
`
`Petitioner RPX Corporation - Ex. 1068, p. 4
`
`

`

`
`
`
`
`
`
`
`A VPN doesn’t necessarily mean communications isolation, but rather
`the controlled segmentation of communications for communities of
`interest across a shared infrastructure.
`
`The common and somewhat formal characterization of the VPN, and
`perhaps the most straightforward and strict definition, follows:
`
`A VPN is a communications environment in which access is
`controlled to permit peer connections only within a defined com-
`munity of interest, and is constructed though some form of
`partitioning of a common underlying communications medium,
`where this underlying communications medium provides services
`to the network on a nonexclusive basis.
`
`A simpler, more approximate, and much less formal description follows:
`
`A VPN is private network constructed within a public network
`infrastructure, such as the global Internet.
`
`It should also be noted that although VPNs may be constructed to
`address any number of specific business needs or technical require-
`ments, a comprehensive VPN solution provides support for dial-in
`access, support for multiple remote sites connected by leased lines (or
`other dedicated means), the ability of the VPN service provider (SP) to
`“host” various services for the VPN customers (for example, Web
`hosting), and the ability to support not just intra-, but also inter-VPN
`connectivity, including connectivity to the global Internet.
`
`VPN Motivations
`There are several motivations for building VPNs, but a common
`thread is that they all share the requirement to “virtualize” some
`portion of an organization’s communications—in other words, make
`some portion (or perhaps all) the communications essentially “invi-
`sible” to external observers, while taking advantage of the efficiencies
`of a common communications infrastructure.
`
`The base motivation for VPNs lies in the economics of com-
`munications. Communications systems today typically exhibit the
`characteristic of a high fixed-cost component, and smaller variable-
`cost components that vary with the transport capacity, or bandwidth,
`of the system. Within this economic environment, it is generally
`financially attractive to bundle numerous discrete communications
`services onto a common, high-capacity communications platform,
`allowing the high fixed-cost components associated with the platform
`to be amortized over a larger number of clients. Accordingly, a
`collection of virtual networks implemented on a single common
`physical communications plant is cheaper to operate than the
`equivalent collection of smaller, physically discrete communications
`plants, each servicing a single network client.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`5
`
`Petitioner RPX Corporation - Ex. 1068, p. 5
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`What Is a VPN? — Part I:
`continued
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`6
`
`Therefore, if aggregation of communications requirements leads to a
`more cost-effective communications infrastructure, why not pool all
`these services into a single public communications system? Why is there
`still the requirement to undertake some form of partitioning within this
`common system that results in these “virtual private” networks?
`
`In response to this question, the second motivation for VPNs is that of
`communications privacy, where the characteristics and integrity of com-
`munications services within one closed environment is isolated from all
`other environments that share the common underlying plant. The level
`of privacy depends greatly on the risk assessment performed by the
`subscriber organization—if the requirement for privacy is low, then the
`simple abstraction of discretion and network obscurity may serve the
`purpose. However, if the requirement for privacy is high, then there is a
`corresponding requirement for strong security of access and potentially
`strong security applied to data passed over the common network.
`
`History
`This article cannot do justice to the concept of VPNs without some
`historical perspective, so we need to look at why VPNs are an
`evolving paradigm, and why they will continue to be an issue of con-
`fusion, contention, and disagreement. This examination is important
`because opinions on VPN solutions are quite varied, as well as how
`they should be approached.
`
`Historically, one of the precursors to the VPN was the
`Public Data
` (PDN), and the current familiar instance of the PDN is the
`Network
`global Internet. The Internet creates a ubiquitous connectivity para-
`digm, where the network permits any connected network entity to
`exchange data with any other connected entity. The parallels with the
`global
` (PSTN) are, of course, all
`Public Switched Telephone Network
`too obvious—where a similar paradigm of ubiquitous public access is
`the predominate characteristic of the network.
`
`The Public Data Network has no inherent policy of traffic segregation,
`and any modification to this network policy of permitting ubiquitous
`connectivity is the responsibility of the connecting entity to define and
`enforce. The network environment is constructed using a single
`addressing scheme and a common routing hierarchy, which allows the
`switching elements of the network to determine the location of all
`connected entities. All these connected entities also share access to a
`common infrastructure of circuits and switching.
`
`However, the model of ubiquity in the “Internet PDN” does not match
`all potential requirements, especially the need for data privacy. For
`organizations that wish to use this public network for private purposes
`within a closed set of participants (for example, connecting a set of
`geographically separated offices), the Internet is not always a palatable
`possibility. Numerous factors are behind this mismatch, including
`issues of Quality of Service (QoS), availability and reliability, use of
`
`Petitioner RPX Corporation - Ex. 1068, p. 6
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`public addressing schemes, use of public protocols, site security, and
`data privacy and integrity (the possibility of traffic interception).
`Additionally, a corporate network application may desire more strin-
`gent levels of performance management than are available within the
`public Internet, or indeed may wish to define a management regime
`that differs from that of the underlying Internet PDN.
`
`Service-Level Agreements
`It is worthwhile at this point to briefly examine the importance of
`
`Service-Level Agreements (SLAs) in regards to the deployment of
`VPNs. SLAs are negotiated contracts between VPN providers and
`their subscribers; they contain the service criteria to which the
`subscriber expects specific services to be delivered. The SLA is argu-
`ably the only binding tool at the subscriber’s disposal with which to
`ensure that the VPN provider delivers the service(s) to the level and
`quality as agreed, and it is in the best interest of the subscribers to
`monitor the criteria outlined in the SLA for compliance. However,
`SLAs present some challenging technical issues for both the provider
`and the subscriber.
`
`For the subscriber, the challenge is to devise and operate service
`measurement tools that can provide a reasonable indication as to what
`extent the SLA is being honored by the provider. Also, it should be
`noted that a subscriber may use an SLA to bind one or more providers
`to a contractual service level, but if the subscriber’s VPN spans
`multiple providers’ domains, the SLA must also encompass the issue of
`provider interconnection and the end-to-end service performance.
`
`For the provider, the challenge lies in honoring multiple SLAs from a
`number of service providers. In the case of an Internet PDN provider,
`the common mode of best-effort service levels is not conducive to
`meeting SLAs, given the unpredictable nature of the host’s resource
`allocation mechanisms. In such environments, the provider either has
`to ensure that the network is generously engineered in terms of the
`ratio of subscriber access capacity to internal switching capacity, or
`the provider can deploy service differentiation structures to ensure
`that minimum resource levels are allocated to each SLA subscriber. It
`must be noted that the former course of action does tend to reduce the
`benefit of aggregation of traffic, which in turn has an ultimate cost
`implication, while the latter course of action has implications in terms
`of operational management complexity and scalability of the network.
`
`Alternatives to the VPN
`The alternative to using the Internet as a VPN today is to lease cir-
`cuits, or similar dedicated communications services, from the public
`network operators (the local telephone company in most cases), and
`create a completely private network. It is a layering convention that
`allows us to label this as “completely private,” because these dedi-
`cated communications services are (at the lower layers of the protocol
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`7
`
`Petitioner RPX Corporation - Ex. 1068, p. 7
`
`

`

`
`
`
`
`
`What Is a VPN? — Part I:
`continued
`
`
`
`
`
`stack) again instances of virtual private communications systems
`constructed atop a common transmission bearer system. Of course,
`this scenario is not without precedent, and it must be noted that most
`of the early efforts in data networking, and many of the current data
`networking architectures, do not assume a deployment model of
`ubiquitous public access.
`
`It is interesting to note that this situation is odd, when you consider
`that the inherent value of an architecture where ubiquitous public
`access over a chaotic collection of closed private networks had been
`conclusively demonstrated in the telephony marketplace since the start
`of the 20th century. Although the data communications industry
`appears to be moving at a considerable technological pace, the level of
`experiential learning, and consequent level of true progress as distinct
`from simple motion, still leaves much to be desired!
`
`Instead of a public infrastructure deployment, the deployment model
`used has been that of a closed (or private) network environment
`where the infrastructure, addressing scheme, management, and ser-
`vices were dedicated to a closed set of subscribers. This model
`matched that of a closed corporate environment, where the network
`was dedicated to serve a single corporate entity as the sole client. This
`precursor to the VPN, which could be called the private data network,
`was physically constructed using dedicated local office wiring and
`dedicated leased circuits (or private virtual circuits from an underlying
`switching fabric such as X.25) to connect geographically diverse sites.
`
`However, this alternative does have an associated cost, in that the
`client now has to manage the network and all its associated elements,
`invest capital in network switching infrastructure, hire trained staff,
`and assume complete responsibility for the provisioning and ongoing
`maintenance of the network service. Such a dedicated use of transport
`services, equipment, and staff is often difficult to justify for many
`small-to-medium sized organizations, and whereas the functionality of
`a private network system is required, the expressed desire is to reduce
`the cost of the service through the use of shared transport services,
`equipment, and management. Numerous scenarios can address this
`need, ranging from outsourcing the management of the switching
`elements of the network (managed network services), to outsourcing
`the capital equipment components (leased network services), to
`outsourcing the management, equipment, and transport elements to a
`service provider altogether.
`
`An Example VPN
`In the simple example illustrated in Figure 1, Network “A” sites have
`established a VPN (depicted by the dashed lines) across the service
`provider’s backbone network, where Network “B” is completely un-
`aware of its existence. Both Networks “A” and “B” can harmoniously
`coexist on the same backbone infrastructure.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`8
`
`Petitioner RPX Corporation - Ex. 1068, p. 8
`
`

`

`BA
`
`A
`
`BA
`
`BA
`
`B B
`
`
`
`
`
`
`
`Figure 1:
`A Virtual Private
`Network of
`“A” Sites
`
`A
`Network A
`
`B
`Network B
`
`VPN A
`
`Service Provider
`Backbone Router
`
`This type of VPN is, in fact, the most common type of VPN—one that
`has geographically diverse subnetworks that belong to a common ad-
`ministrative domain, interconnected by a shared infrastructure outside
`their administrative control (such as the global Internet or a single
`service provider backbone). The principal motivation in establishing a
`VPN of this type is that perhaps most of the communications between
`devices within the VPN community may be sensitive (again, a decision
`on the level of privacy required rests solely on a risk analysis per-
`formed by the administrators of the VPN), yet the total value of the
`communications system does not justify the investment in a fully pri-
`vate communications system that uses discrete transmission elements.
`
`On a related note, the level of privacy that a VPN may enjoy depends
`greatly on the technology used to construct the VPN. For example, if
`the communications between each VPN subnetwork (or between each
`VPN host) is securely encrypted as it transits the common com-
`munications infrastructure, then it can be said that the privacy aspect
`of the VPN is relatively high.
`
`In fact, the granularity of a VPN implementation can be broken down
`further to a single end-to-end, one-to-one connectivity scenario.
`Examples of these types of one-to-one VPNs are single dialup users
`who establish a VPN connection to a secure application, such as an
`online banking service, or a single user establishing a secure, encrypted
`session between a desktop and server application, such as a pur-
`chasing transaction conducted on the World Wide Web. This type of
`one-to-one VPN is becoming more and more prevalent as secure
`electronic commerce applications become more mature and are
`further deployed in the Internet. (See article starting on page 20.)
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`9
`
`Petitioner RPX Corporation - Ex. 1068, p. 9
`
`

`

`
`
`What Is a VPN? — Part I:
`continued
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`It is interesting to note that the concept of virtualization in networking
`has also been considered in regard to deploying both research and
`production services on a common infrastructure. The challenge in the
`research and education community is one in which there is a need to
`satisfy both network research and production requirements. VPNs
`have also been considered as a method to segregate traffic in a
`network such that research and production traffic behave as “ships in
`the night,” oblivious to one another’s existence, to the point that
`major events (for example, major failures, instability) within one
`community of interest are completely transparent to the other. This
`.
`concept is further documented in MORPHnet
`[4]
`
`It should also be noted that VPNs may be constructed to span more
`than one host communications network, so that the “state” of the
`VPN may be supported on one or more VPN provider networks. This
`scenario is perhaps at its most robust when all the providers explicitly
`support the resultant distributed VPN environment, but other
`solutions that do not necessarily involve knowledge of the overlay
`VPN are occasionally deployed with mixed results.
`
`Types of VPNs
`The confusion factor comes into play in the most basic discussions
`regarding VPNs, principally because there are actually several
`different types of VPNs, and depending on the functional require-
`ments, several different methods of constructing each type of VPN are
`available. The process of selection should include consideration of
`what problem is being solved, risk analysis of the security provided by
`a particular implementation, issues of scale in growing the size of the
`VPN, and the complexity involved in implementation of the VPN, as
`well as ongoing maintenance and troubleshooting.
`
`To simplify the description of the different types of VPNs, they are
`broken down in this article into categories that reside in the different
`layers of the TCP/IP protocol suite; Link Layer, Network Layer,
`Transport Layer, and Application Layer.
`
`Network-Layer VPNs
`The network layer in the TCP/IP protocol suite consists of the IP
`routing system—how reachability information is conveyed from one
`point in the network to another. There are a few methods to construct
`VPNs within the network layer—each is examined in the following
`paragraphs. A brief overview of non-IP VPNs is provided in Part II of
`this article.
`
`A brief overview of the differences in the “peer” and “overlay” VPN
`models is appropriate at this point. Simply put, the “peer” VPN model
`is one in which the network-layer forwarding path computation is
`done on a hop-by-hop basis, where each node in the intermediate data
`transit path is a peer with a next-hop node. Traditional routed net-
`works are examples of peer models, where each router in the network
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`1 0
`
`Petitioner RPX Corporation - Ex. 1068, p. 10
`
`

`

`
`
`
`
`
`
`
`path is a peer with its next-hop adjacencies. Alternatively, the
`“overlay” VPN model is one in which the network-layer forwarding
`path is not done on a hop-by-hop basis, but rather, the intermediate
`link-layer network is used as a “cut-through” to another edge node on
`the other side of a large cloud. Examples of “overlay” VPN models
`include ATM, Frame Relay, and tunneling implementations.
`
`Having drawn these simple distinctions between the peer and overlay
`models, it should be noted that the overlay model introduces some
`serious scaling concerns in cases where large numbers of egress peers
`are required because the number of adjacencies increases in direct
`proportion to the number of peers—the amount of computational and
`performance overhead required to maintain routing state, adjacency
`information, and other detailed packet forwarding and routing
`information for each peer becomes a liability in very large networks. If
`all the egress nodes in a cut-through network become peers in an effort
`to make all egress nodes one “Layer 3” hop away from one another,
`the scalability of the VPN overlay model is limited quite remarkably.
`
`For example, as the simple diagram (Figure 2) illustrates, the routers
`that surround the interior switched infrastructure represent egress
`peers, because the switches in the core interior could be configured
`such that all egress nodes are one Layer 3 hop away from one
`another, creating what is commonly known as a “cut-through.” This
`scenario forms the foundation of an overlay VPN model.
`
`Figure 2:
`A Cut-Through VPN
`
`Router
`(Egress Point)
`
`Switch
`(Cut-Through)
`
`Alternatively, if the switches in the interior are replaced with routers,
`then the routers positioned at the edge of the cloud become peers with
`their next-hop router nodes, not other egress nodes. This scenario
`forms the foundation of the peer VPN model.
`
`T h e I n t e r n e t P r o t o c o l J o u r n a l
`1 1
`
`Petitioner RPX Corporation - Ex. 1068, p. 11
`
`

`

`What Is a VPN? — Part I:
`continued
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Controlled Route Leaking
`route filtering) is a method that could
`
`“Controlled route leaking” (or
`also be called “privacy through obscurity” because it consists of
`nothing more than controlling route propagation to the point that
`only certain networks receive routes for other networks that are
`within their own community of interest. This model can be considered
`a “peer” model, because a router within a VPN site establishes a rout-
`ing relationship with a router within the VPN provider’s network,
`instead of an edge-to-edge routing peering relationship with routers in
`other sites of that VPN. Although the common underlying Internet
`generally carries the routes for all networks connected to it, this
`architecture assumes that only a subset of such networks form a VPN.
`The routes associated with this set of networks are filtered such that
`they are not announced to any other set of connected networks, and
`all other non-VPN routes are not announced to the networks of the
`VPN. For example, in Figure 1, if the SP routers “leaked” routing
`information received from one site in Network “A” to only other sites
`in Network “A,” then sites not in Network “A” (for instance, sites in
`Network “B”) would have no explicit knowledge of any other net-
`works which where attached to the service provider’s infrastructure
`(as shown in Figure 3). Given this lack of explicit knowledge of
`reachability to any location other than other members of the same
`VPN, privacy of services is implemented by the inability of any of the
`VPN hosts to respond to packets which contain source addresses from
`outside the VPN community of interest.
`
`BA
`
`2
`
`A3
`
`BA
`
`4
`
`Route Filter to A2
`Permit: A1, A3, A4
`Router Filter to A3
`Permit: A1, A2, A4
`
`Route Filter to A4
`Permit: A1, A2, A3
`A
`Network A
`
`VPN A
`
`Figure 3:
`Controlled Rou