idnits 2.17.1 draft-kung-annfwd-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([NymIP], [RQM-DRAFT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'NymIP' on line 595 looks like a reference -- Missing reference section? 'RQM-DRAFT' on line 587 looks like a reference -- Missing reference section? 'RFC1546' on line 601 looks like a reference -- Missing reference section? 'ANYCAST' on line 591 looks like a reference -- Missing reference section? 'X' on line 156 looks like a reference -- Missing reference section? 'Y' on line 156 looks like a reference -- Missing reference section? 'F' on line 419 looks like a reference -- Missing reference section? 'S' on line 514 looks like a reference -- Missing reference section? 'C' on line 518 looks like a reference -- Missing reference section? 'I' on line 488 looks like a reference -- Missing reference section? 'S1' on line 420 looks like a reference -- Missing reference section? 'F1' on line 518 looks like a reference -- Missing reference section? 'F2' on line 518 looks like a reference -- Missing reference section? 'F3' on line 518 looks like a reference -- Missing reference section? 'ONION' on line 597 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group HT Kung 3 Internet-Draft Scott Bradner 4 Expires May 2002 Harvard University 5 November 2001 7 A Framework for an Anonymizing Packet Forwarder 9 11 Status of This Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 There are a number of situations in the Internet where it would be 35 useful to be able to have an application be able to send traffic to a 36 destination without revealing the IP address of the destination to 37 the source, or the IP address of the source to the destination, or 38 both. One way to do this is to have a network resident set of 39 servers which can forward packets, with encryption and decryption 40 applied to their source and destination addresses when appropriate. 41 We will call this server an anonymizing forwarder. The anonymizing 42 forwarding server intends to contribute to the goal of supporting 43 anonymity at the IP layer [NymIP]. 45 This memo describes several aspects of such an infrastructure based 46 on stateless anonymizing packet forwarders. These include (1) usage 47 examples of the forwarding infrastructure, (2) target servers' 48 registration that receives their encrypted addresses from the 49 infrastructure and sends them to clients' initialization servers, (3) 50 multi-hop forwarding and the associated registration, and (4) threat 51 analysis for the infrastructure and countermeasure strategies. 53 The framework discussions here provide background information on the 54 requirements for an anonymizing packet forwarder described in a 55 companion document [RQM-DRAFT]. 57 1. Usage Examples 59 Notations and Assumptions 61 C: Client 63 S: Target Server 65 S has generated an asymmetric key pair of public and private 66 keys, and holds the private key. 68 I: Initialization Server 70 F: Anonymizing Forwarder 72 F is assumed to be outside of firewalls or NATs of C, S and I, 73 should these firewalls or NATs exist. 75 For forwarding purposes, F can use either a symmetric key, or an 76 asymmetric key pair of public and private keys. In this document 77 we assume that F uses a symmetric key for all its forwarding 78 operations. F will encrypt an address and later decrypt it, so 79 only F will need to know the symmetric key, and will keep it 80 secret. 82 To support target servers' registration, F uses an asymmetric key 83 pair of public and private keys, and holds the private key. 85 The forwarders of the same anycast address ([RFC1546] and 86 [ANYCAST]) all have the same keys. 88 [X]: IP address of X 90 If X is a client behind a firewall or NAT, [X] is the IP address 91 as seen from the outside of the organization. 93 If X is a forwarder, [X] may be its unicast or anycast address. 95 [X]{payload}[Y] 97 A packet with its source and destination IP addresses being [X] 98 and [Y], respectively. 100 (z)r, where r is a symmetric key 102 It is the content z encrypted in r. 104 If r happens to be the lower case letter of the name of a 105 forwarder or server, then r is the symmetric key of the forwarder 106 or server. For example, (z)f means z encrypted in the symmetric 107 key of forwarder F. 109 (z)A, where A is the name of a forwarder or a server 111 It is the content z signed in A's private or encrypted in A's 112 public key. In the former case A does the signing, whereas in 113 the latter case another entity does the encryption. 115 A's ctf 117 A's certificate providing A's public key and vouching for it. 119 X->Y: [X]{payload}[Y] 121 X sends packet [X]{payload}[Y] to Y. 123 X: operation 125 X performs operation. 127 Six Forwarding Operations of a Forwarder 129 Depending on the application, a forwarder may perform one of the 130 following six forwarding operations listed below for a given input 131 packet. Subsequent usage examples will illustrate the use of these 132 operations. 134 FWD-INC ("forward and include"): 135 Input packet: [X]{msg, [Y]}[F] 136 Output packet: [F]{msg, [X]}[Y] 138 FWD-CLR ("forward and clear"): 139 Input packet: [X]{msg, [Y]}[F] 140 Output packet: [F]{msg}[Y] 142 FWD-ENC ("forward and encrypt"): 143 Input packet: [X]{msg, [Y]}[F] 144 Output packet: [F]{msg, ([X])f}[Y] 146 DEC-FWD-INC ("decrypt, forward and include"): 147 Input packet: [X]{msg, ([Y])f}[F] 148 Output packet: [F]{msg, [X]}[Y] 150 DEC-FWD-CLR ("decrypt, forward and clear"): 151 Input packet: [X]{msg, ([Y])f}[F] 152 Output packet: [F]{msg}[Y] 154 DEC-FWD-ENC ("decrypt, forward and encrypt"): 155 Input packet: [X]{msg, ([Y])f}[F] 156 Output packet: [F]{msg, ([X])f}[Y] 158 In addition to these forwarding operations, a forwarder may also 159 support management operations such as target servers' registration 160 (see below). 162 Baseline Usage Example: Hide [S] 164 This example illustrates the use of the anonymizing infrastructure to 165 satisfy the following two properties: 167 (P1) A client C sends request to a target server S without knowing 168 S's address. 170 (P2) C receives reply from S without knowing S's address. 172 The client C first interacts with an initialization server I, which 173 may be a local application or a network-based service. In its 174 message to I, C expresses its wish to access a target server S. Then 175 the initialization server I securely sends C a message containing the 176 following three items: 178 - [F], which is the unicast address of a forwarder F, or the 179 anycast address of a set of forwarders, also denoted by F. 181 - ([S])f 183 - S's ctf 185 When the client wishes to send a request to S, it builds a packet 186 containing the following contents, and sends it to [F]: 188 - (req, ck)S, where req is C's request to S, and ck is a cookie 189 associated with the packet. (req, ck)S is (req, ck) encrypted by 190 S's public key. The purpose of ck is to identify the request. 192 - ([S])f 194 After the packet is sent, C will need to keep ck and S's ctf around 195 for a while, so that they can be used later to verify the reply from 196 S. 198 When F receives the packet, it decrypts the packet, forwards it to 199 [S], with the source address of the original packet, [C], as seen by 200 F included in the packet payload. That is, F performs the operation 201 DEC-FWD-INC. 203 When S receives the packet, it builds a reply packet containing the 204 following contents, and sends it to [F]: 206 - (rep, ck)S: reply and cookie encrypted in the private key of S. 208 - [C]: the source address of the original packet as seen by F. 210 When F receives the packet, it forwards it to [C] without including 211 [S] in the packet payload, so [S] will not be revealed. That is, F 212 performs the operation FWD-CLR. 214 When C receives the packet, it decrypts the reply and cookie using 215 S's public key. By comparing the decrypted cookie with the original 216 cookie stored at C, C decides whether or not the received reply is 217 the one corresponding to its original request. 219 The following summarizes the description above. 221 Baseline Usage Example: Hide [S] 223 C->F: [C]{(req, ck)S, ([S])f}[F] 224 F: DEC-FWD-INC 226 F->S: [F]{(req, ck)S, [C]}[S] 228 S: reply 230 S->F: [S]{(rep, ck)S, [C]}[F] 232 F: FWD-CLR 234 F->C: [F]{(rep, ck)S}[C] 236 C: decrypt reply and cookie to verify the reply 238 Usage Example 1.1: Hide [S] 240 This example is an enhanced version of Baseline Usage Example above. 241 It is designed to defend against a type of replay attacks. Suppose 242 that an adversary repetitively submits C's request: 244 C->F: [C]{(req, ck)S, ([S])f}[F] 246 while monitoring packets on links that could be on the path from F to 247 S and vice versa. If the adversary can identify these packets a 248 priori, then he or she will be able to learn [S] by examining 249 destination or source addresses of these packets. It is therefore 250 important to avoid invariant bit strings, such as [C], (req, ck)S and 251 (rep, ck)S in the Baseline Usage Example above, that could be used to 252 identify these packets. 254 Usage Example 1.1, summarized below, ensures that all these packets 255 will likely have different payloads. Thus it would be difficult to 256 isolate these packets. 258 Usage Example 1.1: Hide [S] 260 C->F: [C]{(req, ck, C's ctf)S, S's ctf, ([S])f}[F] 262 F: DEC-FWD-ENC 264 F->S: [F]{((req, ck, C's ctf)S, [C])r1, (r1)S, ([C])r2, 265 (r2)f}[S] 267 S: reply 269 S->F: [S]{(rep, ck)r3, (r3)C, ([C])r2, (r2)f}[F] 271 F: DEC-FWD-CLR 273 F->C: [F]{(rep, ck)r3, (r3)C}[C] 275 C: decrypt reply and cookie to verify the reply 277 In the above, r1 and r2 are symmetrical session keys randomly 278 selected by F for an each packet, while r3 is a key selected by S. 279 This means that each resubmitted request 281 C->F: [C]{(req, ck, C's ctf)S, S's ctf, ([S])f}[F] 283 will likely result in an entirely different payload in the message 284 from F->S, S->F or F->C. 286 Usage Example 1.2: Hide [C] 288 This example illustrates the use of the anonymizing infrastructure to 289 satisfy the following two properties: 291 (P3) S receives request from C without knowing C's address. 293 (P4) S sends reply to C without knowing C's address 295 C will obtain the following two items from the initialization server: 297 - [F] 299 - [S] 301 We summarize Usage Example 1.2 as follows: 303 Usage Example 1.2: Hide [C] 305 C->F: [C]{req, C's ctf, [S]}[F] 307 F: FWD-ENC 309 F->S: [F]{req, C's ctf, ([C])f}[S] 311 S: reply 313 S->F: [S]{rep, C's ctf, ([C])f}[F] 315 F: DEC-FWD-INC 317 F->C: [F]{(rep, [S])r, (r)C}[C] 318 C: decrypt reply and verify the reply 320 Note that in the packet from F to C, F randomly selects a symmetrical 321 session key r for each packet to defend against replay attacks. In 322 such an attack, an adversary would repetitively resend the same 323 message from S to F, while monitoring links from F to C. If those 324 packets from F to C that are triggered by these repeated resends can 325 be isolated, then their destination addresses will reveal [C]. By 326 dynamically changing their payloads, these packets from F to C can 327 not be isolated easily. 329 Usage Example 1.3: Hide Both [C] and [S] 331 This example illustrates the use of the anonymizing infrastructure to 332 satisfy all the following four properties: 334 (P1) A client C sends request to a target server S without knowing 335 S's address. 337 (P2) C receives reply from S without knowing S's address. 339 (P3) S receives request from C without knowing C's address. 341 (P4) S sends reply to C without knowing C's address. 343 Thus, this usage intends to hide both addresses of C and S. 345 The procedure summarized below for Usage Example 1.3 is a combination 346 of procedures for Usage Example 1.1 and 1.2 above. Usage Example 1.3 347 has the properties of both Usage Example 1.1 and 1.2. 349 Usage Example 1.3: Hide Both [C] and [S] 351 C->F: [C]{(req, ck, C's ctf)S, C's ctf, S's ctf, ([S])f}[F] 353 F: DEC-FWD-ENC 355 F->S: [F]{((req, ck, C's ctf)S, ([C], C's ctf)r2, (r2)f)r1, 356 (r1)S}[S] 358 S: reply 360 S->F: [S]{(rep, ck)r3, (r3)C, ([C], C's ctf)r2, (r2)f}[F] 362 F: DEC-FWD-CLR 364 F->C: [F]{((rep, ck)r3, (r3)C)r4, (r4)C}[C] 365 C: decrypt reply and cookie to verify the reply 367 2. Target Server's Registration 369 A target server S interested in hiding its address [S] by using an 370 anonymizing forwarder F may register itself to an initialization 371 server I. The registration will involve S first sending an 372 encryption request to F asking for ([S])f, and then sending the 373 received ([S])f to I via F. After receiving this information from I, 374 C can send its requests to S via F, as described in the Baseline 375 Usage Example earlier. It is instructive to consider a target 376 server's registration as a process for an initialization server to 377 receive an "access ticket", which consists of information such as [F] 378 and [S])f, that allows clients' requests to reach S via F. 380 Target Server's Registration to I on Use of Forwarder F: 382 S->F: [S]{S's ctf, ([S])S}[F] 384 F: decrypt ([S])S to validate [S]'s authenticity, and 385 encrypt [S] in F's symmetric key 387 F->S: [F]{(([S])f, [F])S}[S] 389 S: decrypt (([S])f)S using S's private key to recover [F] 390 and ([S])f 392 optionally, S may send test messages to F using ([S])f 393 to check if F will forward the messages back to S 395 sign (([S])f, [F]) in S's private key 397 S->F: [S]{S's ctf, (([S])f, [F])S, [I]}[F] 399 F: FWD-CLR 401 F->I: [F]{S's ctf, (([S])f, [F])S}[I] 403 I: decrypt ([S])f, [F])S to validate the authenticity of 404 [S])f and [F] using S's public key, and then receive 405 [F], ([S])f, and S's ctf 407 This registration method has three properties worth mentioning. 408 First, it does not require S to know F's symmetric key. Second, S 409 may change to a new forwarder F' it wants to use for a given I by 410 obtaining ([S])f' from F' and sending it to I. Third, S may use 411 different Fs for different Is, for balancing loads or meeting 412 different security requirements. 414 Note that F encrypts [S] using that from ([S])S, rather than that 415 extracted from the source address of S's message. This is to defend 416 against possible impersonation of S by an adversary. Suppose that an 417 adversary S1 sends an encryption request [S1](S's ctf, [S1])[F] to F, 418 and S1 receives from F reply [F]{(([S1])f)S}[S1]. If S1 can manage 419 to send the packet [F]{(([S1])f)S}[S] to S, then S would mistakenly 420 use ([S1])f instead of ([S])f in the registration. 422 3. Multi-hop Registration and Forwarding 424 In multi-hop forwarding, a sequence of two or more forwarders are 425 used in forwarding a client's packet. These forwarders together are 426 sufficient in decrypting the address of the target server, but any 427 proper subset of them are not. 429 Multi-hop forwarding can provide additional protection against an 430 adversary who may attempt to compromise a forwarder or monitor its 431 output links. For example, by employing forwarders protected under 432 strong but different security measures, the adversary would need to 433 defeat all these security measures in order to succeed. 435 Multi-hop Registration 437 During its registration, a target server S will obtain a sequence of 438 forwarders to use. First, S chooses an F that S trusts, and sends it 439 a request asking for ([S])f. When receiving the request from S, F 440 may find an another forwarder G that F trusts. G may be under a 441 different jurisdiction, so that compromising both F and G would be 442 harder than compromising forwarders in the same jurisdiction. In 443 turn, G may find yet another forwarder H that G trusts, and so on. 444 Finally, the last forwarder will send S the necessary information 445 required by S's registration. 447 We illustrate below the multi-hop registration, using a three-hop 448 example involving three forwarders F1, F2 and F3 corresponding to F, 449 G and F, respectively. We assume here that the Fs each use a public 450 and private key pair, and hold the private key. 452 Target Server's Three-hop Registration to I on Use of 453 Forwarders F1, F2 and F3: 455 S->F1: [S]{S's ctf, ([S])S}[F1] 457 F1: decrypt ([S])S to validate [S]' authenticity using S's 458 public key, encrypt the [S] in F1's symmetric key, and 459 sign [F1] in F1's private key 461 F1->F2: [F1]{S's ctf, F1's ctf, ([S])f1, ([F1])F1}[F2] 463 F2: decrypt ([F1])F1 to validate [F1]'s authenticity using 464 F1's public key, encrypt (([S])f1, [F1]) in F2's 465 symmetric key, and sign [F2] in F2's private key 467 F2->F3: [F2]{S's ctf, F2's ctf, (([S])f1, [F1])f2, 468 ([F2])F2}[F3] 470 F3: decrypt ([F2])F2 to validate [F2]'s authenticity using 471 F2's public key, encrypt (([S])f1, [F1])f2, [F2]) in 472 F3's symmetric key, sign [F3] in F3's private key, and 473 encrypt ((([S])f1, [F1])f2, [F2])f3, ([F3])F3 in S's 474 public key 476 F3->S: [F3]{F3's ctf, (((([S])f1, [F1])f2, [F2])f3, 477 ([F3])F3)S}[S] 479 S: decrypt ([F3])F3 to validate [F3]'s authenticity using 480 F3's public key, and sign ((([S])f1, [F1])f2, [F2])f3, 481 [F3] in S's private key 483 S->F3: [S]{S's ctf, (((([S])f1, [F1])f2, [F2])f3, [F3])S, 484 [I]}[F3] 486 F3: FWD-CLR 488 F3->I: [F3]{S's ctf, (((([S])f1, [F1])f2, [F2])f3, [F3])S}[I] 490 I: receive ((([S])f1, [F1])f2, [F2])f3, [F3] 492 Multi-hop Forwarding 494 We illustrate below multi-hop forwarding with a simple usage example, 495 that corresponds to the single-hop Baseline Usage Example earlier. 497 Multi-hop Baseline Usage Example: Hide [S] 499 C->F3: [C]{(req, ck)S, ((([S])f1, [F1])f2, [F2])f3}[F3] 501 F3: DEC-FWD-INC 503 F3->F2: [F3]{(req, ck)S, (([S])f1, [F1])f2, [C]}[F2] 505 F2: DEC-FWD-INC 507 F2->F1: [F2]{(req, ck)S, ([S])f1, [C], [F3]}[F1] 508 F1: DEC-FWD-INC 510 F1->S: [F1]{(req, ck)S, [C], [F3], [F2]}[S] 512 S: reply 514 S->F1: [S]{(rep, ck)S, [C], [F3], [F2]}[F1] 516 F1: FWD-CLR 518 F1->F2: [F1]{(rep, ck)S, [C], [F3]}[F2] 520 F2: FWD-CLR 522 F2->F3: [F2]{(rep, ck)S, [C]}[F3] 524 F3: FWD-CLR 526 F3->C: [F3]{(rep, ck)S}[C] 528 C: decrypt reply and cookie to verify the reply 530 The nested encryption is similar to that in onion routing [ONION]. 532 Note that schemes similar to those of Usage Example 1.1 can be 533 applied to prevent replay attacks that exploit the fact that (req, 534 ck)S or (rep, ck)S remains an invariant in all the packets. 536 4. Threat Analysis and Counter Measure Strategies 538 Types of Treats 540 There are various types of threats regarding anonymizing forwarders. 541 We consider the following three types: 543 Type 1 threat: The forwarding infrastructure leaks address 544 information that it is supposed to hide. 546 Type 2 treat: The forwarding infrastructure is itself subject to 547 DoS Attacks. 549 Type 3 threat: The forwarding infrastructure is used as a conduit 550 for DoS attacks. 552 Countermeasure Strategies 554 The forwarding infrastructure itself should provide the bulk of the 555 means of protection against these threats. The methods should not 556 involve clients, initialization servers, and target servers, since 557 they are outside management authorities of the infrastructure. 558 Moreover, the infrastructure should not attempt to protect itself 559 through user authentication, since the infrastructure is supposed 560 to support authentication infrastructure, not vice versa. 562 Multi-hop forwarding can help defend Type 1 threats, in the sense 563 that it will make an adversary work harder in order to learn the 564 address of a target server. This is especially true if the 565 forwarders in the multi-hop sequence are under different 566 administrative authorities, because in this case the attacker will 567 need to compromise all the authorities in order to succeed. 569 To defend against Type 2 threats concerning DoS attacks on the 570 forwarding infrastructure, one can have first-hop forwarders 571 provide high-volume, light-weight filtering of requests with 572 spoofed source IP addresses. These servers working at the wire 573 speed could send challenges to the requestors, so that only those 574 with legitimate IP addresses will be able to respond. Forwarders 575 behind the first-hop ones will have their addresses hidden from 576 users. In addition, via registrations, target servers may change 577 the forwarders they use from time to time. 579 To defend against Type 3 threats concerning the forwarding 580 infrastructure being used as conduit for DoS attacks, the 581 infrastructure could reject requests from spoofed source IPs. In 582 addition, a forwarder could rate limit its output on a per link, 583 per source, or per destination basis. 585 References 587 [RQM-DRAFT] Bradner, S., and Kung, H. T., "Requirements for an 588 Anonymizing Packet Forwarder" , Draft, 589 November 2001 591 [ANYCAST] Katabi, D., and Wroclawski, J., "A Framework for Global IP- 592 Anycast (GIA)," Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 593 2000. 595 [NymIP] The NymIP Effort, http://nymip.velvet.com. 597 [ONION] Reed, M., Syverson, P., and Goldschlag, D., "Anonymous 598 Connections and Onion Routing," IEEE Journal on Selected Areas in 599 Communications, vol. 16 no. 4, May 1998, pp. 482-494. 601 [RFC1546] Milliken, W., Partridge C., and Mendez, T., "Host 602 anycasting service," RFC 1546, November 1993. 604 8. Authors' Addresses 606 HT Kung 607 Harvard University 608 33 Oxford St. 609 Cambridge MA 02138 611 Email: kung@harvard.edu 612 Phone: +1-617-496-6211 614 Scott Bradner 615 Harvard University 616 29 Oxford St. 617 Cambridge MA 02138 619 Email: sob@harvard.edu 620 Phone: +1-617-495-3864