Network Working Group HT Kung Internet-Draft Scott Bradner Expires May 2002 Harvard University November 2001 A Framework for an Anonymizing Packet Forwarder Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract There are a number of situations in the Internet where it would be useful to be able to have an application be able to send traffic to a destination without revealing the IP address of the destination to the source, or the IP address of the source to the destination, or both. One way to do this is to have a network resident set of servers which can forward packets, with encryption and decryption applied to their source and destination addresses when appropriate. We will call this server an anonymizing forwarder. The anonymizing forwarding server intends to contribute to the goal of supporting anonymity at the IP layer [NymIP]. This memo describes several aspects of such an infrastructure based on stateless anonymizing packet forwarders. These include (1) usage examples of the forwarding infrastructure, (2) target servers' registration that receives their encrypted addresses from the Kung & Bradner [Page 1] Internet-Draft Anonymizing Forwarder Framework November 2001 infrastructure and sends them to clients' initialization servers, (3) multi-hop forwarding and the associated registration, and (4) threat analysis for the infrastructure and countermeasure strategies. The framework discussions here provide background information on the requirements for an anonymizing packet forwarder described in a companion document [RQM-DRAFT]. 1. Usage Examples Notations and Assumptions C: Client S: Target Server S has generated an asymmetric key pair of public and private keys, and holds the private key. I: Initialization Server F: Anonymizing Forwarder F is assumed to be outside of firewalls or NATs of C, S and I, should these firewalls or NATs exist. For forwarding purposes, F can use either a symmetric key, or an asymmetric key pair of public and private keys. In this document we assume that F uses a symmetric key for all its forwarding operations. F will encrypt an address and later decrypt it, so only F will need to know the symmetric key, and will keep it secret. To support target servers' registration, F uses an asymmetric key pair of public and private keys, and holds the private key. The forwarders of the same anycast address ([RFC1546] and [ANYCAST]) all have the same keys. [X]: IP address of X If X is a client behind a firewall or NAT, [X] is the IP address as seen from the outside of the organization. Kung & Bradner [Page 2] Internet-Draft Anonymizing Forwarder Framework November 2001 If X is a forwarder, [X] may be its unicast or anycast address. [X]{payload}[Y] A packet with its source and destination IP addresses being [X] and [Y], respectively. (z)r, where r is a symmetric key It is the content z encrypted in r. If r happens to be the lower case letter of the name of a forwarder or server, then r is the symmetric key of the forwarder or server. For example, (z)f means z encrypted in the symmetric key of forwarder F. (z)A, where A is the name of a forwarder or a server It is the content z signed in A's private or encrypted in A's public key. In the former case A does the signing, whereas in the latter case another entity does the encryption. A's ctf A's certificate providing A's public key and vouching for it. X->Y: [X]{payload}[Y] X sends packet [X]{payload}[Y] to Y. X: operation X performs operation. Six Forwarding Operations of a Forwarder Depending on the application, a forwarder may perform one of the following six forwarding operations listed below for a given input packet. Subsequent usage examples will illustrate the use of these operations. Kung & Bradner [Page 3] Internet-Draft Anonymizing Forwarder Framework November 2001 FWD-INC ("forward and include"): Input packet: [X]{msg, [Y]}[F] Output packet: [F]{msg, [X]}[Y] FWD-CLR ("forward and clear"): Input packet: [X]{msg, [Y]}[F] Output packet: [F]{msg}[Y] FWD-ENC ("forward and encrypt"): Input packet: [X]{msg, [Y]}[F] Output packet: [F]{msg, ([X])f}[Y] DEC-FWD-INC ("decrypt, forward and include"): Input packet: [X]{msg, ([Y])f}[F] Output packet: [F]{msg, [X]}[Y] DEC-FWD-CLR ("decrypt, forward and clear"): Input packet: [X]{msg, ([Y])f}[F] Output packet: [F]{msg}[Y] DEC-FWD-ENC ("decrypt, forward and encrypt"): Input packet: [X]{msg, ([Y])f}[F] Output packet: [F]{msg, ([X])f}[Y] In addition to these forwarding operations, a forwarder may also support management operations such as target servers' registration (see below). Baseline Usage Example: Hide [S] This example illustrates the use of the anonymizing infrastructure to satisfy the following two properties: (P1) A client C sends request to a target server S without knowing S's address. (P2) C receives reply from S without knowing S's address. The client C first interacts with an initialization server I, which may be a local application or a network-based service. In its message to I, C expresses its wish to access a target server S. Then the initialization server I securely sends C a message containing the following three items: - [F], which is the unicast address of a forwarder F, or the anycast address of a set of forwarders, also denoted by F. Kung & Bradner [Page 4] Internet-Draft Anonymizing Forwarder Framework November 2001 - ([S])f - S's ctf When the client wishes to send a request to S, it builds a packet containing the following contents, and sends it to [F]: - (req, ck)S, where req is C's request to S, and ck is a cookie associated with the packet. (req, ck)S is (req, ck) encrypted by S's public key. The purpose of ck is to identify the request. - ([S])f After the packet is sent, C will need to keep ck and S's ctf around for a while, so that they can be used later to verify the reply from S. When F receives the packet, it decrypts the packet, forwards it to [S], with the source address of the original packet, [C], as seen by F included in the packet payload. That is, F performs the operation DEC-FWD-INC. When S receives the packet, it builds a reply packet containing the following contents, and sends it to [F]: - (rep, ck)S: reply and cookie encrypted in the private key of S. - [C]: the source address of the original packet as seen by F. When F receives the packet, it forwards it to [C] without including [S] in the packet payload, so [S] will not be revealed. That is, F performs the operation FWD-CLR. When C receives the packet, it decrypts the reply and cookie using S's public key. By comparing the decrypted cookie with the original cookie stored at C, C decides whether or not the received reply is the one corresponding to its original request. The following summarizes the description above. Baseline Usage Example: Hide [S] C->F: [C]{(req, ck)S, ([S])f}[F] Kung & Bradner [Page 5] Internet-Draft Anonymizing Forwarder Framework November 2001 F: DEC-FWD-INC F->S: [F]{(req, ck)S, [C]}[S] S: reply S->F: [S]{(rep, ck)S, [C]}[F] F: FWD-CLR F->C: [F]{(rep, ck)S}[C] C: decrypt reply and cookie to verify the reply Usage Example 1.1: Hide [S] This example is an enhanced version of Baseline Usage Example above. It is designed to defend against a type of replay attacks. Suppose that an adversary repetitively submits C's request: C->F: [C]{(req, ck)S, ([S])f}[F] while monitoring packets on links that could be on the path from F to S and vice versa. If the adversary can identify these packets a priori, then he or she will be able to learn [S] by examining destination or source addresses of these packets. It is therefore important to avoid invariant bit strings, such as [C], (req, ck)S and (rep, ck)S in the Baseline Usage Example above, that could be used to identify these packets. Usage Example 1.1, summarized below, ensures that all these packets will likely have different payloads. Thus it would be difficult to isolate these packets. Usage Example 1.1: Hide [S] C->F: [C]{(req, ck, C's ctf)S, S's ctf, ([S])f}[F] F: DEC-FWD-ENC F->S: [F]{((req, ck, C's ctf)S, [C])r1, (r1)S, ([C])r2, (r2)f}[S] S: reply S->F: [S]{(rep, ck)r3, (r3)C, ([C])r2, (r2)f}[F] F: DEC-FWD-CLR Kung & Bradner [Page 6] Internet-Draft Anonymizing Forwarder Framework November 2001 F->C: [F]{(rep, ck)r3, (r3)C}[C] C: decrypt reply and cookie to verify the reply In the above, r1 and r2 are symmetrical session keys randomly selected by F for an each packet, while r3 is a key selected by S. This means that each resubmitted request C->F: [C]{(req, ck, C's ctf)S, S's ctf, ([S])f}[F] will likely result in an entirely different payload in the message from F->S, S->F or F->C. Usage Example 1.2: Hide [C] This example illustrates the use of the anonymizing infrastructure to satisfy the following two properties: (P3) S receives request from C without knowing C's address. (P4) S sends reply to C without knowing C's address C will obtain the following two items from the initialization server: - [F] - [S] We summarize Usage Example 1.2 as follows: Usage Example 1.2: Hide [C] C->F: [C]{req, C's ctf, [S]}[F] F: FWD-ENC F->S: [F]{req, C's ctf, ([C])f}[S] S: reply S->F: [S]{rep, C's ctf, ([C])f}[F] F: DEC-FWD-INC F->C: [F]{(rep, [S])r, (r)C}[C] Kung & Bradner [Page 7] Internet-Draft Anonymizing Forwarder Framework November 2001 C: decrypt reply and verify the reply Note that in the packet from F to C, F randomly selects a symmetrical session key r for each packet to defend against replay attacks. In such an attack, an adversary would repetitively resend the same message from S to F, while monitoring links from F to C. If those packets from F to C that are triggered by these repeated resends can be isolated, then their destination addresses will reveal [C]. By dynamically changing their payloads, these packets from F to C can not be isolated easily. Usage Example 1.3: Hide Both [C] and [S] This example illustrates the use of the anonymizing infrastructure to satisfy all the following four properties: (P1) A client C sends request to a target server S without knowing S's address. (P2) C receives reply from S without knowing S's address. (P3) S receives request from C without knowing C's address. (P4) S sends reply to C without knowing C's address. Thus, this usage intends to hide both addresses of C and S. The procedure summarized below for Usage Example 1.3 is a combination of procedures for Usage Example 1.1 and 1.2 above. Usage Example 1.3 has the properties of both Usage Example 1.1 and 1.2. Usage Example 1.3: Hide Both [C] and [S] C->F: [C]{(req, ck, C's ctf)S, C's ctf, S's ctf, ([S])f}[F] F: DEC-FWD-ENC F->S: [F]{((req, ck, C's ctf)S, ([C], C's ctf)r2, (r2)f)r1, (r1)S}[S] S: reply S->F: [S]{(rep, ck)r3, (r3)C, ([C], C's ctf)r2, (r2)f}[F] F: DEC-FWD-CLR F->C: [F]{((rep, ck)r3, (r3)C)r4, (r4)C}[C] Kung & Bradner [Page 8] Internet-Draft Anonymizing Forwarder Framework November 2001 C: decrypt reply and cookie to verify the reply 2. Target Server's Registration A target server S interested in hiding its address [S] by using an anonymizing forwarder F may register itself to an initialization server I. The registration will involve S first sending an encryption request to F asking for ([S])f, and then sending the received ([S])f to I via F. After receiving this information from I, C can send its requests to S via F, as described in the Baseline Usage Example earlier. It is instructive to consider a target server's registration as a process for an initialization server to receive an "access ticket", which consists of information such as [F] and [S])f, that allows clients' requests to reach S via F. Target Server's Registration to I on Use of Forwarder F: S->F: [S]{S's ctf, ([S])S}[F] F: decrypt ([S])S to validate [S]'s authenticity, and encrypt [S] in F's symmetric key F->S: [F]{(([S])f, [F])S}[S] S: decrypt (([S])f)S using S's private key to recover [F] and ([S])f optionally, S may send test messages to F using ([S])f to check if F will forward the messages back to S sign (([S])f, [F]) in S's private key S->F: [S]{S's ctf, (([S])f, [F])S, [I]}[F] F: FWD-CLR F->I: [F]{S's ctf, (([S])f, [F])S}[I] I: decrypt ([S])f, [F])S to validate the authenticity of [S])f and [F] using S's public key, and then receive [F], ([S])f, and S's ctf This registration method has three properties worth mentioning. First, it does not require S to know F's symmetric key. Second, S may change to a new forwarder F' it wants to use for a given I by obtaining ([S])f' from F' and sending it to I. Third, S may use different Fs for different Is, for balancing loads or meeting Kung & Bradner [Page 9] Internet-Draft Anonymizing Forwarder Framework November 2001 different security requirements. Note that F encrypts [S] using that from ([S])S, rather than that extracted from the source address of S's message. This is to defend against possible impersonation of S by an adversary. Suppose that an adversary S1 sends an encryption request [S1](S's ctf, [S1])[F] to F, and S1 receives from F reply [F]{(([S1])f)S}[S1]. If S1 can manage to send the packet [F]{(([S1])f)S}[S] to S, then S would mistakenly use ([S1])f instead of ([S])f in the registration. 3. Multi-hop Registration and Forwarding In multi-hop forwarding, a sequence of two or more forwarders are used in forwarding a client's packet. These forwarders together are sufficient in decrypting the address of the target server, but any proper subset of them are not. Multi-hop forwarding can provide additional protection against an adversary who may attempt to compromise a forwarder or monitor its output links. For example, by employing forwarders protected under strong but different security measures, the adversary would need to defeat all these security measures in order to succeed. Multi-hop Registration During its registration, a target server S will obtain a sequence of forwarders to use. First, S chooses an F that S trusts, and sends it a request asking for ([S])f. When receiving the request from S, F may find an another forwarder G that F trusts. G may be under a different jurisdiction, so that compromising both F and G would be harder than compromising forwarders in the same jurisdiction. In turn, G may find yet another forwarder H that G trusts, and so on. Finally, the last forwarder will send S the necessary information required by S's registration. We illustrate below the multi-hop registration, using a three-hop example involving three forwarders F1, F2 and F3 corresponding to F, G and F, respectively. We assume here that the Fs each use a public and private key pair, and hold the private key. Target Server's Three-hop Registration to I on Use of Forwarders F1, F2 and F3: S->F1: [S]{S's ctf, ([S])S}[F1] F1: decrypt ([S])S to validate [S]' authenticity using S's public key, encrypt the [S] in F1's symmetric key, and sign [F1] in F1's private key Kung & Bradner [Page 10] Internet-Draft Anonymizing Forwarder Framework November 2001 F1->F2: [F1]{S's ctf, F1's ctf, ([S])f1, ([F1])F1}[F2] F2: decrypt ([F1])F1 to validate [F1]'s authenticity using F1's public key, encrypt (([S])f1, [F1]) in F2's symmetric key, and sign [F2] in F2's private key F2->F3: [F2]{S's ctf, F2's ctf, (([S])f1, [F1])f2, ([F2])F2}[F3] F3: decrypt ([F2])F2 to validate [F2]'s authenticity using F2's public key, encrypt (([S])f1, [F1])f2, [F2]) in F3's symmetric key, sign [F3] in F3's private key, and encrypt ((([S])f1, [F1])f2, [F2])f3, ([F3])F3 in S's public key F3->S: [F3]{F3's ctf, (((([S])f1, [F1])f2, [F2])f3, ([F3])F3)S}[S] S: decrypt ([F3])F3 to validate [F3]'s authenticity using F3's public key, and sign ((([S])f1, [F1])f2, [F2])f3, [F3] in S's private key S->F3: [S]{S's ctf, (((([S])f1, [F1])f2, [F2])f3, [F3])S, [I]}[F3] F3: FWD-CLR F3->I: [F3]{S's ctf, (((([S])f1, [F1])f2, [F2])f3, [F3])S}[I] I: receive ((([S])f1, [F1])f2, [F2])f3, [F3] Multi-hop Forwarding We illustrate below multi-hop forwarding with a simple usage example, that corresponds to the single-hop Baseline Usage Example earlier. Multi-hop Baseline Usage Example: Hide [S] C->F3: [C]{(req, ck)S, ((([S])f1, [F1])f2, [F2])f3}[F3] F3: DEC-FWD-INC F3->F2: [F3]{(req, ck)S, (([S])f1, [F1])f2, [C]}[F2] F2: DEC-FWD-INC F2->F1: [F2]{(req, ck)S, ([S])f1, [C], [F3]}[F1] Kung & Bradner [Page 11] Internet-Draft Anonymizing Forwarder Framework November 2001 F1: DEC-FWD-INC F1->S: [F1]{(req, ck)S, [C], [F3], [F2]}[S] S: reply S->F1: [S]{(rep, ck)S, [C], [F3], [F2]}[F1] F1: FWD-CLR F1->F2: [F1]{(rep, ck)S, [C], [F3]}[F2] F2: FWD-CLR F2->F3: [F2]{(rep, ck)S, [C]}[F3] F3: FWD-CLR F3->C: [F3]{(rep, ck)S}[C] C: decrypt reply and cookie to verify the reply The nested encryption is similar to that in onion routing [ONION]. Note that schemes similar to those of Usage Example 1.1 can be applied to prevent replay attacks that exploit the fact that (req, ck)S or (rep, ck)S remains an invariant in all the packets. 4. Threat Analysis and Counter Measure Strategies Types of Treats There are various types of threats regarding anonymizing forwarders. We consider the following three types: Type 1 threat: The forwarding infrastructure leaks address information that it is supposed to hide. Type 2 treat: The forwarding infrastructure is itself subject to DoS Attacks. Type 3 threat: The forwarding infrastructure is used as a conduit for DoS attacks. Countermeasure Strategies The forwarding infrastructure itself should provide the bulk of the Kung & Bradner [Page 12] Internet-Draft Anonymizing Forwarder Framework November 2001 means of protection against these threats. The methods should not involve clients, initialization servers, and target servers, since they are outside management authorities of the infrastructure. Moreover, the infrastructure should not attempt to protect itself through user authentication, since the infrastructure is supposed to support authentication infrastructure, not vice versa. Multi-hop forwarding can help defend Type 1 threats, in the sense that it will make an adversary work harder in order to learn the address of a target server. This is especially true if the forwarders in the multi-hop sequence are under different administrative authorities, because in this case the attacker will need to compromise all the authorities in order to succeed. To defend against Type 2 threats concerning DoS attacks on the forwarding infrastructure, one can have first-hop forwarders provide high-volume, light-weight filtering of requests with spoofed source IP addresses. These servers working at the wire speed could send challenges to the requestors, so that only those with legitimate IP addresses will be able to respond. Forwarders behind the first-hop ones will have their addresses hidden from users. In addition, via registrations, target servers may change the forwarders they use from time to time. To defend against Type 3 threats concerning the forwarding infrastructure being used as conduit for DoS attacks, the infrastructure could reject requests from spoofed source IPs. In addition, a forwarder could rate limit its output on a per link, per source, or per destination basis. References [RQM-DRAFT] Bradner, S., and Kung, H. T., "Requirements for an Anonymizing Packet Forwarder" , Draft, November 2001 [ANYCAST] Katabi, D., and Wroclawski, J., "A Framework for Global IP- Anycast (GIA)," Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 2000. [NymIP] The NymIP Effort, http://nymip.velvet.com. [ONION] Reed, M., Syverson, P., and Goldschlag, D., "Anonymous Connections and Onion Routing," IEEE Journal on Selected Areas in Communications, vol. 16 no. 4, May 1998, pp. 482-494. Kung & Bradner [Page 13] Internet-Draft Anonymizing Forwarder Framework November 2001 [RFC1546] Milliken, W., Partridge C., and Mendez, T., "Host anycasting service," RFC 1546, November 1993. 8. Authors' Addresses HT Kung Harvard University 33 Oxford St. Cambridge MA 02138 Email: kung@harvard.edu Phone: +1-617-496-6211 Scott Bradner Harvard University 29 Oxford St. Cambridge MA 02138 Email: sob@harvard.edu Phone: +1-617-495-3864 Kung & Bradner [Page 14]