idnits 2.17.1 draft-stiemerling-nat-fw-config-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 157 has weird spacing: '...ter set tran...' == Line 297 has weird spacing: '... 1yz tran...' == Line 298 has weird spacing: '... 2yz perm...' == Line 299 has weird spacing: '... 3yz tran...' == Line 300 has weird spacing: '... 4yz perm...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8170 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) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Stiemerling 2 Document: draft-stiemerling-nat-fw-config-00.txt J. Quittek 3 Expires: May 2002 NEC Europe Ltd. 5 November 2001 7 Simple NAT and Firewall Configuration (SNFC) Protocol Version 1.0 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this document is unlimited. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This memo specifies a protocol for configuring Network Address 39 Translators (NATs) and firewalls dynamically to create address 40 bindings and open pinholes. NATs and firewalls are a problem for 41 applications using voice and video streaming, such as IP telephony, 42 because they need to establish voice or video channels dynamically. 43 The Simple NAT and Firewall Control (SNFC) protocol allows clients to 44 send requests for this purpose to serving NATs and/or firewalls. The 45 protocol is designed to provide a very simple and basic solution that 46 can easily be implemented and used. 48 Table of Contents 50 1 Introduction ................................................. 2 51 2 Terminology .................................................. 2 52 3 SNFC Protocol Overview ....................................... 4 53 4 SNFC Messages ................................................ 5 54 4.1 Common Definitions ......................................... 5 55 4.2 Message Definitions ........................................ 6 56 4.3 Replies .................................................... 6 57 5 Message Processing in Server ................................. 8 58 5.1 Syntax Checking ............................................ 8 59 5.2 Session State Machine ...................................... 8 60 5.2.1 Transistions from State CLOSED ........................... 9 61 5.2.2 Transistions from State OPEN ............................. 10 62 5.3 Binding State Machine ...................................... 10 63 5.3.1 Transport Parameter Set Checking ......................... 11 64 5.3.2 Transitions from State BID_UNUSED ........................ 12 65 5.3.3 Transitions from BIND_IN_ONLY and BIND_OUT_ONLY .......... 13 66 5.3.4 Transitions from State FULL_BINDING ...................... 14 67 6 Controling SNFC Sessions ..................................... 15 68 7 Controling Bindings and Pinholes ............................. 17 69 8 Security Considerations ...................................... 19 70 9 References ................................................... 19 71 10 Authors' Address ............................................ 20 72 11 Full Copyright Statement .................................... 20 74 1. Introduction 76 In today's network environments the use of firewalls and Network 77 Address Translators (NATs) is widespread. Firewalls and NATs improve 78 network security and in the times of IPv4 address depletion NATs are 79 keeping the Internet growing. However, NATs and firewalls also are an 80 obstacle to many applications, because in order to traverse them, 81 application specific and session specific configuration is required. 83 A good example (and the main driver for developing SNFC) is IP 84 telephony. For a connection two voice channels - one for each 85 direction - need to be established. Typically, UDP is used to carry 86 voice data, but for most NATs and firewalls it is a problem to 87 provide the required address mapping and to open corresponding 88 pinholes for UDP traffic without manual configuration. Possible 89 solutions are application level gateways linked to the NAT/firewall 90 or signaling between the application and the NAT/firewall. 92 Providing a signaling-based solution is the main goal of the midcom 93 working group [2,3]. The group currently discusses requirements for a 94 signaling protocol [4]. The SNFC protocol described in this document 95 shall contribute to the requirements discussion by demonstrating how 96 a very simple and straight forward approach to such a protocol can 97 look like. The SNFC protocol is a client/server protocol with the 98 NAT/firewall (middlebox) serving application-level clients (midcom 99 agents) requesting address bindings and firewall configurations. It 100 contains only four different kinds of requests and very simple state 101 machines that are completely specified below. 103 This memo describes the architectural background for the SNFC 104 protocol and its basic concepts in section 3. Section 4 defines all 105 SNFC messages, and section 5 specifies processing of the messages at 106 a NAT/firewall including the complete specification of state 107 machines. Section 6 explains how a client can open and close a SNFC 108 session, and section 7 explains how it can request address bindings 109 and pinhole configurations. Both sections include example message 110 sequences for these actions. Most of the security issues are 111 discussed in section 8. They are very important, because many network 112 security concepts strongly depend on proper firewall configuration. 114 2. Terminology 116 This section defines the terminology that is used throughout this 117 document. 119 NAT Network Address Translation, 120 according to [1]: Network Address 121 Translation is a method by which IP 122 addresses are mapped from one address 123 realm to another, providing 124 transparent routing to end hosts 126 firewall A general firewall contains two 127 components: a packet filter examining 128 information of Layer 2-4 and an 129 Application Level Gateway (ALG). In 130 this document we restrict use of the 131 term `firewall' refers to packet 132 filters unless metioned explicitly 134 NAT/firewall A NAT or a firewall or a combination 135 of both 137 internal side The private network of a NAT (cf. 138 [1], Section 2.8) or the protected 139 network of a firewall 141 external side The public network of a NAT (cf. [1], 142 Section 2.7) or firewall. 144 inner or internal IP Address An IP address which is located at the 145 internal side of a NAT/firewall 147 outer or external IP Address An IP address which is located at the 148 external side of a NAT/firewall. 150 transport parameter set A set consisting of three items: an 151 IP address, a port number, and an IP 152 protocol type. 154 inner transport parameter set Transport parameter set with inner IP 155 address and port number. 157 outer transport parameter set transport parameter set with an outer 158 IP address and port number. 160 inner binding A binding of an inner transport 161 parameter set of a host (TP0) to and 162 an outer transport parameter set of a 163 NAT/firewall (TP2), as shown in 164 Figure 1. 166 +----------+ +--------+ +----------+ 167 | internal |TP0 TP1| |TP2 TP3| external | 168 | host |-------------| NAT/FW |-------------| Host | 169 +----------+ private/ +--------+ public +----------+ 170 protected network 171 network 173 Figure 1: Addresses of internal hosts, NAT/firewall, 174 and external hosts 176 outer Binding A binding of an outer transport 177 parameter set of a host (TP3) to and 178 an outer transport parameter set of a 179 NAT/firewall (TP2), as shown in 180 Figure 1. 182 uni-directional binding An inner binding or an outer binding 184 bi-directional binding A combination of an inner binding and 185 an outer binding 187 full binding A bi-directional binding 189 pin-hole A configuration of the firewall 190 allowing packets matching a binding 191 to pass the firewall. Like bindings, 192 a pinhole may be uni-directional or 193 bi-directional. 195 3. SNFC Protocol Overview 197 The SNFC protocol is intended to comply with the midcom architecture 198 specified in [2]. The protocol allows a client (midcom agent) to 199 establish a SNFC session with a server. An important component of 200 session establishment is the authentication and authorization of the 201 client, because configuring a firewall is a very sensitive issue of 202 security concepts. 204 For the transmission between client and server TCP is used, this 205 avoids dealing with flow control issues and gives the opportunity of 206 using Transport Layer Security (TLS [5]) mechanism. Instead of TLS, 207 IPSEC [6,7] may be used as well. The protocol uses ASCII encodings, 208 because this simplifies documentation, implementation and debugging. 209 This encoding is not considered to reduce scalability significantly. 211 Once a session is established, the client can request the 212 establishments of address bindings at a NAT controlled by the server 213 and the opening of pinholes at a firewall controlled by the server. 214 The approach of SNFC is to use the same requests for both purposes. 215 For example a `bind_in' request (described in sections 4 and 5) 216 requests sends an inner transport parameter set to the server and 217 requests the allocation of outer transport parameter set at the NAT 218 and a binding between both sets: 220 - In case of a pure NAT, the outer transport parameters are 221 allocated and a binding is established providing proper address 222 translation. 224 - In case of a pure firewall, the allocated outer transport 225 parameter set is identical with the internal one sent with the 226 request, and just a pinhole is configured allowing packets 227 matching the transport parameter set to pass. 229 - In case of a combined NAT/firewall, the outer transport parameters 230 are allocated, a binding is established providing proper address 231 translation, and a pinhole is configured for allowing the packets 232 matching the binding to pass. 234 This integration of requests for address binding and for pinhole 235 configuration leads to a very simple protocol with just two requests 236 for binding and pinhole control. 238 4. SNFC Messages 240 The message formats described below are defined using the Augmented 241 BNF (ABNF) defined in RFC 2234 [8]. The definitions for `DIGIT', 242 `HEXDIG', `WSP', `CRLF', `CR', `VCHAR' and `LF' are imported from 243 appendix A of RFC 2234 and not repeated here. 245 4.1. Common Definitions 247 The following definitions are used in the subsequent chapters to 248 define the SNFC protocol messages. 250 IPAddress = IPv4Address / IPv6Address / "0" 251 IPv4Address = 1*3DIGIT 3("." 1*3DIGIT) 252 IPv6Address = 1*4HEXDIG 7( ":" 1*4HEXDIG) 253 Port = 1*DIGIT 254 MID = 1*DIGIT ; Message ID number 256 The MID is an identifier for the client, to recognize which reply 257 belongs to which request, i.e. the MID in the reply is allways the 258 same as in the request. 260 BID = 1*DIGIT ; Binding ID number 262 The BID is the handle for the Firewall/NAT to identify the correct 263 pin-hole and it may correlate with the corresponding pin-hole number 264 in the Firewall/NAT. A BID of zero means not allocated BID. 266 PT = "UDP" / "TCP" / "ICMP" / "ANY" ; IP protocol type 267 Authentication = 1*VCHAR 268 Challenge = 1*VCHAR 269 Message = 1*VCHAR 270 Timeout = 1*DIGIT ; timeout in seconds 271 TPS = IPAddress WSP Port WSP PT ; transport param. set 272 TPS_in = TPS ; internal TPS 273 TPS_ex = TPS ; external TPS 274 Version = "SNFC/1.0" 276 4.2. Message Definitions 278 The following ABNF definitions define the set of SNFC requests which 279 can be sent from a client to a server. 281 request = "open" WSP MID WSP Version WSP Authentication CRLF 282 request =/ "close" WSP MID CRLF 283 request =/ "bind_in" WSP MID WSP BID WSP TPS WSP Timeout CRLF 284 request =/ "bind_out" WSP MID WSP BID WSP TPS WSP Timeout CRLF 286 The `open' and the `close' request are exclusively used for session 287 control. The `bind_in' and the `bind_out' request are exclusively 288 used for binding and pinhole control. 290 4.3. Replies 292 Every reply message starts with a three digit reply code and ends 293 with `CRLF'. The three digits in a reply code have a special meaning. 294 The first digit identifies the class of a reply message. The 295 following classes exist: 297 1yz transient positive response 298 2yz permanent positive response 299 3yz transient negative response 300 4yz permanent negative response 301 5yz asynchronous notification 303 The classes 1yz and 3yz are currently not used by SNFC version 1.0. 304 They are defined only for future SNFC extensions. 306 The second digit encodes the specific category. The following 307 categories exist: 309 x1z syntax errors that don't fit any other category 310 x2z replies for requests concening session control 311 x3z replies for requests concening binding and pinhole control 313 The third digit gives a finer gradation of meaning in each category 314 specified by the second digit. Below is the ABNF definition of all 315 reply messages and codes: 317 Reply =/ "410" WSP MID CRLF ; syntax Error 318 Reply =/ "411" WSP MID CRLF ; unknown or illegal request 319 Reply =/ "510" WSP Message CRLF ; illegal message 321 Reply = "220" WSP MID CRLF ; OK 322 Reply =/ "420" WSP MID CRLF ; protocol version mismatch 323 Reply =/ "421" WSP MID WSP Challenge CRLF ; authentication failed 324 Reply =/ "520" WSP Message CRLF ; session closed 326 Reply =/ "231" WSP MID WSP BID WSP TPS 327 WSP Timeout CRLF ; OK for uni-direct. binding 328 Reply =/ "232" WSP MID WSP BID WSP TPS_in WSP TPS_ex 329 WSP Timeout CRLF ; OK for full binding 330 Reply =/ "233" WSP MID WSP BID CRLF ; binding removed 331 Reply =/ "430" WSP MID CRLF ; unknown or illegal BID 332 Reply =/ "431" WSP MID CRLF ; binding Refused 333 Reply =/ "432" WSP MID CRLF ; illegal IP Address 334 Reply =/ "433" WSP MID CRLF ; protocol type not supported 335 Reply =/ "434" WSP MID CRLF ; illegal port number 336 Reply =/ "435" WSP MID CRLF ; cannot modify binding 337 Reply =/ "530" WSP BID CRLF ; binding timed out 339 5. Message Processing in Server 341 This section describes the processing steps performed by a SNFC 342 server after receiving a message. Common to all incoming messages is 343 that first the syntax is checked. Then we distinguish messages 344 concerning session control ans messages concerning the control of 345 address bindings. For both kinds, we define a state machine and 346 discuss states and transitions. 348 5.1. Syntax Checking 350 When the server receives a message, it first tries to recognize a 351 request consisting of the command string and a message identifier 352 (MID). Messages generated by syntax checking are: 354 - `410' reply 355 - `411' reply 356 - `510' reply 358 If the server is not able to extract both the command string and the 359 message identifier, then the message is discarded. An asynchronous 360 `510' reply may be generated in this case. Otherwise, the command 361 string is checked to be valid, i.e. to be one of the strings `open', 362 `close', bind_in', bind_out', `refresh', or `remove'. If the string 363 is invalid, a `411' reply is sent and processing of the message 364 stops. If a syntax error is detected, a `410' reply is sent and 365 processing of the message stops. Otherwise, the message is further 366 processed as described below. 368 5.2. Session State Machine 370 The session state machine has just two states: CLOSED and OPEN. 371 Transisions between these states only appear in conjunction with one 372 or two of the following messages: 374 - `open' request 375 - `close' request 376 - `220' reply 377 - `420' reply 378 - `421' reply 379 - `520' reply 381 Additionally, a `510' reply may be generated in the CLOSED state as 382 described below. 384 Figure 2 shows the state machine of a single session with all 385 possible transitions. Please note that a server may serve several 386 clients at a time by running several concurrent sessions. 388 open 42X 389 close 220 390 520 391 +-----------+ 392 | v 393 +-------------------+ 394 | CLOSED | 395 +-------------------+ 396 | ^ close 220 397 open 220 | | open 42X 398 v | 520 399 +-------------------+ 400 | OPEN | 401 +-------------------+ 402 | ^ 403 +-----------+ 404 open 220 406 Figure 2: Session state machine 408 The initial state of all sessions is CLOSED. If a client establishes 409 a connection to the server by successfully creating a socket, then a 410 session in state CLOSED is assigned to this connection. For closed 411 sessions only two requests are accepted: `open' and `close'. All 412 other requests received in this state are discarded. An asynchronous 413 `510' reply may be generated in this case. In the OPEN state, all 414 SNFC messages are accepted. However, only `open' and `close' messages 415 have an impact on the session state. 417 5.2.1. Transistions from State CLOSED 419 If an `open' request is received, then first the contained `Version' 420 string is checked. If the version indicated by the string is not 421 compatible to one of the versions supported by the server, then a 422 `420' reply is generated, the connection is closed, and the state 423 machine remains in state CLOSED. Otherwise, the contained 424 `Authentication' string is analysed. If the authentcation check is 425 successful, a `220' reply is generated and the session enters state 426 OPEN. Otherwise, a `421' reply is generated and the session remains 427 in state CLOSED with the connection still established. 429 At any time the server may generate an asynchronous `520' reply 430 followed by closing the connection. In this case the session will 431 remain in state CLOSED. Particularly, the server may generate a `520' 432 reply, if a connection is established and the time the session 433 remains in state CLOSED exceeds a given timeout value. 435 5.2.2. Transistions from State OPEN 437 If a `close' request is received, then the server generates a `220' 438 reply and the session enters state CLOSED with the connection being 439 closed. The same transition occurs if the server decides to close the 440 session. Then it generates a `520' reply, closes the connection, and 441 enters session state CLOSED. 443 If an `open' request is received, it is processed as in the CLOSED 444 state. First the contained `Version' string is checked. If the 445 version indicated by the string is not compatible to one of the 446 versions supported by the server, then a `420' reply is generated, 447 the connection is closed, and the state machine enters state CLOSED. 448 Otherwise, the contained `Authentication' string is analysed. If the 449 authentcation check is successful, a `220' reply is generated and the 450 session remains in state OPEN. Otherwise, a `421' reply is generated 451 and the session enters state CLOSED with the connection kept 452 established. 454 At any time the server may generate an asynchronous `520' reply 455 followed by closing the connection. In this case the session will 456 enter state CLOSED. 458 5.3. Binding State Machine 460 When the session state machine is in state OPEN, the server accepts 461 further requests regarding bindings. The state machine of a binding 462 contains four states: BID_UNUSED, BIND_IN_ONLY, BIND_OUT_ONLY, 463 FULL_BINDING. Transistion between the states occur in conjunction 464 with the following messages: 466 - `bind_in' request 467 - `bind_out' request 468 - `23X' replies 469 - `43X' replies 470 - `530' reply 472 All of these requests and replies refer to exactly one binding which 473 is indicated by the BID field of the message. The BID uniquely 474 identifies a binding. BIDs are allocated and assigned to bindings by 475 the server. If a request contains a BID which unused because it is 476 not assigned to any binding, then the server will discard the request 477 and generate a `430' reply. BID 0 is an exception, it is reserved 478 for a special purpose and it is never assigned to an existing 479 binding. 481 For all BIDs other than 0 there exists a state machine as shown in 482 Figure 3. If the server receives a `bind_in` or a `bind_out' request 483 containing BID 0 then a new BID is allocated. Before the request can 484 be executed, a new binding state machine is instantiated for this BID 485 with the initial state BID_UNUSED. 487 bind_X(BID=0) 43X 488 bind_X(BID=0,timeout=0) 233 489 +-----------+ 490 | v 491 bind_out(BID=0) 231 +---------------+ bind_in(BID=0) 231 492 +--------------| BID_UNUSED |--------------+ 493 | +---------------+ | 494 | ^ bind_X(timeout=0) 233 | 495 v | bind_X 43X v 496 +---------------+ | 530 +---------------+ 497 +->| BIND_OUT_ONLY |----->+<-----------| BIND_IN_ONLY |<-+ 498 | +---------------+ ^ +---------------+ | 499 | | | | | | | 500 +--------+ | +---------------+ | +--------+ 501 bind_out 231 +------->| FULL_BINDING |<-------+ bind_in 231 502 bind_in 232 +---------------+ bind_out 232 503 | ^ 504 +-----------+ 505 bind_X 232 507 Figure 3: Binding state machine 509 When a binding state machines makes a transition to the state 510 BID_UNUSED (including transitions from state BID_UNUSED), then the 511 BID is considered to be unused. The client should not use this BID 512 any further, because it may be re-used by the server when allocating 513 a new BID. 515 5.3.1. Transport Parameter Set Checking 517 When a `bind_in` or a `bind_out' request is processed, the transport 518 parameter set contained in the message is checked. The checking 519 procedure is common for all states: 521 - The IP address is checked whether it is an inner IP address in 522 case of a `bind_in' request or an outer address in case of a 523 `bind_out' request, respectively. If the check fails or if the IP 524 address is considered invalid for some other reason, then the 525 server generates a `432' reply. 527 - The protocol type is checked, whether it is valid and supported. 528 If the check fails, a `433' reply is generated. 530 - The port number is checked whether it is valid. If the check 531 fails, a `434' reply is generated. 533 If the checks are successful the server may perform further checks on 534 the combination of the elements of the transport parameter set, for 535 example it may check available resource or it may consult a policy- 536 based access control system checking whether the client is allowed to 537 make the current request. If one of these checks fails, then the 538 server generates a `431' reply. Otherwise the server will continue 539 with establishing the requested binding. 541 5.3.2. Transitions from State BID_UNUSED 543 In state BID_UNUSED, only `bind_in` and `bind_out' requests with BID 544 0 can have an effect on the state machine. The server first performs 545 the parameter checks described above. If one of them fails, the 546 binding state machine remains in state BID_UNUSED. 548 If the timeout specified by the request message is 0, then the server 549 generates a `233' reply and the binding state machine remains in 550 state BID_UNUSED. 552 If a `bind_in' request passes all checks described above, then the 553 server allocates an external address provided by the Firewall/NAT and 554 it establishes a uni-directional binding of the requested transport 555 parameter set with the new allocated address. Then the state machine 556 for this BID enters the state BIND_IN_ONLY and the server generates a 557 `231' reply reporting 559 - the BID allocated for this binding, 561 - the transport parameter set of the bound external address, 563 - the timeout in seconds after which the binding will automatically 564 be removed by the server. The timeout chosen by the server is 565 less than or equal to the value specified by the client in the 566 `bind_in' request message. 568 If a `bind_out' request passes the checks, the server allocates an 569 internal address provided by the Firewall/NAT and it establishes a 570 uni-directional binding of the requested transport parameter set to 571 the new allocated address. Then the state machine for this BID 572 enters the state BIND_OUT_ONLY and the server generates a `231' reply 573 reporting 575 - the BID allocated for this binding, 577 - the transport parameter set of the bound internal address, 579 - the timeout in seconds after which the binding will automatically 580 be removed by the server. The timeout chosen by the server is 581 less than or equal to the value specified by the client in the 582 `bind_out' request message. 584 5.3.3. Transitions from BIND_IN_ONLY and BIND_OUT_ONLY 586 In state BIND_IN_ONLY and BIND_OUT_ONLY a uni-directional address 587 binding is established. This might be sufficient for UDP connections, 588 but not for TCP. In these states the client can request to extend the 589 binding to a bi-directional one by sending a `bind_out' request in 590 state BIND_IN_ONLY or by sending a `bind_in' request in state 591 BIND_OUT_ONLY, respectively. The request must contain the BID of the 592 already existing uni-directional binding. 594 If the request fails the transport parameter set checking, then the 595 server generates the according `43X' reply and also it removes the 596 already established uni-directional binding. The binding state 597 machine then enters state BID_UNUSED. If the timeout specified by 598 the request message is 0, then the server generates a `233' reply and 599 removes the already established uni-directional binding. The binding 600 state machine then enters state BID_UNUSED. 602 Otherwise, if the request passes the checks of the transport 603 parameter set, the server creates a bi-directional binding to the 604 already known BID and chooses a timeout less than or equal to the 605 value specified by the request. The server generates a `232' reply 606 reporting the chosen timeout and the internal and the external 607 address allocated at the NAT/firewall. The BID state machine enters 608 state FULL_BINDING. 610 Other options for the client are requests for 612 - updating the timeout, 614 - modifying the binding while keeping the BID and keeping the 615 address allocated by the server, 617 - removing the binding. 619 Each of these actions requires the client sending another `bind_in' 620 request in state BIND_IN_ONLY or sending another `bind_out' request 621 in state BIND_OUT_ONLY. 623 For timeout update and for binding removal the client must use 624 exactly the transport parameter set already contained in the previous 625 requests for this BID. The server must ensure that such unchanged 626 transport parameters pass the transport parameter check. 628 If the timeout specified in the request message is 0, the server will 629 remove the binding and generate a `233' reply, and the binding state 630 machine enters state BID_UNUSED. 632 If the timeout specified in the message is larger than 0, the server 633 must process an update of the binding's timeout without any 634 interruption of the NAT/firewall operation for this binding. The 635 server chooses a timeout less than or equal to the value in the 636 request message and reports it by generating `231' reply. The 637 binding state machine remains in its state. 639 If the transport parameters specified in the request message differ 640 from the ones used in the previous message, then they are checked by 641 the server. A `43X' reply is generated on failure of one of these 642 checks. Then the server is supposed to modify the binding. If it is 643 not capable of doing so, it generates a `435' reply, removes the 644 binding and the binding state machine enters state BID_UNUSED. 646 Otherwise, the server will replace the established binding with a new 647 one. The modified binding will keep the address allocated by the 648 server, but bind it to the transport parameter set contained in the 649 message. The BID remains unchanged. Then the server generates a `231' 650 reply confirming the change and reporting the chosen timeout. The 651 binding state machine remains in its state. 653 At any time, the server may remove the binding. It must do so at 654 latest if the timeout expires. But also at any earlier time it may do 655 so, for example if the policy for granting binding requests has 656 changed, if a mis-use of the binding was detected, or if the server 657 cannot continue the operation of the binding for technical reasons. 658 In such a case the server generates an asynchronous `530' message 659 indicating the removal of the binding and the binding state machine 660 enters state BID_UNUSED. 662 5.3.4. Transitions from State FULL_BINDING 664 In state FULL_BINDING the client can request to 666 - update the timeout, 668 - remove the binding, 670 - modify the binding while keeping the BID and keepig the addresses 671 allocated by the server. 673 For timeout update and for binding removal the client can use a 674 `bind_in' request or a `bind_out' request. The request must use 675 exactly the transport parameter set already contained in the previous 676 `bind_in' request or `bind_out' request, respectively. The server 677 must ensure that such unchanged transport parameters pass the 678 transport parameter check. 680 If the timeout specified in the request message is 0, the server will 681 remove the binding and generate a `233' reply, and the binding state 682 machine enters state BID_UNUSED. 684 If the timeout specified in the message is larger than 0, the server 685 must process an update of the binding's timeout without any 686 interruption of the NAT/firewall operation for this binding. The 687 server chooses a timeout less than or equal to the value in the 688 request message and reports it by generating `231' reply. The 689 binding state machine remains in its state. 691 If the transport parameter set specified in the request message 692 differ from the ones used in the previous message, then they are 693 checked by the server. A `43X' reply is generated on failure of one 694 of these checks. Then the server is supposed to modify the binding. 695 If it is not capable of doing so, it generates a `435' reply, removes 696 the binding and the binding state machine enters state BID_UNUSED. 698 Otherwise, the server will replace the established binding with a new 699 one. The modified binding will keep the addresses allocated by the 700 server, but bind it to the transport parameter set contained in the 701 message. The BID remains unchanged. Then the server generates a `232' 702 reply confirming the change and reporting the chosen timeout. The 703 binding state machine remains in state FULL_BINDING. 705 At any time, the server may remove the binding. It must do so at 706 latest if the timeout expires. But also at any earlier time it may do 707 so, for example if the policy for granting binding requests has 708 changed, if a mis-use of the binding was detected, or if the server 709 cannot continue the operation of the binding for technical reasons. 710 In such a case the server generates an asynchronous `530' message 711 indicating the removal of the binding and the binding state machine 712 enters state BID_UNUSED. 714 6. Controling SNFC Sessions 716 After a secure TCP connection has been established between client and 717 server (for example by using TLS [5] or IPSEC [6][7]), the SNFC 718 session requires an initial authentication of the client. This might 719 be technically superfluous, for example if the client already 720 authenticated itself when establishing the connection, but it is an 721 inevitable step of establishing a SNFC session. The client 722 authenticates itself by sending an `open' request containing an 723 authentication string. This might be a shared secret (cookie) in 724 simple authentication systems. 726 For more secure challenge-reply authentication, the client first 727 sends an `open' request with an arbitrary authentication string. 728 When - as expected - the authentication failed, the server the server 729 returns a challengestring in the following `421' reply. Then the 730 client sends a second `open' request now containing the correct 731 authentication string derived from the challenge string. This 732 procedure is illustrated by the following Example (a). 734 For message flow examples in this memo we use the following 735 indication of the direction of a message: 737 C->S: from the client to the server 738 C<-S: from the server to the client 739 --: comment line 740 . . .: some unspecified messages 742 Example (a): successful authentication 743 -- TCP connection establishment and TLS or IPSEC establishment 744 -- client sends dummy authentication string: 0 745 C->S: open 1300 SNFC/1.0 0 746 -- server returns challenge string 747 C<-S: 421 1300 13e66f34b7416ab9389ccc5b441290aa 748 -- client sends correct authentication 749 C->S: open 1301 SNFC/1.0 ab54346de6933ff4556a1b23efd70082 750 C<-S: 220 1301 751 -- session now in state OPEN 752 . . . 753 -- SNFC message exchange 754 . . . 755 -- client closes session 756 C->S: close 40163 757 C<-S: 220 Ok 758 -- session now in state CLOSED 759 -- connection terminated 761 If the client fails to authenticate itself after a number of invalid 762 `open' requests, the server may disconnect itself from the client. 763 The server in Example (b) disconnects after two invalid `open' 764 requests. 766 Example (b): failed authentication 767 -- TCP connection establishment and TLS or IPSEC establishment 768 -- client sends invalid authentication string 769 C->S: open 55000 SNFC/1.0 34EFA 770 -- server returns challenge string 771 C<-S: 421 55000 13e66f34b7416ab9389ccc5b441290aa 772 -- client sends invalid authentication string 773 C->S: open 55333 SNFC/1.0 125d5 774 C->S: 421 55333 13e66f34b7416ab9389ccc5b441290aa 775 -- server in state CLOSED, client disconnected 777 The client closes a session by sending a `close' request. All 778 established bindings configured by this client will remain 779 established until their timeout expires. Also the server may 780 terminate an open session by sending an asynchronous `520' reply. 782 7. Controling Bindings and Pinholes 784 The client can request to establish, entend, modify and remove uni- 785 directional and bi-directional bindings and pinholes. All of these 786 requests, are variants of a `bind_in' or a `bind_out' request. The 787 `bind_in' request name is derived from `establish a binding of the 788 transport parameter set of an external address of the NAT/firewall to 789 the parameter set of an internal address'. A successful `bind_in' 790 request allows a data stream matching the corresponding parameter set 791 to pass the NAT/firewall from the external network to the internal 792 one. The `bind_out' request is defined analogously. 794 Each binding has a timeout value, which determines when a binding is 795 automatically removed by the SNFC server. The client makes a timeout 796 proposal in his `bind_in' or `bind_out' request and the server may 797 accept this proposal or choose a smaller timeout value. For example 798 the server may be configured to accept all timeout values up to a 799 predefined maximum value. The server informs the client about the 800 chosen timeout in by the next reply. 802 Control of bindings nad pinholes is illustrated by Example (c) 803 showing the establishment and removal of a uni-directional UDP 804 binding and pinhole. 806 Example (c): control of uni-directional UDP binding and pinhole 807 -- server is in state OPEN. 808 -- request with BID=0 for binding inner IP address 10.11.1.45 809 -- and UDP port 16175 for 180 seconds 810 C->S: bind_in 2044 0 10.11.1.45 16175 UDP 180 811 -- server allocates external IP address 195.37.70.5 and UDP port 812 -- 13222 and binds it to the internal transport parameter set 813 -- for 180 seconds. BID=1248. 814 C<-S: 231 2044 1248 195.37.70.5 13222 UDP 180 815 -- binding established and pinhole open 816 -- no more messages concerning this BID for 245 seconds 817 . . . 818 -- binding and pinhole not needed anymore 819 -- request to remove by setting timeout to 0 820 C->S: bind_in 2067 1248 10.11.1.45 16175 UDP 0 821 -- binding and pinhole removed 822 C<-S: 233 2067 1248 824 Example (d) shows the message flow of a similar request, but in this 825 case the server is a pure firewall without any NAT function. 826 Therefore the allocated transport parameter set is equal to the one 827 in the request. 829 Example (d): control of uni-directional UDP pinhole only 830 -- server is in state OPEN. 831 -- request with BID=0 for binding inner IP address 195.37.70.163 832 -- and UDP port 16175 for 180 seconds 833 C->S: bind_in 2144 0 195.37.70.163 16175 UDP 180 834 -- server does not allocate its own address, but it opens 835 -- a pinhole for the requested transport parameter set. 836 C<-S: 231 2144 1249 195.37.70.163 16175 UDP 180 837 -- pinhole open 838 -- no more messages concerning this BID for 245 seconds 839 . . . 840 -- pinhole not needed anymore 841 -- request to remove by setting timeout to 0 842 C->S: bind_in 2164 1249 195.37.70.163 16175 UDP 0 843 -- pinhole removed 844 C<-S: 233 2164 1249 846 The message flow for controling a bi-directional binding and pinhole 847 is illustrated by Example (e). It also shows the extension of the 848 timeout. 850 Example (e): control of bi-directional TCP binding and pinhole 851 -- server is in state OPEN. 852 -- request with BID=0 for binding inner IP address 10.11.1.50 853 -- and TCP port 4524 for 540 seconds 854 C->S: bind_in 8888 0 10.11.1.50 4524 TCP 540 855 -- server allocates external IP address 195.37.70.5 and TCP port 856 -- 17250 and binds it to the internal transport parameter set 857 -- for 300 seconds. BID=1250. 858 C<-S: 231 8888 1250 195.37.70.5 17250 TCP 300 859 -- request with BID=1250 for binding outer IP address 860 -- 134.169.34.13 and TCP port 22343 for 540 seconds 861 C->S: bind_out 8889 1250 134.169.34.13 22343 TCP 540 862 -- server allocates internal IP address 10.11.1.2 and TCP port 863 -- 5537 and binds it to the external transport parameter set 864 -- for 300 seconds. 865 C<-S: 232 8889 1250 10.11.1.2 5537 TCP 195.37.70.5 17250 TCP 300 866 -- no more messages concerning this BID for 280 seconds 867 . . . 868 -- binding and pinhole used and need longer as prior granted 869 -- request to extend timeout by 200 seconds 870 C->S: bind_in 9023 1250 10.11.1.50 4524 TCP 260 871 -- request granted 872 C<-S: 232 9023 1250 10.11.1.2 5537 TCP 195.37.70.5 17250 TCP 260 873 -- no more messages concerning this BID for 120 seconds 874 . . . 875 -- binding and pinhole not needed anymore 876 -- request to remove by setting timeout to 0 877 C->S: bind_out 9077 1250 134.169.34.13 22343 TCP 0 878 -- binding and pinhole removed 879 C<-S: 233 9077 1250 881 The last Example (f) shows the rejection of a request, because an 882 illegal internal IP address is used. 884 Example (f): Rejection of illegal internal IP address 885 -- server is in state OPEN 886 C->S: BIND_IN 458 0 102.12.12.251 1254 UDP 300 887 C<-S: 432 458 888 -- no new binding or pinhole established 890 8. Security Considerations 892 By their nature Firewalls and NATs are a very sensitive points 893 concerning network security. In general it appears to be 894 contradictive to open a port at a firewall for configuring pinholes, 895 because this might make the firewall vulnerable. Therefore, 896 effective means are required for inhibiting mis-use of the SNFC 897 service. 899 A SNFC server should use a restricted list of clients that are 900 allowed to use the service. Beyond checking the clients IP address 901 and requiring authentication when building up a secure TCP connection 902 with TLS or IPSEC., the server should expect the client to 903 authenticate itself by using a shared secret or based on a public key 904 infrastructure. 906 The TCP connection also needs to be protected for ensuring integrity 907 of the requests made by the client. Finally, confidentiality of the 908 data exchang between client and server is required to hide 909 information about the participants of communication services that are 910 enabled by SNFC. 912 9. References 914 [1] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) 915 Terminology and Considerations", RFC 2663, August 1999 917 [2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, A., 918 "Middlebox Communication Architecture and framework", Internet 919 Draft, work in progress, , 920 October 2001 922 [3] Huitema, C., "MIDCOM Scenarios", Internet Draft, work in progress, 923 , May 2001 925 [4] Swale, R.P., Mart, P.A., Sijben, P., "Middlebox Control (MIDCOM) 926 Protocol Architecture and Requirements", Internet Draft, work in 927 progress, , July 2001 929 [5] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 930 January 1999 932 [6] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2402, 933 November 1998 935 [7] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload 936 (ESP)", RFC 2406, November 1998 938 [8] Crocker, D., and Overell, P., "Augmented BNF for Syntax 939 Specifications: ABNF", RFC 2234, November 1997 941 10. Authors' Address 943 Martin Stiemerling 944 NEC Europe Ltd. 945 Network Laboratories 946 Adenauerplatz 6 947 69115 Heidelberg 948 Germany 950 Phone: +49 6221 90511-13 951 Email: stiemerling@ccrle.nec.de 953 Juergen Quittek 954 NEC Europe Ltd. 955 Network Laboratories 956 Adenauerplatz 6 957 69115 Heidelberg 958 Germany 960 Phone: +49 6221 90511-15 961 EMail: quittek@ccrle.nec.de 963 11. Full Copyright Statement 965 Copyright (C) The Internet Society (2001). All Rights Reserved. 967 This document and translations of it may be copied and furnished to 968 others, and derivative works that comment on or otherwise explain it 969 or assist in its implementation may be prepared, copied, published 970 and distributed, in whole or in part, without restriction of any 971 kind, provided that the above copyright notice and this paragraph are 972 included on all such copies and derivative works. However, this 973 document itself may not be modified in any way, such as by removing 974 the copyright notice or references to the Internet Society or other 975 Internet organizations, except as needed for the purpose of 976 developing Internet standards in which case the procedures for 977 copyrights defined in the Internet Standards process must be 978 followed, or as required to translate it into languages other than 979 English. 981 The limited permissions granted above are perpetual and will not be 982 revoked by the Internet Society or its successors or assigns. 984 This document and the information contained herein is provided on an 985 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 986 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 987 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 988 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 989 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.