idnits 2.17.1 draft-ietf-midcom-rfc3989-bis-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3239. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (June 2007) is 6152 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) -- Obsolete informational reference (is this intentional?): RFC 3989 (ref. 'MDC-SEM') (Obsoleted by RFC 5189) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stiemerling 3 Internet-Draft J. Quittek 4 Obsoletes: 3989 NEC 5 Intended status: Proposed Standard T. Taylor 6 Expires: December 2007 Nortel 7 June 2007 9 Middlebox Communications (MIDCOM) Protocol Semantics 10 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies semantics for a Middlebox Communication 42 (MIDCOM) protocol to be used by MIDCOM agents for interacting with 43 middleboxes such as firewalls and Network Address Translators (NATs). 44 The semantics discussion does not include any specification of a 45 concrete syntax or a transport protocol. However, a concrete 46 protocol is expected to implement the specified semantics or, more 47 likely, a superset of it. The MIDCOM protocol semantics is derived 48 from the MIDCOM requirements, from the MIDCOM framework, and from 49 working group decisions. This document obsoletes RFC 3989. 51 Table of Contents 53 1. Introduction ................................................. 4 54 1.1. Terminology ............................................ 5 55 1.2. Transaction Definition Template ........................ 7 56 2. Semantics Specification ...................................... 8 57 2.1. General Protocol Design ................................ 8 58 2.1.1. Protocol Transactions .......................... 9 59 2.1.2. Message Types .................................. 10 60 2.1.3. Session, Policy Rule, and Policy Rule Group .... 10 61 2.1.4. Atomicity ...................................... 11 62 2.1.5. Access Control ................................. 12 63 2.1.6. Middlebox Capabilities ......................... 12 64 2.1.7. Agent and Middlebox Identifiers ................ 13 65 2.1.8. Conformance .................................... 13 66 2.2. Session Control Transactions ........................... 14 67 2.2.1. Session Establishment (SE) ..................... 14 68 2.2.2. Session Termination (ST) ....................... 16 69 2.2.3. Asynchronous Session Termination (AST) ......... 17 70 2.2.4. Session Termination by Interruption of 71 Connection ..................................... 18 72 2.2.5. Session State Machine .......................... 18 73 2.3. Policy Rule Transactions ............................... 19 74 2.3.1. Configuration Transactions ..................... 20 75 2.3.2. Establishing Policy Rules ...................... 20 76 2.3.3. Maintaining Policy Rules and Policy Rule Groups 21 77 2.3.4. Policy Events and Asynchronous Notifications ... 22 78 2.3.5. Address Tuples ................................. 22 79 2.3.6. Address Parameter Constraints .................. 24 80 2.3.7. Interface-specific Policy Rules ................ 26 81 2.3.8. Policy Reserve Rule (PRR) ...................... 27 82 2.3.9. Policy Enable Rule (PER) ....................... 31 83 2.3.10. Policy Rule Lifetime Change (RLC) .............. 37 84 2.3.11. Policy Rule List (PRL) ......................... 39 85 2.3.12. Policy Rule Status (PRS) ....................... 40 86 2.3.13. Asynchronous Policy Rule Event (ARE) ........... 42 87 2.3.14. Policy Rule State Machine ...................... 43 88 2.4. Policy Rule Group Transactions ......................... 44 89 2.4.1. Overview ....................................... 44 90 2.4.2. Group Lifetime Change (GLC) .................... 45 91 2.4.3. Group List (GL) ................................ 47 92 2.4.4. Group Status (GS) .............................. 48 93 3. Conformance Statements ....................................... 49 94 3.1. General Implementation Conformance ..................... 50 95 3.2. Middlebox Conformance .................................. 51 96 3.3. Agent Conformance ...................................... 51 98 4. Transaction Usage Examples ................................... 51 99 4.1. Exploring Policy Rules and Policy Rule Groups .......... 51 100 4.2. Enabling a SIP-Signaled Call ........................... 55 101 5. Compliance with MIDCOM Requirements .......................... 60 102 5.1. Protocol Machinery Requirements ........................ 60 103 5.1.1. Authorized Association ......................... 60 104 5.1.2. Agent Connects to Multiple Middleboxes ......... 61 105 5.1.3. Multiple Agents Connect to Same Middlebox ...... 61 106 5.1.4. Deterministic Behavior ......................... 61 107 5.1.5. Known and Stable State ......................... 61 108 5.1.6. Status Report .................................. 62 109 5.1.7. Unsolicited Messages (Asynchronous 110 Notifications).................................. 62 111 5.1.8. Mutual Authentication .......................... 62 112 5.1.9. Session Termination by Any Party ............... 63 113 5.1.10. Request Result ................................. 63 114 5.1.11. Version Interworking ........................... 63 115 5.1.12. Deterministic Handling of Overlapping Rules .... 63 116 5.2. Protocol Semantics Requirements ........................ 64 117 5.2.1. Extensible Syntax and Semantics ................ 64 118 5.2.2. Policy Rules for Different Types of Middleboxes 64 119 5.2.3. Ruleset Groups ................................. 64 120 5.2.4. Policy Rule Lifetime Extension ................. 64 121 5.2.5. Robust Failure Modes ........................... 64 122 5.2.6. Failure Reasons ................................ 64 123 5.2.7. Multiple Agents Manipulating Same Policy Rule .. 65 124 5.2.8. Carrying Filtering Rules ....................... 65 125 5.2.9. Parity of Port Numbers ......................... 65 126 5.2.10. Consecutive Range of Port Numbers .............. 65 127 5.2.11. Contradicting Overlapping Policy Rules ......... 65 128 5.3. Security Requirements .................................. 66 129 5.3.1. Authentication, Confidentiality, Integrity ..... 66 130 5.3.2. Optional Confidentiality of Control Messages ... 66 131 5.3.3. Operation across Untrusted Domains ............. 66 132 5.3.4. Mitigate Replay Attacks ........................ 66 133 6. Security Considerations ...................................... 66 134 7. IAB Considerations on UNSAF .................................. 67 135 8. IANA Considerations .......................................... 68 136 9. Acknowledgments .............................................. 68 137 10. Informative References ....................................... 68 138 10.1. Normative References ................................... 68 139 10.2. Informative References ................................. 68 140 Appendix A. Changes from RFC 3989 ............................... 69 141 Authors' Addresses ............................................... 70 142 Intellectual Property and Copyright Statements ................... 71 144 1. Introduction 146 The MIDCOM working group has defined a framework [MDC-FRM] and a list 147 of requirements [MDC-REQ] for middlebox communication. The next step 148 toward a MIDCOM protocol is the specification of protocol semantics 149 that is constrained, but not completely implied, by the documents 150 mentioned above. 152 This memo suggests a semantics for the MIDCOM protocol. It is fully 153 compliant with the requirements listed in [MDC-REQ] and with the 154 working group's consensus on semantic issues. This document 155 obsoletes RFC 3989 [MDC-SEM]. 157 In conformance with the working group charter, the semantics 158 description is targeted at packet filters and network address 159 translators (NATs), and it supports applications that require dynamic 160 configuration of these middleboxes. 162 The semantics is defined in terms of transactions. Two basic types 163 of transactions are used: request transactions and asynchronous 164 transactions. Further we distinguish two concrete types of request 165 transactions: configuration transactions and monitoring transactions. 167 For each transaction, the semantics is specified by describing (1) 168 the parameters of the transaction, (2) the processing of request 169 messages at the middlebox, and (3) the state transitions at the 170 middlebox caused by the request transactions or indicated by the 171 asynchronous transactions, respectively, and (4) the reply and 172 notification messages sent from the middlebox to the agent in order 173 to inform the agent about the state change. 175 The semantics can be implemented by any protocol that supports these 176 two transaction types and that is sufficiently flexible concerning 177 transaction parameters. Different implementations for different 178 protocols might need to extend the semantics described below by 179 adding further transactions and/or adding further parameters to 180 transactions and/or splitting single transactions into a set of 181 transactions. Regardless of such extensions, the semantics below 182 provides a minimum necessary subset of what must be implemented. 184 The remainder of this document is structured as follows. Section 2 185 describes the protocol semantics. It is structured in four 186 subsections: 188 - General Protocol Issues (section 2.1) 189 - Session Control (section 2.2) 190 - Policy Rules (section 2.3) 191 - Policy Rule Groups (section 2.4) 193 Section 3 contains conformance statements for MIDCOM protocol 194 definitions and MIDCOM protocol implementations with respect to the 195 semantics defined in section 2. Section 4 gives two elaborated usage 196 examples. Finally, section 5 explains how the semantics meets the 197 MIDCOM requirements. 199 1.1. Terminology 201 The terminology in this memo follows the definitions given in the 202 framework [MDC-FRM] and requirements [MDC-REQ] document. 204 In addition, the following terms are used: 206 request transaction A request transaction consists of a 207 request message transfer from the agent to 208 the middlebox, processing of the message 209 at the middlebox, a reply message transfer 210 from the middlebox to the agent, and the 211 optional transfer of notification messages 212 from the middlebox to agents other than 213 the one requesting the transaction. A 214 request transaction might cause a state 215 transition at the middlebox. 217 configuration transaction A configuration transaction is a request 218 transaction containing a request for state 219 change in the middlebox. If accepted, it 220 causes a state change at the middlebox. 222 monitoring transaction A monitoring transaction is a request 223 transaction containing a request for state 224 information from the middlebox. It does 225 not cause a state transition at the 226 middlebox. 228 asynchronous transaction An asynchronous transaction is not 229 triggered by an agent. It may occur 230 without any agent participating in a 231 session with the middlebox. Potentially, 232 an asynchronous transaction includes the 233 transfer of notification messages from the 234 middlebox to agents that participate in an 235 open session. A notification message is 236 sent to each agent that needs to be 237 notified about the asynchronous event. 238 The message indicates the state transition 239 at the middlebox. 241 agent-unique An agent-unique value is unique in the 242 context of the agent. This context 243 includes all MIDCOM sessions the agent 244 participates in. An agent-unique value is 245 assigned by the agent. 247 middlebox-unique A middlebox-unique value is unique in the 248 context of the middlebox. This context 249 includes all MIDCOM sessions the middlebox 250 participates in. A middlebox-unique value 251 is assigned by the middlebox. 253 policy rule In general, a policy rule is "a basic 254 building block of a policy-based system. 255 It is the binding of a set of actions to a 256 set of conditions -- where the conditions 257 are evaluated to determine whether the 258 actions are performed." [RFC3198]. In 259 the MIDCOM context the condition is a 260 specification of a set of packets to which 261 rules are applied. The set of actions 262 always contains just a single element per 263 rule, either action "reserve" or action 264 "enable". 266 policy reserve rule A policy rule containing a reserve action. 267 The policy condition of this rule is 268 always true. The action is the 269 reservation of just an IP address or a 270 combination of an IP address and a range 271 of port numbers on neither side, one side, 272 or both sides of the middlebox, depending 273 on the middlebox configuration. 275 policy enable rule A policy rule containing an enable action. 276 The policy condition consists of a 277 descriptor of one or more unidirectional 278 or bidirectional packet flows, and the 279 policy action enables packets belonging to 280 this flow to traverse the middlebox. The 281 descriptor identifies the protocol, the 282 flow direction, and the source and 283 destination addresses, optionally with a 284 range of port numbers. 286 NAT binding The term NAT binding as used in this 287 document does not necessarily refer to a 288 NAT bind as defined in [NAT-TERM]. A NAT 289 binding in the MIDCOM semantics refers to 290 an abstraction that enables communication 291 between two end points through the NAT- 292 type middlebox. An enable action may 293 result in a NAT bind or a NAT session, 294 depending on the request and its 295 parameters. 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as described in RFC 2119 [RFC2119]. 301 1.2. Transaction Definition Template 303 In the following sections, the semantics of the MIDCOM protocol is 304 specified per transaction. A transaction specification contains the 305 following entries. Parameter entries, failure reason, and 306 notification message type are only specified if applicable. 308 transaction-name 309 A description name for this type of transaction. 311 transaction-type 312 The transaction type is either 'configuration', 'monitoring', or 313 'asynchronous'. See section 1.1 for a description of transaction 314 types. 316 transaction-compliance 317 This entry contains either 'mandatory' or 'optional'. For details 318 see section 2.1.8. 320 request-parameters 321 This entry lists all parameters necessary for this request. A 322 description for each parameter is given. 324 reply-parameters (success) 325 This entry lists all parameters sent back from the middlebox to 326 the agent as positive response to the prior request. A 327 description for each parameter is given. 329 failure reason 330 All negative replies have two parameters: a request identifier 331 identifying the request on which the reply is sent and a parameter 332 indicating the failure reason. As these parameters are 333 compulsory, they are not listed in the template. But the template 334 contains a list of potential failure reasons that may be indicated 335 by the second parameter. The list is not exhaustive. A concrete 336 protocol specification may extend the list. 338 notification message type 339 The type of the notification message type that may be used by this 340 transaction. 342 semantics 343 This entry describes the actual semantics of the transaction. 344 Particularly, it describes the processing of the request message 345 by the middlebox, and middlebox state transitions caused by or 346 causing the transaction, respectively. 348 2. Semantics Specification 350 2.1. General Protocol Design 352 The semantics specification aims at a balance between proper support 353 of applications that require dynamic configuration of middleboxes and 354 simplicity of specification and implementation of the protocol. 356 Protocol interactions are structured into transactions. The state of 357 middleboxes is described by state machines. The state machines are 358 defined by states and state transitions. A single transaction may 359 cause or be caused by state transitions in more than one state 360 machine, but per state machine there is no more than one transition 361 per transaction. 363 2.1.1. Protocol Transactions 365 State transitions are initiated either by a request message from the 366 agent to the middlebox or by some other event at the middlebox. In 367 the first case, the middlebox informs the agent by sending a reply 368 message on the actual state transition; in the second, the middlebox 369 sends an unsolicited asynchronous notification message to each agent 370 affected by the transaction (if it participates in an open session 371 with the middlebox). 373 Request and reply messages contain an agent-unique request identifier 374 that allows the agent to determine to which sent request a received 375 reply corresponds. 377 An analysis of the requirements showed that three kinds of 378 transactions are required: 380 - Configuration transactions allowing the agent to request state 381 transitions at the middlebox. 383 - Asynchronous transactions allowing to report state changes that 384 have not been requested by the agent. 386 - Monitoring transactions allowing the agent to request state 387 information from the middlebox. 389 Configuration transactions and asynchronous transactions provide the 390 basic MIDCOM protocol functionality. They are related to middlebox 391 state transitions, and they concern establishment and termination of 392 MIDCOM sessions and of policy rules. 394 Monitoring transactions are not related to middlebox state 395 transitions. They are used by agents to explore the number, status, 396 and properties of policy rules established at the middlebox. 398 As specified in detail in section 3, configuration transactions and 399 asynchronous transactions are mandatory except of the Group Lifetime 400 Change (GLC). They must be implemented by a compliant middlebox. 401 The Group Lifetime Change (GLC) transaction and some of the 402 monitoring transactions are optional. 404 2.1.2. Message Types 406 The MIDCOM protocol supports three kinds of messages: request 407 messages, reply messages, and notification messages. For each kind, 408 different message types exist. In this semantics document, message 409 types are only defined by the list of parameters. The order of the 410 parameters and their encoding is left to a concrete protocol 411 definition. A protocol definition may also add further parameters to 412 a message type or combine several parameters into one, as long as the 413 information contained in the parameters defined in the semantics is 414 still present. 416 For request messages and positive reply messages there exists one 417 message type per request transaction. Each reply transaction defines 418 the parameter list of the request message and of the positive 419 (successful) reply message by using the transaction definition 420 template defined in section 1.2. 422 In case of a failed request transaction, a negative reply message is 423 sent from the middlebox to the agent. This message is the same for 424 all request transactions; it contains the request identifier 425 identifying the request to which the reply is sent and a parameter 426 indicating the failure reason. 428 There are three notification message types: the Session Termination 429 Notification (STN), the Policy Rule Event Notification (REN), and the 430 Group Event Notification (GEN). All of these contain a middlebox- 431 unique notification identifier. 433 STN The Session Termination Notification message additionally 434 contains a single parameter indicating the reason for session 435 termination by the middlebox. 437 REN The Policy Rule Event Notification message contains the 438 notification identifier, a policy rule identifier, and the 439 remaining policy lifetime. 441 GEN The Group Event Notification message contains the notification 442 identifier, a policy rule group identifier, and the remaining 443 policy rule group lifetime. 445 2.1.3. Session, Policy Rule, and Policy Rule Group 447 All transactions can be further grouped into transactions concerning 448 sessions, transactions concerning policy rules, and transactions 449 concerning policy rule groups. Policy rule groups can be used to 450 indicate relationships between policy rules and to simplify 451 transactions on a set of policy rules by using a single transaction 452 per group instead of one per policy rule. 454 Sessions and policy rules at the middlebox are stateful. Their 455 states are independent of each other, and their state machines (one 456 per session and one per policy rule) can be separated. Policy rule 457 groups are also stateful, but the middlebox does not need to maintain 458 state for policy rule groups, because the semantics were chosen so 459 that the policy rule group state is implicitly defined by the state 460 of all policy rules belonging to the group (see section 2.4). 462 The separation of session state and policy rule state simplifies the 463 specification of the semantics as well as a protocol implementation. 464 Therefore, the semantics specification is structured accordingly and 465 we use two separated state machines to illustrate the semantics. 466 Please note that state machines of concrete protocol designs and 467 implementations will probably be more complex than the state machines 468 presented here. However, the protocol state machines are expected to 469 be a superset of the semantics state machines in this document. 471 2.1.4. Atomicity 473 All request transactions are atomic with respect to each other. This 474 means that processing of a request at the middlebox is never 475 interrupted by another request arriving or already queued. This 476 particularly applies when the middlebox concurrently receives 477 requests originating in different sessions. However, asynchronous 478 transactions may interrupt and/or terminate processing of a request 479 at any time. 481 All request transactions are atomic from the point of view of the 482 agent. The processing of a request does not start before the 483 complete request arrives at the middlebox. No intermediate state is 484 stable at the middlebox, and no intermediate state is reported to any 485 agent. 487 The number of transactions specified in this document is rather 488 small. Again, for simplicity, we reduced it to a minimal set that 489 still meets the requirements. A real implementation of the protocol 490 might require splitting some of the transactions specified below into 491 two or more transactions of the respective protocol. Reasons for 492 this might include constraints of the particular protocol or the 493 desire for more flexibility. In general this should not be a 494 problem. However, it should be considered that this might change 495 atomicity of the affected transactions. 497 2.1.5. Access Control 499 Ownership determines access to policy rules and policy rule groups. 500 When a policy rule is created, a middlebox-unique identifier is 501 generated to identify it in further transactions. Beyond the 502 identifier, each policy rule has an owner. The owner is the 503 authenticated agent that established the policy rule. The middlebox 504 uses the owner attribute of a policy rule to control access to it; 505 each time an authenticated agent requests to modify an existing 506 policy rule, the middlebox determines the owner of the policy rule 507 and checks whether the requesting agent is authorized to perform 508 transactions on the owning agent's policy rules. 510 All policy rules belonging to the same policy rule group must have 511 the same owner. Therefore, authenticated agents have access either 512 to all members of a policy rule group, or to none of them. 514 The middlebox may be configured to allow specific authenticated 515 agents to access and modify policy rules with certain specific 516 owners. Certainly, a reasonable default configuration would let each 517 agent access its own policy rules. Also, it might be good to 518 configure an agent identity to act as administrator, allowing 519 modification of all policy rules owned by any agent. However, the 520 configuration of authorization at the middlebox is out of scope of 521 the MIDCOM semantics and protocol. 523 2.1.6. Middlebox Capabilities 525 For several reasons it is useful that at session establishment the 526 agent learns about particular capabilities of the middlebox. 527 Therefore, the session establishment procedure described in section 528 2.2.1 includes a transfer of capability information from the 529 middlebox to the agent. The list of covered middlebox capabilities 530 includes the following: 532 - Support of firewall function 533 - List of supported NAT functions, perhaps including 534 - address translation 535 - port translation 536 - protocol translation 537 - twice-NAT 538 - Internal IP address wildcard support 539 - External IP address wildcard support 540 - Port wildcard support 541 - Supported IP version(s) for internal network: 542 IPv4, IPv6, or both 544 - Supported IP version(s) for external network: 545 IPv4, IPv6, or both 546 - List of supported optional MIDCOM protocol transactions 547 - Support for interface-specific policy rules 548 - Policy rule persistence: persistent or non-persistent 549 (a rule is persistent when the middlebox can save the rule to 550 a non-volatile memory, e.g., a hard disk or flash memory) 551 - Maximum remaining lifetime of a policy rule or policy rule 552 group 553 - Idle-timeout of policy rules in the middlebox 554 (reserved and enabled policy rules not used by any 555 data traffic for the time of this idle-timeout are deleted 556 automatically by the middlebox; for the deletion of policy 557 rules by middleboxes, see section 2.3.13 about Asynchronous 558 Policy Rule Event). 559 - Maximum number of simultaneous MIDCOM sessions 561 The list of middlebox capabilities may be extended by a concrete 562 protocol specification with further information useful for the agent. 564 2.1.7. Agent and Middlebox Identifiers 566 To allow both agents and middleboxes to maintain multiple sessions, 567 each request message contains a parameter identifying the requesting 568 agent, and each reply message and each notification message contains 569 a parameter identifying the middlebox. These parameters are not 570 explicitly listed in the description of the individual transactions, 571 because they are common to all of them. They are not further 572 referenced in the individual semantics descriptions. Although, they 573 are not necessarily passed explicitly as parameters of the MIDCOM 574 protocol, they might be provided by the underlying (secure) transport 575 protocol being used. Agent identifiers at the middlebox are 576 middlebox-unique, and middlebox identifiers at the agent are agent- 577 unique, respectively. 579 2.1.8. Conformance 581 The MIDCOM requirements in [MDC-REQ] demand capabilities of the 582 MIDCOM protocol that are met by the set of transactions specified 583 below. However, it is not required that an actual implementation of 584 a middlebox supports all these transactions. The set of announced 585 supported transactions may be different for different authenticated 586 agents. The middlebox informs the authenticated agent with the 587 capability exchange at session establishment about the transactions 588 that the agent is authorized to perform. Some transactions need to 589 be offered to every authenticated agent. 591 Each transaction definition below has a conformance entry that 592 contains either 'mandatory' or 'optional'. A mandatory transaction 593 needs to be implemented by every middlebox offering MIDCOM service 594 and must be must be offered to each of the authenticated agents. An 595 optional transaction does not necessarily need to be implemented by a 596 middlebox; it may offer these optional transactions only to certain 597 authenticated agents. The middlebox may offer one, several, all, or 598 no optional transactions to the agents. Whether an agent is allowed 599 to use an optional request transaction is determined by the 600 middlebox's authorization procedure, which is not further specified 601 by this document. 603 2.2. Session Control Transactions 605 Before any transaction on policy rules or policy rule groups is 606 possible, a valid MIDCOM session must be established. A MIDCOM 607 session is an authenticated and authorized association between agent 608 and middlebox. Sessions are initiated by agents and can be 609 terminated by either the agent or the middlebox. Both agent and 610 middlebox may participate in several sessions (with different 611 entities) at the same time. To distinguish different sessions, each 612 party uses local session identifiers. 614 All transactions are transmitted within this MIDCOM session. 616 Session control is supported by three transactions: 618 - Session Establishment (SE) 619 - Session Termination (ST) 620 - Asynchronous Session Termination (AST) 622 The first two are configuration transactions initiated by the agent, 623 and the last one is an asynchronous transaction initiated by the 624 middlebox. 626 2.2.1. Session Establishment (SE) 628 transaction-name: session establishment 630 transaction-type: configuration 632 transaction-compliance: mandatory 634 request-parameters: 636 - request identifier: An agent-unique identifier for matching 637 corresponding request and reply at the agent. 639 - version: The version of the MIDCOM protocol. 641 - middlebox authentication challenge (mc): An authentication 642 challenge token for authentication of the middlebox. As seen 643 below, this is present only in the first iteration of the 644 request. 646 - agent authentication (aa): An authentication token 647 authenticating the agent to the middlebox. As seen below, this 648 is updated in the second iteration of the request with material 649 responding to the middlebox challenge. 651 reply-parameters (success): 653 - request identifier: An identifier matching the identifier 654 request. 656 - middlebox authentication (ma): An authentication token 657 authenticating the middlebox to the agent. 659 - agent challenge token (ac): An authentication challenge token 660 for the agent authentication. 662 - middlebox capabilities: A list describing the middlebox's 663 capabilities. See section 2.1.6 for the list of middlebox 664 capabilities. 666 failure reason: 668 - authentication failed 669 - no authorization 670 - protocol version of agent and middlebox do not match 671 - lack of resources 673 semantics: 675 This session establishment transaction is used to establish a 676 MIDCOM session. For mutual authentication of both parties two 677 subsequent session establishment transactions are required as 678 shown in Figure 1. 680 agent middlebox 681 | session establishment request | 682 | (with middlebox challenge mc) | CLOSED 683 |-------------------------------------------->| 684 | | 685 | successful reply (with middlebox | 686 | authentication ma and agent challenge ac) | 687 |<--------------------------------------------| 688 | | NOAUTH 689 | session establishment request | 690 | (with agent authentication aa) | 691 |-------------------------------------------->| 692 | | 693 | successful reply | 694 |<--------------------------------------------| 695 | | OPEN 696 | | 698 Figure 1: Mutual authentication of agent and middlebox 700 Session establishment may be simplified by using only a single 701 transaction. In this case, server challenge and agent challenge 702 are omitted by the sender or ignored by the receiver, and 703 authentication must be provided by other means, for example by TLS 704 [RFC4346] or IPsec [RFC4302][RFC4303]. 706 The middlebox checks with its policy decision point whether the 707 requesting agent is authorized to open a MIDCOM session. If it is 708 not, the middlebox generates a negative reply with 'no 709 authorization' as failure reason. If authentication and 710 authorization are successful, the session is established, and the 711 agent may start with requesting transactions on policy rules and 712 policy rule groups. 714 Part of the successful reply is an indication of the middlebox's 715 capabilities. 717 2.2.2. Session Termination (ST) 719 transaction-name: session termination 721 transaction-type: configuration 723 transaction-compliance: mandatory 725 request-parameters: 727 - request identifier: An agent-unique identifier for matching 728 corresponding request and reply at the agent. 730 reply-parameters (success only): 732 - request identifier: An identifier matching the identifier of the 733 request. 735 semantics: 737 This transaction is used to close the MIDCOM session on behalf of 738 the agent. After session termination, the middlebox keeps all 739 established policy rules until their lifetime expires or until an 740 event occurs that causes the middlebox to terminate them. 742 The middlebox always generates a successful reply. After sending 743 the reply, the middlebox will not send any further messages to the 744 agent within the current session. It also will not process any 745 further request within this session that it received while 746 processing the session termination request, or that it receives 747 later. 749 2.2.3. Asynchronous Session Termination (AST) 751 transaction-name: asynchronous session termination 753 transaction-type: asynchronous 755 transaction-compliance: mandatory 757 notification message type: Session Termination Notification (STN) 759 reply-parameters (success only): 761 - termination reason: The reason why the session is terminated. 763 semantics: 765 The middlebox may decide to terminate a MIDCOM session at any 766 time. Before terminating the actual session the middlebox 767 generates a STN message and sends it to the agent. After sending 768 the notification, the middlebox will not process any further 769 request by the agent, even if it is already queued at the 770 middlebox. 772 After session termination, the middlebox keeps all established 773 policy rules until their lifetime expires or until an event occurs 774 for which the middlebox terminates them. 776 Unlike in other asynchronous transactions, no more than one 777 notification is sent, because there is only one agent affected by 778 the transaction. 780 2.2.4. Session Termination by Interruption of Connection 782 If a MIDCOM session is based on an underlying network connection, the 783 session can also be terminated by an interruption of this connection. 784 If the middlebox detects this, it immediately terminates the session. 785 The effect on established policy rules is the same as for the 786 Asynchronous Session Termination. 788 2.2.5. Session State Machine 790 A state machine illustrating the semantics of the session 791 transactions is shown in Figure 2. The transaction abbreviations 792 used can be found in the headings of the particular transaction 793 section. 795 All sessions start in state CLOSED. If mutual authentication is 796 already provided by other means, a successful SE transaction can 797 cause a state transition to state OPEN. Otherwise, it causes a 798 transition to state NOAUTH. From this state a failed second SE 799 transaction returns to state CLOSED. A successful SE transaction 800 causes a transition to state OPEN. At any time, an AST transaction 801 or a connection failure may occur, causing a transition to state 802 CLOSED. A successful ST transaction from either NOAUTH or OPEN also 803 causes a return to CLOSED. The parameters of the transactions are 804 explained in Figure 2; the value mc=0 represents an empty middlebox 805 challenge. 807 mc = middlebox challenge 808 SE/failure ma = middlebox authentication 809 +-------+ ac = agent challenge 810 | v aa = agent authentication 811 +----------+ 812 | CLOSED |----------------+ 813 +----------+ | SE(mc!=0)/ 814 | ^ ^ | success(ma,ac) 815 SE(mc=0, | | | AST | 816 aa=OK)/ | | | SE/failure v 817 success | | | ST/success +----------+ 818 | | +------------| NOAUTH | 819 | | +----------+ 820 | | AST | SE(mc=0, 821 v | ST/success | aa=OK)/ 822 +----------+ | success 823 | OPEN |<---------------+ 824 +----------+ 826 Figure 2: Session State Machine 828 2.3. Policy Rule Transactions 830 This section describes the semantics for transactions on policy 831 rules. The following transactions are specified: 833 - Policy Reserve Rule (PRR) 834 - Policy Enable Rule (PER) 835 - Policy Rule Lifetime Change (RLC) 836 - Policy Rule List (PRL) 837 - Policy Rule Status (PRS) 838 - Asynchronous Policy Rule Event (ARE) 840 The first three transactions (PRR, PER, RLC) are configuration 841 transactions initiated by the agent. The fourth and fifth (PRL, PRS) 842 are monitoring transactions. The last one (ARE) is an asynchronous 843 transaction. The PRL and PRS and transactions do not have any effect 844 on the policy rule state machine. 846 Before any transaction can start, a valid MIDCOM session must be 847 established. 849 2.3.1. Configuration Transactions 851 Policy Rule transactions PER and RLC constitute the core of the 852 MIDCOM protocol. Both are mandatory, and they serve for 854 - configuring NAT bindings (PER) 855 - configuring firewall pinholes (PER) 856 - extending the lifetime of established policy rules (RLC) 857 - deleting policy rules (RLC) 859 Some cases require knowing in advance which IP address (and port 860 number) would be chosen by NAT in a PER transaction. This 861 information is required before sufficient information for performing 862 a complete PER transaction is available (see example in section 4.2). 863 For supporting such cases, the core transactions are extended by the 864 Policy Reserve Rule (PRR) transaction serving for 866 - reserving addresses and port numbers at NATs (PRR) 868 2.3.2. Establishing Policy Rules 870 Both PRR and PER establish a policy rule. The action within the rule 871 is 'reserve' if set by PRR and 'enable' if set by PER. 873 The Policy Reserve Rule (PRR) transaction is used to establish an 874 address reservation on neither side, one side, or both sides of the 875 middlebox, depending on the middlebox configuration. The transaction 876 returns the reserved IP addresses and the optional ranges of port 877 numbers to the agent. No address binding or pinhole configuration is 878 performed at the middlebox. Packet processing at the middlebox 879 remains unchanged. 881 On pure firewalls, the PRR transaction is successfully processed 882 without any reservation, but the state transition of the MIDCOM 883 protocol engine is exactly the same as on NATs. 885 On a traditional NAT (see [NAT-TRAD]), only an external address is 886 reserved; on a twice-NAT, an internal and an external address are 887 reserved. The reservation at a NAT is for required resources, such 888 as IP addresses and port numbers, for future use. How the 889 reservation is exactly done depends on the implementation of the NAT. 890 In both cases the reservation concerns either an IP address only or a 891 combination of an IP address with a range of port numbers. 893 The Policy Enable Rule (PER) transaction is used to establish a 894 policy rule that affects packet processing at the middlebox. 895 Depending on its input parameters, it may make use of the reservation 896 established by a PRR transaction or create a new rule from scratch. 898 On a NAT, the enable action is interpreted as a bind action 899 establishing bindings between internal and external addresses. At a 900 firewall, the enable action is interpreted as one or more allow 901 actions configuring pinholes. The number of allow actions depends on 902 the parameters of the request and the implementation of the firewall. 904 On a combined NAT/firewall, the enable action is interpreted as a 905 combination of bind and allow actions. 907 The PRR transaction and the PER transaction are described in more 908 detail in sections 2.3.8 and 2.3.9 below. 910 2.3.3. Maintaining Policy Rules and Policy Rule Groups 912 Each policy rule has a middlebox-unique identifier. 914 Each policy rule has an owner. Access control to the policy rule is 915 based on ownership (see section 2.1.5). Ownership of a policy rule 916 does not change during lifetime of the policy rule. 918 Each policy rule has an individual lifetime. If the policy rule 919 lifetime expires, the policy rule will be terminated at the 920 middlebox. Typically, the middlebox indicates termination of a 921 policy rule by an ARE transaction. A policy rule lifetime change 922 (RLC) transaction may extend the lifetime of the policy rule up to 923 the limit specified by the middlebox at session setup. Also an RLC 924 transaction may be used for shortening a policy rule's lifetime or 925 deleting a policy rule by requesting a lifetime of zero. (Please 926 note that policy rule lifetimes may also be modified by the group 927 lifetime change (GLC) transaction.) 929 Each policy rule is a member of exactly one policy rule group. Group 930 membership does not change during the lifetime of a policy rule. 931 Selecting the group is part of the transaction establishing the 932 policy rule. This transaction implicitly creates a new group if the 933 agent does not specify one. The new group identifier is chosen by 934 the middlebox. New members are added to an existing group if the 935 agent's request designates one. A group only exists as long as it 936 has member policy rules. As soon as all policies belonging to the 937 group have reached the ends of their lifetimes, the group does not 938 exist anymore. 940 Agents can explore the properties and status of all policy rules they 941 are allowed to access by using the Policy Rule Status (PRS) 942 transaction. 944 2.3.4. Policy Events and Asynchronous Notifications 946 If a policy rule changes its state or if its remaining lifetime is 947 changed in ways other than being decreased by time, then all agents 948 that can access this policy rule and that participate in an open 949 session with the middlebox are notified by the middlebox. If the 950 state or lifetime change was requested explicitly by a request 951 message, then the middlebox notifies the requesting agent by 952 returning the corresponding reply. All other agents that can access 953 the policy are notified by a Policy Rule Event Notification (REN) 954 message. 956 Note that a middlebox can serve multiple agents at the same time in 957 different parallel sessions. Between these agents, the sets of 958 policy rules that can be accessed by them may overlap. For example, 959 there might be an agent that authenticates as administrator and that 960 can access all policies of all agents. Or there could be a backup 961 agent running a session in parallel to a main agent and 962 authenticating itself as the same entity as the main agent. 964 In case of a PER, PRR, or RLC transaction, the requesting agent 965 receives a PER, PRR, or RLC reply, respectively. To all other agents 966 that can access the created, modified, or terminated policy rule (and 967 that participate in an open session with the middlebox) the middlebox 968 sends an REN message carrying the policy rule identifier (PID) and 969 the remaining lifetime of the policy rule. 971 In case of a rule termination by lifetime truncation or other events 972 not triggered by an agent, then the middlebox sends an REN message to 973 each agent that can access the particular policy rule and that 974 participates in an open session with the middlebox. This ensures 975 that an agent always knows the most recent state of all policy rules 976 it can access. 978 2.3.5. Address Tuples 980 Request and reply messages of the PRR, PER, and PRS transactions 981 contain address specifications for IP and transport addresses. These 982 parameters include 984 - IP version 985 - IP address 986 - IP address prefix length 987 - transport protocol 988 - port number 989 - port parity 990 - port range 992 Additionally, the request message of PER and the reply message of PRS 993 contain a direction of flow parameter. This direction of flow 994 parameter indicates for UDP and IP the direction of packets 995 traversing the middlebox. For 'inbound', the UDP packets are 996 traversing from outside to inside; for 'outbound', from inside to the 997 outside. In both cases, the packets can traverse the middelbox only 998 uni-directionally. A bi-directional flow is enabled through 'bi- 999 directional' as direction of flow parameter. For TCP, the packet 1000 flow is always bi-directional, but the direction of the flow 1001 parameter is defined as 1003 - inbound: bi-directional TCP packet flow. First packet, with TCP 1004 SYN flag set and ACK flag not set, must arrive at the middlebox 1005 at the outside interface. 1007 - outbound: bi-directional TCP packet flow. First packet, with 1008 TCP SYN flag set and ACK flag not set, must arrive at the 1009 middlebox at the inside interface. 1011 - bi-directional: bi-directional TCP packet flow. First packet, 1012 with TCP SYN flag set and ACK flag not set, may arrive at inside 1013 or outside interface. 1015 We refer to the set of these parameters as an address tuple. An 1016 address tuple specifies either a communication endpoint at an 1017 internal or external device or allocated addresses at the middlebox. 1018 In this document, we distinguish four kinds of address tuples, as 1019 shown in Figure 3. 1021 +----------+ +----------+ 1022 | internal | A0 A1 +-----------+ A2 A3 | external | 1023 | endpoint +----------+ middlebox +----------+ endpoint | 1024 +----------+ +-----------+ +----------+ 1026 Figure 3: Address tuples A0 - A3 1028 - A0 -- internal endpoint: Address tuple A0 specifies a 1029 communication endpoint of a device within -- with respect to the 1030 middlebox -- the internal network. 1032 - A1 -- middlebox inside address: Address tuple A1 specifies a 1033 virtual communication endpoint at the middlebox within the 1034 internal network. A1 is the destination address for packets 1035 passing from the internal endpoint to the middlebox and is the 1036 source for packets passing from the middlebox to the internal 1037 endpoint. 1039 - A2 -- middlebox outside address: Address tuple A2 specifies a 1040 virtual communication endpoint at the middlebox within the 1041 external network. A2 is the destination address for packets 1042 passing from the external endpoint to the middlebox and is the 1043 source for packets passing from the middlebox to the external 1044 endpoint. 1046 - A3 -- external endpoint: Address tuple A3 specifies a 1047 communication endpoint of a device within -- with respect to the 1048 middlebox -- the external network. 1050 For a firewall, the inside and outside endpoints are identical to the 1051 corresponding external or internal endpoints, respectively. In this 1052 case the installed policy rule sets the same value in A2 as in A0 1053 (A0=A2) and sets the same value in A1 as in A3 (A1=A3). 1055 For a traditional NAT, A2 is given a value different from that of A0, 1056 but the NAT binds them. As for the firewall, it is also as it is at 1057 a traditional NAT: A1 has the same value as A3. 1059 For a twice-NAT, there are two bindings of address tuples: A1 and A2 1060 are both assigned values by the NAT. The middlebox outside address 1061 A2 is bound to the internal endpoint A0, and the middlebox inside 1062 address A1 is bound to the external endpoint A3. 1064 2.3.6. Address Parameter Constraints 1066 For transaction parameters belonging to an address tuple, some 1067 constraints exist that are common for all messages using them. 1068 Therefore, these constraints are summarized in the following and are 1069 not repeated again when describing the parameters in the transaction 1070 descriptions are presented. 1072 The MIDCOM semantics defined in this document specifies the handling 1073 of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4 1074 and IPv6) as transport protocols. The handling of any other 1075 transport protocol, e.g., SCTP, is not defined within the semantics 1076 but may be supported by concrete protocol specifications. 1078 The IP version parameter has either the value 'IPv4' or 'IPv6'. In a 1079 policy rule, the value of the IP version parameter must be the same 1080 for address tuples A0 and A1, and for A2 and A3. 1082 The value of the IP address parameter must conform with the specified 1083 IP version. 1085 The IP address of an address tuple may be wildcarded. Whether IP 1086 address wildcarding is allowed or in which range it is allowed 1087 depends on the local policy of the middlebox; see also section 6, 1088 "Security Considerations". Wildcarding is specified by the IP 1089 address prefix length parameter of an address tuple. In line with 1090 the common use of a prefix length, this parameter indicates the 1091 number of high significant bits of the IP address that are fixed, 1092 while the remaining low significant bits of the IP address are 1093 wildcarded. 1095 The value of the transport protocol parameter can be either 'TCP', 1096 'UDP', or 'ANY'. If the transport protocol parameter has the value 1097 'ANY', only IP headers are considered for packet handling in the 1098 middlebox -- i.e., the transport header is not considered. The 1099 values of the parameters port number, port range, and port parity are 1100 irrelevant if the protocol parameter is 'ANY'. In a policy rule, the 1101 value of the transport protocol parameter must be the same for all 1102 address tuples A0, A1, A2, and A3. 1104 The value of the port number parameter is either zero or a positive 1105 integer. A positive integer specifies a concrete UDP or TCP port 1106 number. The value zero specifies port wildcarding for the protocol 1107 specified by the transport protocol parameter. If the port number 1108 parameter has the value zero, then the value of the port range 1109 parameter is irrelevant. Depending on the value of the transport 1110 protocol parameter, this parameter may truly refer to ports or may 1111 refer to an equivalent concept. 1113 The port parity parameter is differently used in the context of 1114 policy reserve rules (PRR) and policy enable rules (PER). In the 1115 context of a PRR, the value of the parameter may be 'odd', 'even', or 1116 'any'. It specifies the parity of the first (lowest) reserved port 1117 number. 1119 In the context of a PER, the port parity parameter indicates to the 1120 middlebox whether port numbers allocated at the middlebox should have 1121 the same parity as the corresponding internal or external port 1122 numbers, respectively. In this context, the parameter has the value 1123 'same' or 'any'. If the value is 'same', then the parity of the port 1124 number of A0 must be the same as the parity of the port number of A2, 1125 and the parity of the port number of A1 must be the same as the 1126 parity of the port number of A3. If the port parity parameter has 1127 the value 'any', then there are no constraints on the parity of any 1128 port number. 1130 The port range parameter specifies a number of consecutive port 1131 numbers. Its value is a positive integer. Like the port number 1132 parameter, this parameter defines a set of consecutive port numbers 1133 starting with the port number specified by the port number parameter 1134 as the lowest port number and having as many elements as specified by 1135 the port range parameter. A value of 1 specifies a single port 1136 number. The port range parameter must have the same value for each 1137 address tuple A0, A1, A2, and A3. 1139 A single policy rule P containing a port range value greater than one 1140 is equivalent to a set of policy rules containing a number n of 1141 policies P_1, P_2, ..., P_n where n equals the value of the port 1142 range parameter. Each policy rule P_1, P_2, ..., P_n has a port 1143 range parameter value of 1. Policy rule P_1 contains a set of 1144 address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the 1145 first port number of the respective address tuples in P; policy rule 1146 P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each 1147 of which contains the second port number of the respective address 1148 tuples in P; and so on. 1150 2.3.7. Interface-specific Policy Rules 1152 Usually agents request policy rules with the knowledge of A0 and A3 1153 only, i.e., the address tuples (see section 2.3.5). But in very 1154 special cases, agents may need to select the interfaces to which the 1155 requested policy rule is bound. Generally, the middlebox is careful 1156 about choosing the right interfaces when reserving or enabling a 1157 policy rule, as it has the overall knowledge about its configuration. 1158 For agents that want to select the interfaces, optional parameters 1159 are included in the Policy Reserve Rule (PRR) and Policy Enable Rule 1160 (PER) transactions. These parameters are called 1162 - inside interface: The selected interface at the inside of the 1163 middlebox -- i.e., in the private or protected address realm. 1165 - outside interface: The selected interface at the outside of the 1166 middlebox -- i.e., in the public address realm. 1168 The Policy Rule Status (PRS) transactions include these optional 1169 parameters in its replies when they are supported. 1171 Agents can learn at session startup whether interface-specific policy 1172 rules are supported by the middlebox, by checking the middlebox 1173 capabilities (see section 2.1.6). 1175 2.3.8. Policy Reserve Rule (PRR) 1177 transaction-name: policy reserve rule 1179 transaction-type: configuration 1181 transaction-compliance: mandatory 1183 request-parameters: 1185 - request identifier: An agent-unique identifier for matching 1186 corresponding request and reply at the agent. 1188 - group identifier: A reference to the group of which the policy 1189 reserve rule should be a member. As indicated in section 2.3.3, 1190 if this value is not supplied, the middlebox assigns a new group 1191 for this policy reserve rule. 1193 - service: The requested NAT service of the middlebox. Allowed 1194 values are 'traditional' or 'twice'. 1196 - internal IP version: Requested IP version at the inside of the 1197 middlebox; see section 2.3.5. 1199 - internal IP address: The IP address of the internal 1200 communication endpoint (A0 in Figure 3); see section 2.3.5. 1202 - internal port number: The port number of the internal 1203 communication endpoint (A0 in Figure 3); see section 2.3.5. 1205 - inside interface (optional): Interface at the inside of the 1206 middlebox; see section 2.3.7. 1208 - external IP version: Requested IP version at the outside of the 1209 middlebox; see section 2.3.5. 1211 - outside interface (optional): Interface at the outside of the 1212 middlebox; see Section 2.3.7. 1214 - transport protocol: See section 2.3.5. 1216 - port range: The number of consecutive port numbers to be 1217 reserved; see section 2.3.5. 1219 - port parity: The requested parity of the first (lowest) port 1220 number to be reserved; allowed values for this parameter are 1221 'odd', 'even', and 'any'. See also section 2.3.5. 1223 - policy rule lifetime: A lifetime proposal to the middlebox for 1224 the requested policy rule. 1226 reply-parameters (success): 1228 - request identifier: An identifier matching the identifier of the 1229 request. 1231 - policy rule identifier: A middlebox-unique policy rule 1232 identifier. It is assigned by the middlebox and used as policy 1233 rule handle in further policy rule transactions, particularly to 1234 refer to the policy reserve rule in a subsequent PER 1235 transaction. 1237 - group identifier: A reference to the group of which the policy 1238 reserve rule is a member. 1240 - reserved inside IP address: The reserved IPv4 or IPv6 address on 1241 the internal side of the middlebox. For an outbound flow, this 1242 will be the destination to which the internal endpoint sends its 1243 packets (A1 in Figure 3). For an inbound flow, it will be the 1244 apparent source address of the packets as forwarded to the 1245 internal endpoint (A0 in Figure 3). The middlebox reserves and 1246 reports an internal address only in the case where twice-NAT is 1247 in effect. Otherwise, an empty value for the addresses 1248 indicates that no internal reservation was made. See also 1249 Section 2.3.5. 1251 - reserved inside port number: See section 2.3.5. 1253 - reserved outside IP address: The reserved IPv4 or IPv6 address 1254 on the external side of the middlebox. For an inbound flow, 1255 this will be the destination to which the external endpoint 1256 sends its packets (A2 in Figure 4). For an outbound flow, it 1257 will be the apparent source address of the packets as forwarded 1258 to the external endpoint (A3 in Figure 3). If the middlebox is 1259 configured as a pure firewall, an empty value for the addresses 1260 indicates that no external reservation was made. See also 1261 section 2.3.5. 1263 - reserved outside port number: See section 2.3.5. 1265 - policy rule lifetime: The policy rule lifetime granted by the 1266 middlebox, after which the reservation will be revoked if it has 1267 not been replaced already by a policy enable rule in a PER 1268 transaction. 1270 failure reason: 1272 - agent not authorized for this transaction 1273 - agent not authorized to add members to this group 1274 - lack of IP addresses 1275 - lack of port numbers 1276 - lack of resources 1277 - specified inside/outside interface does not exist 1278 - specified inside/outside interface not available for specified 1279 service 1281 notification message type: Policy Rule Event Notification (REN) 1283 semantics: 1285 The agent can use this transaction type to reserve an IP address 1286 or a combination of IP address, transport type, port number, and 1287 port range at neither side, one side, or both sides of the 1288 middlebox as required to support the enabling of a flow. 1289 Typically the PRR will be used in scenarios where it is required 1290 to perform such a reservation before sufficient parameters for a 1291 complete policy enable rule transaction are available. See 1292 section 4.2 for an example. 1294 When receiving the request, the middlebox determines how many 1295 address (and port) reservations are required based on its 1296 configuration. If it provides only packet filter services, it 1297 does not perform any reservation and returns empty values for the 1298 reserved inside and outside IP addresses and port numbers. If it 1299 is configured for twice-NAT, it reserves both inside and outside 1300 IP addresses (and an optional range of port numbers) and returns 1301 them. Otherwise, it reserves and returns an outside IP address 1302 (and an optional range of port numbers) and returns empty values 1303 for the reserved inside address and port range. 1305 The A0 parameter (inside IP address version, inside IP address, 1306 and inside port number) can be used by the middlebox to determine 1307 the correct NAT mapping and thus A2 if necessary. Once a PRR 1308 transaction has reserved an outside address (A2) for an internal 1309 end point (A0) at the middlebox, the middlebox must ensure that 1310 this reserved A2 is available in any subsequent PER and PRR 1311 transaction. 1313 For middleboxes supporting interface-specific policy rules, as 1314 defined in section 2.3.7, the optional inside and outside 1315 interface parameters must both be included in the request, or 1316 neither of them should be included. In the presence of these 1317 parameters, the middlebox uses the outside interface parameter to 1318 select the interface at which the outside address tuple (outside 1319 IP address and port number) is reserved, and the inside interface 1320 parameter to select the interface at which the inside address 1321 tuple (inside IP address and port number) is reserved. Without 1322 the presence of these parameters, the middlebox selects the 1323 particular interfaces based on its internal configuration. 1325 If there is a lack of resources, such as available IP addresses, 1326 port numbers, or storage for further policy rules, then the 1327 reservation fails, and an appropriate failure reply is generated. 1329 If a non-existing policy rule group was specified, or if an 1330 existing policy rule group was specified that is not owned by the 1331 requesting agent, then no new policy rule is established, and an 1332 appropriate failure reply is generated. 1334 In case of success, this transaction creates a new policy reserve 1335 rule. If an already existing policy rule group is specified, then 1336 the new policy rule becomes a member of it. If no policy group is 1337 specified, a new group is created with the new policy rule as its 1338 only member. The middlebox generates a middlebox-unique 1339 identifier for the new policy rule. The owner of the new policy 1340 rule is the authenticated agent that sent the request. The 1341 middlebox chooses a lifetime value that is greater than zero and 1342 less than or equal to the minimum of the requested value and the 1343 maximum lifetime specified by the middlebox at session startup, 1344 i.e., 1346 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1348 where 1349 - lt_granted is the lifetime actually granted by the middlebox 1350 - lt_requested is the lifetime the agent requested 1351 - lt_maximum is the maximum lifetime specified at session 1352 setup 1354 A middlebox with NAT capability always reserves a middlebox 1355 external address tuple (A2) in response to a PRR request. In the 1356 special case of a combined twice-NAT/NAT middlebox, the agent can 1357 request only NAT service or twice-NAT service by choosing the 1358 service parameter 'traditional' or 'twice', respectively. An 1359 agent that does not have any preference chooses 'twice'. The 1360 'traditional' value should only be used in order to select 1361 traditional NAT service at middleboxes offering both traditional 1362 NAT and twice NAT. In the 'twice' case, the combined twice- 1363 NAT/NAT middlebox reserves A2 and A1; the 'traditional' case 1364 results in a reservation of A2 only. An agent 1365 must always use the PRR transaction for choosing NAT only or 1366 twice-NAT service in the special case of a combined twice-NAT/NAT 1367 middlebox. A firewall middlebox ignores this parameter. 1369 If the protocol identifier is 'ANY', then the middlebox reserves 1370 available inside and/or outside IP address(es) only. The reserved 1371 address(es) are returned to the agent. In this case, the request- 1372 parameters "port range" and "port parity" as well as reply- 1373 parameters "inside port number" and "outside port number", are 1374 irrelevant. 1376 If the protocol identifier is 'UDP' or 'TCP', then a combination 1377 of an IP address and a consecutive sequence of port numbers, 1378 starting with the specified parity, is reserved, on neither side, 1379 one side, or both sides of the middlebox, as appropriate. The IP 1380 address(es) and the first (lowest) reserved port number(s) of the 1381 consecutive sequence are returned to the agent. (This also 1382 applies to other protocols supporting ports or the equivalent.) 1384 After a new policy reserve rule is successfully established and 1385 the reply message has been sent to the requesting agent, the 1386 middlebox checks whether there are other authenticated agents 1387 participating in open sessions, which can access the new policy 1388 rule. If the middlebox finds one or more of these agents, then it 1389 sends a REN message reporting the new policy rule to each of them. 1391 MIDCOM agents use the policy enable rule (PER) transaction to enable 1392 policy reserve rules that have been established beforehand by a 1393 policy reserve rule (PRR) transaction. See also section 2.3.2. 1395 2.3.9. Policy Enable Rule (PER) 1397 transaction-name: policy enable rule 1399 transaction-type: configuration 1401 transaction-compliance: mandatory 1403 request-parameters: 1405 - request identifier: An agent-unique identifier for matching 1406 corresponding request and reply at the agent. 1408 - policy reserve rule identifier: A reference to an already 1409 existing policy reserve rule created by a PRR transaction. The 1410 reference may be empty, in which case the middlebox must assign 1411 any necessary addresses and port numbers within this PER 1412 transaction. If it is not empty, then the following request 1413 parameters are irrelevant: group identifier, transport protocol, 1414 port range, port parity, internal IP version, external IP 1415 version. 1417 - group identifier: A reference to the group of which the policy 1418 enable rule should be a member. As indicated in section 2.3.3, 1419 if this value is not supplied, the middlebox assigns a new group 1420 for this policy reserve rule. 1422 - transport protocol: See section 2.3.5. 1424 - port range: The number of consecutive port numbers to be 1425 reserved; see section 2.3.5. 1427 - port parity: The requested parity of the port number(s) to be 1428 mapped. Allowed values of this parameter are 'same' and 'any'. 1429 See also section 2.3.5. 1431 - direction of flow: This parameter specifies the direction of 1432 enabled communication, either 'inbound', 'outbound', or 'bi- 1433 directional'. 1435 - internal IP version: Requested IP version at the inside of the 1436 middlebox; see section 2.3.5. 1438 - internal IP address: The IP address of the internal 1439 communication endpoint (A0 in Figure 3); see section 2.3.5. 1441 - internal port number: The port number of the internal 1442 communication endpoint (A0 in Figure 3); see section 2.3.5. 1444 - inside interface (optional): Interface at the inside of the 1445 middlebox; see section 2.3.7. 1447 - external IP version: Requested IP version at the outside of the 1448 middlebox; see section 2.3.5. 1450 - external IP address: The IP address of the external 1451 communication endpoint (A3 in Figure 3); see section 2.3.5. 1453 - external port number: The port number of the external 1454 communication endpoint (A3 in Figure 4), see section 2.3.5. 1456 - outside interface (optional): Interface at the outside of the 1457 middlebox; see section 2.3.7. 1459 - policy rule lifetime: A lifetime proposal to the middlebox for 1460 the requested policy rule. 1462 reply-parameters (success): 1464 - request identifier: An identifier matching the identifier of the 1465 request. 1467 - policy rule identifier: A middlebox-unique policy rule 1468 identifier. It is assigned by the middlebox and used as policy 1469 rule handle in further policy rule transactions. If a policy 1470 reserve rule identifier was provided in the request, then the 1471 returned policy rule identifier has the same value. 1473 - group identifier: A reference to the group of which the policy 1474 enable rule is a member. If a policy reserve rule identifier 1475 was provided in the request, then this parameter identifies the 1476 group of which the policy reserve rule was a member. 1478 - inside IP address: The IP address provided at the inside of the 1479 middlebox (A1 in Figure 3). In case of a twice-NAT, this 1480 parameter will be an internal IP address reserved at the inside 1481 of the middlebox. In all other cases, this reply-parameter will 1482 be identical with the external IP address passed with the 1483 request. If the policy reserve rule identifier parameter was 1484 supplied in the request and the respective PRR transaction 1485 reserved an inside IP address, then the inside IP address 1486 provided in the PER response will be the identical value to that 1487 returned by the response to the PRR request. See also section 1488 2.3.5. 1490 - inside port number: The internal port number provided at the 1491 inside of the middlebox (A1 in Figure 3); see also section 1492 2.3.5. 1494 - outside IP address: The external IP address provided at the 1495 outside of the middlebox (A2 in Figure 4). In case of a pure 1496 firewall, this parameter will be identical with the internal IP 1497 address passed with the request. In all other cases, this 1498 reply-parameter will be an external IP address reserved at the 1499 outside of the middlebox. See also section 2.3.5. 1501 - outside port number: The external port number provided at the 1502 outside of the NAT (A2 in Figure 3); see section 2.3.5.. 1504 - policy rule lifetime: The policy rule lifetime granted by the 1505 middlebox. 1507 failure reason: 1509 - agent not authorized for this transaction 1510 - agent not authorized to add members to this group 1511 - no such policy reserve rule 1512 - agent not authorized to replace this policy reserve rule 1513 - conflict with already existing policy rule (e.g., the same 1514 internal address-port is being mapped to different outside 1515 address-port pairs) 1516 - lack of IP addresses 1517 - lack of port numbers 1518 - lack of resources 1519 - no internal IP wildcarding allowed 1520 - no external IP wildcarding allowed 1521 - specified inside/outside interface does not exist 1522 - specified inside/outside interface not available for specified 1523 service 1524 - reserved A0 to requested A0 mismatch 1526 notification message type: Policy Rule Event Notification (REN) 1528 semantics: 1530 This transaction can be used by an agent to enable communication 1531 between an internal endpoint and an external endpoint 1532 independently of the type of middlebox (NAT, NAPT, firewall, NAT- 1533 PT, combined devices), for unidirectional or bi-directional 1534 traffic. 1536 The agent sends an enable request specifying the endpoints 1537 (optionally including wildcards) and the direction of 1538 communication (inbound, outbound, bi-directional). The 1539 communication endpoints are displayed in Figure 3. The basic 1540 operation of the PER transaction can be described by 1542 1. the agent sending A0 and A3 to the middlebox, 1544 2. the middlebox reserving A1 and A2 or using A1 and A2 from a 1545 previous PRR transaction, 1547 3. the middlebox enabling packet transfer between A0 and A3 by 1548 binding A0-A2 and A1-A3 and/or by opening the corresponding 1549 pinholes, both according to the specified direction, and 1551 4. the middlebox returning A1 and A2 to the agent. 1553 In case of a pure packet filtering firewall, the returned address 1554 tuples are the same as those in the request: A2=A0 and A1=A3. 1555 Each partner uses the other's real address. In case of a 1556 traditional NAT, the internal endpoint may use the real address of 1557 the external endpoint (A1=A3), but the external endpoint uses an 1558 address tuple provided by the NAT (A2!=A0). In case of a twice- 1559 NAT device, both endpoints use address tuples provided by the NAT 1560 for addressing their communication partner (A3!=A1 and A2!=A0). 1562 If a firewall is combined with a NAT or a twice-NAT, the replied 1563 address tuples will be the same as for pure traditional NAT or 1564 twice-NAT, respectively, but the middlebox will configure its 1565 packet filter in addition to the performed NAT bindings. In case 1566 of a firewall combined with a traditional NAT, the policy rule may 1567 imply more than one enable action for the firewall configuration, 1568 as incoming and outgoing packets may use different source- 1569 destination pairs. 1571 For middleboxes supporting interface specific policy rules, as 1572 defined in Section 2.3.7, the optional inside and outside 1573 interface parameters must both be included in the request, or 1574 neither of them should be included. In the presence of these 1575 parameters, the middlebox uses the outside interface parameter to 1576 select the interface at which the outside address tuple (outside 1577 IP address and port number) is bound, and the inside interface 1578 parameter to select the interface at which the inside address 1579 tuple (inside IP address and port number) is bound. Without the 1580 presence of these parameters, the middlebox selects the particular 1581 interfaces based on its internal configuration. 1583 Checking the Policy Reservation Rule Identifier 1585 If the parameter specifying the policy reservation rule 1586 identifier is not empty, then the middlebox checks whether the 1587 referenced policy rule exists, whether the agent is authorized 1588 to replace this policy rule, and whether this policy rule is a 1589 policy reserve rule. 1591 In case of success, this transaction creates a new policy 1592 enable rule. If a policy reserve rule was referenced, then the 1593 policy reserve rule is terminated without an explicit 1594 notification sent to the agent (other than the successful PER 1595 reply). 1597 The PRR transaction sets the internal endpoint A0 during the 1598 reservation process. In the process of creating a new policy 1599 enable rule, the middlebox may check whether the requested A0 1600 is equal to the reserved A0. The middlebox may reject a PER 1601 request with a requested A0 not equal to the reserved A0 and 1602 must then send an appropriate failure message. Alternatively, 1603 the middlebox may change A0 due to the PER request. 1605 The middlebox generates a middlebox-unique identifier for the 1606 new policy rule. If a policy reserve rule was referenced, then 1607 the identifier of the policy reserve rule is reused. 1609 The owner of the new policy rule is the authenticated agent 1610 that sent the request. 1612 Checking the Policy Rule Group Identifier 1614 If no policy reserve rule was specified, then the policy rule 1615 group parameter is checked. If a non-existing policy rule 1616 group is specified, or if an existing policy rule group is 1617 specified that is not owned by the requesting agent, then no 1618 new policy rule is established, and an appropriate failure 1619 reply is generated. 1621 If an already existing policy rule group is specified, then the 1622 new policy rule becomes a member. If no policy group is 1623 specified, then a new group is created with the new policy rule 1624 as its only member. 1626 If the transport protocol parameter value is 'ANY', then the 1627 middlebox enables communication between the specified external IP 1628 address and the specified internal IP address. The addresses to 1629 be used by the communication partners to address each other are 1630 returned to the agent as inside IP address and outside IP address. 1631 If the reservation identifier is not empty and if the reservation 1632 used the same transport protocol type, then the reserved IP 1633 addresses are used. 1635 For the transport protocol parameter values 'UDP' and 'TCP', the 1636 middlebox acts analogously as for 'ANY' but also maps ranges of 1637 port numbers, keeping the port parity, if requested. 1639 The configuration of the middlebox may fail because of lack of 1640 resources, such as available IP addresses, port numbers, or 1641 storage for further policy rules. It may also fail because of a 1642 conflict with an established policy rule. In case of a conflict, 1643 the first-come first-served mechanism is applied. Existing policy 1644 rules remain unchanged and arriving new ones are rejected. 1645 However, in case of a non-conflicting overlap of policy rules 1646 (including identical policy rules), all policy rules are accepted. 1648 The middlebox chooses a lifetime value that is greater than zero 1649 and less than or equal to the minimum of the requested value and 1650 the maximum lifetime specified by the middlebox at session 1651 startup, i.e., 1652 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1654 where 1655 - lt_granted is the lifetime actually granted by the middlebox 1656 - lt_requested is the lifetime the agent requested 1657 - lt_maximum is the maximum lifetime specified at session 1658 setup 1660 In each case of failure, an appropriate failure reply is 1661 generated. The policy reserve rule that is referenced in the PER 1662 transaction is not affected in case of a failure within the PER 1663 transaction -- i.e., the policy reserve rule remains. 1665 After a new policy enable rule is successfully established and the 1666 reply message has been sent to the requesting agent, the middlebox 1667 checks whether there are other authenticated agents participating 1668 in open sessions that can access the new policy rule. If the 1669 middlebox finds one or more of these agents, then it sends a REN 1670 message reporting the new policy rule to each of them. 1672 2.3.10. Policy Rule Lifetime Change (RLC) 1674 transaction-name: policy rule lifetime change 1676 transaction-type: configuration 1678 transaction-compliance: mandatory 1680 request-parameters: 1682 - request identifier: An agent-unique identifier for matching 1683 corresponding request and reply at the agent. 1685 - policy rule identifier: Identifying the policy rule for which 1686 the lifetime is requested to be changed. This may identify 1687 either a policy reserve rule or a policy enable rule. 1689 - policy rule lifetime: The new lifetime proposal for the policy 1690 rule. 1692 reply-parameters (success): 1694 - request identifier: An identifier matching the identifier of the 1695 request. 1697 - policy rule lifetime: The remaining policy rule lifetime granted 1698 by the middlebox. 1700 failure reason: 1702 - agent not authorized for this transaction 1703 - agent not authorized to change lifetime of this policy 1704 rule 1705 - no such policy rule 1706 - lifetime cannot be extended 1708 notification message type: Policy Rule Event Notification (REN) 1710 semantics: 1712 The agent can use this transaction type to request the extension 1713 of an established policy rule's lifetime, the shortening of the 1714 lifetime, or policy rule termination. Policy rule termination is 1715 requested by suggesting a new policy rule lifetime of zero. 1717 The middlebox first checks whether the specified policy rule 1718 exists and whether the agent is authorized to access this policy 1719 rule. If one of the checks fails, an appropriate failure reply is 1720 generated. If the requested lifetime is longer than the current 1721 one, the middlebox also checks whether the lifetime of the policy 1722 rule may be extended and generates an appropriate failure message 1723 if it may not. 1725 A failure reply implies that the new lifetime was not accepted, 1726 and the policy rule remains unchanged. A success reply is 1727 generated by the middlebox if the lifetime of the policy rule was 1728 changed in any way. 1730 The success reply contains the new lifetime of the policy rule. 1731 The middlebox chooses a lifetime value that is greater than zero 1732 and less than or equal to the minimum of the requested value and 1733 the maximum lifetime specified by the middlebox at session 1734 startup, i.e., 1736 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1738 whereas 1739 - lt_granted is the lifetime actually granted by the middlebox 1740 - lt_requested is the lifetime the agent requested 1741 - lt_maximum is the maximum lifetime specified at session 1742 setup 1744 After sending a success reply with a lifetime of zero, the 1745 middlebox will consider the policy rule non-existent. Any further 1746 transaction on this policy rule results in a negative reply, 1747 indicating that this policy rule does not exist anymore. 1749 Note that policy rule lifetime may also be changed by the Group 1750 Lifetime Change (GLC) transaction, if applied to the group of 1751 which the policy rule is a member. 1753 After the remaining policy rule lifetime was successfully changed 1754 and the reply message has been sent to the requesting agent, the 1755 middlebox checks whether there are other authenticated agents 1756 participating in open sessions that can access the policy rule. 1757 If the middlebox finds one or more of these agents, then it sends 1758 a REN message reporting the new remaining policy rule lifetime to 1759 each of them. 1761 2.3.11. Policy Rule List (PRL) 1763 transaction-name: policy rule list 1765 transaction-type: monitoring 1767 transaction-compliance: mandatory 1769 request-parameters: 1771 - request identifier: An agent-unique identifier for matching 1772 corresponding request and reply at the agent. 1774 reply-parameters (success): 1776 - request identifier: An identifier matching the identifier of the 1777 request. 1779 - policy list: List of policy rule identifiers of all policy rules 1780 that the agent can access. 1782 failure reason: 1784 - transaction not supported 1785 - agent not authorized for this transaction 1787 semantics: 1789 The agent can use this transaction type to list all policies that 1790 it can access. Usually, the agent has this information already, 1791 but in special cases (for example, after an agent fail-over) or 1792 for special agents (for example, an administrating agent that can 1793 access all policies) this transaction can be helpful. 1795 The middlebox first checks whether the agent is authorized to 1796 request this transaction. If the check fails, an appropriate 1797 failure reply is generated. Otherwise a list of all policies the 1798 agent can access is returned indicating the identifier and the 1799 owner of each policy. 1801 This transaction does not have any effect on the policy rule 1802 state. 1804 2.3.12. Policy Rule Status (PRS) 1806 transaction-name: policy rule status 1808 transaction-type: monitoring 1810 transaction-compliance: mandatory 1812 request-parameters: 1814 - request identifier: An agent-unique identifier for matching 1815 corresponding request and reply at the agent. 1817 - policy rule identifier: The middlebox-unique policy rule 1818 identifier. 1820 reply-parameters (success): 1822 - request identifier: An identifier matching the identifier of the 1823 request. 1825 - policy rule owner: An identifier of the agent owning this policy 1826 rule. 1828 - group identifier: A reference to the group of which the policy 1829 rule is a member. 1831 - policy rule action: This parameter has either the value 1832 'reserve' or the value 'enable'. 1834 - transport protocol: Identifies the protocol for which a 1835 reservation is requested; see section 2.3.5. 1837 - port range: The number of consecutive port numbers; see section 1838 2.3.5. 1840 - direction: The direction of the communication enabled by the 1841 middlebox. Applicable only to policy enable rules. 1843 - internal IP address version: The version of the internal IP 1844 address (IP version of A0 in Figure 3). 1846 - external IP address version: The version of the external IP 1847 address (IP version of A3 in Figure 3). 1849 - internal IP address: The IP address of the internal 1850 communication endpoint (A0 in Figure 3); see section 2.3.5. 1852 - internal port number: The port number of the internal 1853 communication endpoint (A0 in Figure 3); see section 2.3.5. 1855 - external IP address: The IP address of the external 1856 communication endpoint (A3 in Figure 3); see section 2.3.5. 1858 - external port number: The port number of the external 1859 communication endpoint (A3 in Figure 3); see section 2.3.5. 1861 - inside interface (optional): The inside interface at the 1862 middlebox; see section 2.3.7. 1864 - inside IP address: The internal IP address provided at the 1865 inside of the NAT (A1 in Figure 3); see section 2.3.5. 1867 - inside port number: The internal port number provided at the 1868 inside of the NAT (A1 in Figure 3); see section 2.3.5. 1870 - outside interface (optional): The outside interface at the 1871 middlebox; see section 2.3.7. 1873 - outside IP address: The external IP address provided at the 1874 outside of the NAT (A2 in Figure 3); see section 2.3.5. 1876 - outside port number: The external port number provided at the 1877 outside of the NAT (A2 in Figure 3); see section 2.3.5. 1879 - port parity: The parity of the allocated ports. 1881 - service: The selected service in the case of mixed traditional 1882 and twice-NAT middlebox (see section 2.3.8). 1884 - policy rule lifetime: The remaining lifetime of the policy rule. 1886 failure reason: 1888 - transaction not supported 1889 - agent not authorized for this transaction 1890 - no such policy rule 1891 - agent not authorized to access this policy rule 1893 semantics: 1895 The agent can use this transaction type to list all properties of 1896 a policy rule. Usually, the agent has this information already, 1897 but in special cases (for example, after an agent fail-over) or 1898 for special agents (for example, an administrating agent that can 1899 access all policy rules) this transaction can be helpful. 1901 The middlebox first checks whether the specified policy rule 1902 exists and whether the agent is authorized to access this group. 1903 If one of the checks fails, an appropriate failure reply is 1904 generated. Otherwise all properties of the policy rule are 1905 returned to the agent. Some of the returned parameters may be 1906 irrelevant, depending on the policy rule action ('reserve' or 1907 'enable') and depending on other parameters -- for example, the 1908 protocol identifier. 1910 This transaction does not have any effect on the policy rule 1911 state. 1913 2.3.13. Asynchronous Policy Rule Event (ARE) 1915 transaction-name: asynchronous policy rule event 1917 transaction-type: asynchronous 1919 transaction-compliance: mandatory 1921 notification message type: Policy Rule Event Notification (REN) 1923 semantics: 1925 The middlebox may decide at any point in time to terminate a 1926 policy rule. This transaction is triggered most frequently by 1927 lifetime expiration of the policy rule. Among other events that 1928 may cause this transaction are changes in the policy rule decision 1929 point. 1931 The middlebox sends an REN message to all agents that participate 1932 in an open session with the middlebox and that are authorized to 1933 access the policy rule. The notification is sent to the agents 1934 before the middlebox changes the policy rule's lifetime. The 1935 change of lifetime may be triggered by any other authorized agent 1936 and results in shortening (lt_new < lt_existing), extending 1937 (lt_new > lt_existing), or terminating the policy rule 1938 (lt_new = 0). 1940 The ARE transaction corresponds to the REN message handling described 1941 in section 2.3.4 for multiple agents. 1943 2.3.14. Policy Rule State Machine 1945 The state machine for the policy rule transactions is shown in Figure 1946 4 with all possible state transitions. The used transaction 1947 abbreviations may be found in the headings of the particular 1948 transaction section. 1950 PRR/success +---------------+ 1951 +-----------------+ PRID UNUSED |<-+ 1952 +----+ | +---------------+ | 1953 | | | ^ | | 1954 | v v | | | 1955 | +-------------+ ARE | | PER/ | ARE 1956 | | RESERVED +------------+ | success | RLC(lt=0)/ 1957 | +-+----+------+ RLC(lt=0)/ | | success 1958 | | | success | | 1959 +----+ | v | 1960 RLC(lt>0)/ | PER/success +---------------+ | 1961 success +---------------->| ENABLED +--+ 1962 +-+-------------+ 1963 | ^ 1964 lt = lifetime +-----------+ 1965 RLC(lt>0)/success 1967 Figure 4: Policy Rule State Machine 1969 This state machine exists per policy rule identifier (PRID). 1970 Initially all policy rules are in state PRID UNUSED, which means that 1971 the policy rule does not exist or is not active. After returning to 1972 state PRID UNUSED, the policy rule identifier is no longer bound to 1973 an existing policy rule and may be reused by the middlebox. 1975 A successful PRR transaction causes a transition from the initial 1976 state PRID UNUSED to the state RESERVED, where an address reservation 1977 is established. From there, state ENABLED can be entered by a PER 1978 transaction. This transaction can also be used for entering state 1979 ENABLED directly from state PRID UNUSED without a reservation. In 1980 state ENABLED the requested communication between the internal and 1981 the external endpoint is enabled. 1983 The states RESERVED and ENABLED can be maintained by successful RLC 1984 transactions with a requested lifetime greater than 0. Transitions 1985 from both of these states back to state PRID UNUSED can be caused by 1986 an ARE transaction or by a successful RLC transaction with a lifetime 1987 parameter of 0. 1989 A failed request transactions does not change state at the middlebox. 1991 Note that transitions initiated by RLC transactions may also be 1992 initiated by GLC transactions. 1994 2.4. Policy Rule Group Transactions 1996 This section describes the semantics for transactions on groups of 1997 policy rules. These transactions are specified as follows: 1999 - Group Lifetime Change (GLC) 2000 - Group List (GL) 2001 - Group Status (GS) 2003 All are request transactions initiated by the agent. GLC is a 2004 configuration transaction. GL and GS are monitoring transactions 2005 that do not have any effect on the group state machine. 2007 2.4.1. Overview 2009 A policy rule group has only one attribute: the list of its members. 2010 All member policies of a single group must be owned by the same 2011 authenticated agent. Therefore, an implicit property of a group is 2012 its owner, which is the owner of the member policy rules. 2014 A group is implicitly created when its first member policy rule is 2015 established. A group is implicitly terminated when the last 2016 remaining member policy rule is terminated. Consequently, the 2017 lifetime of a group is the maximum of the lifetimes of all member 2018 policy rules. 2020 A group has a middlebox-unique identifier. 2022 Policy Rule Group transactions are declared as 'optional' by their 2023 respective compliance entry in section 3. However, they provide some 2024 functionalities, such as convenience for the agent in sending only 2025 one request instead of several, that is not available if only 2026 mandatory transactions are available. 2028 The Group Lifetime Change (GLC) transaction is equivalent to 2029 simultaneously performed Policy Rule Lifetime Change (RLC) 2030 transactions on all members of the group. The result of a successful 2031 GLC transaction is that all member policy rules have the same 2032 lifetime. As with the RLC transaction, the GLC transaction can be 2033 used to delete all member policy rules by requesting a lifetime of 2034 zero. 2036 The monitoring transactions Group List (GL) and Group Status (GS) can 2037 be used by the agent to explore the state of the middlebox and to 2038 explore its access rights. The GL transaction lists all groups that 2039 the agent may access, including groups owned by other agents. The GS 2040 transaction reports the status on an individual group and lists all 2041 policy rules of this group by their policy rule identifiers. The 2042 agent can explore the state of the individual policy rules by using 2043 the policy rule identifiers in a policy rule status (PRS) transaction 2044 (see section 2.3.12). 2046 The GL and GS transactions are particularly helpful in case of an 2047 agent fail-over. The agent taking over the role of a failed one can 2048 use these transactions retrieve whichever policies have been 2049 established by the failed agent. 2051 Notifications on group events are generated analogously to policy 2052 rule events. To notify agents about group events, the Policy Rule 2053 Group Event Notification (GEN) message type is used. GEN messages 2054 contain an agent-unique notification identifier, the policy rule 2055 group identifier, and the remaining lifetime of the group. 2057 2.4.2. Group Lifetime Change (GLC) 2059 transaction-name: group lifetime change 2061 transaction-type: configuration 2063 transaction-compliance: optional 2065 request-parameters: 2067 - request identifier: An agent-unique identifier for matching 2068 corresponding request and reply at the agent. 2070 - group identifier: A reference to the group for which the 2071 lifetime is requested to be changed. 2073 - group lifetime: The new lifetime proposal for the group. 2075 reply-parameters (success): 2077 - request identifier: An identifier matching the identifier of the 2078 request. 2080 - group lifetime: The group lifetime granted by the middlebox. 2082 failure reason: 2084 - transaction not supported 2085 - agent not authorized for this transaction 2086 - agent not authorized to change lifetime of this group 2087 - no such group 2088 - lifetime cannot be extended 2090 notification message type: Policy Rule Group Event Notification (GEN) 2092 semantics: 2094 The agent can use this transaction type to request an extension of 2095 the lifetime of all members of a policy rule group, to request 2096 shortening the lifetime of all members, or to request termination 2097 of all member policies (which implies termination of the group). 2098 Termination is requested by suggesting a new group lifetime of 2099 zero. 2101 The middlebox first checks whether the specified group exists and 2102 whether the agent is authorized to access this group. If one of 2103 the checks fails, an appropriate failure reply is generated. If 2104 the requested lifetime is longer than the current one, the 2105 middlebox also checks whether the lifetime of the group may be 2106 extended and generates an appropriate failure message if it may 2107 not. 2109 A failure reply implies that the lifetime of the group remains 2110 unchanged. A success reply is generated by the middlebox if the 2111 lifetime of the group was changed in any way. 2113 The success reply contains the new common lifetime of all member 2114 policy rules of the group. The middlebox chooses the new lifetime 2115 less than or equal to the minimum of the requested lifetime and 2116 the maximum lifetime that the middlebox specified at session setup 2117 along with its other capabilities, i.e., 2118 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2120 where 2121 - lt_granted is the lifetime actually granted by the middlebox 2122 - lt_requested is the lifetime the agent requested 2123 - lt_maximum is the maximum lifetime specified at session 2124 setup 2126 After sending a success reply with a lifetime of zero, the 2127 middlebox will terminate the member policy rules without any 2128 further notification to the agent, and will consider the group and 2129 all of its members non-existent. Any further transaction on this 2130 policy rule group or on any of its members results in a negative 2131 reply, indicating that this group or policy rule, respectively, 2132 does not exist anymore. 2134 After the remaining policy rule group lifetime is successfully 2135 changed and the reply message has been sent to the requesting 2136 agent, the middlebox checks whether there are other authenticated 2137 agents participating in open sessions that can access the policy 2138 rule group. If the middlebox finds one or more of these agents, 2139 it sends a GEN message reporting the new remaining policy rule 2140 group lifetime to each of them. 2142 2.4.3. Group List (GL) 2144 transaction-name: group list 2146 transaction-type: monitoring 2148 transaction-compliance: optional 2150 request-parameters: 2152 - request identifier: An agent-unique identifier for matching 2153 corresponding request and reply at the agent. 2155 reply-parameters (success): 2157 - request identifier: An identifier matching the identifier of the 2158 request. 2160 - group list: List of all groups that the agent can access. For 2161 each listed group, the identifier and the owner are indicated. 2163 failure reason: 2165 - transaction not supported 2166 - agent not authorized for this transaction 2168 semantics: 2170 The agent can use this transaction type to list all groups that it 2171 can access. Usually, the agent has this information already, but 2172 in special cases (for example, after an agent fail-over) or for 2173 special agents (for example, an administrating agent that can 2174 access all groups) this transaction can be helpful. 2176 The middlebox first checks whether the agent is authorized to 2177 request this transaction. If the check fails, an appropriate 2178 failure reply is generated. Otherwise a list of all groups the 2179 agent can access is returned indicating the identifier and the 2180 owner of each group. 2182 This transaction does not have any effect on the group state. 2184 2.4.4. Group Status (GS) 2186 transaction-name: group status 2188 transaction-type: monitoring 2190 transaction-compliance: optional 2192 request-parameters: 2194 - request identifier: An agent-unique identifier for matching 2195 corresponding request and reply at the agent. 2197 - group identifier: A reference to the group for which status 2198 information is requested. 2200 reply-parameters (success): 2202 - request identifier: An identifier matching the identifier of the 2203 request. 2205 - group owner: An identifier of the agent owning this policy rule 2206 group. 2208 - group lifetime: The remaining lifetime of the group. This is 2209 the maximum of the remaining lifetime of all members, policy 2210 rules. 2212 - member list: List of all policy rules that are members of the 2213 group. The policy rules are specified by their middlebox-unique 2214 policy rule identifier. 2216 failure reason: 2218 - transaction not supported 2219 - agent not authorized for this transaction 2220 - no such group 2221 - agent not authorized to list members of this group 2223 semantics: 2225 The agent can use this transaction type to list all member policy 2226 rules of a group. Usually, the agent has this information 2227 already, but in special cases (for example, after an agent fail- 2228 over) or for special agents (for example, an administrating agent 2229 that can access all groups) this transaction can be helpful. 2231 The middlebox first checks whether the specified group exists and 2232 whether the agent is authorized to access this group. If one of 2233 the checks fails, an appropriate failure reply is generated. 2234 Otherwise a list of all group members is returned indicating the 2235 identifier of each group. 2237 This transaction does not have any effect on the group state. 2239 3. Conformance Statements 2241 A protocol definition complies with the semantics defined in section 2242 2 if the protocol specification includes all specified transactions 2243 with all their mandatory parameters. However, it is not required 2244 that an actual implementation of a middlebox supports all these 2245 transactions. Which transactions are required for compliance is 2246 different for agent and middlebox. 2248 This section contains conformance statements for MIDCOM protocol 2249 implementations related to the semantics. Conformance is specified 2250 differently for agents and middleboxes. These conformance statements 2251 will probably be extended by a concrete protocol specification. 2252 However, such an extension is expected to extend the statements below 2253 in such a way that all of them still hold. 2255 The following list shows the transaction-compliance property of all 2256 transactions as specified in the previous section: 2258 - Session Control Transactions 2259 - Session Establishment (SE) mandatory 2260 - Session Termination (ST) mandatory 2261 - Asynchronous Session Termination (AST) mandatory 2263 - Policy Rule Transactions 2264 - Policy Reserve Rule (PRR) mandatory 2265 - Policy Enable Rule (PER) mandatory 2266 - Policy Rule Lifetime Change (RLC) mandatory 2267 - Policy Rule List (PRL) mandatory 2268 - Policy Rule Status (PRS) mandatory 2269 - Asynchronous Policy Rule Event (ARE) mandatory 2271 - Policy Rule Group Transactions 2272 - Group Lifetime Change (GLC) optional 2273 - Group List (GL) optional 2274 - Group Status (GS) optional 2276 3.1. General Implementation Conformance 2278 A compliant implementation of a MIDCOM protocol MUST support all 2279 mandatory transactions. 2281 A compliant implementation of a MIDCOM protocol MAY support none, 2282 one, or more of the following transactions: GLC, GL, GS. 2284 A compliant implementation MAY extend the protocol semantics by 2285 further transactions. 2287 A compliant implementation of a MIDCOM protocol MUST support all 2288 mandatory parameters of each transaction concerning the information 2289 contained. The set of parameters can be redefined per transaction as 2290 long as the contained information is maintained. 2292 A compliant implementation of a MIDCOM protocol MAY support the use 2293 of interface-specific policy rules. Either both or neither of the 2294 optional inside and outside interface parameters in PRR, PER, and PRS 2295 MUST be included if interface-specific policy rules are supported. 2297 A compliant implementation MAY extend the list of parameters of 2298 transactions. 2300 A compliant implementation MAY replace a single transaction by a set 2301 of more fine-grained transactions. In such a case, it MUST be 2302 ensured that requirement 2.1.4 (deterministic behavior) and 2303 requirement 2.1.5 (known and stable state) of [MDC-REQ] are still 2304 met. When a single transaction is replaced by a set of multiple 2305 fine-grained transactions, this set MUST be equivalent to a single 2306 transaction. Furthermore, this set of transactions MUST further meet 2307 the atomicity requirement stated in section 2.1.3. 2309 3.2. Middlebox Conformance 2311 A middlebox implementation of a MIDCOM protocol supports a request 2312 transaction if it is able to receive and process all possible correct 2313 message instances of the particular request transaction and if it 2314 generates a correct reply for any correct request it receives. 2316 A middlebox implementation of a MIDCOM protocol supports an 2317 asynchronous transaction if it is able to generate the corresponding 2318 notification message properly. 2320 A compliant middlebox implementation of a MIDCOM protocol must inform 2321 the agent about the list of supported transactions within the SE 2322 transaction. 2324 3.3. Agent Conformance 2326 An agent implementation of a MIDCOM protocol supports a request 2327 transaction if it can generate the corresponding request message 2328 properly and if it can receive and process all possible correct 2329 replies to the particular request. 2331 An agent implementation of a MIDCOM protocol supports an asynchronous 2332 transaction if it can receive and process all possible correct 2333 message instances of the particular transaction. 2335 A compliant agent implementation of a MIDCOM protocol must not use 2336 any optional transaction that is not supported by the middlebox. The 2337 middlebox informs the agent about the list of supported transactions 2338 within the SE transaction. 2340 4. Transaction Usage Examples 2342 This section gives two usage examples of the transactions specified 2343 in Section 2. The first shows how an agent can explore all policy 2344 rules and policy rule groups that it may access at a middlebox. The 2345 second example shows the configuration of a middlebox in combination 2346 with the setup of a voice over IP session with the Session Initiation 2347 Protocol (SIP) [RFC3261]. 2349 4.1. Exploring Policy Rules and Policy Rule Groups 2351 This example assumes an already established session. It shows how an 2352 agent can find out 2353 - which groups it may access and who owns these groups, 2354 - the status and member list of all accessible groups, and 2355 - the status and properties of all accessible policy rules. 2357 If there is just a single session, these actions are not needed, 2358 because the middlebox informs the agent about each state transition 2359 of any policy rule or policy rule group. However, after the 2360 disruption of a session or after an intentional session termination, 2361 the agent might want to re-establish the session and explore which of 2362 the groups and policy rules it established are still in place. 2364 Also, an agent system may fail and another one may take over. Then 2365 the new agent system needs to find out what has already been 2366 configured by the failing system and what still needs to be done. 2368 A third situation where exploring policy rules and groups is useful 2369 is the case of an agent with 'administrator' authorization. This 2370 agent may access and modify any policy rule or group created by any 2371 other agent. 2373 All agents will probably start their exploration with the Group List 2374 (GL) transaction, as shown in Figure 5. On this request, the 2375 middlebox returns a list of pairs, each containing an agent 2376 identifier and a group identifier (GID). The agent is informed which 2377 of its own groups and which other agents' groups it may access. 2379 agent middlebox 2380 | GL | 2381 |**********************************************>| 2382 |<**********************************************| 2383 | (agent1,GID1) (agent1,GID2) (agent2,GID3) | 2384 | | 2385 | GS GID2 | 2386 |**********************************************>| 2387 |<**********************************************| 2388 | agent1 lifetime PID1 PID2 PID3 PID4 | 2389 | | 2391 Figure 5: Using the GL and the GS transaction 2393 In Figure 5, three groups are accessible to the agent, and the agent 2394 retrieves information about the second group by using the Group 2395 Status (GS) transaction. It receives the owner of the group, the 2396 remaining lifetime, and the list of member policy rules, in this case 2397 containing four policy rule identifiers (PIDs). 2399 In the following, the agent explores these four policy rules. The 2400 example assumes that the middlebox is a traditional NAPT. Figure 6 2401 shows the exploration of the first policy rule. In reply to a Policy 2402 Rule Status (PRS) transaction, the middlebox always returns the 2403 following list of parameters: 2405 - policy rule owner 2406 - group identifier 2407 - policy rule action (reserve or enable) 2408 - protocol type 2409 - port range 2410 - direction 2411 - internal IP address 2412 - internal port number 2413 - external address 2414 - external port number 2415 - middlebox inside IP address 2416 - middlebox inside port number 2417 - middlebox outside IP address 2418 - middlebox outside port number 2419 - IP address versions (not printed) 2420 - middlebox service (not printed) 2421 - inside and outside interface (optional, not printed) 2423 agent middlebox 2424 | PRS PID1 | 2425 |**********************************************>| 2426 |<**********************************************| 2427 | agent1 GID2 RESERVE UDP 1 "" | 2428 | ANY ANY ANY ANY | 2429 | ANY ANY IPADR_OUT PORT_OUT1 | 2430 | | 2432 Figure 6: Status report for an outside reservation 2434 The 'ANY' parameter printed in Figure 6 is used as a placeholder in 2435 policy rules status replies for policy reserve rules. The policy 2436 rule with PID1 is a policy reserve rule for UDP traffic at the 2437 outside of the middlebox. Since this is a reserve rule, direction is 2438 empty. As there is no internal or external address involved yet, 2439 these four fields are wildcarded in the reply. The same holds for 2440 the inside middlebox address and port number. The only address 2441 information given by the reply is the reserved outside IP address of 2442 the middlebox (IPADDR_OUT) and the corresponding port number 2443 (PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be 2444 wildcarded, as the reserve action does not support this. 2446 Applying PRS to PID2 (Figure 7) shows that the second policy rule is 2447 a policy enable rule for inbound UDP packets. The internal 2448 destination is fixed concerning IP address, protocol, and port 2449 number, but for the external source, the port number is wildcarded. 2450 The outside IP address and port number of the middlebox are what the 2451 external sender needs to use as destination in the original packet it 2452 sends. At the middlebox, the destination address is replaced with 2453 the internal address of the final receiver. During address 2454 translation, the source IP address and the source port numbers of the 2455 packets remain unchanged. This is indicated by the inside address, 2456 which is identical to the external address. 2458 agent middlebox 2459 | PRS PID2 | 2460 |**********************************************>| 2461 |<**********************************************| 2462 | agent1 GID2 ENABLE UDP 1 IN | 2463 | IPADR_INT PORT_INT1 IPADR_EXT ANY | 2464 | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | 2465 | | 2467 Figure 7: Status report for enabled inbound packets 2469 For traditional NATs, the identity of the inside IP address and port 2470 number with the external IP address and port number always holds 2471 (A1=A3 in Figure 3). For a pure firewall, the outside IP address and 2472 port number are always identical with the internal IP address and 2473 port number (A0=A2 in Figure 3). 2475 agent middlebox 2476 | PRS PID3 | 2477 |**********************************************>| 2478 |<**********************************************| 2479 | agent1 GID2 ENABLE UDP 1 OUT | 2480 | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | 2481 | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | 2482 | | 2484 Figure 8: Status report for enabled outbound packets 2486 Figure 8 shows enabled outbound UDP communication between the same 2487 host. Here all port numbers are known. Since again A1=A3, the 2488 internal sender uses the external IP address and port number as 2489 destination in the original packets. At the firewall, the internal 2490 source IP address and port number are replaced by the shown outside 2491 IP address and port number of the middlebox. 2493 agent middlebox 2494 | PRS PID4 | 2495 |**********************************************>| 2496 |<**********************************************| 2497 | agent1 GID2 ENABLE TCP 1 BI | 2498 | IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 | 2499 | IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 | 2500 | | 2502 Figure 9: Status report for bi-directional TCP traffic 2504 Finally, Figure 9 shows the status report for enabled bi-directional 2505 TCP traffic. Note that, still, A1=A3. For outbound packets, only 2506 the source IP address and port number are replaced at the middlebox, 2507 and for inbound packets, only the destination IP address and port 2508 number are replaced. 2510 4.2. Enabling a SIP-Signaled Call 2512 This elaborated transaction usage example shows the interaction 2513 between a back-to-back user agent (B2BUA) and a middlebox. The 2514 middlebox itself is a traditional Network Address and Port Translator 2515 (NAPT), and two SIP user agents communicate with each other via the 2516 B2BUA and a NAPT, as shown in Figure 10. The MIDCOM agent is co- 2517 located with the B2BUA, and the MIDCOM server is at the middlebox. 2518 Thus, the MIDCOM protocol runs between the B2BUA and the middlebox. 2520 +-------------+ 2521 | B2BUA | 2522 | for domain ++++ 2523 | example.com | + 2524 +-------------+ + 2525 ^ ^ + 2526 Private | | + Public Network 2527 Network | | + 2528 +----------+ | | +----+------+ +----------------+ 2529 | SIP User |<-+ +->| Middlebox |<------->| SIP User Agent | 2530 | Agent A |<#######>| NAPT |<#######>| B@example.org | 2531 +----------+ +-----------+ +----------------+ 2533 <--> SIP Signaling 2534 <##> RTP Traffic 2535 ++++ MIDCOM protocol 2537 Figure 10: Example of a SIP Scenario 2539 For the sequence charts below, we make these assumptions: 2541 - The NAPT is statically configured to forward SIP signaling from 2542 the outside to the B2BUA -- i.e., traffic to the NAPT's external 2543 IP address and port 5060 is forwarded to the internal B2BUA. 2545 - The SIP user agent A, located inside the private network, is 2546 registered at the B2BUA with its private IP address. 2548 - User A knows the general SIP URL of user B. The URL is 2549 B@example.org. However, the concrete URL of the SIP User Agent 2550 B, which user B currently uses, is not known. 2552 - The RTP paths are configured, but not the RTCP paths. 2554 - The middlebox and the B2BUA share an established MIDCOM session. 2556 - Some parameters are omitted, such as the request identifier 2557 (RID). 2559 Furthermore, the following abbreviations are used: 2561 - IP_AI: Internal IP address of user agent A 2562 - P_AI: Internal port number of user agent A to receive RTP data 2563 - P_AE: External mapped port number of user agent A 2564 - IP_AE: External IP address of the middlebox 2565 - IP_B: IP address of user agent B 2566 - P_B: Port number of user agent B to receive RTP data 2567 - GID: Group identifier 2568 - PID: Policy rule identifier 2570 The abbreviations of the MIDCOM transactions can be found in the 2571 particular section headings. 2573 In our example, user A tries to call user B. The user agent A sends 2574 an INVITE SIP message to the B2BUA (see Figure 10). The SDP part of 2575 the particular SIP message relevant for the middlebox configuration 2576 is shown in the sequence chart as follows: 2578 SDP: m=..P_AI.. 2579 c=IP_AI 2581 where the m tag is the media tag that contains the receiving UDP port 2582 number, and the c tag contains the IP address of the terminal 2583 receiving the media stream. 2585 The INVITE message forwarded to user agent B must contain a public IP 2586 address and a port number to which user agent B can send its RTP 2587 media stream. The B2BUA requests a policy enable rule at the 2588 middlebox with a PER request with the wildcarded IP address and port 2589 number of user agent B. As neither the IP address nor port numbers 2590 of user agent B are known at this point, the address of user agent B 2591 must be wildcarded. The wildcarded IP address and port number 2592 enables the 'early media' capability but results in some insecurity, 2593 as any outside host can reach user agent A on the enabled port number 2594 through the middlebox. 2596 User Agent B2BUA Middlebox User Agent 2597 A NAPT B 2598 | | | | 2599 | INIVTE | | | 2600 | B@example.org | | | 2601 | SDP:m=..P_AI.. | | | 2602 | c=IP_AI | | | 2603 |--------------->| | | 2604 | | | | 2605 | | PER PID1 UDP 1 EVEN IN | | 2606 | | IP_AI P_AI ANY ANY 300s | | 2607 | |*****************************>| | 2608 | |<*****************************| | 2609 | | PER OK GID1 PID1 ANY ANY | | 2610 | | IP_AE P_AE1 300s | | 2612 Figure 11: PER with wildcard address and port number 2614 A successful PER reply, as shown in Figure 11, results in an NAT 2615 binding at the middlebox. This binding enables UDP traffic from any 2616 host outside user agent A's private network to reach user agent A. 2617 So user agent B could start sending traffic immediately after 2618 receiving the INVITE message, as could any other host -- even hosts 2619 that are not intended to participate, such as any malicious host. 2621 If the middlebox does not support or does not permit IP address 2622 wildcarding for security reasons, the PER request will be rejected 2623 with an appropriate failure reason, like 'IP wildcarding not 2624 supported'. Nevertheless, the B2BUA needs an outside IP address and 2625 port number at the middlebox (the NAPT) in order to forward the SIP 2626 INVITE message. 2628 If the IP address of user agent B is still not known (it will be sent 2629 by user agent B in the SIP reply message) and IP address wildcarding 2630 is not permitted, the B2BUA uses the PRR transaction. 2632 By using the PRR request, the B2BUA requests an outside IP address 2633 and port number (see Figure 12) without already establishing a NAT 2634 binding or pin hole. The PRR request contains the service parameter 2635 'tw' -- i.e., the MIDCOM agent chooses the default value. In this 2636 configuration, with NAPT and without a twice NAT, only an outside 2637 address is reserved. In the SDP payload of the INVITE message, the 2638 B2BUA replaces the IP address and port number of user agent A with 2639 the reserved IP address and port from PRR reply (see Figure 12). The 2640 SIP INVITE message is forwarded to user agent B with a modified SDP 2641 body containing the outside address and port number, to which user 2642 agent B will send its RTP media stream. 2644 User Agent B2BUA Middlebox User Agent 2645 A NAPT B 2646 | | | | 2647 ...PER in Figure 11 has failed, continuing with PRR ... 2648 | | | | 2649 | |PRR tw v4 v4 A UDP 1 EVEN 300s| | 2650 | |*****************************>| | 2651 | |<*****************************| | 2652 | | PRR OK PID1 GID1 EMPTY | | 2653 | | IP_AE/P_AE 300s | | 2654 | | | | 2655 | | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE | 2656 | |-------------------------------------------->| 2657 | |<--------------------------------------------| 2658 | | 200 OK SDP:m=..P_B.. c=IP_B | 2660 Figure 12: Address reservation with PRR transaction 2662 This SIP '200 OK' reply contains the IP address and port number at 2663 which user agent B will receive a media stream. The IP address is 2664 assumed to be equal to the IP address from which user agent B will 2665 send its media stream. 2667 Now, the B2BUA has sufficient information for establishing the 2668 complete NAT binding with a policy enable rule (PER) transaction, 2669 i.e., the UDP/RTP data of the call can flow from user agent B to user 2670 agent A. The PER transaction references the reservation by passing 2671 the PID of the PRR (PID1). 2673 For the opposite direction, UDP/RTP data from user agent A to B has 2674 to be enabled also. This is done by a second PER transaction with 2675 all the necessary parameters (see Figure 13). The request message 2676 contains the group identifier (GID1) the middlebox has assigned in 2677 the first PER transaction. Therefore, both policy rules have become 2678 members of the same group. After having enabled both UDP/RTP 2679 streams, the B2BUA can forward the '200 OK' SIP message to user agent 2680 A to indicate that the telephone call can start. 2682 User Agent B2BUA Middlebox User Agent 2683 A NAPT B 2684 | | | | 2685 | | PER PID1 UDP 1 SAME IN | | 2686 | | IP_AI P_AI IP_B ANY 300s | | 2687 | |*****************************>| | 2688 | |<*****************************| | 2689 | | PER OK GID1 PID1 IP_B ANY | | 2690 | | IP_AE P_AE1 300s | | 2691 | | | | 2692 ...media stream from user agent B to A enabled... 2693 | | | | 2694 | | PER GID1 UDP 1 SAME OUT | | 2695 | | IP_AI ANY IP_B P_B 300s | | 2696 | |*****************************>| | 2697 | |<*****************************| | 2698 | | PER OK GID1 PID2 IP_B P_B | | 2699 | | IP_AE P_AE2 300s | | 2700 | | | | 2701 ...media streams from both directions enabled... 2702 | | | | 2703 | 200 OK | | | 2704 |<---------------| | | 2705 | SDP:m=..P_B.. | | | 2706 | c=IP_B | | | 2708 Figure 13: Policy rule establishment for UDP flows 2710 User agent B decides to terminate the call and sends its 'BYE' SIP 2711 message to user agent A. The B2BUA forwards all SIP messages and 2712 terminates the group afterwards, using a group lifetime change (GLC) 2713 transaction with a requested remaining lifetime of 0 seconds (see 2714 Figure 14). Termination of the group includes terminating all member 2715 policy rules. 2717 User Agent B2BUA Middlebox User Agent 2718 A NAPT B 2719 | | | | 2720 | BYE | BYE | 2721 |<---------------|<--------------------------------------------| 2722 | | | | 2723 | 200 OK | 200 OK | 2724 |--------------->|-------------------------------------------->| 2725 | | | | 2726 | | GLC GID1 0s | | 2727 | |*****************************>| | 2728 | |<*****************************| | 2729 | | GLC OK 0s | | 2730 | | | | 2731 ...both NAT bindings for the media streams are removed... 2733 Figure 14: Termination of policy rule groups 2735 5. Compliance with MIDCOM Requirements 2737 This section explains the compliance of the specified semantics with 2738 the MIDCOM requirements. It is structured according to [MDC-REQ]: 2740 - Compliance with Protocol Machinery Requirements (section 5.1) 2741 - Compliance with Protocol Semantics Requirements (section 5.2) 2742 - Compliance with Security Requirements (section 5.3) 2744 The requirements are referred to with the number of the section in 2745 which they are defined: "requirement x.y.z" refers to the requirement 2746 specified in section x.y.z of [MDC-REQ]. 2748 5.1. Protocol Machinery Requirements 2750 5.1.1. Authorized Association 2752 The specified semantics enables a MIDCOM agent to establish an 2753 authorized association between itself and the middlebox. The agent 2754 identifies itself by the authentication mechanism of the Session 2755 Establishment transaction described in section 2.2.1. Based on this 2756 authentication, the middlebox can determine whether or not the agent 2757 will be permitted to request a service. Thus, requirement 2.1.1 is 2758 met. 2760 5.1.2. Agent Connects to Multiple Middleboxes 2762 As specified in section 2.2, the MIDCOM protocol allows the agent to 2763 communicate with more than one middlebox simultaneously. The 2764 selection of a mechanism for separating different sessions is left to 2765 the concrete protocol definition. It must provide a clear mapping of 2766 protocol messages to open sessions. Then requirement 2.1.2 is met. 2768 5.1.3. Multiple Agents Connect to same Middlebox 2770 As specified in section 2.2, the MIDCOM protocol allows the middlebox 2771 to communicate with more than one agent simultaneously. The 2772 selection of a mechanism for separating different sessions is left to 2773 the concrete protocol definition. It must provide a clear mapping of 2774 protocol messages to open sessions. Then requirement 2.1.3 is met. 2776 5.1.4. Deterministic Behavior 2778 Section 2.1.2 states that the processing of a request of an agent may 2779 not be interrupted by any request of the same or another agent. This 2780 provides atomicity among request transactions and avoids race 2781 conditions resulting in unpredictable behavior by the middlebox. 2783 The behavior of the middlebox can only be predictable in the view of 2784 its administrators. In the view of an agent, the middlebox behavior 2785 is unpredictable, as the administrator can, for example, modify the 2786 authorization of the agent at any time without the agent being able 2787 to observe this change. Consequently, the behavior of the middlebox 2788 is not necessarily deterministic from the point of view of any agent. 2790 As predictability of the middlebox behavior is given for its 2791 administrator, requirement 2.1.4 is met. 2793 5.1.5. Known and Stable State 2795 Section 2.1 states that request transactions are atomic with respect 2796 to each other and from the point of view of an agent. All 2797 transactions are clearly defined as state transitions that either 2798 leave the current stable, well-defined state and enter a new stable, 2799 well-defined one or that remain in the current stable, well-defined 2800 state. Section 2.1 clearly demands that intermediate states are not 2801 stable and are not reported to any agent. 2803 Furthermore, for each state transition a message is sent to the 2804 corresponding agent, either a reply or a notification. The agent can 2805 uniquely map each reply to one of the requests that it sent to the 2806 middlebox, because agent-unique request identifiers are used for this 2807 purpose. Notifications are self-explanatory by their definition. 2809 Furthermore, the Group List transaction (section 2.4.3), the Group 2810 Status transaction (section 2.4.4), the Policy Rule List transaction 2811 (section 2.3.11), and the Policy Rule Status transaction (section 2812 2.3.12) allow the agent at any time during a session to retrieve 2813 information about 2815 - all policy rule groups it may access, 2816 - the status and member policy rules of all accessible groups, 2817 - all policy rules it may access, and 2818 - the status of all accessible policy rules. 2820 Therefore, the agent is precisely informed about the state of the 2821 middlebox (as far as the services requested by the agent are 2822 affected), and requirement 2.1.5 is met. 2824 5.1.6. Status Report 2826 As argued in the previous section, the middlebox unambiguously 2827 informs the agent about every state transition related to any of the 2828 services requested by the agent. Also, at any time the agent can 2829 retrieve full status information about all accessible policy rules 2830 and policy rule groups. Thus, requirement 2.1.6 is met. 2832 5.1.7. Unsolicited Messages (Asynchronous Notifications) 2834 The semantics includes asynchronous notifications messages from the 2835 middlebox to the agent, including the Session Termination 2836 Notification message, the Policy Rule Event Notification (REN) 2837 message, and the Group Event Notification (GEN) message (see section 2838 2.1.2). These notifications report every change of state of policy 2839 rules or policy rule groups that was not explicitly requested by the 2840 agent. Thus, requirement 2.1.7 is met by the semantics specified 2841 above. 2843 5.1.8. Mutual Authentication 2845 As specified in section 2.2.1, the semantics requires mutual 2846 authentication of agent and middlebox, by using either two subsequent 2847 Session Establishment transactions or mutual authentication provided 2848 on a lower protocol layer. Thus, requirement 2.1.8 is met. 2850 5.1.9. Session Termination by Any Party 2852 The semantics specification states in section 2.2.2 that the agent 2853 may request session termination by generating the Session Termination 2854 request and that the middlebox may not reject this request. In turn, 2855 section 2.2.3 states that the middlebox may send the Asynchronous 2856 Session Termination notification at any time and then terminate the 2857 session. Thus, requirement 2.1.9 is met. 2859 5.1.10. Request Result 2861 Section 2.1 states that each request of an agent is followed by a 2862 reply of the middlebox indicating either success or failure. Thus, 2863 requirement 2.2.10 is met. 2865 5.1.11. Version Interworking 2867 Section 2.2.1 states that the agent needs to specify the protocol 2868 version number that it will use during the session. The middlebox 2869 may accept this and act according to this protocol version or may 2870 reject the session if it does not support this version. If the 2871 session setup is rejected, the agent may try again with another 2872 version. Thus, requirement 2.2.11 is met. 2874 5.1.12. Deterministic Handling of Overlapping Rules 2876 The only policy rule actions specified are 'reserve' and 'enable'. 2877 For firewalls, overlapping enable actions or reserve actions do not 2878 create any conflict, so a firewall will always accept overlapping 2879 rules as specified in section 2.3.2 (assuming the required 2880 authorization is given). 2882 For NATs, reserve and enable may conflict. If a conflicting request 2883 arrives, it is rejected, as stated in section 2.3.2. If an 2884 overlapping request arrives that does not conflict with those it 2885 overlaps, it is accepted (assuming the required authorization is 2886 given). 2888 Therefore, the behavior of the middlebox in the presence of 2889 overlapping rules can be predicted deterministically, and requirement 2890 2.1.12 is met. 2892 5.2. Protocol Semantics Requirements 2894 5.2.1. Extensible Syntax and Semantics 2896 Requirement 2.2.1 explicitly requests extensibility of protocol 2897 syntax. This needs to be addressed by the concrete protocol 2898 definition. The semantics specification is extensible anyway, 2899 because new transactions may be added. 2901 5.2.2. Policy Rules for Different Types of Middleboxes 2903 Section 2.3 explains that the semantics uses identical transactions 2904 for all middlebox types and that the same policy rule can be applied 2905 to all of them. Thus, requirement 2.2.2 is met. 2907 5.2.3. Ruleset Groups 2909 The semantics explicitly supports grouping of policy rules and 2910 transactions on policy rule groups, as described in section 2.4. The 2911 group transactions can be used for lifetime extension and termination 2912 of all policy rules that are members of the particular group. Thus, 2913 requirement 2.2.3 is met. 2915 5.2.4. Policy Rule Lifetime Extension 2917 The semantics includes a transaction for explicit lifetime extension 2918 of policy rules, as described in section 2.3.3. Thus, requirement 2919 2.2.4 is met. 2921 5.2.5. Robust Failure Modes 2923 The state transitions at the middlebox are clearly specified and 2924 communicated to the agent. There is no intermediate state reached by 2925 a partial processing of a request. All requests are always processed 2926 completely, either successfully or unsuccessfully. All request 2927 transactions include a list of failure reasons. These failure 2928 reasons cover indication of invalid parameters where applicable. In 2929 case of failure, one of the specified reasons is returned from the 2930 middlebox to the agent. Thus, requirement 2.2.5 is met. 2932 5.2.6. Failure Reasons 2934 The semantics includes a failure reason parameter in each failure 2935 reply. Thus, requirement 2.2.6 is met. 2937 5.2.7. Multiple Agents Manipulating Same Policy Rule 2939 As specified in sections 2.3 and 2.4, each installed policy rule and 2940 policy rule group has an owner, which is the authenticated agent that 2941 created the policy rule or group, respectively. The authenticated 2942 identity is input to authorize access to policy rules and groups. 2944 If the middlebox is sufficiently configurable, its administrator can 2945 configure it so that one authenticated agent is authorized to access 2946 and modify policy rules and groups owned by another agent. Because 2947 specified semantics does not preclude this, it meets requirement 2948 2.2.7. 2950 5.2.8. Carrying Filtering Rules 2952 The Policy Enable Rule transaction specified in section 2.3.8 can 2953 carry 5-tuple filtering rules. This meets requirement 2.2.8. 2955 5.2.9. Parity of Port Numbers 2957 As specified in section 2.3.6, the agent is able to request keeping 2958 the port parity when reserving port numbers with the PRR transaction 2959 (see section 2.3.8) and when establishing address bindings with the 2960 PER transaction (see section 2.3.9). Thus requirement 2.2.9 is met. 2962 5.2.10. Consecutive Range of Port Numbers 2964 As specified in section 2.3.6, the agent is able to request a 2965 consecutive range of port numbers when reserving port numbers with 2966 the PRR transaction (see section 2.3.8) and when establishing address 2967 bindings or pinholes with the PER transaction (see section 2.3.9). 2968 Thus requirement 2.2.10 is met. 2970 5.2.11. Contradicting Overlapping Policy Rules 2972 Requirement 2.2.11 is based on the assumption that contradictory 2973 policy rule actions, such as 'enable'/'allow' and 2974 'disable'/'disallows' are supported. In conformance with decisions 2975 made by the working group after finalizing the requirements document, 2976 this requirement is not met by the semantics because no 2977 'disable'/'disallow' action is supported. 2979 5.3. Security Requirements 2981 5.3.1. Authentication, Confidentiality, Integrity 2983 The semantics definition supports mutual authentication of agent and 2984 middlebox in the Session Establishment transaction (section 2.2.1). 2985 The use of an underlying protocol such as TLS or IPsec is mandatory. 2986 Thus, requirement 2.3.1 is met. 2988 5.3.2. Optional Confidentiality of Control Messages 2990 The use of IPsec or TLS allows agent and middlebox to use an 2991 encryption method (including no encryption). Thus, requirement 2.3.2 2992 is met. 2994 5.3.3. Operation across Untrusted Domains 2996 Operation across untrusted domains is supported by mutual 2997 authentication and by the use of TLS or IPsec protection. Thus, 2998 requirement 2.3.3 is met. 3000 5.3.4. Mitigate Replay Attacks 3002 The specified semantics mitigates replay attacks and meets 3003 requirement 2.3.4 by requiring mutual authentication of agent and 3004 middlebox, and by mandating the use of TLS or IPsec protection. 3006 Further mitigation can be provided as part of a concrete MIDCOM 3007 protocol definition -- for example, by requiring consecutively 3008 increasing numbers for request identifiers. 3010 6. Security Considerations 3012 The interaction between a middlebox and an agent (see [MDC-FRM]) is a 3013 very sensitive point with respect to security. The configuration of 3014 policy rules from a middlebox-external entity appears to contradict 3015 the nature of a middlebox. Therefore, effective means have to be 3016 used to ensure 3018 - mutual authentication between agent and middlebox, 3019 - authorization, 3020 - message integrity, and 3021 - message confidentiality. 3023 The semantics defines a mechanism to ensure mutual authentication 3024 between agent and middlebox (see section 2.2.1). In combination with 3025 the authentication, the middlebox is able to decide whether an agent 3026 is authorized to request an action at the middlebox. The semantics 3027 relies on underlying protocols, such as TLS or IPsec, to maintain 3028 message integrity and confidentiality of the transferred data between 3029 both entities. 3031 For the TLS and IPsec use, both sides must use securely configured 3032 credentials for authentication and authorization. 3034 The configuration of policy rules with wildcarded IP addresses and 3035 port numbers results in certain risks, such as opening overly 3036 wildcarded policy rules. An excessively wildcarded policy rule would 3037 be A0 and A3 with IP address set to 'any' IP address, for instance. 3038 This type of pinhole would render the middlebox, in the sense of 3039 security, useless, as any packet could traverse the middlebox without 3040 further checking. The local policy of the middlebox should reject 3041 such policy rule enable requests. 3043 A reasonable default configuration for wildcarding would be that only 3044 one port number may be wildcarded and all IP addresses must be set 3045 without wildcarding. However, there are some cases where security 3046 needs to be balanced with functionality. 3048 The example described in section 4.2 shows how SIP-signaled calls can 3049 be served in a secure way without wildcarding IP addresses. But some 3050 SIP-signaled applications make use of early media (see section 5.5 of 3051 [RFC3398]). To receive early media, the middleboxes need to be 3052 configured before the second participant in a session is known. As 3053 it is not known, the IP address of the second participant needs to be 3054 wildcarded. 3056 In such cases and in several similar ones, there is a security policy 3057 decision to be made by the middlebox operator. The operator can 3058 configure the middlebox so that it supports more functionality, for 3059 example, by allowing wildcarded IP addresses, or so that network 3060 operation is more secure, for example, by disallowing wildcarded IP 3061 addresses. 3063 7. IAB Considerations on UNSAF 3065 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a 3066 process at originating endpoints that attempt to determine or fix the 3067 address (and port) by which they are known to another endpoint. 3068 UNSAF proposals, such as STUN [RFC3489] are considered as a general 3069 class of workarounds for NAT traversal and as solutions for scenarios 3070 with no middlebox communication (MIDCOM). 3072 This document describes the protocol semantics for such a middlebox 3073 communication (MIDCOM) solution. MIDCOM is not intended as a short- 3074 term workaround, but more as a long-term solution for middlebox 3075 communication. In MIDCOM, endpoints are not involved in allocating, 3076 maintaining, and deleting addresses and ports at the middlebox. The 3077 full control of addresses and ports at the middlebox is located at 3078 the MIDCOM server. 3080 Therefore, this document addresses the UNSAF considerations in 3081 [RFC3424] by proposing a long-term alternative solution. 3083 8. IANA Considerations 3085 This document has no actions for IANA. 3087 9. Acknowledgements 3089 We would like to thank all the people contributing to the semantics 3090 discussion on the mailing list for a lot of valuable comments. 3092 10. References 3094 10.1. Normative References 3096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3097 Requirement Levels", BCP 14, RFC 2119, March 1997. 3099 10.2. Informative References 3101 [MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., 3102 and A. Rayhan, "Middlebox communication architecture and 3103 framework", RFC 3303, August 2002. 3105 [MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 3106 "Middlebox Communications (midcom) Protocol 3107 Requirements", RFC 3304, August 2002. 3109 [MDC-SEM] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 3110 Communications (MIDCOM) Protocol Semantics", RFC 3989, 3111 February 2005. 3113 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 3114 Translator (NAT) Terminology and Considerations", RFC 3115 2663, August 1999. 3117 [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network 3118 Address Translator (Traditional NAT)", RFC 3022, January 3119 2001. 3121 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 3122 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 3124 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 3125 2005. 3127 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 3128 4303, December 2005. 3130 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 3131 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 3132 J., and S. Waldbusser, "Terminology for Policy-Based 3133 Management", RFC 3198, November 2001. 3135 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3136 A., Peterson, J., Sparks, R., Handley, M., and E. 3137 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3138 June 2002. 3140 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 3141 "Integrated Services Digital Network (ISDN) User Part 3142 (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3143 3398, December 2002. 3145 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3146 Self-Address Fixing (UNSAF) Across Network Address 3147 Translation", RFC 3424, November 2002. 3149 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 3150 "STUN - Simple Traversal of User Datagram Protocol (UDP) 3151 Through Network Address Translators (NATs)", RFC 3489, 3152 March 2003. 3154 Appendix A. Changes from RFC 3989 3156 1. The example in Section 4.2 used a SIP proxy server modifying 3157 the body of a SIP message. This was a violation of RFC 3261. 3158 This has been fixed by replacing the SIP proxy server with a 3159 back-to-back user agent. 3161 2. Clarifications concerning the used set of transaction types have 3162 been added. 3164 3. Section 3.1. on General Implementation Conformance now uses 3165 key words from RFC 2119. 3167 4. Minor editorial changes have been made and references have been 3168 updated. 3170 Authors' Addresses 3172 Martin Stiemerling 3173 NEC Europe Ltd. 3174 Network Laboratories 3175 Kurfuersten-Anlage 36 3176 69115 Heidelberg 3177 Germany 3179 Phone: +49 6221 4342-113 3180 EMail: stiemerling@netlab.nec.de 3182 Juergen Quittek 3183 NEC Europe Ltd. 3184 Network Laboratories 3185 Kurfuersten-Anlage 36 3186 69115 Heidelberg 3187 Germany 3189 Phone: +49 6221 4342-115 3190 EMail: quittek@netlab.nec.de 3192 Tom Taylor 3193 Nortel 3194 1852 Lorraine Ave. 3195 Ottawa, Ontario 3196 Canada K1H 6Z8 3198 Phone: +1 613 763 1496 3199 EMail: taylor@nortel.com 3201 Full Copyright Statement 3203 Copyright (C) The IETF Trust (2007). 3205 This document is subject to the rights, licenses and restrictions 3206 contained in BCP 78, and except as set forth therein, the authors 3207 retain all their rights. 3209 This document and the information contained herein are provided on an 3210 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3211 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3212 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3213 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3214 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3215 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3217 Intellectual Property 3219 The IETF takes no position regarding the validity or scope of any 3220 Intellectual Property Rights or other rights that might be claimed to 3221 pertain to the implementation or use of the technology described in 3222 this document or the extent to which any license under such rights 3223 might or might not be available; nor does it represent that it has 3224 made any independent effort to identify any such rights. Information 3225 on the procedures with respect to rights in RFC documents can be 3226 found in BCP 78 and BCP 79. 3228 Copies of IPR disclosures made to the IETF Secretariat and any 3229 assurances of licenses to be made available, or the result of an 3230 attempt made to obtain a general license or permission for the use of 3231 such proprietary rights by implementers or users of this 3232 specification can be obtained from the IETF on-line IPR repository at 3233 http://www.ietf.org/ipr. 3235 The IETF invites any interested party to bring to its attention any 3236 copyrights, patents or patent applications, or other proprietary 3237 rights that may cover technology that may be required to implement 3238 this standard. Please address the information to the IETF at ietf- 3239 ipr@ietf.org. 3241 Acknowledgement 3243 Funding for the RFC Editor function is provided by the IETF 3244 Administrative Support Activity (IASA).