idnits 2.17.1 draft-shore-midcom-protos-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 2004) is 7316 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: '1' on line 14 -- Looks like a reference, but probably isn't: '2748' on line 388 == Missing Reference: 'RFC2026' is mentioned on line 455, but not defined == Missing Reference: 'Bradner' is mentioned on line 488, but not defined -- Looks like a reference, but probably isn't: '1996' on line 488 == Unused Reference: 'Fluhrer' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC2748' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC2753' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC3303' is defined on line 439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Barbir' -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dawkins' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fluhrer' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSIS' ** Downref: Normative reference to an Informational RFC: RFC 2753 ** Downref: Normative reference to an Informational RFC: RFC 3234 ** Downref: Normative reference to an Informational RFC: RFC 3303 -- Possible downref: Non-RFC (?) normative reference: ref. 'Rosenberg' -- Possible downref: Non-RFC (?) normative reference: ref. 'Saltzer' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shore' Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Melinda Shore 3 draft-shore-midcom-protos-00.txt Cisco Systems 4 October 2003 5 Expires April 2004 7 Talking to Stuff In The Network: Middlebox Communication Models 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other docu- 22 ments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in 24 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 It is increasingly common for applications to want to influence the 35 behavior of equipment in the network, in violation of various 36 tenets underpinning the the design of IP. A number of different 37 mechanisms and architectures have been proposed, and this very 38 drafty draft is a hoped to be a start at discussing some of the 39 issues related to protocols used for middlebox communication. 41 1. Introduction 43 IP was originally designed around the end-to-end principle 44 [Saltzer] which says, among other things, that application function 45 should not be embedded in the network. This design was executed at 46 a time when the dominant values in the network were sharing and 47 maximizing communication reach. 49 As IP networking found a foothold in the commercial world, however, 50 there grew an increasing need to compartmentalize the network into 51 administrative domains where local policy could be applied. These 52 policies include things like access control, accounting, quality- 53 of-service, and so on. There was also increasing interest in per- 54 formance-enhancing intermediaries and proxies. 56 These middleboxes typically have done their work either by making 57 policy decisions based on packet contents (firewalls filtering on 58 the traditional 5-tuple or QoS-capable routers making decisions 59 based on DSCPs) or by transforming all traffic that traverses it 60 (NAT, for example). 62 Allowing the middlebox to make decisions in isolation from the end- 63 points participating in the data flows that traverse it has turned 64 out to have some serious problems. Among those is that the middle- 65 box often has no way to inspect the traffic to make decisions if 66 the traffic is encrypted (and unfortunately some network adminis- 67 trators are choosing to not encrypt traffic in order to allow mid- 68 dlebox/firewall inspection). Another is that the network should 69 not be allowed to manipulate traffic without authorization from the 70 participating endpoints (for example, it might be a problem if 71 every instance of "Gore" was changed to "Bush" without permission). 72 And another is that it's frequently difficult for middleboxes to 73 recognize relationships among parallel data streams, which has 74 proven to be a very serious problem in protocols and applications 75 which use dynamically-allocated data streams, such as VoIP and 76 streaming media. 78 Various, uncoordinated pieces of work on explicit communication 79 with network devices have progressed in parallel in the IETF, and 80 different approaches and architectures have been developed. Each 81 introduces unique problems and benefits and it may be time to step 82 back and examine what we have (or have not!) learned so far. 83 [RFC3234] discusses different types of middleboxes and their asso- 84 ciated issues, but not the protocols used in sending policy and 85 other requests to them. This memo is an attempt at categorizing 86 those protocols and architectures. 88 [Some obvious things are missing: mobile IP. Some things seem out- 89 of-scope - configuration protocols like DHCP and ipv6 neighbor dis- 90 covery, ??Teredo??, application intermediaries that function as 91 application peers, like SIP proxy servers] 93 2. Terminology 95 Middlebox: Any intermediary device performing functions other than 96 the normal, standard functions of an IP router on the datagram 97 path between a source host and destination host. See 98 [RFC3234] for a more complete discussion. 100 Off-path Signaling: "Off-path signaling" is a generic term refer- 101 ring to the establishment of an explicit policy request/commu- 102 nication connection between an application or an application 103 agent and a network device. It is called "off-path" because 104 the application agent may lie outside the application data 105 path. Also sometimes referred to as "path-decoupled signal- 106 ing." 108 On-path signaling: A generic term for referring to requests sent 109 along the same network path as the data messages they are 110 intended to affect. Also sometimes referred to as "path-cou- 111 pled signaling." 113 Relative topology: The relationship of network devices to one 114 another. Examples incude ordering of devices along a path, or 115 devices that are "next to eachother" topologically in a multi- 116 homed network. 118 3. Endpoint/Proxy-initiated approaches to middlebox communication 120 In this section we look at architectures in which the signaling or 121 middlebox communication request is initiated by a network endpoint 122 or its proxy. When an application running across a network recog- 123 nizes that it requires special services from the network, such as 124 QoS for a particular data stream, a firewall pinhole, a security 125 policy modification, etc., it initiates a request. This function 126 may be proxied by another entity acting on behalf of the endpoint. 128 This is distinct from models in which a middlebox initiates commu- 129 nication with an endpoint or another device, which we discuss 130 later. 132 Also, note that we tend to use the phrases "signaling," "middlebox 133 requests," and "middlebox communication" interchangeably throughout 134 and probably should not. 136 3.1. Client-server approach 138 This is probably the most basic model for sending requests to a 139 network device. It is the one assumed by midcom, an IETF working 140 group defining a protocol specifically to make requests of middle- 141 boxes, in this case firewalls and NATs (although the intention was 142 to devise something general enough to support a variety of middle- 143 box uses). The client-server approach is one mechanism used for 144 off-path signaling but it is not the only one. 146 In this case an endpoint, or an agent acting on behalf of the end- 147 point (for example, a VoIP call control server), initiates a con- 148 trol connection to a middlebox and sends requests, which are 149 granted or denied by the middlebox based on local administrative 150 policy. An agent may be in communication with multiple middleboxes 151 or a middlebox may be in communication with multiple agents, but 152 the basic communication model remains the same (Figure 1 shows the 153 middlebox control model -- no data streams are shown). 155 +-----------+ 156 | | 157 | | 158 | Agent | 159 | | 160 | | 161 +-----------+ 162 / \ 163 / \ 164 +-----------+ \+------------+ +------------+ 165 | | | | | | 166 | | | | | | 167 | Host 1 | | Middlebox | | Host 2 | 168 | | | | | | 169 | | | | | | 170 +-----------+ +------------+ +------------+ 172 Figure 1 174 This model raises a number of architectural issues, not the least 175 of which are location and routing. An agent has to know if there 176 are middleboxes along a given data path and if it has knowledge of 177 multiple middleboxes it has to be able to determine which are 178 relevant and which are not. An even more difficult problem is that 179 it may be the case that if there is more than one middlebox along a 180 path, requests could potentially be sensitive to topological order- 181 ing within the network. This is particularly true when one of 182 those middleboxes is a NAT and packets' transport addresses are 183 being altered in transit. 185 A clear advantage of using a client-server model for middlebox 186 requests is that the security model is relatively simple, with the 187 ability to authenticate and authorize being artifacts of a 188 straightforward relationship between the agent and middlebox as 189 well as whatever policy mechanisms are available. 191 Other examples of this kind of protocol include SOCKS [RFC1928], 192 TURN [Rosenberg] 194 3.2. On-path signaling 196 On-path signaling sends middlebox requests along the same path (or 197 is hoped to be the same path) that will be traversed by the associ- 198 ated data stream. Probably the best-known protocol and architec- 199 ture used for on-path signaling is RSVP [RFC2205], and while RSVP 200 was originally used to carry IntServ requests it has been general- 201 ized somewhat to extend its use for establishing MPLS LSPs 202 [RFC3209]. There have been proposals to use RSVP for other middle- 203 box communication applications [Shore], and there are plans to sup- 204 port middlebox communications in the IETF's next on-path signaling 205 protocol [NSIS]. 207 In on-path signaling, a request is sent between the two hosts orig- 208 inating and terminating a data stream. That is to say that the 209 source and destination addresses in the signaling request are the 210 same as those of the data stream (or proxies acting on behalf of 211 either or both endpoints). Requests are not addressed directly to 212 the middleboxes. Instead, something in the packet, for example a 213 router alert or a transport protocol port number, can be used to 214 indicate that the request is one that should be intercepted and 215 acted upon by the middlebox. Figure 2 shows the middlebox communi- 216 cation model (again, no data streams are shown). 218 +------+ +-----------+ +-----------+ +------+ 219 | |------->| |---->| |--->| | 220 |Host 1| |Middlebox 1| |Middlebox 2| |Host 2| 221 | |<-------| |<----| |<---| | 222 +------+ +-----------+ +-----------+ +------+ 224 Figure 2 226 In RSVP, path state (routing) is established as the request flows 227 from Host 1 towards Host 2, while reservation state is confirmed 228 and installed in the reverse direction, as the request flows from 229 Host 2 towards Host 1. This need not necessarily be the case. 231 This model has some clear advantages around topological issues 232 (discovery, routing, relative topology), and it can be used for 233 topology discovery and determination. One example of this is the 234 Tunnel Endpoint Discovery protocol, which is used to discover IPSec 235 gateway locations in order to establish IPSec tunnels. An entry 236 gateway injects a message into the network towards the destination 237 address of a data flow. The message is intercepted by an IPSec 238 gateway and returned to the originating gateway which then initi- 239 ates an IKE session with the discovered gateway, bringing up an 240 IPSec tunnel. 242 but there are several associated disadvantages. One is that the 243 signaling model is path-oriented, which suggests the existence of a 244 path, or at least a source and destination. A protocol like this 245 is not useful for provisioning or configuration. For example, a 246 path-coupled signaling protocol is unsuitable for sending a message 247 to a middlebox asking for specific QoS treatment for all traffic. 248 While individual requests can be sent out to request service for 249 each data stream, clearly this generates more traffic and cannot 250 solve certain middlebox problems such as asking for a more-or-less 251 static firewall pinhole for accepting incoming requests (on well- 252 known ports, for example). 254 Another difficulty is that the security model can be somewhat 255 murky. While endpoint (request initiator) credentialing can be 256 done, message authentication can be a problem in an environment 257 where nodes along the path may be modifying the contents of the 258 request and you might not have an existing relationship with other 259 nodes along the path. Authorization is difficult in the absence of 260 existing relationships, as well. 262 The most straightforward approach to securing middlebox requests in 263 this environment is to secure traffic between adjacent hops and 264 rely on transitivity. Security may not actually be transitive in 265 all situations, and it is sometimes unclear what a "hop" is, par- 266 ticularly when the protocol is being used to support a variety of 267 uses and any given node may not be relied upon to be participating 268 in a particular use. 270 4. Middlebox-initiated approaches to middlebox communication 272 In some instances, middleboxes may choose to consult with a sending 273 endpoint or with another device for further information on how to 274 process a packet. In these cases, the middlebox initiates a 275 request. 277 4.1. Callback protocols 279 In some cases, a middlebox may decide to contact a packet's sender 280 either to request additional information (say, credentials) or to 281 send it a notification. Obvious, early and crude examples of this 282 kind of use include ICMP messages like source quench and various 283 unreachables. 285 This has been suggested as one possible communication model for 286 transport intermediaries [Blumenthal] but is not in wide use. It 287 demonstrates many of the same advantages and disadvantages as call- 288 out protocols, but may have fewer firewall traversal problems 289 (which is not to say that there will be no problems). The OPES 290 documents (see below) require that an endpoint be notified and 291 allowed to authorize (or not) treatment of its request or response 292 to its request, but it remains unspecified. 294 4.2. Callout protocols 296 In a callout protocol, a middlebox initiates contact with someone 297 other than a packet's sender. One example of this is the proposed 298 architecture for a "transport triggers" service for transport layer 299 protocols (notably TCP) [Dawkins]. Another is the callout function 300 of the OPES architecture [Barbir] 302 4.2.1. TRIGTRAN 304 TRIGTRAN is path-oriented, in that it assumes the existence of two 305 participating endpoints which are sending data to one another. 307 When a transport intermediary wishes to notify the endpoints of a 308 transport event or of connection path characteristics, it generates 309 a message which is sent to the receiver of the data triggering the 310 event, rather than the sender. Note that these requests are advi- 311 sory only, but nevertheless do constitute a form of middlebox com- 312 munication. There is a reasonable expectation that an endpoint 313 that has received a TRIGTRAN notification will modify its own 314 behavior, which in turn imposes some security requirements on the 315 protocol. Figure 3 shows the flow of the control traffic (here we 316 assume that Host A is the originator of the traffic and Host B is 317 the receiver). 319 +------+ +----------------------+ +------+ 320 |Host A| |Transport Intermediary|--->|Host B| 321 +------+ +----------------------+ +------+ 323 Figure 3 325 As with path-oriented signaling and callback protocols, callout 326 protocols have the advantage of not requiring device or topology 327 discovery. The endpoints are known. However, the most common 328 authorization model for firewalls (and indeed, the fundamental 329 premise behind NATs) is that connections initiated from inside a 330 firewall or NAT are allowed and that data sent from outside a fire- 331 wall or NAT is discarded either because it's a policy violation 332 (firewalls) or because the device doesn't know where to send it 333 (NATs). Consequently, because TRIGTRAN messages are path-oriented 334 but not in-band, and because TRIGTRAN and other callout messages 335 are not embedded in the data stream of interest they will have a 336 problem reaching an endpoint if there is a NAT or firewall along 337 the path. 339 Note that in TRIGTRAN and other protocols where a network-embedded 340 device sends information that suggests to an endpoint that it mod- 341 ify its behavior (another example is when an endpoint discovers or 342 receives its external address from a NAT via midcom or another pro- 343 tocol), the middlebox must identify itself and be authorized to 344 provide the service in question. The reasons are obvious (DoS 345 attacks, connection hijacking, etc.), but this creates a somewhat 346 different expectation from the usual one that an endpoint is the 347 one who must authenticate itself to the server or network device. 349 4.2.2. Open Pluggable Edge Services (OPES) 351 The IETF's OPES working group has developed an architecture to 352 allow invocation of network-embedded application services that are 353 initiated by server-side devices. For example, requests from a 354 client may be redirected for load balancing, or a web page may be 355 automatically translated from one language to another. OPES sup- 356 ports the use of "callout servers." When a middlebox (in this case 357 an "OPES processor") receives traffic it would like to refer out 358 for processing, it encapsulates and forwards it (possibly after 359 performing some transformation itself). The transformed data are 360 returned to the OPES processor. There are essentially two middle- 361 boxes here, the OPES processor, which is a middlebox with respect 362 to the data originator, and the callout processor, which is a mid- 363 dlebox with respect to the OPES processor. See Figure 4, which 364 shows the control connections for the callout protocol. 366 +-----------------+ 367 |Callout Processor| 368 +-----------------+ 369 ^ 370 / 371 / 372 / 373 +------+ +--------------+ +------+ 374 |Host A| |OPES Processor| |Host B| 375 +------+ +--------------+ +------+ 377 Figure 4 379 It could be argued that this is actually an instance of off-path 380 signaling, much like midcom. This probably doesn't survive 381 scrutiny in the overall network context, however, because of the 382 relationships among the participants. In midcom, the device 383 requesting treatment of the sender's data has a very close trust 384 relationship with the sender (and in fact may be the sender). In 385 OPES the sender has no relationship with the callout processor and 386 is not even aware that it exists. 388 COPS [2748] is arguably another example of a callout protocol. 390 Conclusion 392 Based on the above discussion we can start to identify certain 393 properties that may be used to describe different aspects of mid- 394 dlebox communication. Among these are: 396 path-coupled/path-decoupled 397 endpoint-initiated/middlebox-initiated 398 on-path/in-stream 400 We believe that there are other distinctions that can be teased 401 out, as well, and that as we go forward with new middlebox communi- 402 cation protocols it is easily worth some effort to come to a 403 broader understanding of the issues and environments. 405 References 407 [Barbir] Barbir, A. et al. "An Architecture for Open Pluggable Edge 408 Services (OPES)," work in progress. December 2002. 410 [Blumenthal] Blumenthal, U. et al. "Securely Enabling Intermediary-based 411 Transport Services," work in progress. June 2003. 413 [Dawkins] Dawkins, S., Williams, C. and A. Yegin, "Framework and 414 Requirements for TRIGTRAN," work in progress. March 2003. 416 [Fluhrer] Fluhrer, S. "Tunnel Endpoint Discovery," work in progress 417 (expired internet draft). November 2001. 419 [NSIS] "Next Steps in Signaling (nsis)," working group charter. 420 http://www.ietf.org/html.charters/nsis-charter.html. 422 [RFC1928] Leach, M. et al. "SOCK Protocol Version 5," March 1996. 424 [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP)," RFC 425 2205, September 1997. 427 [RFC2748] Durham, D. et al. "The COPS (Common Open Policy Service) Pro- 428 tocol." RFC 2748, January 2000. 430 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin. "A Framework for 431 Policy-based Admission Control," RFC 2753, January 2000. 433 [RFC3209] Awduche, D. et al. "RSVP-TE: Extensions to RSVP for LSP Tun- 434 nels, RFC 3209, December 2001. 436 [RFC3234] Carpenter, G. and S. Brim. "Middleboxes: Taxonomy and 437 Issues," RFC 3234, February 2002. 439 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 440 Rayhan. "Middlebox communication architecture and framework, RFC 441 3303, August 2002. 443 [Rosenberg] Rosenberg, J., Mahy, R., and C. Huitema, "Traversal Using 444 Relay NAT (TURN)," work in progress, October 2003. 446 [Saltzer] Saltzer, J.H., Reed, D.P., Clark, D.D. "The End-to-End Argu- 447 ment in System Design," ACM Transactions in Computer Systems 2(4), 448 November 1984. 450 [Shore] Shore, M. "The TIST (Topology-Insensitive Service Traversal) 451 Protocol," work in progress (expired internet draft), May 2002. 453 5. Copyright 455 The following copyright notice is copied from RFC 2026 [RFC2026] 456 Section 10.4, and describes the applicable copyright for this docu- 457 ment. 459 Copyright (C) The Internet Society October 1, 2003. All Rights 460 Reserved. 462 This document and translations of it may be copied and furnished to 463 others, and derivative works that comment on or otherwise explain 464 it or assist in its implementation may be prepared, copied, pub- 465 lished and distributed, in whole or in part, without restriction of 466 any kind, provided that the above copyright notice and this para- 467 graph are included on all such copies and derivative works. How- 468 ever, this document itself may not be modified in any way, such as 469 by removing the copyright notice or references to the Internet 470 Society or other Internet organizations, except as needed for the 471 purpose of developing Internet standards in which case the proce- 472 dures for copyrights defined in the Internet Standards process must 473 be followed, or as required to translate it into languages other 474 than English. 476 The limited permissions granted above are perpetual and will not be 477 revoked by the Internet Society or its successors or assignees. 479 This document and the information contained herein is provided on 480 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 481 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 482 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 483 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 484 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 6. Intellectual Property 488 The following notice is copied from RFC 2026 [Bradner, 1996], Sec- 489 tion 10.4, and describes the position of the IETF concerning intel- 490 lectual property claims made against this document. 492 The IETF takes no position regarding the validity or scope of any 493 intellectual property or other rights that might be claimed to per- 494 tain to the implementation or use other technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; neither does it represent that it 497 has made any effort to identify any such rights. Information on 498 the IETF's procedures with respect to rights in standards-track and 499 standards-related documentation can be found in BCP-11. Copies of 500 claims of rights made available for publication and any assurances 501 of licenses to be made available, or the result of an attempt made 502 to obtain a general license or permission for the use of such pro- 503 prietary rights by implementers or users of this specification can 504 be obtained from the IETF Secretariat. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights which may cover technology that may be required to practice 509 this standard. Please address the information to the IETF Execu- 510 tive Director. 512 Author's Address 514 Melinda Shore 515 Cisco Systems 516 809 Hayts Road 517 Ithaca, NY 14850 518 USA 519 mshore@cisco.com