idnits 2.17.00 (12 Aug 2021) /tmp/idnits58096/draft-werner-nsis-natfw-nslp-statemachine-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 841. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 9, 2007) is 5300 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) == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '1') == Outdated reference: draft-ietf-pana-statemachine has been published as RFC 5609 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS C. Werner 3 Internet-Draft N. Steinleitner, Ed. 4 Expires: May 12, 2008 X. Fu 5 Univ. Goettingen 6 H. Tschofenig 7 Nokia Siemens Networks 8 C. Aoun 9 November 9, 2007 11 NAT/FW NSLP State Machine 12 draft-werner-nsis-natfw-nslp-statemachine-06.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 12, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes the state machines for the NSIS Signaling 46 Layer Protocol for Network Address Translation/Firewall signaling 47 (NAT/FW NSLP). A set of state machines for NAT/FW NSLP entities at 48 different locations of a signaling path are presented in order to 49 illustrate how NAT/FW NSLP may be implemented. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Notational conventions used in state diagrams . . . . . . . . 3 56 4. State Machine Symbols . . . . . . . . . . . . . . . . . . . . 6 57 5. Common Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 7 59 5.2. Common Variables . . . . . . . . . . . . . . . . . . . . . 9 60 5.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. State machine for the NAT/FW NI/NR+ . . . . . . . . . . . . . 9 62 7. State machine for the NAT/FW NF . . . . . . . . . . . . . . . 11 63 8. State machine for the NAT/FW NR/NI+ . . . . . . . . . . . . . 15 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 72 Intellectual Property and Copyright Statements . . . . . . . . . . 21 74 1. Introduction 76 This document describes the state machines for NAT/FW NSLP [1], 77 trying to show how NAT/FW NSLP can be implemented to support its 78 deployment. The state machines described in this document are 79 illustrative of how the NAT/FW NSLP protocol defined in [1] may be 80 implemented for the first NAT/FW NSLP node in the signaling path, 81 intermediate NAT/FW NSLP nodes with Firewall and/or NAT 82 functionality, and the last NAT/FW NSLP node in the signaling path. 83 Where there are differences [1] are authoritative. The state 84 machines are informative only. Implementations may achieve the same 85 results using different methods. 87 The messages used in the NAT/FW NSLP protocol can be summarized as 88 follows: 90 Requesting message Responding message 91 ------------------------+--------------------------- 92 CREATE |RESPONSE 93 EXT |RESPONSE 94 RESPONSE |NONE 95 NOTIFY |NONE 96 ------------------------+--------------------------- 98 We describe a set of state machines for different roles of entities 99 running NAT/FW NSLP to illustrate how NAT/FW NSLP may be implemented. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [2]. 107 3. Notational conventions used in state diagrams 109 The following state transition tables are completed mostly based on 110 the conventions specified in [3]. The complete text is described 111 below. 113 State transition tables are used to represent the operation of the 114 protocol by a number of cooperating state machines each comprising a 115 group of connected, mutually exclusive states. Only one state of 116 each machine can be active at any given time. 118 All permissible transitions from a given state to other states and 119 associated actions performed when the transitions occur are 120 represented by using triplets of (exit condition, exit action, exit 121 state). All conditions are expressions that evaluate to TRUE or 122 FALSE; if a condition evaluates to TRUE, then the condition is met. 123 A state "ANY" is a wildcard state that matches the current state in 124 each state machine. The exit conditions of a wildcard state are 125 evaluated after all other exit conditions of specific to the current 126 state are met. 128 On exit from a state, the procedures defined for the state and the 129 exit condition are executed exactly once, in the order that they 130 appear on the page. (Note that the procedures defined in [4] are 131 executed on entry to a state, which is one major difference from this 132 document.) Each procedure is deemed to be atomic; i.e., execution of 133 a procedure completes before the next sequential procedure starts to 134 execute. No procedures execute outside of a state block. The 135 procedures in only one state block execute at a time, even if the 136 conditions for execution of state blocks in different state machines 137 are satisfied, and all procedures in an executing state block 138 complete execution before the transition to and execution of any 139 other state block occurs, i.e., the execution of any state block 140 appears to be atomic with respect to the execution of any other state 141 block and the transition condition to that state from the previous 142 state is TRUE when execution commences. The order of execution of 143 state blocks in different state machines is undefined except as 144 constrained by their transition conditions. A variable that is set 145 to a particular value in a state block retains this value until a 146 subsequent state block executes a procedure that modifies the value. 148 On completion of the transition from the previous state to the 149 current state, all exit conditions for the current state (including 150 exit conditions defined for the wildcard state) are evaluated 151 continuously until one of the conditions is met. 153 Any event variable is set to TRUE when the corresponding event occurs 154 and set to FALSE immediately after completion of the action 155 associated with the current state and the event. 157 The interpretation of the special symbols and operators is reused 158 from [4] and the state diagrams are based on the conventions 159 specified in [5], Section 8.2.1. 161 The complete text is reproduced here: 163 State diagrams are used to represent the operation of the protocol 164 by a number of cooperating state machines each comprising a group 165 of connected, mutually exclusive states. Only one state of each 166 machine can be active at any given time. 168 All permissible transitions between states are represented by 169 arrows, the arrowhead denoting the direction of the possible 170 transition. Labels attached to arrows denote the condition(s) 171 that must be met in order for the transition to take place. All 172 conditions are expressions that evaluate to TRUE or FALSE; if a 173 condition evaluates to TRUE, then the condition is met. The label 174 UCT denotes an unconditional transition (i.e., UCT always 175 evaluates to TRUE). A transition that is global in nature (i.e., 176 a transition that occurs from any of the possible states if the 177 condition attached to the arrow is met) is denoted by an open 178 arrow; i.e., no specific state is identified as the origin of the 179 transition. When the condition associated with a global 180 transition is met, it supersedes all other exit conditions 181 including UCT. The special global condition BEGIN supersedes all 182 other global conditions, and once asserted remains asserted until 183 all state blocks have executed to the point that variable 184 assignments and other consequences of their execution remain 185 unchanged. 187 On entry to a state, the procedures defined for the state (if any) 188 are executed exactly once, in the order that they appear on the 189 page. Each action is deemed to be atomic; i.e., execution of a 190 procedure completes before the next sequential procedure starts to 191 execute. No procedures execute outside of a state block. The 192 procedures in only one state block execute at a time, even if the 193 conditions for execution of state blocks in different state 194 machines are satisfied, and all procedures in an executing state 195 block complete execution before the transition to and execution of 196 any other state block occurs, i.e., the execution of any state 197 block appears to be atomic with respect to the execution of any 198 other state block and the transition condition to that state from 199 the previous state is TRUE when execution commences. The order of 200 execution of state blocks in different state machines is undefined 201 except as constrained by their transition conditions. A variable 202 that is set to a particular value in a state block retains this 203 value until a subsequent state block executes a procedure that 204 modifies the value. 206 On completion of all of the procedures within a state, all exit 207 conditions for the state (including all conditions associated with 208 global transitions) are evaluated continuously until one of the 209 conditions is met. The label ELSE denotes a transition that 210 occurs if none of the other conditions for transitions from the 211 state are met (i.e., ELSE evaluates to TRUE if all other possible 212 exit conditions from the state evaluate to FALSE). Where two or 213 more exit conditions with the same level of precedence become TRUE 214 simultaneously, the choice as to which exit condition causes the 215 state transition to take place is arbitrary. 217 In addition to the above notation, there are a couple of 218 clarifications specific to this document. First, all boolean 219 variables are initialized to FALSE before the state machine execution 220 begins. Second, the following notational shorthand is specific to 221 this document: 223 = | | ... 224 Execution of a statement of this form will result in 225 having a value of exactly one of the expressions. The logic for 226 which of those expressions gets executed is outside of the state 227 machine and could be environmental, configurable, or based on 228 another state machine such as that of the method. 230 4. State Machine Symbols 232 ( ) Used to force the precedence of operators in Boolean expressions 233 and to delimit the argument(s) of actions within state boxes. 234 ; Used as a terminating delimiter for actions within state boxes. 235 Where a state box contains multiple actions, the order of 236 execution follows the normal language conventions for reading 237 text. 238 = Assignment action. The value of the expression to the right of 239 the operator is assigned to the variable to the left of the 240 operator. Where this operator is used to define multiple 241 assignments, e.g., a = b = X the action causes the value of the 242 expression following the right-most assignment operator to be 243 assigned to all of the variables that appear to the left of the 244 right-most assignment operator. 245 ! Logical NOT operator. 246 && Logical AND operator. 247 || Logical OR operator. 248 if...then... Conditional action. If the Boolean expression 249 following the if evaluates to TRUE, then the action following the 250 then is executed. 251 { statement 1, ... statement N } Compound statement. Braces are 252 used to group statements that are executed together as if they 253 were a single statement. 254 != Inequality. Evaluates to TRUE if the expression to the left of 255 the operator is not equal in value to the expression to the right. 256 == Equality. Evaluates to TRUE if the expression to the left of the 257 operator is equal in value to the expression to the right. 258 > Greater than. Evaluates to TRUE if the value of the expression to 259 the left of the operator is greater than the value of the 260 expression to the right. 262 <= Less than or equal to. Evaluates to TRUE if the value of the 263 expression to the left of the operator is either less than or 264 equal to the value of the expression to the right. 265 ++ Increment the preceding integer operator by 1. 267 5. Common Rules 269 Throughout the document we use terms defined in the [1], such as NI, 270 NF, NR, CREATE, EXT or RESPONSE. 272 5.1. Common Procedures 274 tx_CREATE(): Transmit a CREATE message 275 tx_CREATE(LIFETIME>0): Transmit CREATE message with lifetime object 276 greater than 0 for session creation. 277 tx_CREATE(LIFETIME=0): Transmit CREATE message with lifetime object 278 explicitly set to 0 for session deletion. 279 tx_RESPONSE(code,type): Transmit RESPONSE message with specified 280 code (SUCCESS or ERROR) and result type (related to a specific 281 request type message: CREATE or EXT). A code or result type may 282 be omitted, typically when forwarding received RESPONSE messages. 283 tx_EXT(): Transmit a EXT message 284 rx_RESPONSE(code, type): Evaluates to TRUE if a RESPONSE message has 285 been received with the specified code (SUCCESS or ERROR) and 286 result type (related to a specific request type message: CREATE or 287 EXT). If the code or type is omitted, any received RESPONSE 288 message which is only matching the given code or type will 289 evaluate this procedure to TRUE. 290 rx_CREATE(): Evaluates to TRUE if a CREATE message has been 291 received. 292 rx_CREATE(Lifetime > 0): Evaluates to TRUE if a CREATE message with 293 lifetime object greater than 0 has been received. 294 rx_CREATE(Lifetime == 0): Evaluates to TRUE if a CREATE message with 295 lifetime object explicitly set to 0 has been received. 296 rx_EXT(): Evaluates to TRUE if a EXT message has been received. 297 rx_EXT(Lifetime > 0): Evaluates to TRUE if a EXT message with 298 lifetime object greater than 0 has been received. 299 rx_EXT(Lifetime == 0): Evaluates to TRUE if a EXT message with 300 lifetime object explicitly set to 0 has been received. 301 CHECK_AA(): Checks Authorization and Authentication of the received 302 message. Evaluates to TRUE if the check is successful, otherwise 303 it evaluates to FALSE. This check is performed on all received 304 messages hence it will only be shown within the state machine when 305 the check has failed. This CHECK_AA also MAY include a local 306 policy check for the received message. 308 CreateSession(): Installs all session related states, variables, 309 bindings, policies. 310 DeleteSession(): Removes all session related states, variables, 311 bindings, policies. 312 CreatePinhole(): Installs a pinhole for the new session. 313 DeletePinhole(): Removes a previously installed pinhole. 314 CreateReservations(): Creates a matching based on the MRI and open 315 pinholes for the signaling traffic. 316 DeleteReservations(): Deletes previously installed matchings and 317 pinholes for the signaling traffic. 318 CreateBinding(): Creates a public/private network translation 319 binding on a NAT device for the requesting entity. 320 DeleteBinding(): Deletes a previously created a public/private 321 network translation binding on a NAT device for the requesting 322 entity. 323 StartTimer(identifier): This procedure starts a timer with a certain 324 timespan, which is up to the specific implementation. The 325 parameter 'identifier' identifies this timer uniquely. Any 326 subsequent StartTimer(identifier), StopTimer(identifier), 327 (identifier)_TIMEOUT refer to the same timer labeled x. This 328 timer is required to time the lifetime of state, which means that 329 when it times out, it indicates the current machine state should 330 be left or its validation has expired. This procedure starts the 331 timer 'identifier'. If a timer with the same 'identifier' has 332 already been started and not yet stopped, the timer is now stopped 333 and restarted. After the timer has timed out, the procedure 334 (identifier)_TIMEOUT evaluates to TRUE. The timer does not 335 restart automatically, but must be started again with a 336 StartTimer(identifier). Used identifier are STATE, REFRESH, 337 CREATE, EXT or RESPONSE. 338 StopTimer(identifier): This procedure stops the timer labeled 339 'identifier'. If it has already been stopped, this procedure has 340 no effect. If the timer has already timed out, this procedure 341 removes the timeout-state from the timer 'identifier', so 342 subsequent calls to (identifier)_TIMEOUT evaluate to FALSE. A 343 timeout cannot occur until the timer 'identifier' has been 344 (re-)started. 345 (identifier)_TIMEOUT: This procedure evaluates to TRUE if the 346 (identifier)-timer has timed out and indicates a state lifetime 347 expiration. This procedure cannot evaluate to TRUE if the timer 348 has been stopped. Used timers are STATE_TIMEOUT, REFRESH_TIMEOUT, 349 CREATE_TIMEOUT, EXT_TIMEOUT or RESPONSE_TIMEOUT. 350 tg_CREATE: External trigger to send a CREATE message (typically 351 triggered by the application). 353 tg_TEARDOWN: External trigger to delete a previously created session 354 (typically triggered by the application) 355 tg_EXT: External trigger to send a EXT message towards an 356 opportunistic address (typically triggered by the application) 357 tg_CREATE_PROXY: Internal trigger to send a CREATE message (used in 358 proxy mode, triggered by corresponding NAT/FW NSLP session). 359 tg_TEARDOWN_PROXY: Internal trigger to delete a previously created 360 session (used in proxy mode, triggered by corresponding NAT/FW 361 NSLP session). 363 5.2. Common Variables 365 IS_EDGE: Boolean flag which evaluates to TRUE if the node is on the 366 network edge, otherwise it evaluates to FALSE. 367 IS_PUBLICSIDE: Boolean flag which evaluates to TRUE if the (CREATE- 368 or EXT-) message has been received on the public side of the 369 network. 370 CREATE(LIFETIME): Gets the value of the LIFETIME object in the 371 CREATE message. 372 counter(CREATE): Denotes the current number of retries of CREATE 373 message which has been re-transmitted due to previous 374 RESPONSE_ERROR message. If the number of counter(CREATE) equals 375 the value of counterLimit(CREATE), the current session creation 376 attempt is aborted and the application is being notified. 377 counter(EXT): Denotes the current number of retries of EXT message 378 which has been re-transmitted due to previous RESPONSE_ERROR 379 message. If the number of counter(EXT) equals the value of 380 counterLimit(EXT), the current session creation attempt is aborted 381 and the application is being notified. 383 5.3. Constants 385 counterLimit(CREATE): Contains the maximum number of retransmission 386 attempts of a CREATE message after it is aborted and the 387 application is being notified. 388 counterLimit(EXT): Contains the maximum number of retransmission 389 attempts of a EXT message after it is aborted and the application 390 is being notified. 392 6. State machine for the NAT/FW NI/NR+ 394 This section presents the state machine for the NSIS initator which 395 is capable of NAT/FW NSLP signaling. 397 ----------- 398 State: INITIALIZE 399 ----------- 401 Condition Action State 402 ----------------------------+-----------------------------+---------- 403 UCT |Initialize variables | IDLE 404 ----------------------------+-----------------------------+---------- 406 ----------- 407 State: IDLE 408 Entry: DeleteSession(); 409 Exit : CreateSession(); 410 ----------- 412 Condition Action State 413 ----------------------------+-----------------------------+---------- 414 tg_CREATE |tx_CREATE(); | WAITRESP 415 | | 416 tg_CREATE_PROXY |tx_CREATE(); | WAITRESP 417 ----------------------------+-----------------------------+---------- 419 ----------- 420 State: WAITRESP 421 Entry: ResetCounter(CREATE); 422 StartTimer(RESPONSE); 423 Exit : StopTimer(RESPONSE); 424 ----------- 426 Condition Action State 427 ----------------------------+-----------------------------+---------- 428 RESPONSE_TIMEOUT && |counter(CREATE)++; | WAITRESP 429 (counter(CREATE)< |StartTimer(RESPONSE); | 430 counterLimit(CREATE)) |tx_CREATE(); | 431 | | 432 rx_RESPONSE(SUCCESS,CREATE) |ReportAsyncEvent(); | SESSION 433 | | 434 tg_TEARDOWN |tx_CREATE(Lifetime=0); | IDLE 435 | | 436 tg_TEARDOWN_PROXY |tx_CREATE(Lifetime=0); | IDLE 437 | | 438 RESPONSE_TIMEOUT && |ReportAsyncEvent(); | IDLE 439 (counter(CREATE)== | | 440 counterLimit(CREATE)) | | 441 | | 442 rx_RESPONSE(ERROR,CREATE) |ReportAsyncEvent(); | IDLE 443 ----------------------------+-----------------------------+---------- 445 ----------- 446 State: SESSION 447 Entry: ResetCounter(CREATE); 448 StartTimer(REFRESH); 449 Exit : StopTimer(REFRESH); 450 StopTimer(RESPONSE); 451 ----------- 453 Condition Action State 454 ----------------------------+-----------------------------+---------- 455 REFRESH_TIMEOUT |StartTimer(RESPONSE); | SESSION 456 |tx_CREATE(); | 457 | | 458 RESPONSE_TIMEOUT && |counter(CREATE)++; | SESSION 459 (counter(CREATE) < |StartTimer(RESPONSE); | 460 counterLimit(CREATE)) |tx_CREATE(); | 461 | | 462 rx_RESPONSE(SUCCESS,CREATE) |StopTimer(RESPONSE); | SESSION 463 |StartTimer(REFRESH); | 464 |ResetCounter(CREATE); | 465 | | 466 tg_TEARDOWN |tx_CREATE(LIFETIME=0); | IDLE 467 | | 468 tg_TEARDOWN_PROXY |tx_CREATE(LIFETIME=0); | IDLE 469 | | 470 RESPONSE_TIMEOUT && |ReportAsyncEvent(); | IDLE 471 (counter(CREATE) == | | 472 counterLimit(CREATE)) | | 473 | | 474 rx_RESPONSE(ERROR,CREATE) |ReportAsyncEvent(); | IDLE 475 ----------------------------+-----------------------------+---------- 477 7. State machine for the NAT/FW NF 479 This section describes the state machine for intermediate nodes 480 within the signaling path capable of processing NAT/FW NSLP messages. 481 These nodes typically implement firewall and/or network address 482 translation (NAT) functionality. 484 Condition Action State 485 ----------------------------+-----------------------------+---------- 486 UCT |Initialize variables | IDLE 487 ----------------------------+-----------------------------+---------- 489 ----------- 490 State: IDLE 491 Entry: DeleteSession(); 492 Exit : CreateSession(); 493 ----------- 495 Condition Action State 496 ----------------------------+-----------------------------+---------- 497 (rx_EXT) && (IS_PUBLICSIDE) |tx_RESPONSE(ERROR, EXT); | IDLE 498 | | 499 (rx_CREATE(Lifetime > 0)) |tx_CREATE(); | CREATE_ 500 | | WAITRESP 501 | | 502 ((rx_EXT) && (!IS_EDGE) |tx_EXT(); | NONEDGE_ 503 && (!IS_PUBLICSIDE)) | | EXT 504 | | 505 ((rx_EXT) && (IS_EDGE) |tx_RESPONSE(SUCCESS,EXT); | EDGE_EXT 506 && (!IS_PUBLICSIDE)) |tx_CREATE; | 507 |if(proxy_object) then | 508 | (tg_CREATE_PROXY);| 509 ----------------------------+-----------------------------+---------- 511 ----------- 512 State: CREATE_WAITRESP 513 Entry: StartTimer(STATE); 514 Exit : StopTimer(STATE); 515 ----------- 517 Condition Action State 518 ----------------------------+-----------------------------+---------- 519 rx_RESPONSE(ERROR,CREATE) |tx_RESPONSE(ERROR,CREATE); | IDLE 520 |ReportAsyncEvent(); | 521 | | 522 STATE_TIMEOUT |tx_RESPONSE(ERROR,CREATE); | IDLE 523 |ReportAsyncEvent(); | 524 | | 525 (rx_CREATE(Lifetime == 0)) |tx_CREATE(Lifetime=0); | IDLE 526 | | 527 rx_RESPONSE(SUCCESS,CREATE) |tx_RESPONSE(SUCCESS,CREATE); | SESSION 528 ----------------------------+-----------------------------+---------- 529 ----------- 530 State: NONEDGE_EXT 531 Entry: StartTimer(EXT); 532 CreateReservations(); 533 Exit : StopTimer(EXT); 534 DeleteReservations(); 535 ----------- 537 Condition Action State 538 ----------------------------+-----------------------------+---------- 539 (rx_EXT(Lifetime > 0)) |StopTimer(EXT); | NONEDGE_ 540 |StartTimer(EXT); | EXT 541 |tx_EXT(); | 542 | | 543 rx_RESPONSE(SUCCESS, EXT) |tx_RESPONSE(SUCCESS,EXT); | NONEDGE_ 544 | | EXT 545 | | 546 rx_RESPONSE(ERROR, EXT) |tx_RESPONSE(ERROR,EXT); | IDLE 547 |ReportAsyncEvent(); | 548 | | 549 (rx_EXT(Lifetime == 0)) |tx_EXT(Lifetime=0); | IDLE 550 |ReportAsyncEvent(); | 551 | | 552 EXT_TIMEOUT |ReportAsyncEvent(); | IDLE 553 ----------------------------+-----------------------------+---------- 554 ----------- 555 State: EDGE_EXT 556 Entry: StartTimer(EXT); 557 CreateReservations(); 558 Exit : StopTimer(EXT); 559 DeleteReservations(); 560 ----------- 562 Condition Action State 563 ----------------------------+-----------------------------+---------- 564 (rx_EXT(Lifetime > 0)) |StopTimer(EXT); | EDGE_EXT 565 |StartTimer(EXT); | 566 |tx_RESPONSE(SUCCESS, EXT); | 567 | | 568 (rx_EXT(Lifetime == 0)) |tx_EXT(Lifetime=0); | IDLE 569 |ReportAsyncEvent(); | 570 |if(proxy_mode) then | 571 | (tg_TEARDOWN_PROXY);| 572 | | 573 EXT_TIMEOUT |ReportAsyncEvent(); | IDLE 574 |if(proxy_mode) then | 575 | (tg_TEARDOWN_PROXY);| 576 ----------------------------+-----------------------------+---------- 577 ----------- 578 State: SESSION 579 Entry: StartTimer(CREATE) 580 CreatePinhole(); 581 CreateBinding(); 582 Exit : StopTimer(RESPONSE); 583 StopTimer(CREATE); 584 DeletePinhole(); 585 DeleteBinding(); 586 ----------- 588 Condition Action State 589 ----------------------------+-----------------------------+---------- 590 RESPONSE_TIMEOUT |StopTimer(RESPONSE); | SESSION 591 |tx_RESPONSE(ERROR,CREATE); | 592 | | 593 (rx_EXT(Lifetime > 0)) |StopTimer(CREATE); | SESSION 594 |StartTimer(RESPONSE); | 595 |tx_CREATE(); | 596 | | 597 rx_RESPONSE(SUCCESS,CREATE) |StopTimer(RESPONSE); | SESSION 598 |StartTimer(CREATE); | 599 |tx_RESPONSE(SUCCESS,CREATE); | 600 | | 601 CREATE_TIMEOUT |ReportAsyncEvent(); | IDLE 602 | | 603 (rx_EXT(Lifetime == 0)) |tx_CREATE(Lifetime=0); | IDLE 604 ----------------------------+-----------------------------+---------- 606 8. State machine for the NAT/FW NR/NI+ 608 This section presents the state machines for the NSIS responder which 609 is capable of NSLP NAT/FW signaling. 611 ----------- 612 State: INITIALIZE 613 ----------- 615 Condition Action State 616 ----------------------------+-----------------------------+---------- 617 UCT |Initialize variables | IDLE 618 ----------------------------+-----------------------------+---------- 619 ----------- 620 State: IDLE 621 Entry: DeleteSession(); 622 Exit : CreateSession(); 623 ----------- 625 Condition Action State 626 ----------------------------+-----------------------------+---------- 627 (rx_CREATE) && !(CHECK_AA())|tx_RESPONSE(ERROR,CREATE); | IDLE 628 | | 629 tg_EXT |tx_EXT(); | EXT_ 630 | | WAITRESP 631 | | 632 (rx_EXT(Lifetime > 0)) |tx_RESPONSE(SUCCESS,CREATE); | SESSION 633 ----------------------------+-----------------------------+---------- 635 ----------- 636 State: EXT_WAITRESP 637 Entry: ResetCounter(EXT); 638 StartTimer(RESPONSE); 639 Exit : StopTimer(RESPONSE); 640 ----------- 642 Condition Action State 643 ----------------------------+-----------------------------+---------- 644 RESPONSE_TIMEOUT && |counter(EXT)++; | EXT_ 645 (counter(EXT) < |StartTimer(RESPONSE); | WAITRESP 646 counterLimit(EXT)) |tx_EXT(); | 647 | | 648 rx_RESPONSE(SUCCESS,EXT) |ReportAsyncEvent(); | EXT 649 | | 650 RESPONSE_TIMEOUT && |ReportAsyncEvent(); | IDLE 651 (counter(EXT) == | | 652 counterLimit(EXT)) | | 653 | | 654 rx_RESPONSE(ERROR,EXT) |ReportAsyncEvent(); | IDLE 655 | | 656 tg_TEARDOWN |tx_EXT(Lifetime=0); | IDLE 657 ----------------------------+-----------------------------+---------- 658 ----------- 659 State: EXT 660 Entry: ResetCounter(EXT); 661 StartTimer(REFRESH); 662 Exit : StopTimer(RESPONSE); 663 StopTimer(REFRESH); 664 ----------- 666 Condition Action State 667 ----------------------------+-----------------------------+---------- 668 RESPONSE_TIMEOUT && |counter(EXT)++; | EXT 669 (counter(EXT) < |StartTimer(RESPONSE); | 670 counterLimit(EXT)) |tx_EXT(); | 671 | | 672 rx_RESPONSE(SUCCESS,EXT) |StartTimer(REFRESH); | EXT 673 |StopTimer(RESPONSE); | 674 |ResetCounter(EXT); | 675 | | 676 REFRESH_TIMEOUT |tx_EXT(); | EXT 677 |StartTimer(RESPONSE); | 678 | | 679 RESPONSE_TIMEOUT && |ReportAsyncEvent(); | IDLE 680 (counter(EXT) == | | 681 counterLimit(EXT)) | | 682 | | 683 rx_RESPONSE(ERROR,EXT) |ReportAsyncEvent(); | IDLE 684 | | 685 tg_TEARDOWN |tx_EXT(Lifetime=0); | IDLE 686 ----------------------------+-----------------------------+---------- 688 ----------- 689 State: SESSION 690 Entry: StartTimer(STATE); 691 Exit : StopTimer(STATE); 692 ----------- 694 Condition Action State 695 ----------------------------+-----------------------------+---------- 696 (rx_CREATE(LIFETIME > 0)) |tx_RESPONSE(SUCCESS,CREATE); | SESSION 697 |StopTimer(STATE); | 698 |StartTimer(STATE); | 699 | | 700 (rx_CREATE(LIFETIME == 0)) |ReportAsyncEvent(); | IDLE 701 | | 702 STATE_TIMEOUT |ReportAsyncEvent(); | IDLE 703 ----------------------------+-----------------------------+---------- 705 9. Security Considerations 707 This document does not raise new security considerations. Any 708 security concerns with the NAT/FW NSLP are likely reflected in 709 security related NSIS work already (such as [1] or [6]). 711 For the time being, the state machines described in this document do 712 not consider the security aspect of NAT/FW NSLP protocol itself. A 713 future version of this document will add security relevant states and 714 state transitions. 716 10. Open Issues 718 Route change and the open issues in [1] will be added in future 719 versions of this document. 721 11. Contributors 723 Tseno Tsenov contributed since the initial version and Henning Peters 724 collaborated to refining of the state machine since 01 version. 726 12. Acknowledgments 728 The authors would like to thank Martin Stiemerling for his valuable 729 comments and discussions. 731 13. References 733 13.1. Normative References 735 [1] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 736 (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress), 737 July 2007. 739 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 740 Levels", RFC 2119, March 1997. 742 13.2. Informative References 744 [3] Fajardo, V., "State Machines for Protocol for Carrying 745 Authentication for Network Access (PANA)", 746 draft-ietf-pana-statemachine-06 (work in progress), 747 October 2007. 749 [4] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State 750 Machines for Extensible Authentication Protocol (EAP) Peer and 751 Authenticator", RFC 4137, August 2005. 753 [5] Institute of Electrical and Electronics Engineers, "DRAFT 754 Standard for Local and Metropolitan Area Networks: Port-Based 755 Network Access Control (Revision)", IEEE 802-1X-REV/D9, 756 January 2004. 758 [6] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 759 Steps in Signaling (NSIS)", RFC 4081, June 2005. 761 Authors' Addresses 763 Constantin Werner 764 University of Goettingen 765 Telematics Group 766 Lotzestr. 16-18 767 Goettingen 37083 768 Germany 770 Email: werner@cs.uni-goettingen.de 772 Niklas Steinleitner (editor) 773 University of Goettingen 774 Telematics Group 775 Lotzestr. 16-18 776 Goettingen 37083 777 Germany 779 Email: steinleitner@cs.uni-goettingen.de 781 Xiaoming Fu 782 University of Goettingen 783 Telematics Group 784 Lotzestr. 16-18 785 Goettingen 37083 786 Germany 788 Email: fu@cs.uni-goettingen.de 789 Hannes Tschofenig 790 Nokia Siemens Networks 791 Otto-Hahn-Ring 6 792 Munich, Bavaria 81739 793 Germany 795 Email: Hannes.Tschofenig@nsn.com 797 Cedric Aoun 798 Paris 799 France 801 Email: cedric@caoun.net 803 Full Copyright Statement 805 Copyright (C) The IETF Trust (2007). 807 This document is subject to the rights, licenses and restrictions 808 contained in BCP 78, and except as set forth therein, the authors 809 retain all their rights. 811 This document and the information contained herein are provided on an 812 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 813 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 814 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 815 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 816 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Intellectual Property 821 The IETF takes no position regarding the validity or scope of any 822 Intellectual Property Rights or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; nor does it represent that it has 826 made any independent effort to identify any such rights. Information 827 on the procedures with respect to rights in RFC documents can be 828 found in BCP 78 and BCP 79. 830 Copies of IPR disclosures made to the IETF Secretariat and any 831 assurances of licenses to be made available, or the result of an 832 attempt made to obtain a general license or permission for the use of 833 such proprietary rights by implementers or users of this 834 specification can be obtained from the IETF on-line IPR repository at 835 http://www.ietf.org/ipr. 837 The IETF invites any interested party to bring to its attention any 838 copyrights, patents or patent applications, or other proprietary 839 rights that may cover technology that may be required to implement 840 this standard. Please address the information to the IETF at 841 ietf-ipr@ietf.org. 843 Acknowledgment 845 Funding for the RFC Editor function is provided by the IETF 846 Administrative Support Activity (IASA).