GRC's RSVP Agent Technology

A public disclosure of our remote
client authentication technology
by Steve Gibson

The Challenge of Accurately Determining the User's IP

A Bit of History
Shortly after the first release of ShieldsUP! we discovered that the simple use of the user's web-browser connection IP was not reliably resolving the user's actual machine IP. This was most often the result of a "transparent" caching proxy server placed "in the circuit" by the user's ISP (many, if not most, cable modem providers), a user-configured third-party proxy server (anonymizer.com, freedom.net, etc.), or a local NAT router.

The upshot, in any case, was that the ShieldsUP! tests would be mistargeted at the apparent connection IP which was not the IP of the user's machine. In response to this significant problem I quickly generated a two-part solution that has survived and served us quite well to this point:

The ShieldsUP! site technology was revised to briefly REQUIRE a secure (SSL) browser connection. Without requiring ANY user action this transparently resolved the great majority of problems which occurred for users of transparent caching ISP's. Since secure connections could not be cached and intercepted, the brief use of a secure connection circumvents the ISP's cache and allows the user's true IP to be determined.

You will discover that even if an insecure connection is attempted to the ShieldsUP! system entry-point (https://www.grc.com/x/ne.dll?bh0bkyd2) it will be quickly and silently "coerced" into a secure connection. This can not be bypassed or overridden.

However, deliberately configured browser proxies, more aggressive corporate SSL filters, and NAT routers, all continued to present problems. Additionally, a few users were unable, for various local administrative reasons, to establish secure connections of any sort. To address these problems, a second fall back solution was created and strongly recommended . . .

IP_Agent was created as a simple client-side agent to provide the user's IP address to ShieldsUP!. (Unfortunately, as we'll see, it turned out to be a bit too simple.) IP_Agent operated by generating a special "query URL" containing an encoding of the user's local IP(s). This URL was forwarded to the ShieldsUP! site which decoded the query to resolve the user's true IP address. This solution had the additional benefit of being able to enumerate multiple IP addresses on clients with multiple Internet connections (something the browser-connection based solution could not), thus allowing the user to decide which of their IP's should be tested.

Unfortunately, this "trusting solution" turned out to be too trusting. That trust was exploited by malicious hackers in several instances:

IP_Agent's simple IP encoding was "decoded" and used to create a "fake agent" that would allow a malicious user to cause the ShieldsUP! system to perform a "third-party scan" of any other IP address. In effect, the malicious hacker would use ShieldsUP! to test some other machine on the Internet while hiding behind the anonymity created by ShieldsUP!.

The second exploit discovered was the ability for a user to install a "fake-IP interface" on a machine and assign to it the third-party IP to be scanned. When IP_Agent was used on such a system it would "enumerate" the installed interfaces — including the "fake IP" — and offer to scan it for the user.

A Comprehensive and Secure Solution for the Future
The several known exploits of IP_Agent were allowed to persist only because the IP tests performed by the first-generation ShieldsUP! service (with a single exclamation point) were extremely mild, relatively innocuous, and widely available elsewhere. This, of course, changes with the introduction of the second-generation ShieldsUP!! system (with two exclamation points) and the extremely potent NanoProbe technology and system . . .

As mentioned above, the second-generation (and still completely FREE) ShieldsUP!! service will have much sharper teeth than its predecessor. But those "teeth" will only be accessible when the service is invoked through the use of the second-generation IP_Agent employing the new R.S.V.P. technology:

Don't let the level of detail in this diagram freak you
out too much. It's actually pretty straightforward.

How it Works . . .
The RSVP process consists of three phases, shown divided by dotted-lines in the schematic diagram above:

 Connection Establishment: The RSVP Agent running in the client computer establishes a TCP connection to the GRC NanoProbe server. This connection is validated by the NanoProbe server's unspoofable, Denial-of-Service-hardened, cryptographic, GENESIS TCP/IP protocol stack.

 Session Establishment: Once an authentic connection has been confirmed, the "connection" is elevated to a "session" by a request/cryptoken/data exchange.

 Connection/Session Maintenance: The client's connection to the server is continuously re-verified throughout the duration of services being provided to the client.

(Note: If you are not yet versed in the details of TCP packet protocol, my disclosure of the GENESIS technology contains a clear and careful explanation. You might wish to see that first.):

Connection Establishment:
	The RSVP Agent initiates the procedure by contacting the nanoprobe.grc.com server over the well-known FTP port 21. This port was chosen because it will not be transparently cached by the client's ISP and is unlikely to be firewalled or otherwise blocked. Any local outbound-blocking firewall running on the client machine will need to allow the RSVP Agent to contact the NanoProbe server over port 21. (Note that the feasibility of the use of port 21 has been extensively confirmed through the similar use of 8,300,009 downloaded copies of our LeakTest utility, which uses the same port in the same way.) If the RSVP Agent discovers more than one active IP-protocol interface available on the client, it will simultaneously use all available interfaces to contact the NanoProbe server.
	In keeping with standard GENESIS TCP/IP stack operation, any inbound SYN packet is responded to with a crytographically-derived SYN/ACK packet, but no other local state is created or retained at this time. If the inbound SYN was erroneous or spoofed, or if the client never responds for whatever reason, we're done. SYN-spoofing and flooding of the NanoProbe server is of absolutely no consequence.
	If the first SYN packet sent by the client was authentic and valid, the server's returning SYN/ACK packet will arrive and cause the client to complete the TCP connection's 3-way handshake by returning the final ACK to the server. Upon receipt of the client's ACK, the NanoProbe server utilizes the GENESIS technology to cryptographically authenticate the received ACK and, presuming that the ACK is valid, to create an active client connection. Since a round trip, to and from the client's IP address, is REQUIRED for GENESIS cryptographic authentication to succeed, the NanoProbe server has now confirmed the non-spoofable IP address of client.
Session Establishment:
	After establishing a verified connection, all NanoProbe server clients upgrade their "connection" to a "session" by specifying the type of service they desire. The client sends the server a "Session Request" packet identifying itself and its software version. This allows for feature-set growth and version-specific evolution to be gracefully accommodated. (Note that requiring the client to "make the first move" across the newly established TCP connection has the benefit of compensating for the possible network loss of the client's previous ACK packet: Since the GENESIS stack deliberately maintains no record of the client's opening SYN overture, a lost final ACK (see item #3 above) from the client would never be detected since the client would have no reason to retransmit the non-data carrying packet. However, since TCP requires the receipt of all transmitted data to be actively acknowledged by the receiver, the client will continue retransmitting its session request until it receives an acknowledgement from the NanoProbe server. In this way we are guaranteed of establishing the connection, and we overcome a limitation imposed by the GENESIS stack's "stateless" spoofing resistance.)
	Upon receipt of a valid RSVP Agent Session Request, the NanoProbe server generates and transmits a unique "Cryptoken" to the client. NanoProbe server Cryptokens are reversibly-encrypted 64-bit values which are never reused. Since 64-bits provides us with more than 18 billion billion unique values, this should be sufficient. If the client has multiple active IP interfaces, and has established multiple connections to the NanoProbe server over different IP addresses, each connection will cause the generation and transmission of a unique Cryptoken.
	Upon receipt of the Session Cryptoken, the RSVP Agent prepares and transmits an application-specific Client Data Package to the NanoProbe server. This data includes the Session Cryptoken and whatever additional information may be required to perform the session's requested work. If the client has established multiple connections to the NanoProbe server, it will receive a different Session Cryptoken across each connection. The client is free to choose any one of them at random, although in practice it will simply use the first one received, discarding any others. This single chosen Cryptoken will be returned across every client connection and used by the NanoProbe server to identify and aggregate the connections belonging to this client. This Cryptoken is the unique identifier for the security testing session being conducted on behalf of the client. For example, this Cryptoken will be used in the browser's URL to establish a web-session for the dynamic display of the security testing results.
Connection/Session Maintenance: The Problem: The NanoProbe Technology is capable of conducting aggressive tests upon the client and its Internet connection. Therefore we must be certain not to mistakenly direct potentially lethal NanoProbes to an unsuspecting client. Everything about the RSVP Agent technology prevents spoofing. But what about AFTER the spoof-proof connection has been established? Since dial-up, NAT-mapped, and other transient IP addresses are rapidly reused, we must have a means of continuously re-verifying the connection to our target client. This problem manifests itself in reports of newly connected dial-up users being bombarded by scanning/testing packets because the PREVIOUS user of that transient IP had requested an intensive scan, then disconnected from the Internet. That's never been a problem with ShieldsUP! and we can not allow it to become one with ShieldsUP!! and NanoProbe. The Solution:
	By deliberately sending the client an ACK packet containing a "mis-acknowledgment" of the next expected Client Sequence Number (CSN), the NanoProbe server coerces the client's TCP/IP protocol stack into correcting the server's "mistaken impression" by answering with another ACK packet containing the correct sequence numbers.
	When the client receives an ACK packet from the NanoProbe server containing deliberately misstated sequence numbers, the client's TCP/IP stack "corrects" the server's mistake by returning a ACK packet containing the correct sequence numbers. This has the desired effect of verifying the exact identity of the attached client. Even though this is very much like a traditional "ping" exchange (an ICMP echo request and reply), the difference is significant: Any TCP/IP stack would reply to the server's ICMP "ping", whereas only the proper client TCP/IP stack — having an established TCP connection in exactly the proper state — can possibly produce the correct reply to our special "TCP connection verification ping". The RSVP Agent technology provides the NanoProbe system with continuous, economical, and affirmative confirmation of the client's Internet connection presence. Immediately prior to targeting any potentially hazardous NanoProbes to the client's IP address, the NanoProbe server will perform steps 7 & 8, repeating them as often as necessary. The receipt of any incorrect response, or failure to receive a correct acknowledgement (allowing sufficient retries to account for network losses) will immediately terminate all planned and pending tests.

RSVP and the "Man in the Middle"
A "man in the middle" attack is the generic term given to any network attack that depends upon the active interception and alteration of network traffic flowing between two endpoints. In our case, a man in the middle exploit would look like this:

As simple as the diagram above appears, achieving a man in the middle position cannot be accomplished by the random malicious hacker. It requires Internet Service Provider (ISP) style access to the client's Internet connection.

Due to the heterogeneous structure and router-traffic-based routing of data across the Internet, packets are routed in a dynamic and non-pre-determined fashion as they move from one endpoint to another. Therefore, the MITM would need to be virtually adjacent to the client to be tested. Note that Gibson Research Corporation (grc.com) connects directly to a tier-one provider, Verio. We are "zero routers away" from the Internet backbone to absolutely minimize the opportunity for an unauthorized MITM at our end.

But the point of this analysis is to play the devil's advocate, so let's see what else a Fake RSVP Agent would need to do if ISP-level interception could be achieved:

In order for testing NanoProbes to be directed at the client machine, the Fake RSVP Agent would need to initiate an RSVP connection to the NanoProbe server using the client's IP address. Since this is tantamount to "spoofing the GENESIS stack", and since the GENESIS stack can not be spoofed, the MITM must be able to receive and intercept all packets bound for the client (whether or not they are carrying data) and selectively intercept only those which are used for managing the RSVP Agent session.

This is further complicated by the fact that the NanoProbe server utilizes a new technology called "differential IP analysis" which originates testing packets from multiple IP addresses to analyze the client's responses to IP addresses with which it has no existing relationship. In other words, the Fake RSVP Agent would need to simulate the client's awareness of a connection to the NanoProbe server (for example, creating a port mapping through a NAT router), which would not actually exist since the client would have no such relationship. Firewalls that dynamically stealth the "ident" (port 113) based upon whether the probing server is currently known to the client render such simulations extremely complex.

To pull this off, the Fake RSVP agent would need to understand the RSVP protocol in detail, examine every packet flowing to and from the unsuspecting client, then intercept and respond only to those which are about maintaining and authenticating the RSVP connection. And all the while the Fake RSVP Agent would need to accurately simulate any client responses which might differ as a result of the client knowing nothing about the NanoProbe server.

In Summary . . .
Difficult though it would be to create an intercepting/filtering/analyzing Fake RSVP agent, it could theoretically be accomplished. However, even if such a tool did exist, it would be utterly useless without complete access to the unsuspecting client's Internet connection. But moreover, anyone capable of such a feat of low-level TCP/IP packet engineering would already be well capable of creating their own advanced Internet scanning technology. Scanning the client for themselves would be vastly simpler and more feasible than attempting to spoof the entire NanoProbe system.

Is RSVP Agent Secure?

Yes. The RSVP Agent technology was designed to thwart any feasible exploit that might subvert the next-generation ShieldsUP!! and NanoProbe Internet security services. Given the theoretical and practical realities required for RSVP Agent subversion, we established an extremely sound footing with this highly-secure, next-generation, client-side Internet security testing agent.

Now  . . . let's use it for something!!