idnits 2.17.1 draft-ietf-nat-rsip-protocol-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: ---------------------------------------------------------------------------- ** 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 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 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 are 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In the case of Basic-NAT-Like operation, the number of IP addresses requested in an ASSIGN may be more than one, but an RSIP-client MAY NOT be assigned port sets. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. '2' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Michael Borella 3 Expires August 1999 David Grabelsky 4 3Com Corp. 6 Jeffrey Lo 7 Kunihiro Tuniguchi 8 NEC USA 10 Realm Specific IP: Protocol Specification 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This draft presents a protocol that enables an alternative to network 37 address translation (NAT). Realm-Specific IP (RSIP) defines an 38 architecture in which an RSIP server is a multi-homed host connecting 39 two routing realms. An RSIP client in the first routing realm may be 40 assigned a plurality of routing parameters from the second routing 41 realm. The RSIP client will be allowed to create packets using these 42 parameters, and tunnel them across the first routing realm. For 43 example, more than one host from a private address space using RSIP 44 may share one or more public address. Unlike NAT, RSIP does not 45 break the end-to-end integrity of protocols. We present a general, 46 extensible negotiation protocol to be operated between RSIP clients 47 and servers which facilitates the assignment of parameters and 48 resources from the server to the client. This draft is a 49 generalization of the techniques introduced in the drafts (DNAT) and 51 (Host-NAT). 53 1. Introduction 55 Network Address Translation (NAT) has gained popularity as a method 56 of separating public and private address spaces, and alleviating 57 network address shortages. A NAT translates the addresses of packets 58 leaving a first routing realm to an address from a second routing 59 realm, and performs the reverse function for packets entering the 60 first routing realm from the second routing realm. This translation 61 is performed transparently to the hosts in either space, and may 62 include modification of TCP/UDP port numbers as well as IP addresses. 64 While a NAT does not require hosts to be aware of the translation, it 65 will require an application layer gateway (ALG) for any protocol that 66 transmits IP addresses or port numbers in packet payloads (such as 67 FTP). Additionally, a NAT will not work with protocols that require 68 IP addresses and ports to remain unmodified between the source and 69 destination hosts or protocols that prevent such modifications to 70 occur (such as some IPSec modes). 72 An alternative to a transparent NAT is an architecture that allows 73 the clients within the first (e.g., private) routing realm to 74 directly use addresses and other routing parameters from the second 75 (e.g., public) routing realm. This form of Realm-Specific IP (RSIP) 76 requires that an RSIP-server (a router or gateway between the two 77 realms) assign at least one address from the second routing realm, 78 and perhaps some other resources, to each RSIP-client host in the 79 first routing realm that needs to establish end-to-end connectivity 80 to a host, entity or device in the second routing realm. Thus, the 81 second routing realm is not transparent to RSIP-client, but this 82 system allows packets to maintain their integrity from RSIP-client to 83 destination. In order to resolve addressing and routing ambiguities 84 in the first routing realm, all publicly routed packets are tunneled 85 between RSIP-client and the RSIP-server, or tunneled such that the 86 RSIP-server can perform a NAT function on the outer IP header only. 87 ALGs are not required in the RSIP-server. 89 A disadvantage to RSIP is that it requires that hosts be modified so 90 that they tunnel externally-bound packets and place some number of 91 layer three, layer four or other values from those assigned by the 92 RSIP-server in each packet bound for the second routing realm. 94 This draft discusses a method for assigning parameters to an RSIP- 95 client from an RSIP-server. In particular, this method is a 96 generalization of the techniques introduced in the drafts (DNAT) and 98 (Host-NAT). 100 1.1. Specification of Requirements 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 103 NOT", "SHALL", and "SHALL NOT", and "MAY" that appear in this 104 document are to be interpreted as described in [1]. 106 2. Architecture 108 For simplicity, for the remainder of this document we will assume 109 that the RSIP-clients in the first routing realm (network) use 110 private (network 10) IP addresses, and that the second routing realm 111 (network) uses public IP addresses. The RSIP-server connects the 112 public and private realms and contains interfaces to both. Other NAT 113 terminology found in this document is defined in [2]. 115 The diagram below describes an exemplary reference architecture for 116 RSIP. Some number of RSIP-clients are attached via a private network 117 to an RSIP-server, which also acts as a router or gateway between the 118 private and public networks. This router has been assigned some 119 number of public addresses that it may use or allocate for use on the 120 public network. 122 +-------------+ 123 | RSIP-client | 124 | 1 +--+ 125 | 10.0.0.2 | | +-------------+ 126 +-------------+ | 10.0.0.1 | | 149.112.240.0/24 127 +-----------------+ RSIP-server +------------------- 128 +-------------+ | | | 129 | RSIP-client | | +-------------+ 130 | 2 +--+ private public 131 | 10.0.0.3 | | network network 132 +-------------+ | 133 | 134 | 135 ... 137 RSIP MAY be based on either the Basic NAT or the NAPT model. In the 138 Basic NAT model, a unique public IP address is assigned to each 139 private NAT client that is actively communicating with the public 140 network. Only one NAT client uses a given public address. In the 141 NAPT model, one public address is shared by one or more NAT clients. 143 One or more NAT clients may use the same public address by limiting 144 the ports that they use to disjoint subsets of the port space. The 145 NAT server assigns these disjoint port sets to each host, along with 146 the public IP address. For the remainder of this document we will 147 assume the NAPT model. 149 For purposes of illustration, we will provide a brief example of the 150 transport operation of RSIP with respect to the above architecture. 151 We assume that RSIP-client 10.0.0.2 has been assigned public address 152 149.112.240.10 and port set 10000-10015 (the actual mechanism for 153 this assignment is discussed below). Packets transmitted from this 154 client to a WWW server at the external address of 128.153.4.3 will be 155 appear as follows on the private network: 157 Outer IP Inner IP TU Ports 158 +--------------+----------------+----------+ 159 Src: | 10.0.0.2 | 149.112.240.10 | 10000 | 160 +--------------+----------------+----------+ 161 Dst: | 10.0.0.1 | 128.153.4.3 | 80 | 162 +--------------+----------------+----------+ 164 Note that 10000 was chosen arbitrarily from the port set by the 165 kernel port selection code of the RSIP-client. Upon reaching the 166 RSIP-server, the outer IP header is stripped off, and the remaining 167 packet is transmitted on the public network. Incoming packets to the 168 RSIP-client may be demultiplexed based on layer three, layer four, or 169 other parameters, and tunneled from the RSIP-server to the RSIP- 170 client. 172 Note that the architecture and protocols for RSIP may allow for 173 cascading of RSIP-servers. For example, RSIP-server A may assign 174 some number of public IP addresses and port sets to RSIP-server B, 175 which is entirely inside of the private network. RSIP-server B will 176 then assign some of these addresses and port sets to private hosts. 177 This architecture conforms to the model in which a corporation (in 178 charge of RSIP-server B) buys public network access from an ISP (in 179 charge of RSIP-server A). In this scenario, RSIP-server B and end 180 hosts within the corporation could be considered the RSIP-client of 181 RSIP-server A and RSIP-server B respectively. 183 2.1. RSIP Parameter Negotiation 185 An RSIP-client initiates a binding request with an RSIP-server by 186 transmitting a REGISTER message. This allows the RSIP-server to 187 become aware of the RSIP-client. The RSIP-server will assign a 188 unique identifier to the RSIP-client. Negotiation of tunnel type 189 may also occur. 191 An RSIP client must then use the ASSIGN message to request one or 192 more IP addresses, port sets and/or other parameters from the 193 public realm. Upon these parameters will be assigned with a lease 194 time, after which their assignment must be renewed. 196 At this point, the RSIP-client may use the assigned parameters to 197 transmit packets to the public network. 199 If an RSIP-client no longer needs some parameters, that it has 200 been assigned, it may release them by transmitting a FREE message 201 to the RSIP-server, and specifying the parameters to release 202 within that message. 204 If an RSIP-client no longer needs to communicate with the public 205 network, it may use the DE_REGISTER message to notify the RSIP- 206 server of such. Use of the DE-REGISTER message effectively 207 releases all of the RSIP-client's parameters. It must register 208 and be assigned parameters once more before it transmits packets 209 to the public network again. 211 The ERROR message may be used at any time by the RSIP-server to 212 indicate that an RSIP-client's request was denied or malformed. 214 2.2. Operation 216 In the case of Basic-NAT-Like operation, the number of IP 217 addresses requested in an ASSIGN may be more than one, but an 218 RSIP-client MAY NOT be assigned port sets. 220 In the case of NAPT-like operation, an RSIP-client MUST request 221 one or more port sets in ASSIGN messages that contain an IP 222 address, but only one IP address may be requested per ASSIGN 223 message. If more than one IP address is desired, the request MUST 224 be issued as two independent ASSIGN requests, and each will be 225 given a different binding. 227 If the resources requested are temporarily unavailable, an RSIP- 228 server MAY either commit a subset of the resources requested or 229 return an ERROR message indicating that the requested resource was 230 temporarily unavailable. An RSIP-client is free to attempt 231 another ASSIGN request for the same resource after an interval of 232 time. 234 An RSIP-server MAY allow freeing to be done on a subset of an 235 assigned range, address range in the case of traditional NAT-like 236 operation and port range in the case of NAPT-like operation. Child 237 ranges as a result of a subset free MUST retain the same binding. 238 If an RSIP-server receives a FREE message that refers to 239 parameters not assigned to the originating RSIP-client, an ERROR 240 message indicating that the parameter range was invalid MUST be 241 returned. If an RSIP server receives a FREE message referring to 242 an unknown binding, an ERROR message indicating that the binding 243 is unknown MUST be returned. 245 If an RSIP-client wishes to extend the duration of an existing 246 binding, an ASSIGN request with the same Bind ID and the desired 247 extension duration MAY be sent. The RSIP-server SHOULD either 248 grant the request, grant a smaller duration than that requested or 249 deny the request. If a smaller duration is granted, this duration 250 MUST be included in the response message to the ASSIGN request. In 251 the case when the request is denied, the appropriate error 252 response MUST be sent. 254 2.3. Subnet Query 256 In some cases it is not possible for an RSIP-client to know 257 whether a packet should be tunneled to the RSIP-server or 258 transmitted using the local (private) routing realm only. The RSIP 259 protocol provides a subnet query mechanism through which an RSIP- 260 client may query an RSIP-server to ask whether a particular subnet 261 falls within the private domain. An RSIP-client queries the 262 server using the QUERY message with the subnet included in the IP 263 address field of the message. The RSIP-server MAY confirm the 264 subnet queried or MAY return the whole range of subnets supported 265 so as to enable the RSIP-client to cache the entries. The RSIP- 266 server may be manually configured to know the topology of the 267 private domain. 269 2.4. Unreliable Transport 271 A sequence number field SHOULD be included in all messages if UDP, 272 or some other unreliable transport mechanism, is used. The 273 sequence number starts with zero in the client's REGISTER message 274 and end with a maximum value in the server's DE_REGISTER message. 275 This field SHOULD be incremented by one for every request issued. 276 Responses MUST include the same sequence number as that of the 277 request which it acknowledges. 279 If an RSIP-client does not receive a response from the RSIP-server 280 for a request, a new request with the same sequence number MAY be 281 issued after an interval of time. An RSIP-server receiving a 282 request with a sequence number smaller than what it previously 283 received SHOULD ignore the request. Pipelining of requests and 284 aggregation of responses are not allowed. 286 Sequence number wraparound is highly unlikely, however it must be 287 considered in both the RSIP clients and servers. 289 2.5. Parameter Assignment Transport and Mechanisms 291 In order to assign parameters to the RSIP-client from the RSIP- 292 server, a transport protocol and an assignment mechanism must be 293 used. Design of the end-to-end NAT protocol aims to be transport 294 independent, so that existing transport protocols such as UDP or 295 TCP can be used. 297 The assignment mechanisms MAY be DHCP, COPS, DIAMETER or some 298 similar protocol. While these protocols would allow nearly- 299 arbitrary parameters to be assigned to the RSIP-clients, our 300 current goal is to determine the parameters that are necessary for 301 RSIP to operate in full generality, and define a basic protocol 302 with which these parameters can be negotiated and assigned. Once 303 the fundamental requirements of RSIP parameter assignment are 304 specified, it may either be integrated into an existing protocol 305 or left alone as its own protocol. 307 3. General Message and Parameter Formats 309 In this section we define the general message and parameter format. 310 Codes for each parameter and message types will be discussed the 311 following sections. Within an RSIP control packet, the parameters 312 MAY appear in any order, but it is recommended that required 313 parameters precede all optional parameters. 315 The general message format is shown below. 317 1 byte Variable Variable 318 +-----------+---------------+------------------- 319 | Type | Parameter 1 | Parameter 2 ... 320 +-----------+---------------+------------------- 322 The type field indicates how the parameters are to be interpreted 323 (e.g., request, response, error, etc.). 325 The general format of all parameters is shown below. 327 1 byte 2 bytes 'Length' bytes 328 +------+----------+---------------------- 329 | Code | Length | Parameter value ... 330 +------+----------+---------------------- 332 All parameters consist of a fixed portion and a variable portion. 333 The fixed portion is a 1 byte code value and a 2 byte length. The 334 remaining portion of the parameter is the parameter value, the length 335 which is the number of bytes indicated by the length field. 337 4. Parameter Types and Formats 339 Number of IP Addresses 341 Code Length Number of Addresses 342 +------+--------+----------------------+ 343 | 0 | 1 | (1 byte) | 344 +------+--------+----------------------+ 346 Used in ASSIGN messages to request a particular number of public 347 addresses to be assigned. 349 Number of Ports 351 Code Length Number of Ports 352 +------+--------+-------------------+ 353 | 1 | 1 | (1 byte) | 354 +------+--------+-------------------+ 356 Used in ASSIGN messages to request a particular number of ports to 357 be assigned. 359 IP Address 361 Code Length IP Address 362 +------+-------------------------+-------------------------------+ 363 | 2 | Multiple of 4 | (Multiple of 4 bytes) | 364 +------+-------------------------+-------------------------------+ 366 This field represents the IPv4 address(es) negotiated. More than 367 one IP addresses MAY be included after the length field; thus, the 368 length field MUST be a multiple of 4. 370 IP Address Range 372 Code Length Low Address High Address 373 (May repeat) 374 +------+------------------------+-----------------------------+ 375 | 3 | Multiple of 8 | (4 bytes) | (4 bytes) | 376 +------+------------------------+-----------------------------+ 378 In cases where the number of IPv4 addresses negotiated is large 379 and contiguous, the IPv4 address range parameter is used to 380 represent the range. Multiple ranges MAY be represented within a 381 single IP Address Range parameter. 383 Port Range 385 Code Length Low Port High Port 386 (May Repeat) 387 +------+-----------------------+-----------------------+ 388 | 4 | Multiple of 4 | (2 bytes) | (2 bytes) | 389 +------+-----------------------+-----------------------+ 391 The port range MUST be contiguous and is inclusive. Multiple 392 ranges MAY be represented within a port range parameter. 394 Lease Time 396 Code Length Lease Time 397 +------+--------+-------------------+ 398 | 5 | 4 | (4 bytes) | 399 +------+--------+-------------------+ 401 Number of seconds that an RSIP-client may retain the parameters 402 assigned by an RSIP-server. 404 Error 406 Code Length Error 407 +------+--------+-------------------+ 408 | 6 | 2 | (2 bytes) | 409 +------+--------+-------------------+ 411 These error codes allow an RSIP-server to inform an RSIP-client 412 why a particular request has failed. 414 0 Unknown Error - An error that cannot be identified has occurred 415 1 Bind ID Not Found - The request refers to an invalid Bind ID. 416 2 Client ID Not Found - The request refers to an invalid Client ID. 417 3 Invalid Message - The request does not contain an mandatory 418 parameter or cannot be parsed. 419 4 NAT Type Not Supported - The request refers to a NAT type not 420 supported by this NAT-server. 421 5 Not Authorized - The RSIP-client is not authorized to make the 422 request. 423 6 Resource Temporarily Unavailable - The request has asked for a 424 resource (e.g., addresses, ports) that the RSIP-server 425 is not currently able to grant. 426 7 Tunnel Type Not Supported - The request refers to a tunnel type 427 that the RSIP-server does not support. 428 8 Wrong Sequence Number - The request used a sequence number that 429 the RSIP-server did not expect. 431 Client ID 433 Code Length Client ID 434 +------+--------+-------------------+ 435 | 7 | 4 | (4 bytes) | 436 +------+--------+-------------------+ 438 A unique number assigned by an RSIP-server when an RSIP-client 439 registers with the server. It is used to identify the RSIP-client. 441 Bind ID 443 Code Length Bind ID 444 +------+--------+-------------------+ 445 | 8 | 4 | (4 bytes) | 446 +------+--------+-------------------+ 448 The Bind ID is a unique number allocated for each new assignment. 449 It is returned as part of an ASSIGN response to a successful 450 ASSIGN request. Subsequent message exchanges pertaining a bind 451 MUST include its Bind ID. When a or range of parameters is 452 assigned to an RSIP-client, the parameter is said to be 'bound' to 453 that client. More than one bind with different Bind IDs may be 454 established between an RSIP-client and RSIP-server pair. A binding 455 will expire when its lease time runs out or when the RSIP-client 456 de-registers itself with the RSIP-server. 458 Sequence Number 460 Code Length Sequence Number 461 +------+--------+-------------------+ 462 | 9 | 1 | (1 byte) | 463 +------+--------+-------------------+ 465 If the transport protocol is connectionless. such as UDP, the 466 sequence number field MUST be included as a means to order the 467 messages and/or match requests and responses. 469 Tunnel Type 471 Code Length Tunnel Type 472 +------+--------+-------------+ 473 | 10 | n | (n bytes) | 474 +------+--------+-------------+ 476 The type of tunnel used between an RSIP-client and an RSIP-server. 477 Values are assigned as follows: 479 0 Reserved 480 1 IP-IP 481 2 GRE 482 3 L2TP 483 4 IPSec 485 NOTE: More tunnel types should be defined, especially for the 486 different variations of IPSec. 488 NAT Type 490 Code Length NAT Type 491 +------+--------+-------------+ 492 | 11 | n | (n bytes) | 493 +------+--------+-------------+ 495 The type of NAT-like operation that the RSIP-server will perform. 496 The following values have been assigned: 498 1 Traditional NAT 499 2 NAPT 500 3 Twice NAT 502 Vendor Specific Parameter 504 Code Length Vendor ID Subcode Parameter 505 +------+----------+------------+-----------+-----------+ 506 | 12 | n+4 | (2 bytes) | (2 bytes) | (n bytes) | 507 +------+----------+------------+-----------+-----------+ 509 This parameter allows vendors to specify vendor specific 510 information. The Vendor ID field the vendor-specific ID assigned 511 by IANA. Subcodes are defined and used by each vendor. 513 5. Message Type 515 Apart from the message type field, which MUST appear at the beginning 516 of each message, other parameters MAY appear in any order. Note that 517 message sequencing MAY need to be introduced depending on the 518 transport. The following message types are defined in simple BNF. 519 Required parameters are enclosed in <> and MUST appear. Optional 520 parameters are enclosed in [] and MAY appear. 522 ERROR Response 524 An ERROR response is used to provide error responses to an RSIP- 525 client message. The message type is 1. 527 ::= 528 [][] 529 [] 531 REGISTER 533 The REGISTER message is used by an RSIP-client to register with an 534 RSIP-server. An RSIP-client MUST register before it requests 535 parameters from the RSIP-server. The message type is 2. The RSIP- 536 client MAY list all of the tunnel types and NAT types supported. 537 The default tunnel type is IP-IP, and the default NAT type is 538 NAPT. 540 ::= 541 [][...] 542 [...] 544 ::= 545 [][] 546 [...] 548 DE_REGISTER 550 The DE_REGISTER message is used by an RSIP-client to de-register 551 with an RSIP-server. The message type is 3. 553 ::= 554 [] 556 ::= 557 [] 559 ASSIGN 561 The ASSIGN message is used by an RSIP-client to request parameter 562 assignments. The message type is 4. If a client is given a single 563 IP address, a port range MUST be specified if NAPT is the NAT 564 type. If a client is given a range of n IP addresses, this 565 parameter MUST be followed by exactly n port range parameters. 566 The Client ID field MUST be included, otherwise, an RSIP-server 567 MUST return an ERROR message with the "Client ID not found" error 568 parameter. The lease time parameter MAY be included in an 569 assignment request as an indication of a desired bind duration. 570 If a lease time is not requested by an RSIP-client, an RSIP-server 571 SHOULD assign a default lease time. 573 ::= 574 [][] 575 [] [] 576 [] 578 ::= 579 [][...] 580 [][] 582 ::= 583 [][] 584 [...] 585 [] 587 FREE 589 The FREE message is used by an RSIP-client to free parameter 590 assignments. The message type is 5. If no parameters are 591 specified in a FREE message, then all of the parameters associated 592 with the Bind ID MUST be freed. 594 ::= 595 [][...] 596 [...][ ...] 598 ::= 599 [][] 600 [...][...] 602 QUERY 604 A QUERY message is used by an RSIP-client to request if a subnet 605 is supported by an RSIP-server. The message type is 6. 607 ::= 608 [] 610 ::= 611 [] 613 6. To Do 615 - Distinguish request and response messages 616 - Examples 618 7. Security Considerations 619 RSIP, in and of itself, does not provide security. It may provide 620 the illusion of security or privacy by hiding a private address 621 space, but security and privacy can only be ensured by the proper use 622 of strong encryption. 624 An RSIP implementation must be guarded against potential denial- of- 625 service attacks. A malicious RSIP-client may be able to determine 626 the parameters associated with another RSIP-client via packet 627 sniffing. An attacker could free the resources allocated by the 628 RSIP-server by spoofing a FREE request. Negotiation between an RSIP 629 client and server should be secured with an appropriate 630 authentication mechanism. 632 RSIP-servers SHOULD NOT forward packets from a RSIP-client without 633 checking the validity of the source IP address and source port 634 number, as well as any other relevant parameters. Other necessary 635 policy based routing checks SHOULD also be made. Improper use of 636 source IP address, source port number, or any RSIP-client using a 637 resource or parameter assigned to a different RSIP-client are 638 auditable events. An RSIP-server SHOULD log negotiation transactions 639 in which a client attempts to use an improper Client ID or Bind ID. 641 8. References 643 [1] S. Bradner. "Key words for use in RFCs to indicate requirement 644 levels," RFC 2119, Mar. 1997. 646 [2] P. Srisuresh, Matt holdrege, "NAT: Terminology and 647 considerations" Internet Draft , Work in progress. 650 9. Acknowledgements 652 The authors would like to thank Pyda Srisuresh and Rick Cobb for 653 their input. 655 10. Authors' Addresses 657 Michael Borella 658 3Com Corp. 659 Advanced Technologies Research Center 660 1800 W. Central Rd. 661 Mount Prospect IL 60056 662 (847) 342-6093 663 mike_borella@3com.com 665 David Grabelsky 666 3Com Corp. 667 Advanced Technologies Research Center 668 1800 W. Central Rd. 669 Mount Prospect IL 60056 670 (847) 222-2483 671 david_grabelsky@3com.com 673 Jeffrey Lo 674 NEC USA 675 C&C Research Labs. 676 110 Rio Robles 677 San Jose, CA 95134 678 (408) 943 3033 679 jlo@ccrl.sj.nec.com 681 Kunihiro Taniguchi 682 NEC USA 683 C&C Research Labs. 684 110 Rio Robles 685 San Jose, CA 95134 686 (408) 943 3032 687 taniguti@ccrl.sj.nec.com 689 Copyright (c) The Internet Society (1999). All Rights Reserved. 691 This document and translations of it may be copied and furnished to 692 others, and derivative works that comment on or otherwise explain it 693 or assist in its implementation may be prepared, copied, published 694 and distributed, in whole or in part, without restriction of any 695 kind, provided that the above copyright notice and this paragraph are 696 included on all such copies and derivative works. However, this 697 document itself may not be modified in any way, such as by removing 698 the copyright notice or references to the Internet Society or other 699 Internet organizations, except as needed for the purpose of 700 developing Internet standards in which case the procedures for 701 copyrights defined in the Internet Standards process must be 702 followed, or as required to translate it into languages other than 703 English. 705 The limited permissions granted above are perpetual and will not be 706 revoked by the Internet Society or its successors or assigns. 708 This document and the information contained herein is provided on an 709 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 710 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 711 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 712 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 713 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.