Network Working Group
`Request for Comments: 1919
`Category: Informational
`
`M. Chatel
`Consultant
`March 1996
`
`Classical versus Transparent IP Proxies
`
`Status of this Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`Abstract
`
` Many modern IP security systems (also called "firewalls" in the
` trade) make use of proxy technology to achieve access control. This
` document explains "classical" and "transparent" proxy techniques and
` attempts to provide rules to help determine when each proxy system
` may be used without causing problems.
`
`Table of Contents
`
`1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
`2. Direct communication (without a proxy) . . . . . . . . . . . 3
` 2.1. Direct connection example . . . . . . . . . . . . . . . . 3
` 2.2. Requirements of direct communication . . . . . . . . . . . 5
`3. Classical application proxies . . . . . . . . . . . . . . 5
` 3.1. Classical proxy session example . . . . . . . . . . . . . 6
` 3.2. Characteristics of classical proxy configurations . . . 12
` 3.2.1. IP addressing and routing requirements . . . . . . . . 12
` 3.2.2. IP address hiding . . . . . . . . . . . . . . . . . . 14
` 3.2.3. DNS requirements . . . . . . . . . . . . . . . . . . . 14
` 3.2.4. Software requirements . . . . . . . . . . . . . . . . 15
` 3.2.5. Impact of a classical proxy on packet filtering . . . 15
` 3.2.6. Interconnection of conflicting IP networks . . . . . . 16
`4. Transparent application proxies . . . . . . . . . . . . . 19
` 4.1. Transparent proxy connection example . . . . . . . . . . 20
` 4.2. Characteristics of transparent proxy configurations . . 26
` 4.2.1. IP addressing and routing requirements . . . . . . . . 26
` 4.2.2. IP address hiding . . . . . . . . . . . . . . . . . . 28
` 4.2.3. DNS requirements . . . . . . . . . . . . . . . . . . . 28
` 4.2.4. Software requirements . . . . . . . . . . . . . . . . 29
` 4.2.5. Impact of a transparent proxy on packet filtering . . 30
` 4.2.6. Interconnection of conflicting IP networks . . . . . . 31
`5.
`Comparison chart of classical and transparent proxies . . 31
`6. Improving transparent proxies . . . . . . . . . . . . . . 32
`7. Security Considerations . . . . . . . . . . . . . . . . . 34
`
`Chatel
`
`Informational
`
`[Page 1]
`
`Juniper Ex. 1050-p. 1
`Juniper v Implicit
`
`

`

`RFC 1919
`
`Classical versus Transparent IP Proxies
`
`March 1996
`
`8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 34
`9. References . . . . . . . . . . . . . . . . . . . . . . . . 35
`
`1. Background
`
` An increasing number of organizations use IP security systems to
` provide specific access control when crossing network security
` perimeters. These systems are often deployed at the network boundary
` between two organizations (which may be part of the same "official"
` entity), or between an organization’s network and a large public
` internetwork such as the Internet.
`
` Some people believe that IP firewalls will become commodity products.
` Others believe that the introduction of IPv6 and of its improved
` security capabilities will gradually make firewalls look like stopgap
` solutions, and therefore irrelevant to the computer networking scene.
` In any case, it is currently important to examine the impact of
` inserting (and removing) a firewall at a network boundary, and to
` verify whether specific types of firewall technologies may have
` different effects on typical small and large IP networks.
`
` Current firewall designs usually rely on packet filtering, proxy
` technology, or a combination of both. Packet filtering (although hard
` to configure correctly in a security sense) is now a well documented
` technology whose strengths and weaknesses are reasonably understood.
` Proxy technology, on the other hand, has been deployed a lot but
` studied little. Furthermore, many recent firewall products support a
` capability called "transparent proxying". This type of feature has
` been subject to much more marketing attention than actual technical
` analysis by the networking community.
`
` It must be remembered that the Internet’s growth and success is
` strongly related to its "open" nature. An Internet which would have
` been segmented from the start with firewalls, packet filters, and
` proxies may not have become what it is today. This type of discussion
` is, however, outside the scope of this document, which just attempts
` to provide an understandable description of what are network proxies,
` and of what are the differences, strengths, and weaknesses of
` "classical" and "transparent" network proxies. Within the context of
` this document, a "classical" proxy is the older (some would say old-
` fashioned) type of proxy of the two.
`
` Also note that in this document, the word "connection" is used for an
` application session that uses TCP, while the word "session" refers to
` an application dialog that may use UDP or TCP.
`
`Chatel
`
`Informational
`
`[Page 2]
`
`Juniper Ex. 1050-p. 2
`Juniper v Implicit
`
`

`

`RFC 1919
`
`Classical versus Transparent IP Proxies
`
`March 1996
`
`2. Direct communication (without a proxy)
`
` In the "normal" Internet world, systems do not use proxies and simply
` use normal TCP/IP to communicate with each other. It is important
` (for readers who may not be familiar with this) to take a quick look
` at the operations involved, in order to better understand what is the
` exact use of a proxy.
`
` 2.1 Direct connection example
`
`Let’s take a familiar network session and describe some details of
`its operation. We will look at what happens when a user on a
`client system "c.dmn1.com" sets up an FTP connection to the server
`system "s.dmn2.com". The client system’s IP address is
`c1.c2.c3.c4, the server’s IP address is s1.s2.s3.s4.
`
`+---------------+
`+----------+
`+---------------+
`| |
`\
`/ IP
`| |
`| c.dmn1.com |----+ network(s) +----| s.dmn2.com |
`| (c1.c2.c3.c4) |
`\ /
`| (s1.s2.s3.s4) |
`+---------------+
`+----------+
`+---------------+
`
`The user starts an instance of an FTP client program on the client
`system "c.dmn1.com", and specifies that the target system is
`"s.dmn2.com". On command-line systems, the user typically types:
`
`ftp s.dmn2.com
`
`The client system needs to convert the server’s name to an IP
`address (if the user directly specified the server by address,
`this step is not needed).
`
`Converting the server name to an IP address requires work to be
`performed which ranges between two extremes:
`
`a) the client system has this name in its hosts file, or has
`local DNS caching capability and successfully retrieves the
`name of the server system in its cache. No network activity
`is performed to convert the name to an IP address.
`
`b) the client system, in combination with DNS name servers,
`generate DNS queries that eventually propagate close to the
`root of the DNS tree and back down the server’s DNS branch.
`Eventually, a DNS server which is authoritative for the
`server system’s domain is queried and returns the IP
`address associated with "s.dmn2.com" (depending on the case,
`it may return this to the client system directly or to an
`
`Chatel
`
`Informational
`
`[Page 3]
`
`Juniper Ex. 1050-p. 3
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` intermediate name server). Ultimately, the client system
` obtains a valid IP address for s.dmn2.com. For simplicity,
` we assume the server has only one IP address.
`
` +---------------+ +--------+ +---------------+
` | | / IP \ | |
` | c.dmn1.com |---+ network(s) +---| s.dmn2.com |
` | (c1.c2.c3.c4) | \ / | (s1.s2.s3.s4) |
` +---------------+ +--------+ +---------------+
` A | / \
` | | address for / \
` | | s.dmn2.com? / \
` | | / \
` | | / \
` | | +--------+ s.dmn2.com? +--------+
` | +---->| DNS |------------->| DNS |
` | | server | | server |
` +--------| X |<-------------| Y |
` s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+
`
` Once the client system knows the IP address of the server system,
` it attempts to establish a connection to the standard FTP
` "control" TCP port on the server (port 21). For this to work, the
` client system must have a valid route to the server’s IP address,
` and the server system must have a valid route to the client’s IP
` address. All intermediate devices that behave like IP gateways
` must have valid routes for both the client and the server. If
` these devices perform packet filtering, they must ALL allow the
` specific type of traffic required between C and S for this
` specific application.
`
` +---------------+ +---------------+
` | c.dmn1.com | | s.dmn2.com |
` | (c1.c2.c3.c4) | | (s1.s2.s3.s4) |
` +---------------+ +---------------+
` | | | |
` | | route to S route to C | |
` | V V |
` | |
` | A | A
` | | route to C | | route to S
` | | | |
` | | C S C | |
` +----+ <-- +----+ --> +----+ <-- +----+
` | G1 |--------| Gx |--------| Gy |---------| Gn |
` +----+ --> +----+ <-- +----+ --> +----+
` S C S
`
`Chatel Informational [Page 4]
`
`Juniper Ex. 1050-p. 4
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` The actual application work for the FTP session between the client
` and server is done with a bidirectional flow of TCP packets
` between the client’s and server’s IP addresses.
`
` The FTP protocol uses a slightly complex protocol and TCP
` connection model which is, luckily, not important to the present
` discussion. This allows slightly shortening this document...
`
` 2.2 Requirements of direct communication
`
` Based on the preceding discussion, it is possible to say that the
` following is required for a direct session between a client and
` server to be successful:
`
` a) If the client uses the NAME of the server to reference it,
` the client must either have a hardcoded name-to-address
` binding for the server, or it must be able to resolve the
` server name (typically using DNS). In the case of DNS, this
` implies that the client and server must be part of the same
` DNS architecture or tree.
`
` b) The client and server must be part of the same internetwork:
` the client must have a valid IP route towards the server,
` the server must have a valid IP route towards the client,
` and all intermediate IP gateways must have valid routes
` towards the client and server ("IP gateway" is the RFC
` standard terminology; people often use the term "IP router"
` in computer rooms).
`
` c) If there are devices on the path between the client and
` server that perform packet filtering, all these devices must
` permit the forwarding of packets between the IP address of
` the client and the IP address of the server, at least for
` packets that fit the protocol model of the FTP application
` (TCP ports used, etc.).
`
`3. Classical application proxies
`
` A classical application proxy is a special program that knows one (or
` more) specific application protocols. Most application protocols are
` not symetric; one end is considered to be a "client", one end is a
` "server".
`
` A classical application proxy implements both the "client" and
` "server" parts of an application protocol. In practice, it only needs
` to implement enough of the client and server protocols to accomplish
` the following:
`
`Chatel Informational [Page 5]
`
`Juniper Ex. 1050-p. 5
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` a) accept client sessions and appear to them as a server;
`
` b) receive from a client the name or address of the final target
` server (this needs to be passed over the "client-proxy" session
` in a way that is application-specific);
`
` c) setup a session to the final server and appear to be a client
` from the server’s point of view;
`
` d) relay requests, responses, and data between the client and
` server;
`
` e) perform access controls according to the proxy’s design
` criteria (the main goal of the proxy, after all).
`
` The functional goal of the proxy is to relay application data between
` clients and servers that may not have direct IP connectivity. The
` security goal of the proxy is to do checks and types of access
` controls that typical client and server software do not support or
` implement.
`
` The following information will make it clear that classical proxies
` can offer many hidden benefits to the security-conscious network
` designer, at the cost of deploying client software with proxy
` capabilities or of educating the users on proxy use.
`
` Client software issues are now easier to handle, given the increasing
` number of popular client applications (for Web, FTP, etc.) that offer
` proxy support. Designers developing new protocols are also more
` likely to plan proxy capability from the outset, to ensure their
` protocols can cross the many existing large corporate firewalls that
` are based at least in part on classical proxy technology.
`
` 3.1 Classical proxy session example
`
` We will repeat our little analysis of an FTP session. This time,
` the FTP session is passing through a "classical" application proxy
` system. As is often the case (although not required), we will
` assume that the proxy system has two IP addresses, two network
` interfaces, and two DNS names.
`
` The proxy system is running a special program which knows how to
` behave like an FTP client on one side, and like an FTP server on
` the other side. This program is what people call the "proxy". We
` will assume that the proxy program is listening to incoming
` requests on the standard FTP control port (21/tcp), although this
` is not always the case in practice.
`
`Chatel Informational [Page 6]
`
`Juniper Ex. 1050-p. 6
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` +---------------+ +----------+
` | | / IP \
` | c.dmn1.com |----+ network(s) +----------+
` | (c1.c2.c3.c4) | \ / |
` +---------------+ +----------+ +-----------------+
` | (p1.p2.p3.p4) |
` | proxy1.dmn3.com |
` | |
` | proxy2.dmn4.com |
` | (p5.p6.p7.p8) |
` +---------------+ +----------+ +-----------------+
` | | / IP \ |
` | s.dmn2.com |----+ network(s) +----------+
` | (s1.s2.s3.s4) | \ /
` +---------------+ +----------+
`
` The user starts an instance of an FTP client program on the client
` system "c.dmn1.com", and MUST specify that the target system is
` "proxy1.dmn3.com". On command-line systems, the user typically
` types:
`
` ftp proxy1.dmn3.com
`
` The client system needs to convert the proxy’s name to an IP
` address (if the user directly specified the proxy by address, this
` step is not needed).
`
` Converting the proxy name to an IP address requires work to be
` performed which ranges between two extremes:
`
` a) the client system has this name in its hosts file, or has
` local DNS caching capability and successfully retrieves the
` name of the proxy system in its cache. No network activity
` is performed to convert the name to an IP address.
`
` b) the client system, in combination with DNS name servers,
` generate DNS queries that eventually propagate close to the
` root of the DNS tree and back down the proxy’s DNS branch.
` Eventually, a DNS server which is authoritative for the
` proxy system’s domain is queried and returns the IP
` address associated with "proxy1.dmn3.com" (depending on the
` case, it may return this to the client system directly or
` to an intermediate name server). Ultimately, the client
` system obtains a valid IP address for proxy1.dmn3.com.
`
`Chatel Informational [Page 7]
`
`Juniper Ex. 1050-p. 7
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` +---------------+ +--------+
` | | / IP \
` | c.dmn1.com |--------+ network(s) +------------+
` | (c1.c2.c3.c4) | \ / |
` +---------------+ +--------+ +-----------------+
` A | / \ | (p1.p2.p3.p4) |
` | | address for / \ | proxy1.dmn3.com |
` | | proxy1.dmn3.com? / \ | ... |
` | | / \ +-----------------+
` | | / \
` | | / \
` | | +--------+ proxy1.dmn3.com? +--------+
` | +-------->| DNS |------------------>| DNS |
` | | server | | server |
` +------------| X |<------------------| Y |
` p1.p2.p3.p4 +--------+ p1.p2.p3.p4 +--------+
`
` Once the client system knows the IP address of the proxy system,
` it attempts to establish a connection to the standard FTP
` "control" TCP port on the proxy (port 21). For this to work, the
` client system must have a valid route to the proxy’s IP address,
` and the proxy system must have a valid route to the client’s IP
` address. All intermediate devices that behave like IP gateways
` must have valid routes to both the client and the proxy. If these
` devices perform packet filtering, they must ALL allow the specific
` type of traffic required between C and P1 for this specific
` application (FTP).
`
` Finally, the proxy system must accept this incoming connection,
` based on the client’s IP address (the purpose of the proxy is
` generally to do access control, after all).
`
` +---------------+ | ... |
` | c.dmn1.com | | proxy1.dmn3.com |
` | (c1.c2.c3.c4) | | (p1.p2.p3.p4) |
` +---------------+ +-----------------+
` | | | |
` | | route to P1 route to C | |
` | V V |
` | |
` | A | A
` | | route to C | | route to P1
` | | | |
` | | C P1 C | |
` +----+ <-- +----+ --> +----+ <-- +----+
` | G1 |--------| Gx |--------| Gy |---------| Gn |
` +----+ --> +----+ <-- +----+ --> +----+
` P1 C P1
`
`Chatel Informational [Page 8]
`
`Juniper Ex. 1050-p. 8
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` The actual application work for the FTP session between the client
` and proxy is done with a bidirectional flow of TCP packets between
` the client’s and proxy’s IP addresses.
`
` For this to work, the proxy FTP application MUST fully support the
` FTP protocol and look identical to an FTP server from the client’s
` point of view.
`
` Once the client<->proxy session is established, the final target
` server name must be passed to the proxy, since, when using a
` "classical" application proxy, a way MUST be defined for the proxy
` to determine the final target system. This can be achieved in
` three ways:
`
` a) The client system supplies the name or address of the final
` target system to the proxy in a method that is compatible
` with the specific application protocol being used (in our
` example, FTP). This is generally considered to be the main
` problem with classical proxies, since for each application
` being proxied, a method must be defined for passing the
` name or address of the final target system. This method
` must be compatible with every variant of client application
` that implements the protocol (i.e. the target-passing
` method must fit within the MINIMUM functionalities required
` by the specific application protocol).
`
` For the FTP protocol, the generally popular method for
` passing the final server name to the proxy is as follows:
`
` When the proxy prompts the FTP client for a username, the
` client specifies a string of the form:
`
` target_username@target_system_name
` or
` target_username@target_ip_address
`
` The proxy will then know what is the final target system.
` The target_username (and the password supplied by the
` client) will be forwarded "as is" by the proxy to the final
` target system.
`
` A well-known example of an FTP proxy that behaves in this way
` is the "ftp-gw" program which is part of the Trusted
` Information System’s firewall toolkit, available by anonymous
` FTP at ftp.tis.com. Several commercial firewalls also support
` this de-facto standard.
`
`Chatel Informational [Page 9]
`
`Juniper Ex. 1050-p. 9
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` b) If there is only one possible final destination, the proxy
` may be configured to know this destination in advance.
` Since the IP address of the client system is known when the
` proxy must make this decision, the proxy can (if required)
` select a different destination based on the IP address of
` the client.
`
` c) The client software may also support capabilities that allow
` it to present to the user the illusion of a direct session
` (the user just specifies the final target system, and the
` client software automatically handles the problem of
` reaching to the proxy system and passing the name or address
` of the final target system in whatever mutually-acceptable
` form).
`
` A well-known example of a system that provides modified
` client software, proxy software, and that provides the
` illusion of transparency is NEC’s SOCKS system, available by
` anonymous FTP at ftp.nec.com.
`
` Alternatively, several FTP client applications support the
` "username@destination_host" de-facto standard implemented
` (for example) by the "ftp-gw" proxy application.
`
` Once the FTP proxy application knows the name or IP address of the
` target system, it can choose to do two things:
`
` a) Setup a session to the final target system, the more
` frequent case.
`
` b) Decide (based on some internal configuration data) that it
` cannot reach the final target system directly, but must go
` through another proxy. This is rare today, but may become
` temporarily common due to the current shortage of IP
` network numbers which encourages organizations to deploy
` "hidden" network numbers which are already assigned
` elsewhere. Sessions between systems which have the same
` IP network number but which belong to different actual
` networks may require going through two proxy systems.
` This is discussed in more detail in section 3.2.6,
` "Interconnection of conflicting IP networks".
`
` If the FTP proxy decides to connect directly to the target system,
` and what it has is the target system name, it will need to convert
` the target system name into an IP address. If this process
` involves DNS resolution, something like the following will happen:
`
`Chatel Informational [Page 10]
`
`Juniper Ex. 1050-p. 10
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` +-----------------+
` | proxy1.dmn3.com |
` | (p1.p2.p3.p4) | +--------+
` | | / IP \
` | proxy2.dmn4.com |--------+ network(s) +------------+
` | (p5.p6.p7.p8) | \ / |
` +-----------------+ +--------+ +---------------+
` A | / \ | (s1.s2.s3.s4) |
` | | address for / \ | s.dmn2.com |
` | | s.dmn2.com? / \ | |
` | | / \ +---------------+
` | | / \
` | | / \
` | | +--------+ s.dmn2.com? +--------+
` | +-------->| DNS |------------------>| DNS |
` | | server | | server |
` +------------| X |<------------------| Y |
` s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+
`
` Once the proxy system knows the IP address of the server system,
` it attempts to establish a connection to the standard FTP
` "control" TCP port on the server (port 21). For this to work, the
` proxy system must have a valid route to the server’s IP address,
` and the server system must have a valid route to at least one of
` the proxy’s IP address. All intermediate devices that behave like
` IP gateways must have valid routes to both the proxy and the
` server. If these devices perform packet filtering, they must ALL
` allow the specific type of traffic required between the proxy and
` S for this specific application.
`
`Chatel Informational [Page 11]
`
`Juniper Ex. 1050-p. 11
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` +-----------------+
` | proxy1.dmn3.com |
` | (p1.p2.p3.p4) |
` | | +----------------+
` | proxy2.dmn4.com | | s.dmn2.com |
` | (p5.p6.p7.p8) | | (s1.s2.s3.s4) |
` +-----------------+ +----------------+
` | | | |
` | | route to S route to P2 | |
` | V V |
` | |
` | A | A
` | | route to P2 | | route to S
` | | | |
` | | P2 S P2 | |
` +----+ <-- +----+ --> +----+ <-- +----+
` | G1 |--------| Gx |--------| Gy |---------| Gn |
` +----+ --> +----+ <-- +----+ --> +----+
` S P2 S
`
` The actual FTP application work between the proxy and server is
` done with a bidirectional flow of TCP packets between the proxy’s
` and server’s IP addresses.
`
` What actually happens BETWEEN THE CLIENT AND SERVER? They both
` send replies and responses to the proxy, which forwards data to
` the "other" end. When one party opens a data connection and sends
` a PORT command to the proxy, the proxy allocates its own data
` connection and sends its PORT command to the "other" end. The
` proxy also copies data across the connections created in this way.
`
` 3.2 Characteristics of classical proxy configurations
`
` Several IP internetworks may be linked using only classical proxy
` technology. It is currently popular to link two specific IP
` internetworks in this way: the Internet and some organization’s
` "private" IP network. Such a proxy-based link is often the key
` component of a firewall.
`
` When this is done, several benefits and problems are introduced
` for network administrators and users.
`
` 3.2.1 IP addressing and routing requirements.
`
` The proxy system must be able to address all client and server
` systems to which it may provide service. It must also know
` valid IP routes to all these client and server systems.
`
`Chatel Informational [Page 12]
`
`Juniper Ex. 1050-p. 12
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` Client and server systems must be able to address the proxy
` system, and must know a valid IP route to the proxy system. If
` the proxy system has several IP addresses (and often, several
` physical network interfaces), the client and server systems
` need only to be able to access ONE of the proxy system’s IP
` addresses.
`
` Note that client and server systems that use the proxy for
` communication DO NOT NEED valid IP addressing or routing
` information for systems that they reach through the proxy.
`
` In this sense, it can be said that systems separated by a
` classical proxy are isolated from each other in an IP
` addressing sense and in an IP routing sense.
`
` On the other hand, the classical proxy system (if running a
` standard TCP/IP software stack) needs to have a single coherent
` view of IP addressing and routing. If such a proxy system
` interconnects two IP networks and two systems use the same IP
` network/subnetwork number (one system on each network), the
` proxy will only be able to address one of the systems.
`
` This restriction can be removed by chaining classical proxies
` (this is described later in section 3.2.6, "Interconnection of
` conflicting IP networks").
`
` Using a classical proxy for interconnection of IP
` internetworks, it is also possible, with care, to achieve a
` desirable "fail-safe" feature: no valid routing entries need to
` exist for an internetwork which should be reached only through
` the proxy (routing updates that could add such entries shout be
` BLOCKED). If the proxy suddenly starts to behave like an IP
` router, only one-way attacks become possible.
`
` In other words, assume an attacker has control of the remote
` internetwork and has found a way to cause the proxy to route IP
` packets, or has found a way to physically bypass the proxy.
`
` The attacker may inject packets, but the attacked internal
` systems will be unable to reply to those packets. This
` certainly does not make attacks infeasible (as exemplified by
` certain holiday-period events in recent years), but it still
` makes attacks more difficult.
`
`Chatel Informational [Page 13]
`
`Juniper Ex. 1050-p. 13
`Juniper v Implicit
`
`

`

`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
`