idnits 2.17.1 draft-bradner-annfwd-req-00.txt: ** The Status of Memo section seems to be numbered ** The Abstract section seems to be numbered 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 6 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 7 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 ([FRW-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 8188 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) -- Looks like a reference, but probably isn't: '2' on line 51 == Unused Reference: 'RFC2119' is defined on line 254, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'RED' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANYCAST' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRW-DRAFT' -- Possible downref: Non-RFC (?) normative reference: ref. 'NymIP' ** Downref: Normative reference to an Informational RFC: RFC 1546 -- Possible downref: Non-RFC (?) normative reference: ref. 'ONION' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRUST' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Internet-Draft HT Kung 4 Expires May 2002 Harvard University 5 November 2001 7 Requirements for an Anonymizing Packet Forwarder 9 11 1. 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 2. 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. 43 This memo describes the requirements for such a server. A companion 44 document [FRW-DRAFT] will describe a proposed framework on the usage 45 of anonymizing forwarders and how these requirements are applicable. 47 3. Conventions Used in This Document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119 [2]. 52 4. Background 54 This memo describes the requirements for an anonymizing packet 55 forwarder to be used in situations such as the following. 57 A client needs to interact with a server (the "target server") but 58 the IP address of the target server needs to be hidden in order to 59 minimize the potential for denial of service (DoS) attacks on the 60 target server. The client first interacts with an initialization 61 server, which may be a local application or a network-based server. 62 This initialization server securely sends the client a message that 63 includes the IP address of the target server encrypted in the key of 64 a set of forwarding servers and an IP address that can be used to 65 reach the same set of forwarding servers. Additional information can 66 also be included to be used for authenticating the request. The 67 forwarding servers can be using anycast-style addressing (see 68 [RFC1546] and [ANYCAST]). 70 When the client wishes to send a message to the target server, it 71 builds the packet without including the destination IP address, and 72 sends this along with the encrypted address of the target server to 73 the IP address for the forwarding servers. The forwarding server 74 decrypts the target server address. If additional authenticating 75 information is present, the forwarding server can check that 76 information before proceeding. When all checks have been completed, 77 the forwarding server builds a packet by taking the packet supplied 78 by the client and inserting the IP address of the target server into 79 the destination address field. The packet is then sent to the target 80 server. 82 The design of the anonymizing forwarding server described in this 83 memo assumes that the use will be for low-bandwidth signaling, not 84 data transfer that may require high bandwidth. This assumption is 85 made so that rate limiting can be used to minimize the chance that 86 the anonymizing forwarding server could be used to hide a denial of 87 service attack. 89 There are many applications that fit the model of signaling defined 90 here. These include request/response messages in connection setup 91 and termination, user authentication, service registration, and 92 service discovery. These types of applications only need medium 93 bandwidth to function properly. 95 The anonymizing forwarding server of this type differs from other 96 address translation servers or devices such as NAT/VPN/Proxy. First, 97 as mentioned above, the anonymizing forwarding server is for 98 signaling, not for data transfer. Second, it is a stateless packet 99 forwarder. In particular, it does not keep any connection or session 100 state or any mapping tables that, for example, could be used to 101 generate translated IP addresses and port numbers. A consequence is 102 that the anonymizing forwarding server is oblivious to the number of 103 connections or sessions, and does not have translation tables to 104 manage. 106 The anonymizing forwarding server performs a function of decrypting a 107 packet to recover the IP address of the next forwarding hop or the 108 final destination. This function is similar to that performed by a 109 node in onion routing [ONION]. The anonymizing forwarding server 110 differs from onion routing in that it is intended to provide a stand- 111 alone anonymizing network infrastructure at the IP layer. 113 There are other application level anonymizers, including mixmaster 114 for anonymous email forwarding [MIX] and anonymizing proxy [TRUST]. 116 The anonymizing forwarding server intends to contribute to the goal 117 of supporting anonymity at the IP layer, as envisioned by the 118 "Controlled Nymity IP" effort [NymIP]. 120 5. Threat Model 122 One of the main threats we are trying to deal with is revealing the 123 IP address of the target server, but in doing so, we do not want our 124 anonymizing forwarders to become the conduit for denial of service 125 attacks. 127 Since all traffic going in and out an anonymizing forwarding server 128 is visible, our approaches need to be resistant to traffic analysis. 130 An anonymizing forwarding server may be compromised due to reasons 131 such as password leak and broken systems. In addition, an 132 imperfection of a system that hides the location of a forwarder and 133 its output links may allow an adversary to monitor the output links. 134 In these cases, the IP address of the target server could be revealed 135 to the adversary. To mitigate this threat, various approaches can be 136 taken. For example, the forwarding infrastructure can forward a 137 packet in multiple hops using forwarders under different management 138 authorities. Forwarders can hide their existence by hiding 139 themselves behind other forwarders. Forwarders can also use 140 different IP addresses at times. In this case, initialization 141 servers will need to be synchronized with the change of forwarders' 142 IP addresses. When the risk of compromised forwarders is determined 143 to be sufficiently high, the IP address of the target server can be 144 changed. 146 An anonymizing forwarding server can itself be a target of denial of 147 service attacks. It needs to be resistant to such attacks. 149 In this requirement we are not specifically concerned with protecting 150 the packet contents between the client and forwarding server since we 151 expect the end to end packet contents will be encrypted. 153 6. Requirements 155 Forwarding Function: The forwarding server MUST be able to receive an 156 arriving packet on a port, encrypt, decrypt and extract some of the 157 contents of the packet, select the IP address of the next hop using 158 the decrypted content, verify the source, build the outgoing packet, 159 and forward it to the next hop. 161 Stateless: The forwarding server MUST NOT keep any state about 162 individual packet transmissions in order to do its work. This means 163 that packets of a given application session may use different 164 forwarding servers. All messages to a forwarding server MUST contain 165 all the information that the forwarding server will need to verify 166 the source, build the packet and forward it to the next hop. All 167 information about a particular packet SHOULD be discarded as soon as 168 the transmission is complete. The destination and source IP addresses 169 SHOULD be kept, but SHOULD NOT be in a correlated way, so that rate 170 limiting can be done (see below). 172 Anycast: The forwarding server MAY use anycast-style addressing (see 173 [RFC1546] and [ANYCAST]), so that any of a number of forwarding 174 servers using the same anycast address may forward a packet sent to 175 it. 177 Multi-hop Forwarding: A forwarding server MAY support multi-hop 178 forwarding, under which a client's packet may be forwarded by a 179 sequence of two or more forwarders before reaching its target server. 180 These forwarders together are sufficient in decrypting the IP address 181 of the target server, but a subset of them are not. Multi-hop 182 forwarding can provide added protection against an adversary who 183 attempts to compromise a forwarder or monitor its output links. For 184 example, by involving forwarders protected under strong but different 185 security measures in multi-hop forwarding, we can reduce the chance 186 that a set of forwarders that are sufficient for the decryption are 187 all compromised. That is, the adversary would need to defeat all the 188 security measures, rather than just one of them, in order to succeed. 190 Scalable Deployment: Forwarding servers MUST be able to be deployed 191 in such a way that the number of servers can be raised as the demand 192 increases. 194 Overall Rate Limiting: Each forwarding server SHOULD be able to limit 195 the maximum rate at which it will forward messages in order to 196 minimize the ease with which it could be used in a denial of service 197 attack. 199 Per Next-hop Rate Limiting: In addition to putting a limit on the 200 overall rate that a single forwarding server will forward traffic to 201 a next-hop forwarder or to any one destination, there SHOULD be a 202 maximum limit on the rate at which traffic can be sent to any of 203 them. 205 Per Preceding-hop Rate Limiting: Similar to the above, there MAY be a 206 maximum rate at which traffic will be forwarded for any preceding-hop 207 forwarder or for any single source. 209 DoS Resistant: The forwarding infrastructure itself SHOULD be denial 210 of service resistant. Any forwarding server that may receive packets 211 directly from clients should be able to sustain requests arriving at 212 the wire speed. This means that the server should not have extra 213 services running that could prevent it from achieving wire-speed 214 performance. It SHOULD also be protected against SYN and other well- 215 known attacks. 217 Managing Request Queue: For any forwarding server that may receive 218 packets directly from clients, its queue of forwarding requests 219 SHOULD be DoS resistant as well. A Random Early Discard [RED] queue 220 management could be used to discard requests when they arrive at too 221 high a rate. 223 Traffic Analysis Resistant: The forwarding server SHOULD provide 224 means of inhibiting an adversary from correlating input and output 225 traffic, and thus inferring the IP address or location of the next 226 hop or the target server. For example, the forwarding server MAY 227 randomly delay packets, make all output packets of the same size, 228 randomize their transmission order, and insert false traffic. 230 Statistics and logging: The forwarding server MAY provide facilities 231 for statistics gathering and logging purposes, provided the 232 information does not correlate input and output IP addresses. 234 Encryption Schemes: The address of the target host MUST be so 235 encrypted that clients of the forwarding server and other 236 unauthorized parties cannot see the address before it is decrypted. 237 The key infrastructure required by the encryption scheme SHOULD be 238 scalable to support a large number of clients and a moderate number 239 of forwarding servers. 241 7. Security Considerations 243 We have identified two areas of security concerns. The first is the 244 necessity of minimizing the risk that forwarding servers could be 245 used to launch DoS attacks. The rate limiting requirement is one of 246 the methods to be used to address this issue. The second is the need 247 for a key management infrastructure to support encryption in the 248 forwarding server's key, and to prevent the server from being 249 compromised. Existing and future public-key infrastructure (PKI) 250 could be exploited. 252 8. References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels," RFC 2119, March 1997. 257 [MIX] Chaum, D. L., "Untraceable Electronic Mail, Return Addresses, 258 and Digital Pseudonyms," Communications of the ACM February 1981 259 Volume 24 Number 2. 261 [RED] Floyd, S., and Jacobson, V., "Random Early Detection gateways 262 for Congestion Avoidance," Volume 1, Number 4, August 1993, p. 263 397-413. 265 [ANYCAST] Katabi, D., and Wroclawski, J., "A Framework for Global IP- 266 Anycast (GIA)," Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 267 2000. 269 [FRW-DRAFT] Kung, H. T. and Bradner, S., " A Framework for an 270 Anonymizing Packet Forwarder" , 271 Draft, November 2001 273 [NymIP] The NymIP Effort, http://nymip.velvet.com. 275 [RFC1546] Milliken, W., Partridge C., and Mendez, T., "Host 276 anycasting service," RFC 1546, November 1993. 278 [ONION] Reed, M., Syverson, P., and Goldschlag, D., "Anonymous 279 Connections and Onion Routing," IEEE Journal on Selected Areas in 280 Communications, vol. 16 no. 4, May 1998, pp. 482-494. 282 [TRUST] Waldman, M., Cranor, L. F., and Rubin, A., "Trust," in P2P: 283 Harnessing the Benefits of a Disruptive Technology, edited by A. 284 Oram, O'Reilly & Associates, Sebastopol, California 2001, pp. 286 242-270. 288 8. Authors' Addresses 290 Scott Bradner 291 Harvard University 292 29 Oxford St. 293 Cambridge MA 02138 295 Email: sob@harvard.edu 296 Phone: +1-617-495-3864 298 HT Kung 299 Harvard University 300 33 Oxford St. 301 Cambridge MA 02138 303 Email: kung@harvard.edu 304 Phone: +1-617-496-6211