idnits 2.17.1 draft-rfced-info-almesberger-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 277 has weird spacing: '... IPAddr flo...' == Line 282 has weird spacing: '... IPAddr linkL...' -- 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 (October 1996) is 10054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) -- Unexpected draft version: The latest known version of draft-ietf-ipatm-framework-doc is -06, but you're referring to -07. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch is -02, but you're referring to -03. Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Expires: May 1997 Internet-Draft 3 Internet-Draft Werner Almesberger 4 Jean-Yves Le Boudec 5 Category: Informational Philippe Oechslin 6 LRC, DI-EPFL, Switzerland 7 October 1996 9 Application REQuested IP over ATM (AREQUIPA) 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific 30 Abstract 32 This document specifies a method for allowing ATM-attached hosts 33 that have direct ATM connectivity to set up end-to-end IP over ATM 34 connections within the reachable ATM cloud, on request from 35 applications, and for the exclusive use by the requesting 36 applications. This allows the requesting applications to benefit in 37 a straightforward way from ATM's inherent ability to guarantee the 38 quality of service (QoS). 40 Given a mapping from service classes, as defined by INTSERV[6], to 41 ATM traffic descriptors, Arequipa can be used to implement 42 integrated services over ATM link layers. Usage of Arequipa to 43 provide integrated services even if ATM is only available for 44 intermediate links is not discussed in this document but should be 45 straight-forward. 47 The major advantage of using an approach like Arequipa is that it 48 needs to be implemented only on the hosts using it. It requires no 49 extra service (eg. NHRP or RSVP) to be deployed on the switches or 50 routers of the ATM cloud. 52 Internet-Draft Expires: May 1997 Internet-Draft 54 We discuss the implementation of Arequipa for hosts running IPv4 and 55 IPv6. As an illustration, we also discuss how World-Wide-Web 56 applications can use Arequipa to deliver documents with a guaranteed 57 quality of service. 59 In particular we show how 61 - Arequipa can be implemented in IPv4 by slightly modifying the 62 existing implementation of support for IP over ATM [1], 63 - Arequipa can be implemented in IPv6[3] by the appropriate use of 64 flow labels and the extension of the neighbour cache, 65 - Arequipa can be used in the Web by adding extra information in 66 the headers of HTTP requests and responses. 68 Finally, we address safety and security implications. 70 1. Introduction 72 QoS guarantees are important for delivery of multi-media data and 73 commercial services on the Internet. When two applications on 74 machines running IP over ATM need to transfer data, all the 75 necessary gears to guarantee QoS can be found in the ATM layer. 76 We consider the case where it is desired to use end-to-end ATM 77 connections between applications residing on ATM hosts that have 78 end-to-end ATM connectivity. 80 Opening direct ATM connections between two applications is 81 possible, but then the already available transport protocols, like 82 TCP, can not be reused. 84 This is why we propose Application REQuested IP over ATM (AREQUIPA). 85 Arequipa allows applications to request that two machines be 86 connected by a direct ATM connection with given QoS at the link 87 level. Arequipa makes sure that only data from the applications that 88 requested the connection actually goes through that 89 connection. After setup of the Arequipa connection, the applications 90 can use the standard IP protocol suite to exchange data. 92 2. API semantics 94 We now define a semantical API for Arequipa. Note that an actual 95 API may perform additional functions (eg. mapping of a given 96 service specification to ATM traffic descriptors) 98 Internet-Draft Expires: May 1997 Internet-Draft 100 We define the three new API functions for the TCP/IP stack: 102 Arequipa_preset (socket_descriptor, destination IP address, 103 destination protid/port, destination ATM Address, 104 ATM service and QoS parameters) 106 Arequipa_preset establishes or prepares establishment of a new ATM 107 connection to the given address with the given ATM service and QoS. 108 It makes sure that any further data sent on the specified socket 109 will use the new ATM connection. 111 Arequipa_preset is invoked before a TCP/IP connection is 112 established or before sending data(grams), respectively. (Active 113 open.) 115 Arequipa_expect (socket_descriptor, allow) 117 Arequipa_expect prepares the system to use an expected incoming 118 Arequipa connection for outgoing traffic of a given socket. If 119 allow equals TRUE then, as soon as the socket receives data from 120 an incoming Arequipa connection, all its return traffic is sent 121 over that Arequipa connection. If allow equals FALSE the traffic 122 from that socket is always sent over the standard IP route. Note 123 that Arequipa_expect is only applicable to connection oriented 124 sockets, eg. TCP sockets or connected UDP sockets. 126 Arequipa_expect is invoked by the peer which is expecting 127 data(grams) or accepting connections. (Passive open.) It is 128 typically called immediately after a socket has been created. It 129 may also be called when a data transfer is already going on. 131 Arequipa_close (socket_descriptor) 133 Closes the corresponding ATM connection. Any further traffic 134 between the endpoints is routed like other traffic. Arequipa_close 135 is implied when closing the socket. 137 Note that the use of Arequipa_expect or _preset only reflects the 138 direction of the initial dialog in the Arequipa connection. Actual 139 data can flow in both directions. 141 An actual implementation may use less arguments for Arequipa_preset 142 if some of the information is already passed by other networking 143 operations. 145 Internet-Draft Expires: May 1997 Internet-Draft 147 3. Implementation with IPv4 149 To implement Arequipa with IPv4, ATMARP must be able not only to 150 handle associations of ATM addresses and IP addresses, but also 151 associations of one ATM address with an IP address plus endpoint 152 (socket). This allows to dedicate an ATM connection for the traffic 153 between two endpoints. 155 For the active open, a destination ATM address must be associated 156 with a socket. In systems using per-socket route and ARP caching, 157 this can be done by presetting the caches with the appropriate 158 values. Establishment of the SVC is delegated to ATMARP. Care must 159 be taken that routing and ARP information obtained through Arequipa 160 does not leak to other parts of the system. 162 For the passive open, an incoming SVC must be associated with the 163 socket that terminates the corresponding connection or data flow. 164 Most of this functionality is already available in the existing 165 protocol stack. To avoid an incoming Arequipa SVC to be mistaken 166 for an IP-over-ATM SVC, the setup message uses a specific Broadband 167 High Layer Identifier (BHLI), see below. Seeing the BHLI, ATMARP 168 knows that the SVC is of the dedicated type. The socket to which it 169 has to be associated is identified as soon as a datagram is received 170 through the SVC. If an Arequipa_expect has been done for that socket, 171 then the SVC is used for all return traffic of that socket. 173 If application A1 on host H1 wants a direct ATM connection to 174 application A2 on host H2 it does the following: 176 Both applications first get in contact using the standard IP over 177 ATM to exchange the ATM address of the receiver (atm2) and the 178 endpoints (S1, S2) (i.e. protocol and port number; we assume that a 179 protocol with ports, such as TCP or UDP, is used) at both hosts 180 between which communication will occur. How this is performed 181 depends on the application protocols. In Section 5 we give an 182 example for HTTP. 184 A2 invokes Arequipa_expect to indicate that it wants to make use of 185 an expected incoming ATM connection. 187 A1 invokes Arequipa_preset to open or prepare opening of an ATM 188 connection to H2 using ATM address atm2 and the QoS desired by A1 as 189 soon as data is sent through S1. The connection is associated with S1 190 such that no other traffic (e.g. generated by other applications) 191 uses the new ATM connection. 193 An Arequipa connection shall be signaled by using the procedures and 194 codings described in RFC1755 [7], with the addition that the BHLI 195 information element be included in the SETUP message, with the 196 following coding: 198 ------------------------------------------------------------------ 199 | bb_high_layer_information | 200 ------------------------------------------------------------------ 201 | high_layer_information_type 3 (vendor-specific | 202 | application id.) | 203 | high_layer_information 00-60-D7 (EPFL OUI) | 204 | 01-00-00-01 (Arequipa) | 205 ------------------------------------------------------------------ 207 Internet-Draft Expires: May 1997 Internet-Draft 209 As soon as data arrives from H1:S1 at H2:S2, the ATM connection the 210 data has arrived on is identified as the dedicated connection for 211 this data flow and S2 is changed to exclusively send on that 212 connection. 214 From this point on all traffic exchanged between S1 of A1 and S2 of 215 A2 will use the new ATM connection with the desired QoS. 217 Note that it is possible for H1 and H2 to belong to the same LIS [2] 218 and still decide to use an Arequipa connection between applications, 219 in addition to one or several other, non-Arequipa ATM connections 220 between hosts H1 and H2. There may also exist several Arequipa 221 connections between two hosts. 223 4. Implementation with IPv6 225 With IPv6, sources take advantage of the Flow Label field in 226 the IPv6 header [3]. 228 We assume as in [4] that the conceptual host model uses, among 229 others, a neighbour cache and a destination cache. The destination 230 cache holds entries about destinations to which traffic has been 231 sent recently, while the neighbour cache holds entries about 232 neighbours to which traffic has been sent recently. With the 233 classical IP over ATM model [1], entries in the neighbour cache can 234 only refer to systems in the same LIS; we propose to go beyond this 235 limitation and allow systems beyond the LIS to appear there and be 236 treated as neighbours, in the case where a direct link level 237 connection (here, an ATM connection) can be established. 239 The destination is keyed in [4] by the IP (destination) address. We 240 replace this by the IP (destination) address and flow label. 242 We assume that with IPv6, a mechanism will be provided for 243 applications to request flow labels which, at the host, form a 244 unique flow-label/destination-address pair. This will prevent two 245 different flows which go to the same destination from accidentally 246 using the same flow label. Such a uniqueness requirement is also 247 desirable for other applications which rely on 248 flow-label/destination-address pairs, like for example RSVP. 250 A typical scenario is: 252 Application A1 on host H1 and application A2 on host H2 first get in 253 contact using the standard IP over ATM to exchange their ATM address 254 (atm1, atm2) and to define a protocol, port number pair (S1, S2) and 255 flow labels (L1, L2) for the communication over the ATM connection. 256 (We assume that a protocol with ports, such as TCP or UDP, is 257 used). How this is performed depends on the application protocols. In 258 Section 5 we give an example for HTTP. 260 Internet-Draft Expires: May 1997 Internet-Draft 262 A2 tells its networking entity that it wants to send its outgoing 263 packets with flow label L2 over an expected incoming ATM connection. 264 A1 tells its data link entity to open an ATM connection to H2 using 265 ATM address atm2, with the QoS desired by A1. The connection is 266 associated with L1 and L2 as explained below so that no other 267 traffic generated by other applications uses the new ATM 268 connection. 270 From this point on all traffic exchanged between applications A1 on 271 H1 and application A2 on H2 will use this ATM connection. 273 An example of destination and neighbour cache entries at H1 is given 274 below. 276 Destination Cache 277 IPAddr flowLabel neighbourCache pathMTU 278 H2 L1 ptr1 (1) 279 H2 * ptr2 (2) 281 Neighbour Cache 282 IPAddr linkLayerAddr isRouter reachabilityState invalidationTimer 283 H2 v2 no (3) t2 284 R3 v3 yes REACHABLE t3 286 In the example, the route to destination H2 for all traffic other 287 than the one using the ATM connection requested between application 288 A1 and A2 uses the default route (perhaps set up by the classical IP 289 model), with router R3 as the next hop; v2 is a pointer to an ATM 290 interface and a VPCI/VCI that identifies the Arequipa 291 connection. Similarly, v3 points to the ATM connection to router 292 R3. ptr1 points to the first line in Neighbour Cache, and ptr2 to the 293 second one. Path MTUs (1) and (2) are obtained by ATM signaling; 294 they may be different. Reachability state (3) is determined as usual 295 by the reachability protocol [4]. 297 Host H1 must restrict the use of this ATM connection to datagrams 298 with flow label L1. Other traffic from H1 to H2 must use the generic 299 entry in the destination table (flow label = "*"). Host H1 must 300 restrict the use of flow label L1 for destination H2 to traffic 301 generated by application A1 on port S1. (The same holds by analogy 302 for host H2). 304 On the receiving side, host H2 may use label L1 for routing 305 internally the IP packets to the appropriate entity. 307 Internet-Draft Expires: May 1997 Internet-Draft 309 5. Example: Arequipa for the Web 311 This is a brief explanation of how Web [5] servers and browsers can 312 use Arequipa to transmit documents with a guaranteed QoS. 314 What we describe below does not violate the standards of HTML 315 and HTTP but makes use of their built-in extensibility. The 316 server and client we describe can thus interact seamlessly with 317 non-modified servers or clients. A similar extension could 318 be used if Web documents were to be exchanged using RSVP. 320 Browsers add one extra field in all their requests or responses to 321 indicate their ATM address. Web documents are extended with meta 322 information to describe the ATM service and corresponding QoS 323 needed to transmit them. Note that this information could be in 324 form of an intserv flowspec and mapped to ATM traffic descriptors. 326 If a browser always wants documents with QoS meta-information to be 327 delivered using Arequipa, it adds an additional field in its request 328 to indicate the port on which it is expecting the data. 330 If a browser wants to decide whether Arequipa should be used or not, 331 it does not give the port on which the server should send the data. 333 When a server gets a request with an ATM address, it checks whether 334 the requested document has QoS meta-information. If this is not the 335 case, it delivers the document like a standard server. If the 336 document has QoS meta-information, the server looks for a port 337 information in the request. If it finds a port, it opens an Arequipa 338 socket (Arequipa_preset) to the ATM address of the client with the 339 QoS given in the document. It sends the reply through this new 340 connection. If the server finds no port information, it sends only 341 the header of the reply (which includes meta-information) over the 342 standard HTTP connection, as if the client had issued a HEAD or GET- 343 IF-MODIFIED request. 345 When a client receives the header of a document it can decide whether 346 it wants the document to be transmitted using Arequipa or not. A 347 client without a priori knowledge about the document, may therefore 348 always want to retrieve the header before requesting the full 349 document. 351 Illustration: 353 A client requests some documents but wants to decide if QoS 354 sensitive documents should be sent using Arequipa or not. Thus it 355 adds to its requests its ATM address but not the socket information. 357 GET batman.mpeg 358 UserAgent: MyAgent/1.0 359 ATM-address: my_public_address.my_private_address 361 Internet-Draft Expires: May 1997 Internet-Draft 363 The server checks batman.mpeg for QoS meta info. It finds the meta 364 info and sees an ATM address, but no socket pragma in the 365 request. It only returns the header of the document, which includes 366 the meta-information: 368 HTTP/1.0 200 OK 369 Server: MyAgent/1.0 370 ATM-Service: CBR 371 ATM-QoS-PCR: 2000 372 Content-type: video/mpeg 374 The client sees the QoS info and decides that it wants to download 375 the document using Arequipa. It opens a TCP socket for listening, 376 makes the Arequipa_expect call and sends the following request: 378 GET batman.mpeg 379 UserAgent: MyAgent/1.0 380 ATM-address: my_public_address.my_private_address 381 Pragma: socket=TCP.8090 383 Again the server checks batman.mpeg for QoS meta info. It finds the 384 meta info and sees the ATM address and the socket pragma in the 385 request. It creates a TCP socket, makes the Arequipa_preset call, 386 connects its TCP socket to the one of the client and sends the 387 response over the new TCP connection: 389 HTTP/1.0 200 OK 390 Server: MyAgent/1.0 ATM.address 391 ATM-Service: CBR 392 ATM-QoS-PCR: 2000 393 Content-type: video/mpeg 395 397 When the server sends the data over the new TCP connection it also 398 sends a copy of the response header over the TCP connection on which 399 the request was made. For example, this allows a browser to spawn a 400 viewer before requesting the data, to give the Arequipa connection to 401 the viewer and to still get the status of the request over the normal 402 TCP connection. 404 6. Safety considerations (loops) 406 A major concern about ATM shortcuts in IP networks are routing 407 loops. Arequipa is not prone to such dangers since it establishes 408 connections between applications and not between hosts. All datagrams 409 traveling through an Arequipa connection are destined for a given 410 socket on the machine at the end of the connection and don't need to 411 be forwarded by the IP layer. Therefore, neither hosts nor routers 412 implementing Arequipa as described in this document must ever forward 413 IP packets received over Arequipa connections. 415 Internet-Draft Expires: May 1997 Internet-Draft 417 7. Security considerations 419 The main security problem we see with Arequipa is that it could be 420 used to bypass IP firewalls. 422 IP firewalls are used to protect private networks connected to 423 untrusted IP networks. The network is configured such that all 424 traffic going into or coming from the protected network has to go 425 through the machine(s) acting as a firewall. 427 If hosts in a network protected by a firewall are able to establish 428 direct ATM connections to hosts outside the protected network, then 429 Arequipa could be used to bypass the firewall. To avoid this, hosts 430 inside a protected network should not be given direct connectivity to 431 the outside of the network. 433 Arequipa can be used in a safe way by machines inside and outside a 434 protected network, if an application proxy is installed on the 435 firewall. In the Web, this is a typical scenario. Proxy HTTP servers 436 are often found on firewalls, not only for security reasons, but also 437 for caching. If an application proxy is used, each host can establish 438 an Arequipa connection to the proxy which can then relay and monitor 439 the traffic across the firewall. 441 Note that hosts can easily identify (and refuse) unsolicited 442 Arequipa connections by the BHLI identifier that is passed at 443 connection setup. 445 8. References 447 [1] M. Laubach, Classical IP and ARP over ATM, IETF RFC 1577 449 [2] R. G. Cole, D. H. Shur, C. Villamizar, IP over ATM: A Framework 450 Document, Internet Draft, April 96, 451 draft-ietf-ipatm-framework-doc-07, work in progress 453 [3] R. Hinden and S. Deering, Internet Protocol Version (IPv6) 454 Addressing Architecture, Internet Draft, December 1995, 455 draft-ietf-ipngwg-addr-arch-03.txt, work in progress 457 [4] T. Narten, E. Nordmark and W.A. Simpson, Neighbour Discovery for 458 IPv6 (IPv6), Internet Draft, March 96, 459 draft-ietf-ipngwg-discovery-06.txt, work in progress 461 [5] T. Berners-Lee, R. Fielding, H. Nielsen, Hypertext Transfer 462 Protocol -- HTTP/1.0, IETF RFC1945, May 1996. 464 [6] S. Shenker/J. Wroclawski, Network Element Service Specification 465 Template, Internet Draft, November, 1995, 466 draft-ietf-intserv-svc-template-02.txt, work in progress 468 [7] M. Perez, F.-C. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 469 ATM Signaling Support for IP over ATM, IETF RFC1755, 1995. 471 Internet-Draft Expires: May 1997 Internet-Draft 472 9. Authors' Address 474 Werner Almesberger, 475 Jean-Yves Le Boudec, 476 Philippe Oechslin (contact author) 478 Laboratoire de Reseaux de Communication 479 Swiss Federal Institute of Technology (EPFL) 480 1015 Lausanne 481 Switzerland 483 email: {almesber, leboudec, oechslin}@di.epfl.ch 485 Internet-Draft Expires: May 1997 Internet-Draft