`
`Network Working Group M. Chatel
`Request for Comments: 1919 Consultant
`Category: Informational 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]
`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
`https://www.ietf.org/rfc/rfc1919.txt
`
`2/16/2015
`
`Hospitality Core Services, LLC - Ex 1023 - Page 001
`
`EXHIBIT 1011
`Guest-Tek v. Nomadix, IPR2018-00376
`
`
`
`Page 22 of 33
`
` | c.dmn1.com | | proxy system |
` | (c1.c2.c3.c4) | | (p1.p2.p3.p4) |
` +---------------+ +-----------------+
` | | | |
` | | 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
`
` At the start of the FTP session, a TCP packet with a source
` address of C and a destination address of S travels to the proxy
` system, expecting to cross it just like a normal IP gateway.
`
` This is when the transparent proxy shows its magic:
`
` The proxy's TCP/IP software stack sees this incoming packets (and
` subsequent ones) for a destination address that is NOT one of its
` own addresses. Based on some criteria (a configuration file, for
`
`Chatel Informational [Page 23]
`
`RFC 1919 Classical versus Transparent IP Proxies March 1996
`
` example), it decides NOT to forward or drop the packet (which are
` the only two choices an RFC-standard TCP/IP implementation would
` have). The proxy system accepts the packet as if it was directed
` to one of its own IP addresses.
`
`packet. Since
` In our example, the incoming packet is a TCP packet. Since
` standard TCP/IP stacks store both a LOCAL and REMOTE IP address
` standard TCP/IP stacks store both a LOCAL and REMOTE IP address
` field for each TCP connection, the transparent proxy may set the
` field for each TCP connection, the transparent proxy may set the
` LOCAL IP address field to the IP address that the client wants to
` LOCAL IP address field to the IP address that the client wants to
` reach (s1.s2.s3.s4 in our example). The stand
` reach (s1.s2.s3.s4 in our example). The standard TCP/IP stack
` probably needs to be modified to do this. UDP examples, although
` not connection-based, could be handled in similar ways.
`
` Once this is done, the actual FTP proxy application is invoked
` since an incoming connection to TCP port 21 has occurred. It can
` determine what is the final target destination instantly, since
` the LOCAL IP address field of the connection contains the target
` server's IP address. There is no need for the proxy application
` to ask the client what is the final target system.
`
` Since the FTP proxy application knows the 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
`
`https://www.ietf.org/rfc/rfc1919.txt
`
`2/16/2015
`
`Hospitality Core Services, LLC - Ex 1023 - Page 002
`
`