idnits 2.17.1 draft-ietf-aft-mcast-fw-traversal-01.txt: -(154): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(413): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(561): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(833): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-27) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == There are 30 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 3) being 63 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. ** The abstract seems to contain references ([RFC-1928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 20, 1997) is 9655 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SOCKS5' -- Possible downref: Non-RFC (?) normative reference: ref. 'Van97' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AFT Working Group D. Chouinard 3 Internet Draft Intel Corporation 4 Expires in six months November 20, 1997 6 SOCKS V5 UDP and Multicast Extensions to 7 Facilitate Multicast Firewall Traversal 9 draft-ietf-aft-mcast-fw-traversal-01.txt 11 Status of this Memo 13 This document is a submission to the IETF Authenticated Firewall 14 Traversal (AFT) Working Group. Comments are solicited and should be 15 addressed to the working group mailing list (aft@socks.nec.com) or 16 to the editor. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as ``work in 27 progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This proposal creates a mechanism for managing the ingress or egress 38 of IP multicast through a firewall. It does this by defining 39 extensions to the existing SOCKS V5 protocol [RFC-1928], which 40 provides a framework for doing user-level, authenticated firewall 41 traversal of unicast TCP and UDP traffic. However, because the 42 current UDP support in SOCKS V5 has scalability problems as well as 43 other deficiencies -- and these need to be addressed before 44 multicast support can be achieved -- the extensions are defined in 45 two parts: Base-level UDP extensions, and Multicast UDP extensions. 47 Using the SOCKS framework for managing multicast flows in/out of an 48 organization, offers numerous security advantages over what is 49 possible with a conventional firewall approach. These are spelled 50 out in the draft. 52 Table of Contents 54 1. Conventions used in this document................................3 55 2. Introduction.....................................................3 56 3. Use of Feature Discovery.........................................4 57 4. Base-level UDP Extensions........................................5 58 4.1. SOCKS Requests...................................................6 59 4.1.1. ENHANCED_UDP_MODE........................................6 60 4.2. SOCKS Replies....................................................7 61 4.3. UDP Control Channel..............................................8 62 4.3.1. UDP BIND.................................................9 63 4.3.2. UDP RELEASE.............................................11 64 4.4. Procedure for TCP-Encapsulation.................................11 65 4.5. Procedure for UDP-based Clients.................................12 66 5. Multicast Extensions............................................13 67 5.1. Assumptions and Requirements....................................14 68 5.2. UDP Control Commands and Flags..................................16 69 5.2.1. Receiving From a Multicast Group........................16 70 5.2.2. Sending to a Multicast Group............................18 71 5.2.3. Releasing a Multicast Association.......................19 72 5.2.4. Setting the TTL.........................................19 73 6. Security Considerations.........................................20 74 7. Acknowledgments.................................................21 75 8. References......................................................21 76 9. Disclaimer......................................................21 77 10. Authors' Address................................................21 79 What�s Changed 81 This revision contains the following changes from the version 00, 82 dated July 23, 1997. 84 @ The title was modified to include "to Facilitate Multicast 85 Firewall Traversal." 87 @ The document name was changed to draft-ietf-aft-mcast-fw- 88 traversal-01.txt to better reflect the purpose of the 89 document. 91 @ The abstract was shortened. 93 @ The Introduction section was added to provide background on 94 the security issues with multicast and firewalls, and how 95 SOCKS can solve them. 97 @ Clarification was added indicating that addressing 98 information must be included in UDP BIND messages for an 99 existing association. 101 @ Clarification was added on how non-proxy-based SOCKS servers 102 respond to UDP BIND commands. 104 @ The section on Multicast Assumptions and Requirements 105 (Section 5.1) was supplemented with a discussion about non- 106 proxy-based multicast-capable SOCKS servers. 108 1. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 112 this document are to be interpreted as described in [RFC-2119]. 114 2. Introduction 116 The main impetus for writing this draft is to provide a solution to 117 getting multicast safely through firewalls. This section presents 118 the case why an augmented SOCKS protocol provides such a solution. 120 Following are some of the security concerns that come to mind when 121 considering allowing multicast through a firewall: 123 1.Prevent users from inadvertently sending stuff out (i.e., 124 limit who can send content out, and with what scope) 126 2.Limit who can bring multicast content into an organization 128 3.Limit what groups can be joined 130 4.Provide protection to internal users who have joined an 131 external multicast group (consistent with the protection 132 defined by the unicast security policy) 134 5.Provide a detailed log of all multicast session activity (who 135 was listening/sending and for how long) 137 6.Limit how much bandwidth is consumed by flows (which could by 138 user dependent) to prevent over-utilization of an 139 organization�s network. 141 Nearly all of these concerns require that the firewall know the 142 identity of the user and what they are attempting to do. While the 143 same argument could be made for unicast protocols, it is actually a 144 more pervasive argument for multicast. The reasons are: 146 @ Most multicast applications have no formal control protocol 147 that a firewall can monitor in order to dynamically modify 148 filtering rules for UDP flows 150 @ The only real "control protocol" a firewall can always 151 monitor is the IGMP messages that carry multicast routing 152 protocol information (DVMRP, PIM, etc.). However, since 153 these messages are router-to-router, they do not contain 154 anything about the original initiator of the message. What�s 155 more, only the first IGMP join for a given group will even 156 traverse the firewall; subsequent joins for the same group 157 will be assimilated into the routing tree formed inside the 158 firewall. 160 The end result is that without some light-weight �out-of-band� 161 control protocol that authenticates a multicast client to the 162 firewall and makes requests of the firewall, it is not possible to 163 address most of the security concerns mentioned above. 165 Given that such a protocol is needed, ideally it should be 166 implementable in such a way that it is transparent to, and 167 independent of, the multicast application running on the client. 168 Because SOCKS is implemented at the session layer, and provides the 169 same kinds of capabilities for unicast applications, it is ideally 170 situated to provide these services for multicast applications; 171 indeed, even more so for multicast applications because of the 172 inherent challenges with IP multicast! 174 Using a multicast SOCKS solution offers the following advantages 175 over a conventional firewall that provides class D address filtering 176 as well as IGMP monitoring and filtering: 178 @ The Multicast SOCKS Server (MSS) knows the identity of the 179 user who has asked to a join a group (due to user 180 authentication). In a conventional approach, simply 181 monitoring the IGMP only reveals that somebody issued a join 182 of a particular group. 184 @ The MSS not only knows the group address that a client wishes 185 to join, it also knows the port. This enables the MSS to 186 filter traffic specific to that group address and port, and 187 block traffic to the group address that is for other ports 188 (where unsuspecting unicast services may be listening on). 189 This enables better protection of clients that have joined an 190 external group. In a conventional approach where the 191 firewall monitors IGMP, only the group address is specified; 192 not the port. 194 @ A proxy-based SOCKS server can convert multicast to unicast, 195 and in doing so, can provide enhanced security 196 (authentication, integrity, and privacy). 198 The remainder of the document discusses how the aforementioned 199 extensions are manifested into the SOCKS V5 protocol. 201 3. Use of Feature Discovery 203 Using the SOCKS feature discovery extension documented in [Van97], a 204 SOCKS client MAY query a SOCKS server to see if it supports the UDP 205 and/or Multicast extensions. In Feature Description List (FDL) 206 syntax, the tag-subtag used by the SOCKS server to indicate this 207 support is COMMAND-ENHANCED_UDP_MODE (04 04 in hexadecimal). Note, 208 ENHANCED_UDP_MODE is a new command which is described in Section 209 4.1.1. 211 The values are: 213 Value Description 214 -------------------------------------------------------- 215 X'01' Base-level UDP extensions (covered in Section 4) 216 X'02' Multicast UDP extensions (covered in Section 5) 218 SOCKS servers that support *only* the Base-level UDP extensions do 219 so only for unicast addresses. 221 SOCKS servers that support *only* the Multicast UDP extensions still 222 support the base-level UDP extensions, but only in the context of 223 providing the services described in Section 5. 225 SOCKS servers that support both extensions (i.e., for unicast and 226 multicast) must explicitly indicate both values in the tag-subtag 227 for enhanced UDP mode (e.g., 04 04 02 01 02 in hexadecimal). 229 4. Base-level UDP Extensions 231 The base-level UDP extensions augment the current SOCKS UDP support 232 by increasing efficiency and scalability, as well as providing the 233 foundation for the multicast extensions (discussed in Section 5). 235 The base-level UDP extensions provide the following new 236 functionality: 238 * Ability to control multiple UDP sockets over one control 239 connection 241 * Reduced overhead on UDP datagram handling (by reducing the 242 size of the SOCKS UDP datagram header). 244 * Ability for SOCKS client to send and *receive* TCP- 245 encapsulated UDP. 247 * Correct handling of fragmentation. 249 In order to provide these extensions, new commands are added, as 250 well as changes to some of the existing SOCKS V5 packet structures 251 and procedures. These changes are done in a way to maintain 252 compatibility between a SOCKS client or server that does not support 253 the extensions. 255 The following is a summary of the changes: 257 * The packet structure for both the UDP control channel packets 258 and the reply packet changes after the SOCKS client and 259 server enter "UDP enhanced-mode" (described below). 261 * All UDP-related commands are done on the UDP control channel 262 and, among other new fields, include an Association 263 IDentifier (AID) that uniquely identifies a particular UDP 264 session (association) between an address/port on the SOCKS 265 client and an address/port on a remote host. 267 * The following new UDP commands are added: 269 * UDP Bind: Establishes a UDP association for sending and/or 270 receiving (replaces the UDP Associate command as well as 271 the INTERFACE DATA subcommand specified in [SOCKS5]) 272 * UDP Release: Releases a previously established association. 274 * Support for TCP-encapsulation of UDP data is supported by 275 first establishing a UDP send and/or receive association for 276 TCP-encapsulation, and then sending a new packet type (SOCKS- 277 UDP-DATA-REQUEST) specifically for encapsulating UDP over 278 TCP. 280 * The TCP control connection is not terminated when a command 281 for a particular socket cannot be satisfied (since multiple 282 UDP sessions can be controlled over the connection) 284 * The SOCKS UDP data header is reduced in size by using the 285 association identifier instead of the actual destination 286 address. Further, a Datagram Identifier field is added to 287 this header to address problems with fragmentation. 289 The details of these extensions are spelled out in the following 290 sections (in a manner consistent with that used in RFC 1928). 292 4.1. SOCKS Requests 294 The SOCKS Request message has not changed, however, a new command 295 (ENHANCED_UDP_MODE) is added. 297 * CMD 298 Existing commands: 299 * CONNECT X'01' (used only for TCP) 300 * BIND X'02' (used only for TCP) 301 * UDP ASSOCIATE X'03' (not supported once Enhanced UDP Mode 302 is achieved) 304 New command: 305 * ENHANCED_UDP_MODE X'04' 307 4.1.1. ENHANCED_UDP_MODE 309 4.1.1.1. Request 311 Providing the SOCKS server advertises support for the base-level UDP 312 extensions (or even the multicast extensions), the client may send 313 this command to the server, indicating its desire to use the base- 314 level UDP extensions. The message is populated as follows: 316 VER: X'05' 317 CMD: ENHANCED_UDP_MODE (X'04') 319 All other fields are unused and SHOULD be 0s. 321 4.1.1.2. Reply 322 The reply message is the same as that used in SOCKS V5, however the 323 version number will contain the version of the UDP extension instead 324 of the SOCKS version number. The current version is X'01'. 326 Upon receiving a successful reply, the TCP control channel has 327 achieved "Enhanced UDP Mode," and subsequently, can only be used for 328 the UDP commands defined in Section 4.3. 330 4.2. SOCKS Replies 332 Once "Enhanced UDP Mode" has been established, the format of all 333 subsequent SOCKS Reply messages is as follows: 335 +------------+--------+----------+--------+--------+-------+------+ 336 | PKT TYPE(1)| SIZE(2)| REPLY(1) |FLAGS(2)| RSVD(1)| TID(2)|AID(4)| 337 +------------+--------+----------+--------+--------+-------+------+ 338 | LOCAL ADDR TYPE (1) | LOCAL ADDR (var) | LOCAL PORT (2) | 339 +---------------------+-------------------+-----------------------+ 340 | REMOTE ADDR TYPE(1) | REMOTE ADDR (var) | REMOTE PORT (2) | 341 +---------------------+-------------------+-----------------------+ 343 The fields in the Reply packet are as follows: 345 * PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 346 * SIZE: Total size (in octets) of this message, in network 347 order. 348 * REPLY: 349 Existing return codes (SOCKS V5): 350 * X'00' succeeded 351 * X'01' general SOCKS server failure 352 * X'02' connection not allowed by ruleset 353 * X'03' Network unreachable 354 * X'04' Host unreachable 355 * X'05' Connection refused 356 * X'06' TTL expired 357 * X'07' Command not supported 358 * X'08' Address type not supported 359 New return codes: 360 * X'10' Bad Association ID 361 * X'11' Multicast Receive not allowed by ruleset 362 * X'12' Multicast Send not allowed by ruleset 363 * X'13' Bad Association context 364 * X'14' Bad multicast address 365 * X'15' TTL value not allowed by ruleset 366 * FLAGS: Command-dependent flag 367 * RSVD: Reserved. 368 * TID: A 2-byte opaque Transaction Identifier that is set by 369 the client in the request and is returned by the server in a 370 response to a particular request. The server does not use or 371 interpret this value in any way; it merely returns it in the 372 response to a particular request. 373 * AID: A 4-byte opaque Association Identifier that identifies 374 a particular association. 376 * LOC ADDR TYPE/ADDR/PORT: Addressing information on the local 377 side of the SOCKS server; that is, on the same side as the 378 SOCKS client. The ADDR TYPEs and the format of the ADDR are 379 the same as those in SOCKS V5. 380 * REM ADDR TYPE/ADDR/PORT: Addressing information on the remote 381 side of the SOCKS server. The ADDR TYPEs and the format of 382 the ADDR are the same as those in SOCKS V5. 384 4.3. UDP Control Channel 386 Once "Enhanced UDP Mode" has been established, the format of all 387 subsequent SOCKS UDP Control messages is as follows: 389 +------------+--------+----------+--------+--------+-------+------+ 390 | PKT TYPE(1)| SIZE(2)| UDPCMD(1)|FLAGS(2)| RSVD(1)| TID(2)|AID(4)| 391 +------------+--------+----------+--------+--------+-------+------+ 392 | LOCAL ADDR TYPE (1) | LOCAL ADDR (var) | LOCAL PORT (2) | 393 +---------------------+-------------------+-----------------------+ 394 | REMOTE ADDR TYPE(1) | REMOTE ADDR (var) | REMOTE PORT (2) | 395 +---------------------+-------------------+-----------------------+ 397 The fields in the CONTROL CHANNEL packet are as follows: 399 * PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 400 * SIZE: Total size (in octets) of this message, in network 401 order. 402 * UDP CMD: UDP command 403 * UDP BIND: X'05' (new) 404 * UDP RELEASE: X'06' (new) 405 (Note: additional commands are defined in the Multicast 406 extensions section of this document) 407 * FLAGS: A command-dependent bit-mask. These values are bit- 408 wise ORed to form the actual flag. 409 Valid flags are: 410 * RECEIVE-FROM: X'0001' 411 * SEND-TO: X�0002� 412 * UDP-UNICAST: X�0004� 413 * TCP-ENCAPSULATED: X�0008� � Indicates that datagrams will 414 be encapsulated in TCP using the procedures in Section 4.4. 415 (Note: additional commands are defined in the Multicast 416 extensions section of this document) 417 * RSVD: Reserved. 418 * TID: 2-byte opaque Transaction Identifier - client sets in 419 request, server returns in response. Enables client to 420 couple replies to requests. 421 * AID: 4-byte opaque Association Identifier 422 * LOC ADDR TYPE/ADDR/PORT: Local (source) address information 423 on the SOCKS client. The ADDR TYPEs and the format of the 424 ADDR are the same as those in SOCKS V5. 425 * REM ADDR TYPE/ADDR/PORT: Remote address information (for the 426 ultimate destination). The ADDR TYPEs and the format of the 427 ADDR are the same as those in SOCKS V5. 429 The use of these fields is command dependent and is further 430 described below. 432 4.3.1. UDP BIND 434 4.3.1.1. Request 436 The SOCKS client sends the UDP BIND command each time a new binding 437 (or association) is made between the SOCKS client and a UDP source 438 or destination, enabling the SOCKS Server to establish a "UDP Relay" 439 for the association. 441 The client MUST populate the following fields: 443 PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 444 SIZE: Total size (in octets) of this message, in network order. 445 UDP CMD: UDP BIND (X'05') 446 FLAGS: A bit-wise OR of the various flags defined in Section 447 4.3. 449 Examples: 450 RECEIVE-FROM | SEND-TO | UDP-UNICAST - client wants to send 451 and receive using the unicast UDP method. 453 RECEIVE-FROM | UDP-UNICAST - client wants to only receive 454 using the unicast UDP method. 456 RECEIVE-FROM | SEND-TO | TCP-ENCAPSULATED-UDP - client wants 457 to send and receive using the TCP-encapsulated method. The 458 client must do a UDP BIND with the SEND and TCP-ENCAPSULATED- 459 UDP flags set, and get a successful response before following 460 the procedures in Section 4.4. 462 Other combinations are also possible, however, UDP-UNICAST 463 are TCP-ENCAPSULATED-UDP are mutually exclusive. 465 RSVD: Unused (X�00�). 466 TID: Contains a unique value (chosen by the client) that enables 467 the client to identify the reply to this particular 468 request. 469 AID: Contains an existing association ID if a send or receive 470 association already exists on this same socket to the 471 destination address or X'00000000'. 472 LOCAL ADDR TYPE/ADDR/PORT: Contains the address and port that 473 the client will use to send the UDP datagrams on for this 474 association. 475 REMOTE ADDR TYPE/ADDR/PORT: Contains the remote (destination) 476 address and port that the client wishes to send to or 477 receive from. 479 It is permissible for a SOCKS client to establish a send or receive 480 association to the same remote address in one UDP BIND operation, or 481 by sending a another UDP BIND. Subsequent UDP BINDs SHOULD include 482 the existing AID rather than establishing an entirely new AID for 483 the reverse direction, though the addressing information MUST still 484 be included. 486 SOCKS client implementations are free to choose how many and which 487 UDP sockets they control over a single TCP control connection. For 488 example, a SOCKS client may control all UDP sockets for the entire 489 client over a single control connection. Alternatively, it could 490 group only those UDP sockets being used by a given process over a 491 single control connection. It could even degenerate into the SOCKS 492 V5 model of creating a control channel for each UDP socket, though 493 this practice is not recommended. 495 4.3.1.2. Reply Processing 497 The reply to a UDP BIND will contain the following information: 499 PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 500 SIZE: Total size (in octets) of this message, in network order. 501 REPLY: succeeded (X'00') or specific failure. Note: if the 502 SOCKS server cannot entirely satisfy the request, it MUST 503 fail the request, and send back an appropriate failure 504 code. 505 FLAGS: Contains a bit-wise OR of the parts of the request that 506 the SOCKS server could satisfy (even if the entire request 507 is failed due to parts that could not be satisfied). 508 RSVD: Unused (X�00�). 509 TID: Will contain the same value as that used in the 510 corresponding request. 512 If the REPLY is a failure, then the remaining fields are not 513 populated and SHOULD be 0s. If REPLY is succeeded, then the 514 remaining fields MUST be populated as follows: 516 AID: The AID will contain a unique identifier (the SOCKS server 517 determines the extent of the uniqueness) that the client 518 must use in subsequent UDP commands referring to this 519 association. The AID must also be used in the SOCKS header 520 on the UDP datagrams (discussed below). 521 LOCAL ADDR TYPE/ADDR/PORT: The Address on the SOCKS server that 522 the SOCKS client must send to for UDP datagrams to be 523 forwarded. This is also the address that the SOCKS server 524 will send from when forwarding datagrams to the SOCKS 525 client. Note: non-proxy-based SOCKS servers would fill 526 this field in with the destination address specified by the 527 client in the REMOTE ADDR fields in the UDP BIND. 528 REMOTE ADDR TYPE/ADDR/PORT: The address information, specific to 529 the interface, that the SOCKS server will send (or receive) 530 on, on behalf of the SOCKS client for this particular 531 association. On a multi-homed SOCKS server, this address 532 is usually not reachable by the SOCKS client, but is 533 reachable by the host on the remote side of the SOCKS 534 server. Note: non-proxy-based SOCKS servers would fill this 535 field in with the client�s local address specified by the 536 client in the LOCAL ADDR fields in the UDP BIND. 538 If a UDP Control Channel is closed, the SOCKS Server MUST release 539 all associations established on that control channel. Thus, 540 implementations should not necessarily close the control connection 541 if a UDP BIND fails (as was common practice in SOCKS V5 when a UDP 542 ASSOCIATE failed), unless there are no other UDP associations active 543 or the implementation desires this behavior. 545 4.3.2. UDP RELEASE 547 4.3.2.1. Request 549 The SOCKS client sends the UDP RELEASE command when a previously 550 established association is to be terminated. The UDP RELEASE must 551 contain the AID for the particular UDP association to be terminated. 552 It MUST also contain the appropriate flag(s) for which the 553 association is to be released. 555 PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 556 SIZE: Total size (in octets) of this message, in network order. 557 UDP CMD: UDP RELEASE (X'06') 558 FLAGS: Contains a bit-wise OR of one or more of the following: 559 RECEIVE-FROM (X�0001�) 560 SEND-TO (X�0002�) 561 Note: it is permissible for an implementation to send X�03� 562 (an OR of RECEIVE-FROM and SEND-TO) even if it had 563 previously only established a send or receive association, 564 but not both. 565 RSVD: Unused (X�00�). 566 TID: contains a unique value (chosen by the client) that enables 567 the client to identify the reply to this particular 568 request. 569 AID: Association Identifier that identifies the UDP association 570 to be released. 572 4.3.2.2. Reply Processing 574 The SOCKS Server will send a REPLY to a UDP RELEASE with the 575 following fields populated: 577 PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 578 SIZE: Total size (in octets) of this message, in network order. 579 REPLY: succeeded (X'00') or specific failure 580 FLAGS: Same as those specified in the request. 581 RSVD: Unused (X�00�). 582 TID: Will contain the same value as that used in the 583 corresponding request. 584 AID: Association Identifier contained in the UDP RELEASE 586 4.4. Procedure for TCP-Encapsulation 588 Once a client has established an association ID for TCP-encapsulated 589 data transmission, then it must send the encapsulated data over the 590 UDP control channel using the following packet structure: 592 +-------------+----------+---------+-----------------+ 593 |PKT TYPE (1) | SIZE (2) | AID (4) | DATA (variable) | 594 +-------------+----------+---------+-----------------+ 596 PKT TYPE: SOCKS-UDP-DATA-REQUEST (X'03') 597 SIZE: Total size (in octets) of this message, in network order. 598 AID: Association ID 599 DATA: Application data. Note: The size of the application data 600 is SIZE � 7. 602 There is no reply to a SOCKS-UDP-DATA-REQUEST. The SOCKS server 603 either silently relays the request or discards the packet if it 604 cannot or will not relay it. 606 The programming interface MUST report an available buffer space for 607 UDP datagrams that is no more than 65,529 decimal (2^16 � 7) since 608 the two-byte size field in the header includes the 7-byte header 609 itself. 611 It is permissible for a client to establish and control multiple UDP 612 associations (TCP-encapsulated or otherwise) over a single control 613 channel. Thus, SOCKS clients and servers that support TCP- 614 encapsulation MUST support receiving SOCKS-UDP-DATA-REQUEST and 615 SOCKS-UDP-CONTROL-REQUEST packets on the same control connection. 617 4.5. Procedure for UDP-based Clients 619 In a manner similar to SOCKS V5, a UDP-based client operating in 620 enhanced UDP mode MUST send its datagrams to the UDP relay server at 621 the UDP port indicated by LOCAL ADDR and PORT in the reply to the 622 UDP BIND request. If the selected authentication method provides 623 encapsulation for the purposes of authenticity, integrity, and/or 624 confidentiality, the datagram MUST be encapsulated using the 625 appropriate encapsulation. 627 Each UDP datagram carries a UDP request header with it (note this 628 request header differs significantly from that used in SOCKS V5). 630 +---------+----------+----------+---------+-----------------+ 631 | RSV (1) | FRAG (1) | DGID (2) | AID (4) | DATA (variable) | 632 +---------+----------+----------+---------+-----------------+ 634 The fields in the UDP Data header are: 636 RSV: Reserved X'00' 637 FRAG: Current fragment number 638 00 = standalone (not fragmented) 639 1-127 = fragment # specific to this DGID 640 MSB set (128-255) = End of fragment 641 DGID: Datagram Identifier � opaque Identifier that uniquely 642 identifies the fragments of a specific datagram 643 AID: Association Identifier 644 DATA: user data 646 As in SOCKS V5, when a UDP relay server decides to relay a UDP 647 datagram, it does so silently, without any notification to the 648 requesting client. Similarly, it will drop datagrams it cannot or 649 will not relay. 651 Furthermore, when a UDP relay server receives a reply datagram from 652 a remote host, it MUST encapsulate that datagram using the above UDP 653 request header and any authentication-method-dependent 654 encapsulation. 656 The SOCKS server must ensure that only datagrams originated from the 657 expected remote host (i.e., the one designated in the REMOTE ADDR 658 information in the UDP BIND) are relayed to the SOCKS client. Any 659 datagrams arriving from a source IP address other than the one 660 recorded for the particular association MUST be dropped. 662 The programming interface on the SOCKS client MUST report an 663 available buffer space for UDP datagrams that is 8-Bytes smaller 664 that the actual space provided by the operating system. This allows 665 for the SOCKS UDP data header. 667 Fragmentation is optional and is handled the same as that documented 668 in [RFC-1928], with the following exception: 670 * When fragmentation is supported and a datagram is fragmented, 671 the DGID field MUST be populated with a unique value that 672 remains constant for all fragments of the particular datagram 673 on the particular association. Note: DGID MUST be unique to 674 the degree that no other SOCKS data header with the same AID 675 uses the same value until the last fragment of a given 676 datagram is transmitted. Implementations are encouraged to 677 preserve the uniqueness longer by using a monotonically 678 increasing counter for each datagram that is fragmented. The 679 receiving end of the fragments can use the DGID to ensure 680 that all fragments of the *same* datagram are received 681 properly before passing the datagram up to the application 682 layer. 684 5. Multicast Extensions 686 If during feature discovery (described in Section 3), a SOCKS server 687 advertises support for the Multicast UDP extensions, then the SOCKS 688 client and server must follow the guidelines set forth in this 689 section as well as support the base-level UDP extensions specified 690 in Section 4 (for multicast usage). The procedure for the SOCKS 691 client to indicate to the SOCKS server that it wants to use the 692 multicast extensions is the same as that described in Section 4.1.1 693 and is summarized below. 695 1. SOCKS client does feature discovery to the SOCKS server and 696 learns whether or not Multicast UDP extensions are supported 697 2. If so, the SOCKS client may send ENHANCED_UDP_MODE command 698 3. After a successful reply, the SOCKS client may use the 699 multicast extensions. 701 5.1. Assumptions and Requirements 703 The following list provides some assumptions and requirements about 704 the deployment and usage of SOCKS in a multicast environment. The 705 actual protocol details in the next section are in large part 706 derived from these assumptions. 708 * A Multicast-capable SOCKS Server (MSS) is a SOCKS server that 709 supports the multicast extensions defined below. It MAY also 710 support all of the SOCKS V5 capabilities defined in [RFC- 711 1928], including TCP services. However, a MSS could be 712 dedicated for multicast usage only. 713 * A Multicast-capable SOCKS Client (MSC) configuration will 714 specify the MSS address, as well as the range of class D IP 715 addresses and TTL for which it must use the MSS. 716 * The MSS is not required to have the capabilities of a 717 multicast router (mrouter) built into it. A MSS could 718 coexist with a mrouter, collectively forming a barrier 719 between an internal and external multicast network (e.g., 720 Mbone) through which all multicast traffic must pass in order 721 to enter or leave the internal network. See Figure 1 below 722 for an example of such an arrangement. 724 _________ ______ ____________ 725 | | | | / Internal \ 726 ========| Mrouter |-------| MSS |------| Network | 727 |_________| |______| \____________/ 728 tunnel to | 729 external net __|___ 730 (mbone) | | 731 | MSC | 732 |______| 734 Figure 1: Example Usage of a SOCKS Multicast Server 736 Other possibilities exist where perhaps the MSC exists on the 737 "external" network. However, for the purpose of the 738 discussion in Section 5, the MSC is assumed to be on the 739 "internal" network, and internal and external are relative to 740 Figure 1. 742 * The MSS SHOULD support two different modes of operation for 743 multicast: 745 * Multicast-to-Unicast Mode (MU-mode) - the MSS receives 746 packets from an external multicast group and unicasts them 747 to internal MSCs who have established a receive association 748 to that group. Similarly, any packets received from an 749 internal MSC are multicast externally, as well as unicast 750 to the other MSCs that have a receive association to the 751 particular multicast group address. 753 * Multicast-to-Multicast Mode (MM-mode) - the MSS receives 754 packets from an external multicast group and multicasts 755 them to internal MSCs on the same multicast group address. 756 Similarly, packets received by the MSS from an internal MSC 757 on a particular multicast address are multicast externally 758 on the same address. 760 MM-mode provides less control than MU-mode in that non-SMCs 761 could listen to a group address once it's allowed in. 762 However, MM-mode significantly increases efficiency and 763 scalability since it needs only to multicast a given 764 datagram once rather than unicasting a copy to each SMC 765 with an association to the multicast group. 767 When operating in MM-mode, no UDP data headers will be used 768 on datagrams since authentication-method-dependent 769 encapsulation is not currently possible for a group; hence, 770 handling fragmentation is not an issue. Note: in order to 771 support encapsulation, an authentication-method-dependent 772 procedure is needed to securely distribute shared security 773 parameters to each of the members of a particular group. 774 This mechanism is currently not defined, and is for further 775 study. 777 How the mode is configured on the MSS, and whether it applies 778 globally, on a user basis, or a multicast group basis, is 779 implementation dependent. 781 * In both modes, the MSS MUST NOT forward packets from internal 782 hosts that have not authenticated themselves to the MSS and 783 received permission to receive from or send to a multicast 784 group. 786 * MSSs SHOULD support filtering/blocking of externally 787 originated multicast datagrams based on a configurable list 788 of source addresses. This allows an MSS to be aware of other 789 MSSs that share the same border between the two networks 790 (e.g., corporate network and the Internet), enabling it to 791 filter potential duplicate packets that originated from one 792 of the other MSSs. 794 * The implementation of a MSS may or may not be based on a 795 proxy architecture. Typically, SOCKS servers have been 796 implemented as a proxy; in such case, the UDP streams are 797 received by a process on the MSS and then retransmitted (in 798 either MU-MODE or MM-MODE fashion). Alternatively, an MSS 799 could be implemented in such a way that the UDP datagrams are 800 not proxied at the application layer, but routed at the 801 network layer. In this case, SOCKS acts as a control 802 protocol to a mrouter-like device in order to dynamically 803 modify the multicast UDP filter rules. 805 5.2. UDP Control Commands and Flags 807 In order to support multicast, the following functionality is needed 808 between the MSC and MSS: 810 * Start/stop receiving datagrams from a multicast group 811 * Start/stop allowing the sending of datagrams to a multicast 812 group 813 * Change the multicast scope (TTL) that the MSS uses when 814 sending (relaying) the datagrams to a multicast group 816 To provide these capabilities, the following additions are made to 817 the usage of the base-level UDP extensions: 819 * Flags are added to the UDP BIND command and reply (UDP- 820 MULTICAST, MM-MODE, MU-MODE), which allow the MSC to 821 establish a multicast-receive or multicast-send association 822 (or both) using a single association ID (AID), as well as to 823 request and learn the multicast mode from the MSS. 824 * A new UDP command (SET-MCAST-TTL) has been added to control 825 the changing of the multicast scope. 827 The values for the new command and the command flags are defined as 828 follows: 830 UDP Command: 831 * UDP BIND: 832 * command flags 833 * UDP-MULTICAST: X�0010� (16 Decimal) - acts as a modifier 834 to the other flags defined in defined in Section 4.3. 835 * Multicast-to-Unicast Mode (MU-MODE): X'0020' (32 836 Decimal) 837 * Multicast-to-multicast Mode (MM-MODE): X'0040' (64 838 Decimal) 839 * SET TTL: X'07' 841 The details of the new multicast commands/flags follow below. 843 5.2.1. Receiving From a Multicast Group 845 5.2.1.1. Request 847 A UDP BIND command containing both the RECEIVE-FROM and UDP- 848 MULTICAST FLAGs set, indicates the MSC's desire to receive packets 849 from a particular multicast group. If the MSC has already 850 established an association to this multicast group on the same 851 socket (via the SEND-TO/UDP-MULTICAST flags), then the MSC SHOULD 852 include the existing AID. Note: while it is possible for the SMC to 853 create an entirely new AID, it is potentially more wasteful on the 854 MSS, and is not recommended. 856 As in the base-level UDP extensions, a client implementation MAY 857 establish both a send and receive association in one or two UDP BIND 858 operations. If the MSC groups the send and receive request together 859 and the MSS can not satisfy the entire request, the reply to the UDP 860 BIND will fail with an appropriate failure and the FLAGS SHOULD be 861 set with what the MSC is permitted to do (relative to what was 862 requested). 864 The MSC MUST populate the following fields: 866 PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 867 SIZE: Total size (in octets) of this message, in network order. 868 UDP CMD: UDP BIND (X'05') 869 FLAGS: Bitwise OR of RECEIVE-FROM and UDP-MULTICAST. May 870 optionally include MM-MODE and/or MU-MODE to indicate the 871 MSC�s preference of the mode. If both flags are included 872 or excluded, the client has no preference. The MSS is not 873 obligated to honor the MSC�s preference, but SHOULD if 874 possible (i.e., it doesn�t violate security policy). 875 Additionally, the use of TCP-ENCAPSULATED-UDP is allowed 876 with RECEIVE-FROM and UDP-MULTICAST, and is mutually 877 exclusive with the MM-MODE flag. 878 RSVD: Unused (X�00�). 879 TID: Unique Transaction ID generated by the MSC. 880 AID: Contains an existing association ID if a send-association 881 already exists on this same socket to the same multicast 882 group or X'00000000'. 883 LOCAL ADDR TYPE/ADDR/PORT: contains the unicast address and port 884 (on the MSC) that the MSS will use if MU-mode is employed. 885 REMOTE ADDR TYPE/ADDR/PORT: contains the multicast group address 886 that the MSC desires to join. 888 5.2.1.2. Reply Processing 890 The successful response to this command will contain the following 891 fields populated by the MSS: 893 PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 894 SIZE: Total size (in octets) of this message, in network order. 895 REPLY: one of: 896 * X�00� Succeeded 897 * X'10' Bad Association ID 898 * X'11' Multicast Receive not allowed by ruleset 899 * X'12' Multicast Send not allowed by ruleset 900 * X'14' Bad multicast address 901 Note: if the SOCKS server cannot entirely satisfy the 902 request, it MUST fail the request, and send back an 903 appropriate failure code. 904 FLAGS: Contains a bit-wise OR of the parts of the request that 905 the SOCKS server could satisfy (even if the entire request 906 is failed due to parts that could not be satisfied) 907 including selection of the multicast mode. 908 RSVD: Unused (X�00�). 910 TID: Contains the MSC-generated transaction ID in the 911 corresponding request. 912 AID: Unique Identifier for this association. 913 LOCAL ADDR TYPE/ADDR/PORT: If MU-Mode is used, these fields 914 contain the unicast address and port on the MSS that the 915 MSC will receive datagrams from. 916 REMOTE ADDR TYPE/ADDR/PORT: Contains the multicast group address 917 that the MSC requested to join. 919 Upon receiving a successful reply, a multicast receive association 920 has been established between the MSC and MSS, and the MSC may begin 921 receiving any traffic generated to the group address. However, 922 before the MSC can send to the group, it must establish a "send 923 association" by following the procedure in Section 5.2.2. 925 5.2.2. Sending to a Multicast Group 927 5.2.2.1. Request 929 A UDP BIND command containing both the SEND-TO and UDP-MULTICAST 930 FLAGs set indicates the MSC's desire to send to a particular 931 multicast group. This command must be issued by the MSC regardless 932 if the MSC has already established a receive-association (by using 933 UDP BIND with the RECEIVE-FROM/UDP-MULTICAST flags). If the MSC has 934 already established a receive association to this multicast group on 935 the same socket, then the MSC SHOULD include the existing AID. 936 Note: while it is possible for the SMC to create an entirely new 937 AID, it is potentially more wasteful on the MSS, and is not 938 recommended. 940 The MSC MUST populate the following fields: 942 PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 943 SIZE: Total size (in octets) of this message, in network order. 944 UDP CMD: UDP BIND (X'05') 945 FLAGS: Bitwise OR of SEND-TO and UDP-MULTICAST. May optionally 946 include MM-MODE and/or MU-MODE to indicate the MSC�s 947 preference of the mode. If both flags are included or 948 excluded, the client has no preference. The MSS is not 949 obligated to honor the MSC�s preference, but SHOULD if 950 possible (i.e., it doesn�t violate security policy). 951 Additionally, the use of TCP-ENCAPSULATED-UDP is allowed 952 with SEND-TO and UDP-MULTICAST, and is mutually exclusive 953 with the MM-MODE flag. 954 RSVD: Contains the TTL value (1-255) the MSS should use during 955 transmission to the multicast group. 956 TID: Unique Transaction ID generated by the MSC. 957 AID: Contains an existing association ID if a receive- 958 association already exists on this same socket to the same 959 multicast group or X'00000000'. 960 LOCAL ADDR TYPE/ADDR/PORT: Contains the unicast address and port 961 (on the MSC) that the MSS will receive from if MU-mode is 962 employed. 964 REMOTE ADDR TYPE/ADDR/PORT: Contains the multicast group address 965 that the MSC desires to send to. 967 Upon receiving a successful reply, a multicast send-association has 968 been established between the MSC and MSS. 970 5.2.2.2. Reply Processing 972 The response to this command will contain the following fields 973 populated: 975 PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 976 SIZE: Total size (in octets) of this message, in network order. 977 REPLY: one of: 978 * X'10' Bad Association ID 979 * X'11' Multicast Receive not allowed by ruleset 980 * X'12' Multicast Send not allowed by ruleset 981 * X'14' Bad multicast address 982 FLAGS: if REPLY is succeeded, then contains a bit mask 983 containing the mode selected by the MSS 984 Multicast-to-Unicast Mode (MU-MODE): X'0020' 985 or 986 Multicast-to-multicast Mode (MM-MODE): X'0040' 987 RSVD: Unused (X�00�). 988 TID: Contains the MSC-generated transaction ID in the 989 corresponding request. 990 AID: Unique Identifier for this association. 991 LOCAL ADDR TYPE/ADDR/PORT: If REPLY is succeeded and FLAGS is 992 MU-Mode, these fields contain the unicast address and port 993 on the MSS that the MSC MUST send datagrams to for them to 994 be relayed to the multicast group. 995 REMOTE ADDR TYPE/ADDR/PORT: If REPLY is succeeded and FLAGS is 996 MM-Mode, these fields contain the multicast address and 997 port that the MSC MUST send datagrams to for them to be 998 relayed to the multicast group specified in the request. 999 Typically this would be the same as that specified in the 1000 request. 1002 5.2.3. Releasing a Multicast Association 1004 Releasing a multicast send or receive association (or both) is 1005 identical to the procedure described for the base-level UDP 1006 extensions in Section 4.3.2. 1008 5.2.4. Setting the TTL 1010 5.2.4.1. Request 1012 The SOCKS MSC uses the SET TTL command to instruct the MSS of the 1013 TTL (Time-to-Live) value that it SHOULD use when sending datagrams 1014 to a particular multicast group. This command is only valid for an 1015 established multicast send association. 1017 PKT TYPE: SOCKS-UDP-CONTROL-REQUEST (X'01') 1018 SIZE: Total size (in octets) of this message, in network order. 1019 UDP CMD: SET TTL (X'07') 1020 FLAGS: unused (X'0000') 1021 RSVD: Contains the TTL value (1-255) the MSS should use during 1022 transmission to the multicast group. 1023 TID: Unique Transaction ID generated by the MSC. 1024 AID: Contains an existing association ID. 1026 5.2.4.2. Reply Processing 1028 The reply to a SET TTL will be populated as follows: 1030 PKT TYPE: SOCKS-UDP-CONTROL-REPLY (X'02') 1031 SIZE: Total size (in octets) of this message, in network order. 1032 REPLY: one of: 1033 succeeded (X'00') 1034 Bad Association ID (X'10') 1035 Bad Association context (X'13') - No send association is 1036 established 1037 TTL value not allowed by ruleset (X'15') � TTL value is too 1038 high 1039 TID: Contains the MSC-generated transaction ID in the 1040 corresponding request. 1041 FLAGS: Unused (X'0000') 1042 AID: Unique Identifier for this association. 1044 6. Security Considerations 1046 This document describes extensions to [RFC-1928] which itself is a 1047 security protocol for the session-layer traversal of IP network 1048 firewalls. As in [RFC-1928], the security of firewall traversal is 1049 highly dependent on the authentication and encapsulation methods 1050 provided by a particular implementation, and selected during the 1051 negotiation between the SOCKS client and SOCKS server. 1053 Multicast-specific considerations include: 1055 * MM-Mode vs. MU-Mode: MU-Mode is more secure than MM-Mode for 1056 two reasons: 1057 1.) Packets are specifically unicast from the SOCKS server to 1058 the SOCKS client, and vice-versa, making them harder 1059 (than MM-Mode) to intercept for eavesdroppers; 1060 2.) Authentication-method-dependent encapsulation is 1061 supported in MU-Mode, but not MM-Mode. Thus, in MU- 1062 Mode, it is possible for the SOCKS server to use packet- 1063 level authentication in determining whether to forward a 1064 packet, whereas in MM-Mode, it must resort to inspecting 1065 the source IP address. 1066 For many environments, the added performance and scalability 1067 offered by MM-Mode may outweigh the additional security 1068 offered by MU-Mode. Administrators should carefully 1069 understand the tradeoffs. 1070 * SOCKS client implementations SHOULD optionally support 1071 getting user confirmation upon attempting to send multicast 1072 traffic through a SOCKS server. This helps prevent the 1073 unintentional multicasting of data beyond an organizational 1074 boundary. 1075 * SOCKS Server implementations MAY perform content filtering in 1076 cases where, based on addressing or other means, the server 1077 knows what the content should be. For example, since the 1078 class D addresses in the range of 224.2.*.* are reserved for 1079 conferencing, a SOCKS server could ensure the UDP traffic is 1080 encapsulated in RTP/RTCP headers. 1082 7. Acknowledgments 1084 This document benefited from the thoughtful insights and comments 1085 from Marc Vanheyningen, Wei Lu, Jamie Jason, and Kira Attwood. 1087 8. References 1089 [RFC-2119] Bradner, S, "Key words for use in RFCs to Indicate 1090 Requirement Levels", RFC 2119, Harvard University, March 1091 1997. 1092 [RFC-1928] Leech, M., et. al., "SOCKS Protocol Version 5", RFC 1093 1928, March 1996. 1094 [SOCKS5] Leech, M., et. al., "SOCKS Protocol Version 5", March 1095 1997, work in progress. 1096 [Van97] VanHeyningen, M., "Feature Discovery: A Generic 1097 Mechanism for SOCKS Version 5", July 1997, work in 1098 progress. 1099 9. Disclaimer 1101 The views and specification herein are those of the author and are 1102 not necessarily those of his employer. The author and his employer 1103 specifically disclaim responsibility for any problems arising from 1104 correct or incorrect implementation or use of this specification. 1106 10. Authors' Address 1108 Dave Chouinard 1109 Intel Corporation 1110 MS JF3-206 1111 2111 NE 25th Ave. 1112 Hillsboro, OR, USA 97124 1113 +1(503)264-7481 1114 dave_chouinard@mail.intel.com