[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                      HT Kung
Internet-Draft                                             Scott Bradner
Expires May 2002                                           Harvard University
                                                           November 2001

            A Framework for an Anonymizing Packet Forwarder

                  <draft-kung-annfwd-framework-00.txt>

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-bradner-annfwd-req.txt>, 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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/