idnits 2.17.1 draft-ietf-midcom-semantics-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2600 has weird spacing: '...network to re...' == Line 3164 has weird spacing: '...for the purpo...' -- 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 2004) is 7255 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. 'MDC-FRM') ** Downref: Normative reference to an Informational RFC: RFC 3304 (ref. 'MDC-REQ') ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Stiemerling 2 Document: draft-ietf-midcom-semantics-08.txt J. Quittek 3 Expires: December 2004 NEC 4 Tom Taylor 5 Nortel Networks 7 June 2004 9 MIDCOM Protocol Semantics 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Distribution of this document is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This memo specifies semantics for a Middlebox Communication (MIDCOM) 41 protocol to be used by MIDCOM agents for interacting with 42 middleboxes, such as firewalls and NATs. The semantics discussion 43 does not include any specification of a concrete syntax or a 44 transport protocol. However, a concrete protocol is expected to 45 implement the specified semantics or - more probably - a superset of 46 it. The MIDCOM protocol semantics is derived from the MIDCOM 47 requirements, from the MIDCOM framework, and from working group 48 decisions. 50 Table of Contents 52 1 Introduction ................................................. 4 53 1.1 Terminology ................................................ 5 54 1.2 Transaction Definition Template ............................ 7 55 2 Semantics Specification ...................................... 8 56 2.1 General Protocol Design .................................... 8 57 2.1.1 Protocol Transactions .................................... 8 58 2.1.2 Message Types ............................................ 9 59 2.1.3 Session, Policy Rule, and Policy Rule Group .............. 10 60 2.1.4 Atomicity ................................................ 10 61 2.1.5 Access Control ........................................... 11 62 2.1.6 Middlebox Capabilities ................................... 11 63 2.1.7 Agent and Middlebox Identifiers .......................... 12 64 2.1.8 Conformance .............................................. 12 65 2.2 Session Control Transactions ............................... 13 66 2.2.1 Session Establishment (SE) ............................... 13 67 2.2.2 Session Termination (ST) ................................. 15 68 2.2.3 Asynchronous Session Termination (AST) ................... 16 69 2.2.4 Session Termination by Interruption of Connection ........ 17 70 2.2.5 Session State Machine .................................... 17 71 2.3 Policy Rule Transactions ................................... 18 72 2.3.1 Configuration Transactions ............................... 18 73 2.3.2 Establishing Policy Rules ................................ 18 74 2.3.3 Maintaining Policy Rules and Policy Rule Groups .......... 19 75 2.3.4 Policy Events and Asynchronous Notifications ............. 20 76 2.3.5 Address Tuples ........................................... 21 77 2.3.6 Address Parameter Constraints ............................ 22 78 2.3.7 Interface specific Policy Rules .......................... 24 79 2.3.8 Policy Reserve Rule (PRR) ................................ 25 80 2.3.9 Policy Enable Rule (PER) ................................. 29 81 2.3.10 Policy Rule Lifetime Change (RLC) ....................... 34 82 2.3.11 Policy Rule List (PRL) .................................. 36 83 2.3.12 Policy Rule Status (PRS) ................................ 37 84 2.3.13 Asynchronous Policy Rule Event (ARE) .................... 39 85 2.3.14 Policy Rule State Machine ............................... 40 86 2.4 Policy Rule Group Transactions ............................. 41 87 2.4.1 Overview ................................................. 41 88 2.4.2 Group Lifetime Change (GLC) .............................. 42 89 2.4.3 Group List (GL) .......................................... 44 90 2.4.4 Group Status (GS) ........................................ 45 91 3 Conformance Statements ....................................... 46 92 3.1 General Implementation Conformance ......................... 46 93 3.2 Middlebox Conformance ...................................... 47 94 3.3 Agent Conformance .......................................... 47 95 4 Transaction Usage Examples ................................... 48 96 4.1 Exploring Policy Rules and Policy Rule Groups .............. 48 97 4.2 Enabling a SIP-Signaled Call ............................... 51 98 5 Compliance with MIDCOM Requirements .......................... 56 99 5.1 Protocol Machinery Requirements ............................ 56 100 5.1.1 Authorized Association ................................... 56 101 5.1.2 Agent connects to Multiple Middleboxes ................... 57 102 5.1.3 Multiple Agents connect to same Middlebox ................ 57 103 5.1.4 Deterministic Behavior ................................... 57 104 5.1.5 Known and Stable State ................................... 57 105 5.1.6 Status Report ............................................ 58 106 5.1.7 Unsolicited Messages (Asynchronous Notifications) ........ 58 107 5.1.8 Mutual Authentication .................................... 58 108 5.1.9 Session Termination by any Party ......................... 58 109 5.1.10 Request Result .......................................... 59 110 5.1.11 Version Interworking .................................... 59 111 5.1.12 Deterministic Handling of Overlapping Rules ............. 59 112 5.2 Protocol Semantics Requirements ............................ 59 113 5.2.1 Extensible Syntax and Semantics .......................... 59 114 5.2.2 Policy Rules for Different Types of Middleboxes .......... 59 115 5.2.3 Ruleset Groups ........................................... 60 116 5.2.4 Policy Rule Lifetime Extension ........................... 60 117 5.2.5 Robust Failure Modes ..................................... 60 118 5.2.6 Failure Reasons .......................................... 60 119 5.2.7 Multiple Agents Manipulating Same Policy Rule ............ 60 120 5.2.8 Carrying Filtering Rules ................................. 60 121 5.2.9 Parity of Port Numbers ................................... 61 122 5.2.10 Consecutive Range of Port Numbers ....................... 61 123 5.2.11 Contradicting Overlapping Policy Rules .................. 61 124 5.3 Security Requirements ...................................... 61 125 5.3.1 Authentication, Confidentiality, Integrity ............... 61 126 5.3.2 Optional Confidentiality of Control Messages ............. 61 127 5.3.3 Operation across Un-trusted Domains ...................... 61 128 5.3.4 Mitigate Replay Attacks .................................. 61 129 6 Security Considerations ...................................... 62 130 7 IAB Considerations on UNSAF .................................. 63 131 8 Acknowledgments .............................................. 63 132 9 References ................................................... 63 133 9.1 Normative References ....................................... 63 134 9.2 Informative References ..................................... 64 135 10 Authors' Addresses .......................................... 64 136 11 Full Copyright Statement .................................... 65 138 1. Introduction 140 The MIDCOM working group has defined a framework [MDC-FRM] for the 141 middlebox communication and a list of requirements [MDC-REQ]. The 142 next step towards a MIDCOM protocol is the specification of protocol 143 semantics that are constrained, but not completely implied by the 144 documents mentioned above. 146 This memo suggests a semantics for the MIDCOM protocol. It is fully 147 compliant with the requirements listed in [MDC-REQ] and with the 148 working group's consensus on semantic issues. 150 In conformance with the working group charter, the semantics 151 description is targeted at packet filters and network address 152 translators (NATs) and it supports applications that require dynamic 153 configuration of these middleboxes. 155 The semantics are defined in terms of transactions. Two basic types 156 of transactions are used: request-reply transactions and asynchronous 157 transactions. For each transaction the semantics is specified by 158 describing (1) the parameters of the transaction, (2) the processing 159 of request messages at the middlebox, and (3) the state transitions 160 at the middlebox caused by the request transactions or indicated by 161 the asynchronous transactions, respectively, and the (4) reply and 162 notification messages sent from the middlebox to the agent in order 163 to inform the agent about the state change. 165 The semantics can be implemented by any protocol that supports these 166 two transaction types and that is sufficiently flexible concerning 167 transaction parameters. Different implementations for different 168 protocols might need to extend the semantics described below by 169 adding further transactions and/or adding further parameters to 170 transactions and/or splitting single transactions into a set of 171 transactions. Regardless of such extensions, the semantics below 172 provide a minimum necessary subset of what must be implemented. 174 The remainder of this document is structured as follows. Section 2 175 describes the protocol semantics. It is structured in four 176 subsections: 178 - General Protocol Issues (Section 2.1) 179 - Session Control (Section 2.2) 180 - Policy Rules (Section 2.3) 181 - Policy Rule Groups (Section 2.4) 183 Section 3 contains conformance statements for MIDCOM protocol 184 definitions and MIDCOM protocol implementations with respect to the 185 semantics defined in Section 2. Section 4 gives two elaborated usage 186 examples. Finally, Section 5 explains how the semantics meets the 187 MIDCOM requirements. 189 1.1. Terminology 191 The terminology in this memo follows the definitions given in the 192 framework [MDC-FRM] and requirements [MDC-REQ] document. 194 In addition the following terms are used: 196 request transaction A request transaction consists of a 197 request message transfer from the agent to 198 the middlebox, processing of the message 199 at the middlebox, a reply message transfer 200 from the middlebox to the agent, and the 201 optional transfer of notification messages 202 from the middlebox to other agents than 203 the one requesting the transaction. A 204 request transaction might cause a state 205 transition at the middlebox. 207 configuration transaction A configuration transaction is a request 208 transaction containing a request for state 209 change in the middlebox. If accepted, it 210 causes a state change at the middlebox. 212 monitoring transaction A monitoring transaction is a request 213 transaction containing a request for state 214 information from the middlebox. It does 215 not cause a state transition at the 216 middlebox. 218 asynchronous transaction An asynchronous transaction is not 219 triggered by an agent. It may occur 220 without any agent participating in a 221 session with the middlebox. Potentially, 222 an asynchronous transaction includes the 223 transfer of notification messages from the 224 middlebox to agents that participate in an 225 open session. A notification message is 226 sent to each agent that need to be 227 notified about the asynchronous event. 228 The message indicates the state transition 229 at the middlebox. 231 agent-unique An agent-unique value is unique in the 232 context of the agent. This context 233 includes all MIDCOM sessions the agent 234 participates in. An agent-unique value is 235 assigned by the agent. 237 middlebox-unique A middlebox-unique value is unique in the 238 context of the middlebox. This context 239 includes all MIDCOM sessions the middlebox 240 participates in. A middlebox-unique value 241 is assigned by the middlebox. 243 policy rule In general, a policy rule is "a basic 244 building block of a policy-based system. 245 It is the binding of a set of actions to a 246 set of conditions - where the conditions 247 are evaluated to determine whether the 248 actions are performed." [RFC3198]. In 249 the MIDCOM context the condition is a 250 specification of a set of packets to which 251 rules are applied. The set of actions 252 always contains just a single element per 253 rule, either action "reserve" or action 254 "enable". 256 policy reserve rule A policy rule containing a reserve action. 257 The policy condition of this rule is 258 always true. The action is the 259 reservation of just an IP address or a 260 combination of an IP address and a range 261 of port numbers on neither, one, or both 262 sides of the middlebox, depending on the 263 middlebox configuration. 265 policy enable rule A policy rule containing an enable action. 266 The policy condition consists of a 267 descriptor of one or more unidirectional 268 or bidirectional packet flows, and the 269 policy action enables packets belonging to 270 this flow to traverse the middlebox. The 271 descriptor identifies the protocol, the 272 flow direction, the source and destination 273 addresses, optionally with a range of port 274 numbers. 276 NAT binding The term NAT binding used in this document 277 is not necessarily referring to a NAT bind 278 as defined in [NAT-TERM]. A NAT binding 279 in the MIDCOM semantics refers to an 280 abstraction that enables communication 281 between two end points through the NAT- 282 type middlebox. An enable action may 283 result in a NAT bind or a NAT session, 284 depending on the request and its 285 parameters. 287 1.2. Transaction Definition Template 289 In the following sections, semantics of the MIDCOM protocol is 290 specified per transaction. A transaction specification contains the 291 following entries. Parameter entries, failure reason and notification 292 message type are only specified if applicable. 294 transaction-name 295 A description name for this type of transaction. 297 transaction-type 298 The transaction type is either 'configuration', 'monitoring', or 299 'asynchronous'. See Section 1.1. for a description of 300 transaction types. 302 transaction-compliance 303 This entry contains either 'mandatory' or 'optional'. For details 304 see Section 2.1.8. 306 request-parameters 307 This entry lists all parameters that are necessary for this 308 request. A description for each parameter is given. 310 reply-parameters (success) 311 This entry lists all parameters that are sent back from the 312 middlebox to the agent as positive response to the prior request. 313 A description for each parameter is given. 315 failure reason 316 All negative replies do have two parameters, a request identifier 317 identifying the request on which the reply is sent and a parameter 318 indicating the failure reason. Since these parameters are 319 compulsory, they are not listed in the template. But the template 320 contains a list of potential failure reasons that may be indicated 321 by the second parameter. The list is not exhaustive. A concrete 322 protocol specification may extend the list. 324 notification message type 325 The type of the notification message type that may be used by this 326 transaction. 328 semantics 329 This entry describes the actual semantics of the transaction. 330 Particularly, it describes the processing of the request message 331 by the middlebox, and middlebox state transitions caused by or 332 causing the transaction, respectively. 334 2. Semantics Specification 336 2.1. General Protocol Design 338 The semantics specification aims at a balance between proper support 339 of applications that require dynamic configuration of middleboxes and 340 simplicity of specification and implementation of the protocol. 342 Protocol interactions are structured into transactions. State of 343 middleboxes is described by state machines. The state machines are 344 defined by states and state transitions. A single transaction may 345 cause or be caused by state transitions in more than one state 346 machine, but per state machine there is no more than one transition 347 per transaction. 349 2.1.1. Protocol Transactions 351 State transitions are either initiated by a request message from the 352 agent to the middlebox, or they are initiated by some other event at 353 the middlebox. In the first case, the middlebox informs the agent by 354 sending a reply message on the actual state transition, in the latter 355 case the middlebox sends an unsolicited asynchronous notification 356 message to each agent that is affected by the transaction (if it 357 participates in an open session with the middlebox). 359 Request and reply messages contain an agent-unique request identifier 360 that allows the agent to determine to which sent request a received 361 reply corresponds. 363 An analysis of the requirements showed that four kinds of 364 transactions are required: 366 - configuration transactions allowing the agent to request state 367 transitions at the middlebox 369 - asynchronous transactions allowing the middlebox to change state 370 without a request by an agent. 372 - monitoring transaction allowing the agent to request state 373 information from the middlebox 375 - convenience transactions combining a set of configuration 376 transactions 378 Configuration transactions and asynchronous transactions provide the 379 basic MIDCOM protocol functionality. They are related to middlebox 380 state transitions and they concern establishment and termination of 381 MIDCOM sessions and of policy rules. 383 Monitoring transactions are not related to middlebox state 384 transitions. They are used by agents for exploring number, status 385 and properties of policy rules established at the middlebox. 387 Convenience transactions simplify MIDCOM sessions by combining a set 388 of configuration transactions into a single one. They are not 389 necessary for MIDCOM protocol operation. 391 As specified in detail in Section 3, configuration transactions and 392 asynchronous transactions are mandatory. They must be implemented by 393 a compliant middlebox. All convenience transactions are optional and 394 some of the monitoring transactions are optional. 396 2.1.2. Message Types 398 The MIDCOM protocol supports three kinds of messages: request 399 messages, reply messages and notification messages. For each kind, 400 there exist different message types. In this semantics document, 401 message types are only defined by the list of parameters. The order 402 of the parameters and their encoding is left to a concrete protocol 403 definition. A protocol definition may also add further parameters to 404 a message type or combine several parameters into one, as long as the 405 information contained in the parameters defined in the semantics is 406 still contained. 408 For request messages and positive reply messages there exists one 409 message type per request transaction. Each reply transaction defines 410 the parameter list of the request message and of the positive 411 (successful) reply message using the transaction definition template 412 that is defined in Section 1.2. 414 In case of a failed request transaction, a negative reply message is 415 sent from the middlebox to the agent. This message has the same type 416 for all request transactions. It contains the request identifier 417 identifying the request on which the reply is sent and a parameter 418 indicating the failure reason. 420 For notification messages, there exist three message types: the 421 Session Termination Notification (STN) message type, the Policy Rule 422 Event Notification (REN) message type and the Group Event 423 Notification (GEN) message type. All of them contain a middlebox- 424 unique notification identifier. 426 STN The Session Termination Notification message additionally 427 contains a single parameter indicating the reason of session 428 termination by the middlebox. 430 REN The Policy Rule Event Notification message contains the 431 notification identifier, a policy rule identifier and the 432 remaining policy lifetime. 434 GEN The Group Event Notification message contains the notification 435 identifier, a policy rule group identifier and the remaining 436 policy rule group lifetime. 438 2.1.3. Session, Policy Rule, and Policy Rule Group 440 All transactions can further be grouped into transactions concerning 441 sessions, transactions concerning policy rules, and transactions 442 concerning policy rule groups. Policy rule groups can be used to 443 indicate relationships between policy rules and to simplify 444 transactions on a set of policy rules by using a single transaction 445 per group instead of one per policy rule. 447 Sessions and policy rules at the middlebox are stateful. Their 448 states are independent of each other and their state machines (one 449 per session and one per policy rule) can be separated. Policy rule 450 groups are also stateful, but the middlebox does not need to maintain 451 state for policy rule groups, because the semantics were chosen such 452 that the policy rule group state is implicitly defined by the state 453 of all policy rules belonging to the group (see Section 2.4). 455 The separation of session state and policy rule state simplifies the 456 specification of the semantics as well as a protocol implementation. 457 Therefore, the semantics specification is structured accordingly and 458 we use two separated state machines to illustrate the semantics. 459 Please note, that state machines of concrete protocol designs and 460 implementations will most probably be more complex than the state 461 machines presented here. However, the protocol state machines are 462 expected to be a superset of the semantics state machines in this 463 document. 465 2.1.4. Atomicity 467 All request transactions are atomic with respect to each other. This 468 means that processing of a request at the middlebox is never 469 interrupted by another arriving or already queued request. This 470 particularly applies when the middlebox concurrently receives 471 requests originating in different sessions. However, asynchronous 472 transactions may interrupt and/or terminate processing of a request 473 at any time. 475 All request transactions are atomic from the point of view of the 476 agent. Processing of a request does not start before the complete 477 request arrives at the middlebox. No intermediate state is stable at 478 the middlebox and no intermediate state is reported to any agent. 480 The number of transactions specified in this document is rather 481 small. Again for simplicity we reduced it close to a minimal set 482 that still meets the requirements. For a real implementation of the 483 protocol, it might be required to split some of the transactions 484 specified below into two or more transactions of the respective 485 protocol. Reasons for this might be constraints of the particular 486 protocol or the desire for more flexibility. In general this should 487 not be a problem. However, it should be considered that this might 488 change atomicity of the affected transactions. 490 2.1.5. Access Control 492 Access to policy rules and policy rule groups is based on ownership. 493 When a policy rule is created, a middlebox-unique identifier is 494 generated for identifying it in further transactions. Beyond the 495 identifier, each policy rule has an owner. The owner is the 496 authenticated agent that established the policy rule. The middlebox 497 uses the owner attribute of a policy rule for controlling access to 498 it: each time an authenticated agent requests to modify an existing 499 policy rule, the middlebox determines the owner of the policy rule 500 and checks if the requesting agent is authorized to perform 501 transactions on the owning agent's policy rules. 503 All policy rules belonging to the same policy rule group must have 504 the same owner. Therefore, authenticated agents either have access 505 to all members of a policy rule group, or to none of them. 507 The middlebox may be configured to allow specific authenticated 508 agents to access and modify policy rules with certain specific 509 owners. Certainly, a reasonable default configuration would be that 510 each agent can access its own policy rules. Also, it might be a good 511 idea, to have an agent identity configured to act as administrator 512 being allowed to modify all policy rules owned by any agent. Anyway, 513 the configuration of authorization at the middlebox is out of scope 514 of the MIDCOM semantics and protocol. 516 2.1.6. Middlebox Capabilities 518 For several reasons it is useful that the agent learns at session 519 establishment about particular capabilities of the middlebox. 520 Therefore, the session establishment procedure described in Section 521 2.2.1 includes a transfer of capability information from the 522 middlebox to the agent. The list of covered middlebox capabilities 523 includes 524 - support of firewall function 525 - list of supported NAT functions 526 The list of supported NAT functions may include 527 - address translation 528 - port translation 529 - protocol translation 530 - twice-NAT 531 - internal IP address wildcard support 532 - external IP address wildcard support 533 - port wildcard support 534 - supported IP version(s) for internal network: 535 IPv4, IPv6, or both 536 - supported IP version(s) for external network: 537 IPv4, IPv6, or both 538 - list of supported optional MIDCOM protocol transactions 539 - optional interface specific policy rule support: not 540 supported or supported. 541 - policy rule persistency: persistent or non-persistent 542 A rule is persistent when the middlebox can save the rule to 543 a non-volatile memory, e.g. a hard disk or flash memory. 544 - maximum remaining lifetime of a policy rule or policy rule 545 group 546 - idle-timeout of policy rules in the middlebox 547 Reserved and enabled policy rules that are not used by any 548 data traffic for the time of this idle-timeout are deleted 549 automatically by the middlebox. For the deletion of policy 550 rules by middleboxes see Section 2.3.13 about Asynchronous 551 Policy Rule Event (ARE). 552 - maximum number of simultaneous MIDCOM sessions 554 The list of middlebox capabilities may be extended by a concrete 555 protocol specification by further information that is useful for the 556 agent. 558 2.1.7. Agent and Middlebox Identifiers 560 In order to allow both agents and middleboxes to maintain multiple 561 sessions each request message contains a parameter identifying the 562 requesting agent, and each reply message and each notification 563 message contains a parameter identifying the middlebox. These 564 parameters are not explicitly listed in the description of the 565 individual transactions, because they are common to all of them and 566 not further referred to in the individual semantics descriptions. 567 Also, they are not necessarily passed explicitly as parameters of the 568 MIDCOM protocol, but they might be provided by the used underlying 569 (secure) transport protocol. Agent identifiers at the middlebox are 570 middlebox-unique and middlebox identifiers at the agent are agent- 571 unique respectively. 573 2.1.8. Conformance 575 The MIDCOM requirements in [MDC-REQ] demand certain capabilities of 576 the MIDCOM protocol, which are met by the set of transactions 577 specified below. However, an actual implementation of a middlebox 578 may support only a subset of these transactions. The set of 579 announced supported transactions may be different for different 580 authenticated agents. At session establishment, the middlebox 581 informs the authenticated agent by capability exchange, which 582 transactions the agent is authorized to perform. Some transactions 583 need to be offered to every authenticated agent. 585 Each transaction definition below has a conformance entry which 586 contains either 'mandatory' or 'optional'. A mandatory transaction 587 needs to be implemented by every middlebox offering MIDCOM service 588 and must be must be offered to each of the authenticated agents. An 589 optional transaction does not necessarily need to be implemented by a 590 middlebox. If an optional transaction is implemented in the 591 middlebox, the middlebox may offer these optional transactions only 592 to certain authenticated agents. The middlebox may offer one, 593 several, all, or no optional transactions to the agents. Whether or 594 not an agent is allowed to use an optional request transaction is 595 determined by the middlebox's authorization procedure which is not 596 further specified by this document. 598 2.2. Session Control Transactions 600 Before any transaction on policy rules or policy rule groups is 601 possible, a valid MIDCOM session must be established. A MIDCOM 602 session is an authenticated and authorized association between agent 603 and middlebox. Sessions are initiated by agents and can be 604 terminated by either the agent or the middlebox. Both agent and 605 middlebox may participate in several sessions (with different 606 entities) at the same time. For distinguishing different sessions 607 each party uses local session identifiers. 609 All transactions are transmitted within this MIDCOM session. 611 Session control is supported by three transactions: 613 - Session Establishment (SE) 614 - Session Termination (ST) 615 - Asynchronous Session Termination (AST) 617 The first two are configuration transactions initiated by the agent, 618 the last one is an asynchronous transaction initiated by the 619 middlebox. 621 2.2.1. Session Establishment (SE) 623 transaction-name: session establishment 625 transaction-type: configuration 627 transaction-compliance: mandatory 629 request-parameters: 631 - request identifier: an agent-unique identifier for matching 632 corresponding request and reply at the agent. 634 - version: the version of the MIDCOM protocol 636 - middlebox authentication challenge (mc): an authentication 637 challenge token for authentication of the middlebox. As seen 638 below, this is present only in the first iteration of the 639 request. 641 - agent authentication (aa): an authentication token to 642 authenticate the agent to the middlebox. As seen below, this is 643 updated in the second iteration of the request with material 644 responding to the middlebox challenge. 646 reply-parameters (success): 648 - request identifier: an identifier matching the identifier 649 request. 651 - middlebox authentication (ma): an authentication token to 652 authenticate the middlebox to the agent. 654 - agent challenge token (ac): an authentication challenge token for 655 the agent authentication. 657 - middlebox capabilities: a list describing the middlebox's 658 capabilities. See Section 2.1.6. for the list of middlebox 659 capabilities. 661 failure reason: 662 - authentication failed 663 - no authorization 664 - protocol version of agent and middlebox do not match 665 - lack of resources 667 semantics: 669 This session establishment transaction is used to establish a 670 MIDCOM session. For mutual authentication of both parties two 671 subsequent session establishment transactions are required as 672 shown in Figure 1. 674 agent middlebox 675 | session establishment request | 676 | (with middlebox challenge mc) | CLOSED 677 |-------------------------------------------->| 678 | | 679 | successful reply (with middlebox | 680 | authentication ma and agent challenge ac) | 681 |<--------------------------------------------| 682 | | NOAUTH 683 | session establishment request | 684 | (with agent authentication aa) | 685 |-------------------------------------------->| 686 | | 687 | successful reply | 688 |<--------------------------------------------| 689 | | OPEN 690 | | 692 Figure 1: Mutual authentication of agent and middlebox 694 Session establishment may be simplified by using only a single 695 transaction. In this case server challenge and agent challenge 696 are omitted by the sender or ignored by the receiver, and 697 authentication must be provided by other means, for example by TLS 698 [RFC2246] or IPsec [RFC2402][RFC2406]. 700 The middlebox checks with its policy decision point if the 701 requesting agent is authorized to open a MIDCOM session. If not a 702 negative reply with 'no authorization' as failure reason is 703 generated by the middlebox. If authentication and authorization 704 are successful, the session is established and the agent may start 705 with requesting transactions on policy rules and policy rule 706 groups. 708 Part of the successful reply is an indication of the middlebox's 709 capabilities. 711 2.2.2. Session Termination (ST) 713 transaction-name: session termination 715 transaction-type: configuration 717 transaction-compliance: mandatory 719 request-parameters: 721 - request identifier: an agent-unique identifier for matching 722 corresponding request and reply at the agent. 724 reply-parameters (success only): 726 - request identifier: an identifier matching the identifier of the 727 request. 729 semantics: 731 This transaction is used to close the MIDCOM session on behalf of 732 the agent. After session termination the middlebox keeps all 733 established policy rules until their lifetime expires or until an 734 event occurs which causes the middlebox to terminate them. 736 The middlebox always generates a successful reply. After sending 737 the reply, the middlebox will not send any further messages to the 738 agent within the current session. It also will not process any 739 further request within this session, which it has received while 740 it was processing the session termination request, or which it 741 receives later. 743 2.2.3. Asynchronous Session Termination (AST) 745 transaction-name: asynchronous session termination 747 transaction-type: asynchronous 749 transaction-compliance: mandatory 751 notification message type: Session Termination Notification (STN) 753 reply-parameters (success only): 755 - termination reason: the reason why the session is terminated. 757 semantics: 759 The middlebox may decide at any point in time to terminate a 760 MIDCOM session. Before terminating the actual session the 761 middlebox generates a STN message and sends it to the agent. After 762 sending the notification, the middlebox will not process any 763 further request by the agent, even if it is already queued at the 764 middlebox. 766 After session termination the middlebox keeps all established 767 policy rules until their lifetime expires or until an event occurs 768 on which the middlebox terminates them. 770 Different to other asynchronous transactions, no more than one 771 notification is sent, because there is only one agent affected by 772 the transaction. 774 2.2.4. Session Termination by Interruption of Connection 776 If a MIDCOM session is based on an underlying network connection, 777 then the session can also be terminated by an interruption of this 778 connection. If the middlebox detects this, it immediately terminates 779 the session. The effect on established policy rules is the same as 780 for the Asynchronous Session Termination. 782 2.2.5. Session State Machine 784 A state machine illustrating the semantics of the session 785 transactions is shown in Figure 2. The used transaction 786 abbreviations can be found in the headings of the particular 787 transaction section. 789 All sessions start in state CLOSED. A successful SE transaction can 790 cause a state transition to state OPEN, if mutual authentication is 791 already provided by other means. Otherwise, it causes a transition 792 to state NOAUTH. From this state a failed second SE transaction 793 returns to state CLOSED. A successful SE transaction causes a 794 transition to state OPEN. At any time an AST transaction or a 795 connection failure may occur causing a transition to state CLOSED. A 796 successful ST transaction from either NOAUTH or OPEN also causes a 797 return to CLOSED. The parameters of the transactions are explained 798 in Figure 2, the value mc=0 represents an empty middlebox challenge. 800 mc = middlebox challenge 801 SE/failure ma = middlebox authentication 802 +-------+ ac = agent challenge 803 | v aa = agent authentication 804 +----------+ 805 | CLOSED |----------------+ 806 +----------+ | SE(mc!=0)/ 807 | ^ ^ | success(ma,ac) 808 SE(mc=0, | | | AST | 809 aa=OK)/ | | | SE/failure v 810 success | | | ST/success +----------+ 811 | | +------------| NOAUTH | 812 | | +----------+ 813 | | AST | SE(mc=0, 814 v | ST/success | aa=OK)/ 815 +----------+ | success 816 | OPEN |<---------------+ 817 +----------+ 819 Figure 2: Session State Machine 821 2.3. Policy Rule Transactions 823 This section describes the semantics for transactions on policy 824 rules. The following transactions are specified: 826 - Policy Reserve Rule (PRR) 827 - Policy Enable Rule (PER) 828 - Policy Rule Lifetime Change (RLC) 829 - Policy Rule List (PRL) 830 - Policy Rule Status (PRS) 831 - Asynchronous Policy Rule Event (ARE) 833 The first three transactions (PRR, PER, RLC) are configuration 834 transactions initiated by the agent. The fourth and fifth (PRL, PRS) 835 are a monitoring transactions. And the last one (ARE) is an 836 asynchronous transaction. The PRL and PRS and transactions do not 837 have any effect on the policy rule state machine. 839 Before any transaction can start, a valid MIDCOM session must be 840 established. 842 2.3.1. Configuration Transactions 844 Policy Rule transactions PER and RLC constitute the core of the 845 MIDCOM protocol. Both are mandatory and they serve for 847 - configuring NAT bindings (PER) 848 - configuring firewall pinholes (PER) 849 - extending the lifetime of established policy rules (RLC) 850 - deleting policy rules (RLC) 852 In some cases it is required to know in advance which IP address (and 853 port number) would be chosen by NAT in a PER transaction. This 854 information is required before sufficient information for performing 855 a complete PER transaction is available (see example in Section 4.2). 856 For supporting such cases, the core transactions are extended by the 857 Policy Reserve Rule (PRR) transaction serving for 859 - reserving addresses and port numbers at NATs (PRR) 861 2.3.2. Establishing Policy Rules 863 Both PRR and PER establish a policy rule. The action within the rule 864 is 'reserve' if set by PRR and 'enable' if set by PER. 866 The Policy Reserve Rule (PRR) transaction is used to establish an 867 address reservation on neither, one, or both sides of the middlebox, 868 depending on the middlebox configuration. The transaction returns 869 the reserved IP addresses and the optional ranges of port numbers to 870 the agent. No address binding or pinhole configuration is performed 871 at the middlebox. Packet processing at the middlebox remains 872 unchanged. 874 On pure firewalls, the PRR transaction is successfully processed 875 without any reservation, but the state transition of the MIDCOM 876 protocol engine is exactly the same as on NATs. 878 On a traditional NAT (see [NAT-TRAD]), only an external address is 879 reserved; on a twice-NAT, an internal and an external address is 880 reserved. The reservation at a NAT is the reservation of the 881 required resources ,like IP addresses and port numbers, for future 882 use. How the reservation is exactly done depends on the 883 implementation of the NAT. In both cases the reservation concerns 884 either an IP address only or a combination of an IP address with a 885 range of port numbers. 887 The Policy Enable Rule (PER) transaction is used to establish a 888 policy rule that has an effect on packet processing at the middlebox. 889 Depending on its input parameters, it may make use of the reservation 890 established by a PRR transaction, or create a new rule from scratch. 892 On a NAT, the enable action is interpreted as bind action 893 establishing bindings between internal and external addresses. At a 894 firewall, the enable action is interpreted as one or more allow 895 actions configuring pinholes. The number of allow actions depends on 896 the parameters of the request and the implementation of the firewall. 898 On a combined NAT/firewall, the enable action is interpreted as a 899 combination of bind and allow actions. 901 The PRR transaction and the PER transaction are described in more 902 detail in Sections 2.3.8. and 2.3.9. below. 904 2.3.3. Maintaining Policy Rules and Policy Rule Groups 906 Each policy rule has a middlebox-unique identifier. 908 Each policy rule has an owner. Access control to the policy rule is 909 based on ownership (see section 2.1.5). Ownership of a policy rule 910 does not change during lifetime of the policy rule. 912 Each policy rule has its individual lifetime. If the policy rule 913 lifetime expires, the policy rule will be terminated at the 914 middlebox. Typically, the middlebox indicates termination of a 915 policy rule by an ARE transaction. A policy rule lifetime change 916 (RLC) transaction may extend the lifetime of the policy rule up to 917 the limit specified by the middlebox at session setup. Also a RLC 918 transaction may be used for shortening a policy rule's lifetime or 919 deleting a policy rule by requesting a lifetime of zero. (Please 920 note that policy rule lifetimes may also be modified by the group 921 lifetime change (GLC) transaction). 923 Each policy rule is member of exactly one policy rule group. Group 924 membership does not change during the lifetime of a policy rule. 925 Selecting the group is part of the transaction establishing the 926 policy rule. This transaction implicitly creates a new group if the 927 agent does not specify one. The new group identifier is chosen by 928 the middlebox. New members are added to a group, if the agent's 929 request designates an already existing group. A group only exists as 930 long as it has member policy rules. As soon as all policies 931 belonging to the group reach the end of their lifetimes, the group 932 does not exist anymore. 934 Agents can explore the properties and status of all policy rules they 935 are allowed to access by using the Policy Rule Status (PRS) 936 transaction. 938 2.3.4. Policy Events and Asynchronous Notifications 940 If a policy rule changes its state or if a policy rule's remaining 941 lifetime is changed in another way than being decreased by time, then 942 all agents that can access this policy rule and that participate in 943 an open session with the middlebox are notified by the middlebox. If 944 the state or lifetime change was requested explicitly by a request 945 message, then the middlebox notifies the agent by returning the 946 corresponding reply. All other agents that can access the policy are 947 notified by an Policy Rule Event Notification (REN) message. 949 Please note that a middlebox can serve multiple agents at the same 950 time in different parallel sessions. Between these agents, the sets 951 of policy rules that can be accessed by them may overlap. For 952 example, there might be an agent that authenticates as administrator 953 and can access all policies of all agents. Or there is a backup 954 agent running a session in parallel to a main agent and 955 authenticating itself as the same entity as the main agent. 957 In case of a PER, PRR, or RLC transaction, the requesting agent 958 receives a PER, PRR, or RLC reply, respectively. To all other agents 959 that can access the created, modified, or terminated policy rule (and 960 that participate in an open session with the middlebox) the middlebox 961 sends a REN message carrying the policy rule identifier (PID) and the 962 remaining lifetime of the policy rule. 964 In case of a rule termination by lifetime extension or other events 965 not triggered by an agent, then the middlebox sends a REN message to 966 each agents that can access the particular policy rule and that 967 participates in an open session with the middlebox. This ensures 968 that an agent always knows the most recent state of all policy rules 969 it can access. 971 2.3.5. Address Tuples 973 Request and reply messages of the PRR, PER, and PRS transactions 974 contain address specifications for IP and transport addresses. These 975 parameters include 977 - IP version 978 - IP address 979 - IP address prefix length 980 - transport protocol 981 - port number 982 - port parity 983 - port range 985 Additionally the request message of PER and reply message of PRS 986 contains a direction of flow parameter. This direction of flow 987 parameter indicates for UDP and IP the direction of packets 988 traversing the middlebox. For 'inbound' the UDP packets are 989 traversing from outside to inside, for 'outbound' the UDP packets are 990 traversing from inside to the outside. In both cases of 'inbound' 991 and 'outbound' the packets can traverse the middelbox only uni- 992 directional. A bi-directional flow is enabled through 'bi- 993 directional' as direction of flow parameter. In the case of TCP the 994 packet flow is always bi-directional, but the direction of flow 995 parameter is defined as: 997 - inbound: bi-directional TCP packet flow. First packet, with TCP 998 SYN flag set and ACK flag not set, must arrive at the middlebox 999 at the outside interface. 1001 - outbound: bi-directional TCP packet flow. First packet, with TCP 1002 SYN flag set and ACK flag not set, must arrive at the middlebox 1003 at the inside interface. 1005 - bi-directional: bi-directional TCP packet flow. First packet, 1006 with TCP SYN flag set and ACK flag not set, may arrive at inside 1007 or outside interface. 1009 We refer to the set of these parameters as an address tuple. An 1010 address tuple specifies either a communication endpoint at an 1011 internal or external device or allocated addresses at the middlebox. 1012 In this document, we distinguish four kinds of address tuples as 1013 shown in Figure 3. 1015 +----------+ +----------+ 1016 | internal | A0 A1 +-----------+ A2 A3 | external | 1017 | endpoint +----------+ middlebox +----------+ endpoint | 1018 +----------+ +-----------+ +----------+ 1020 Figure 3: Address tuples A0 - A3 1022 - A0 - internal endpoint: address tuple A0 specifies a 1023 communication endpoint of a device within the - with respect to 1024 the middlebox - internal network. 1026 - A1 - middlebox inside address: address tuple A1 specifies a 1027 virtual communication endpoint at the middlebox within the 1028 internal network. A1 is the destination address for packets 1029 passing from the internal endpoint to the middlebox, and is the 1030 source for packets passing from the middlebox to the internal 1031 endpoint. 1033 - A2 - middlebox outside address: address tuple A2 specifies a 1034 virtual communication endpoint at the middlebox within the 1035 external network. A2 is the destination address for packets 1036 passing from the external endpoint to the middlebox, and is the 1037 source for packets passing from the middlebox to the external 1038 endpoint. 1040 - A3 - external endpoint: address tuple A3 specifies a 1041 communication endpoint of a devices within the - with respect to 1042 the middlebox - external network. 1044 For a firewall, the inside and outside endpoints are identical to the 1045 corresponding external or internal endpoints, respectively. In this 1046 case the installed policy rule sets the same value in A2 as in A0 1047 (A0=A2), and sets the same value in A1 as in A3 (A1=A3). 1049 For a traditional NAT, A2 is given a value different from that of A0, 1050 but the NAT binds them. As for the firewall, so at a traditional NAT: 1051 A1 has the same value as A3. 1053 For a twice-NAT there are two bindings of address tuples: A1 and A2 1054 are both assigned values by the NAT. The middlebox outside address 1055 A2 is bound to the internal endpoint A0 and the middlebox inside 1056 address A1 is bound to the external endpoint A3. 1058 2.3.6. Address Parameter Constraints 1060 For transaction parameters belonging to an address tuple some 1061 constraints exist which are common for all messages using them. 1062 Therefore, these constraints are summarized in the following and not 1063 repeated again when describing the parameters in the transaction 1064 descriptions. 1066 The MIDCOM semantics defined in this document specifies the handling 1067 of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4 1068 and IPv6) as transport protocols. The handling of any other 1069 transport protocol, e.g. SCTP, is not defined within the semantics 1070 but may be supported by concrete protocol specifications. 1072 The IP version parameter has either the value 'IPv4' or 'IPv6'. In a 1073 policy rule, the value of the IP version parameter must be the same 1074 for address tuples A0 and A1, and it must be the same for A2 and A3. 1076 The value of the IP address parameter must conform with the specified 1077 IP version. 1079 The IP address of an address tuple may be wildcarded. Whether IP 1080 address wildcarding is allowed or in which range it is allowed 1081 depends on the local policy of the middlebox, see also section 6 1082 "Security Considerations". Wildcarding is specified by the IP 1083 address prefix length parameter of an address tuple. In line with 1084 the common use of a prefix length, this parameter indicates the 1085 number of high significant bits of the IP address that are fixed, 1086 while the remaining low significant bits of the IP address are 1087 wildcarded. 1089 The value of the transport protocol parameter can be either 'TCP', 1090 'UDP', or 'ANY'. If the transport protocol parameter has the value 1091 'ANY', only IP headers are considered for packet handling in the 1092 middlebox, i.e. the transport header is not considered. The values 1093 of the parameters port number, port range and port parity are 1094 irrelevant if the protocol parameter is 'ANY'. In a policy rule the 1095 value of the transport protocol parameter must be the same for all 1096 address tuples A0, A1, A2, and A3. 1098 The value of the port number parameter is either zero or a positive 1099 integer. A positive integer specifies a concrete UDP or TCP port 1100 number. The value zero specifies port wildcarding for the protocol 1101 specified by the transport protocol parameter. If the port number 1102 parameter has the value zero, then the value of the port range 1103 parameter is irrelevant. Depending on the value of the transport 1104 protocol parameter, this parameter may truly refer to ports, or may 1105 refer to an equivalent concept. 1107 The port parity parameter is differently used in the context of 1108 policy reserve rules (PRR) and policy enable rules (PER). In the 1109 context of a PRR, the value of the parameter may be 'odd', 'even', or 1110 'any'. It specifies the parity of the first (lowest) reserved port 1111 number. 1113 In the context of a PER, the port parity parameter indicates to the 1114 middlebox, whether or not port numbers allocated at the middlebox 1115 should have the same parity as the corresponding internal or external 1116 port numbers, respectively. In this context, the parameter has 1117 either the value 'same' or 'any'. If it has the value 'same', then 1118 the parity of the port number of A0 must be the same as the parity of 1119 the port number of A2, and the parity of the port number of A1 must 1120 be the same as the parity of the port number of A3. If the port 1121 parity parameter has the value 'any', then there are no constraints 1122 on the parity of any port number. 1124 The port range parameter specifies a number of consecutive port 1125 numbers. Its value is a positive integer. Together with the port 1126 number parameter this parameter defines a set of consecutive port 1127 numbers starting with the port number specified by the port number 1128 parameter as the lowest port number and having as many elements as 1129 specified by the port range parameter. A value of one specifies just 1130 a single port number. The port range parameter must have the same 1131 value for each address tuple A0, A1, A2, and A3. 1133 A single policy rule P containing a port range value greater than one 1134 is equivalent to a set of policy rules containing a number n of 1135 policies P_1, P_2, ..., P_n that equals the value of the port range 1136 parameter. All policy rules P_1, P_2, ..., P_n have a port range 1137 parameter value of one. Policy rule P_1 contains a set of address 1138 tuples A0_1, A1_1, A2_1, and A3_1, that each contain the first port 1139 number of the respective address tuples in P; policy rule P_2 1140 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, that 1141 each contain the second port number of the respective address tuples 1142 in P; and so on. 1144 2.3.7. Interface specific Policy Rules 1146 Usually agents do request policy rules with the knowledge of A0 and 1147 A3 only, i.e. the address tuples (see Section 2.3.5). But in very 1148 special cases, agents may need to select the interfaces to which the 1149 requested policy rule is bound. In the general case the middlebox 1150 takes care about choosing the right interfaces when reserving or 1151 enabling a policy rule, since it has the overall knowledge about its 1152 configuration. For agents that want to select the interfaces, 1153 optional parameters are include in the Policy Reserve Rule (PRR) and 1154 Policy Enable Rule (PER) transactions. These parameter are called 1156 - inside interface - the selected interface at the inside of the 1157 middlebox, i.e. in the private or protected address realm. 1159 - outside interface - the selected interface at the outside of the 1160 middlebox, i.e. in the public address realm. 1162 The Policy Rule Status (PRS) transactions include these optional 1163 parameters in its replies when they are supported. 1165 Agents can learn at session startup whether interface specific policy 1166 rules are supported by the middlebox or not, by checking the 1167 middlebox capabilities (see Section 2.1.6). 1169 2.3.8. Policy Reserve Rule (PRR) 1171 transaction-name: policy reserve rule 1173 transaction-type: configuration 1175 transaction-compliance: mandatory 1177 request-parameters: 1179 - request identifier: an agent-unique identifier for matching 1180 corresponding request and reply at the agent. 1182 - group identifier: a reference to the group of which the policy 1183 reserve rule should be a member. As indicated in Section 2.3.3., 1184 if this value is not supplied, the middlebox assigns a new group 1185 for this policy reserve rule. 1187 - service: the requested NAT service of the middlebox. Allowed 1188 values are 'traditional' or 'twice'. 1190 - internal IP version: requested IP version at the inside of the 1191 middlebox, see Section 2.3.5. 1193 - internal IP address: the IP address of the internal communication 1194 endpoint (A0 in Fig. 3), see Section 2.3.5. 1196 - internal port number: the port number of the internal 1197 communication endpoint (A0 in Fig. 3), see Section 2.3.5. 1199 - inside interface (optional): interface at the inside of the 1200 middlebox, see Section 2.3.7. 1202 - external IP version: requested IP version at the outside of the 1203 middlebox, see Section 2.3.5. 1205 - outside interface (optional): interface at the outside of the 1206 middlebox, see Section 2.3.7. 1208 - transport protocol: see section 2.3.5. 1210 - port range: the number of consecutive port numbers to be 1211 reserved, see Section 2.3.5. 1213 - port parity: the requested parity of the first (lowest) port 1214 number to be reserved, Allowed values of this parameter are 1215 'odd', 'even', and 'any'. See also Section 2.3.5. 1217 - policy rule lifetime: a lifetime proposal to the middlebox for 1218 the requested policy rule. 1220 reply-parameters (success): 1222 - request identifier: an identifier matching the identifier of the 1223 request. 1225 - policy rule identifier: a middlebox-unique policy rule 1226 identifier. It is assigned by the middlebox and used as policy 1227 rule handle in further policy rule transactions, particularly to 1228 refer to the policy reserve rule in a subsequent PER transaction. 1230 - group identifier: a reference to the group of which the policy 1231 reserve rule is a member. 1233 - reserved inside IP address: The reserved IPv4 or IPv6 address on 1234 the internal side of the middlebox. For an outbound flow, this 1235 will be the destination to which the internal endpoint sends its 1236 packets (A1 in Figure 3). For an inbound flow, this will be the 1237 apparent source address of the packets as forwarded to the 1238 internal endpoint (A0 in Figure 3). The middlebox reserves and 1239 reports an internal address only in the case where twice-NAT is 1240 in effect. Otherwise, an empty value for the addresses indicates 1241 that no internal reservation was made. See also Section 2.3.5. 1243 - reserved inside port number: see section 2.3.5. 1245 - reserved outside IP address: The reserved IPv4 or IPv6 address on 1246 the external side of the middlebox. For an inbound flow, this 1247 will be the destination to which the external endpoint sends its 1248 packets (A2 in Figure 4). For an outbound flow, this will be the 1249 apparent source address of the packets as forwarded to the 1250 external endpoint (A3 in Figure 3). If the middlebox is 1251 configured as a pure firewall, an empty value for the addresses 1252 indicates that no external reservation was made. See also 1253 Section 2.3.5. 1255 - reserved outside port number: see section 2.3.5. 1257 - policy rule lifetime: the policy rule lifetime granted by the 1258 middlebox, after which the reservation will be revoked if it has 1259 not been replaced already by a policy enable rule in a PER 1260 transaction. 1262 failure reason: 1263 - agent not authorized for this transaction 1264 - agent not authorized for adding members to this group 1265 - lack of IP addresses 1266 - lack of port numbers 1267 - lack of resources 1268 - specified inside/outside interface does not exist 1269 - specified inside/outside interface not available for specified 1270 service 1272 notification message type: Policy Rule Event Notification (REN) 1274 semantics: 1276 The agent can use this transaction type to reserve an IP address 1277 or a combination of IP address, transport type, port number and 1278 port range at neither, one, or both sides of the middlebox as 1279 required to support the enabling of a flow. Typically the PRR 1280 will be used in scenarios where it is required to perform such a 1281 reservation before sufficient parameters for a complete policy 1282 enable rule transaction are available. See section 4.2 for an 1283 example. 1285 When receiving the request, the middlebox determines how many 1286 address (and port) reservations are required based on its 1287 configuration. If it provides only packet filter services, it 1288 does not perform any reservation and just returns empty values for 1289 the reserved inside and outside IP addresses and port numbers. If 1290 it is configured for twice-NAT, it reserves both inside and 1291 outside IP addresses (and an optional range of port numbers) and 1292 returns them. Otherwise, it reserves and returns an outside IP 1293 address (and an optional range of port numbers) and returns empty 1294 values for the reserved inside address and port range. The A0 1295 parameter (inside IP address version, inside IP address, and 1296 inside port number) can be used by the middlebox to determine the 1297 correct NAT mapping and thus A2 if necessary. 1299 Once a PRR transaction has reserved an outside address (A2) for an 1300 internal end point (A0) at the middlebox, the middlebox must 1301 ensure that this reserved A2 is available in any subsequent PER 1302 and PRR transaction. 1304 For middleboxes supporting interface specific policy rules, as 1305 defined in Section 2.3.7., the optional inside and outside 1306 interface parameters must be included both in the request or none 1307 of them. In the presence of these parameters the middlebox uses 1308 the outside interface parameter to select the interface at which 1309 the outside address tuple (outside IP address and port number) is 1310 reserved, and the inside interface parameter to select the 1311 interface at which the inside address tuple (inside IP address and 1312 port number) is reserved. Without the presence of these 1313 parameters, the middlebox selects the particular interfaces based 1314 on its internal configuration. 1316 If there is a lack of resources, such as available IP addresses, 1317 port numbers, or storage for further policy rules, then the 1318 reservation fails and an appropriate failure reply is generated. 1320 If a non-existing policy rule group was specified, or if an 1321 existing policy rule group was specified that is not owned by the 1322 requesting agent, then no new policy rule is established and an 1323 appropriate failure reply is generated. 1325 In case of success, this transaction creates a new policy reserve 1326 rule. If an already existing policy rule group is specified, then 1327 the new policy rule becomes a member of it. If no policy group is 1328 specified a new group is created with the new policy rule as its 1329 only member. The middlebox generates a middlebox-unique 1330 identifier for the new policy rule. The owner of the new policy 1331 rule is the authenticated agent that sent the request. The 1332 middlebox chooses a lifetime value that is greater than zero and 1333 less than or equal to the minimum of the requested value and the 1334 maximum lifetime specified by the middlebox at session startup, 1335 i.e.: 1337 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1339 whereas: 1340 - lt_granted is the actually granted lifetime by the middlebox 1341 - lt_requested is the requested lifetime of the agent 1342 - lt_maximum is the maximum lifetime specified at session 1343 setup 1345 The middlebox always reserves a middlebox external address tuple 1346 (A2) due to a PRR request. In a special case of a combined twice- 1347 NAT/NAT middlebox the agent can request only NAT service or twice- 1348 NAT service by choosing the service parameter 'traditional' or 1349 'twice' respectively. An agent that does not have any preference 1350 chooses 'twice'. The 'traditional' value should only be used in 1351 order to select traditional NAT service at middleboxes offering 1352 both traditional NAT and twice NAT. In the 'twice' case the 1353 combined twice-NAT/NAT middlebox reserves A2 and A1, the 1354 'traditional' case results in a reservation of A2 only. An agent 1355 must always use the PRR transaction for choosing NAT only or 1356 twice-NAT service in the special case of a combined twice-NAT/NAT 1357 middlebox. A firewall middlebox ignores this parameter. 1359 If the protocol identifier is 'ANY', then the middlebox reserves 1360 available inside and/or outside IP address(es) only. The reserved 1361 address(es) are returned to the agent. In this case the request- 1362 parameters port range and port parity as well as reply-parameters 1363 inside port number and outside port number are irrelevant. 1365 If the protocol identifier is 'UDP' or 'TCP', then a combination 1366 of an IP address and a consecutive sequence of port numbers, 1367 starting with the specified parity, is reserved, on neither, one, 1368 or both sides of the middlebox as appropriate. The IP address(es) 1369 and the first (lowest) reserved port number(s) of the consecutive 1370 sequence are returned to the agent. (This also applies to other 1371 protocols supporting ports or the equivalent.) 1373 After a new policy reserve rule was successfully established and 1374 the reply message has been sent to the requesting agent, the 1375 middlebox checks if there are other authenticated agents 1376 participating in open sessions, which can access the new policy 1377 rule. If the middlebox finds one or more of these agents, then it 1378 sends a REN message reporting the new policy rule to each of them. 1380 MIDCOM agents use the policy enable rule (PER) transaction to enable 1381 policy reserve rules that have been established beforehand by a 1382 policy reserve rule (PRR) transaction. See also Section 2.3.2. 1384 2.3.9. Policy Enable Rule (PER) 1386 transaction-name: policy enable rule 1388 transaction-type: configuration 1390 transaction-compliance: mandatory 1392 request-parameters: 1394 - request identifier: an agent-unique identifier for matching 1395 corresponding request and reply at the agent. 1397 - policy reserve rule identifier: a reference to an already 1398 existing policy reserve rule created by a PRR transaction. The 1399 reference may be empty, in which case the middlebox must assign 1400 any necessary addresses and port numbers within this PER 1401 transaction. If it is not empty, then the following request 1402 parameters are irrelevant: group identifier, transport protocol, 1403 port range, port parity, internal IP version, external IP 1404 version. 1406 - group identifier: a reference to the group of which the policy 1407 enable rule should be a member. As indicated in Section 2.3.3., 1408 if this value is not supplied, the middlebox assigns a new group 1409 for this policy reserve rule. 1411 - transport protocol: see section 2.3.5. 1413 - port range: the number of consecutive port numbers to be 1414 reserved, see Section 2.3.5. 1416 - port parity: the requested parity of the port number(s) to be 1417 mapped. Allowed values of this parameter are 'same' and 'any'. 1418 See also Section 2.3.5. 1420 - direction of flow: this parameter specifies the direction of 1421 enabled communication, either 'inbound', 'outbound', or 'bi- 1422 directional'. 1424 - internal IP version: requested IP version at the inside of the 1425 middlebox, see Section 2.3.5. 1427 - internal IP address: the IP address of the internal communication 1428 endpoint (A0 in Fig. 3), see Section 2.3.5. 1430 - internal port number: the port number of the internal 1431 communication endpoint (A0 in Fig. 3), see Section 2.3.5. 1433 - inside interface (optional): interface at the inside of the 1434 middlebox, see Section 2.3.7. 1436 - external IP version: requested IP version at the outside of the 1437 middlebox, see Section 2.3.5. 1439 - external IP address: the IP address of the external communication 1440 endpoint (A3 in Fig. 3), see Section 2.3.5. 1442 - external port number: the port number of the external 1443 communication endpoint (A3 in Fig. 4), see Section 2.3.5. 1445 - outside interface (optional): interface at the outside of the 1446 middlebox, see Section 2.3.7. 1448 - policy rule lifetime: a lifetime proposal to the middlebox for 1449 the requested policy rule. 1451 reply-parameters (success): 1453 - request identifier: an identifier matching the identifier of the 1454 request. 1456 - policy rule identifier: a middlebox-unique policy rule 1457 identifier. It is assigned by the middlebox and used as policy 1458 rule handle in further policy rule transactions. If a policy 1459 reserve rule identifier was provided in the request, then the 1460 returned policy rule identifier has the same value. 1462 - group identifier: a reference to the group of which the policy 1463 enable rule is a member. If a policy reserve rule identifier was 1464 provided in the request, then this parameter identifies the 1465 group, of which the policy reserve rule was a member. 1467 - inside IP address: the IP address provided at the inside of the 1468 middlebox (A1 in Fig. 3). In case of a twice-NAT, this parameter 1469 will be an internal IP address reserved at the inside of the 1470 middlebox. In all other cases, this reply-parameter will be 1471 identical with the external IP address passed with the request. 1472 If the policy reserve rule identifier parameter was supplied in 1473 the request and if the respective PRR transaction reserved an 1474 inside IP address, then the inside IP address provided in the PER 1475 response will be the identical value to that returned by the 1476 response to the PRR request. See also Section 2.3.5. 1478 - inside port number: the internal port number provided at the 1479 inside of the middlebox (A1 in Fig. 3), see also Section 2.3.5. 1481 - outside IP address: the external IP address provided at the 1482 outside of the middlebox (A2 in Fig. 4). In case of a pure 1483 firewall, this parameter will be identical with the internal IP 1484 address passed with the request. In all other cases, this reply- 1485 parameter will be an external IP address reserved at the outside 1486 of the middlebox. See also Section 2.3.5. 1488 - outside port number: the external port number provided at the 1489 outside of the NAT (A2 in Fig. 3), see Section 2.3.5.. 1491 - policy rule lifetime: the policy rule lifetime granted by the 1492 middlebox. 1494 failure reason: 1495 - agent not authorized for this transaction 1496 - agent not authorized for adding members to this group 1497 - no such policy reserve rule 1498 - agent not authorized for replacing this policy reserve rule 1499 - conflict with already existing policy rule (e.g. the same 1500 internal address-port is being mapped to different outside 1501 address-port pairs) 1502 - lack of IP addresses 1503 - lack of port numbers 1504 - lack of resources 1505 - no internal IP wildcarding allowed 1506 - no external IP wildcarding allowed 1507 - specified inside/outside interface does not exist 1508 - specified inside/outside interface not available for specified 1509 service 1510 - reserved A0 to requested A0 mismatch 1512 notification message type: Policy Rule Event Notification (REN) 1514 semantics: 1516 This transaction can be used by an agent for enabling 1517 communication between an internal endpoint and an external 1518 endpoint independently of the type of middlebox (NAT, NAPT, 1519 firewall, NAT-PT, combined devices, ... ), for unidirectional or 1520 bi-directional traffic. 1522 The agent sends an enable request specifying the endpoints 1523 (optionally including wildcards) and the direction of 1524 communication (inbound, outbound, bi-directional). The 1525 communication endpoints are displayed in Figure 3. The basic 1526 operation of the PER transaction can be described by 1528 1. the agent sending A0 and A3 to the middlebox, 1530 2. the middlebox reserving A1 and A2 or using A1 and A2 from a 1531 previous PRR transaction 1533 3. the middlebox enabling packet transfer between A0 and A3 by 1534 binding A0-A2 and A1-A3 and/or by opening the corresponding 1535 pinholes, both according to the specified direction, 1537 4. the middlebox returning A1 and A2 to the agent. 1539 In case of a pure packet filtering firewall, the returned address 1540 tuples are the same as the ones in the request: A2=A0 and A1=A3. 1541 Each partner uses the other one's real address. In case of a 1542 traditional NAT the internal endpoint may use the real address of 1543 the external endpoint (A1=A3), but the external endpoint uses an 1544 address tuple provided by the NAT (A2!=A0). In case of a twice- 1545 NAT device, both endpoints use address tuples provided by the NAT 1546 for addressing their communication partner (A3!=A1 and A2!=A0). 1548 If a firewall is combined with a NAT or a twice-NAT, the replied 1549 address tuples will be the same as for pure traditional NAT or 1550 twice-NAT, respectively, but the middlebox will configure its 1551 packet filter in addition to the performed NAT bindings. In case 1552 of a firewall combined with a traditional NAT, the policy rule may 1553 imply more than one enable action for the firewall configuration, 1554 because incoming and outgoing packets may use different source- 1555 destination pairs. 1557 For middleboxes supporting interface specific policy rules, as 1558 defined in Section 2.3.7., the optional inside and outside 1559 interface parameters must be included both in the request or none 1560 of them. In the presence of these parameters the middlebox uses 1561 the outside interface parameter to select the interface at which 1562 the outside address tuple (outside IP address and port number) is 1563 bound, and the inside interface parameter to select the interface 1564 at which the inside address tuple (inside IP address and port 1565 number) is bound. Without the presence of these parameters, the 1566 middlebox selects the particular interfaces based on its internal 1567 configuration. 1569 Checking the policy reservation rule identifier 1571 If the parameter specifying the policy reservation rule 1572 identifier is not empty, then the middlebox checks whether or 1573 not the referenced policy rule exists, whether or not the agent 1574 is authorized to replace this policy rule, and whether or not 1575 this policy rule is a policy reserve rule. 1577 In case of success, this transaction creates a new policy 1578 enable rule. If a policy reserve rule was referenced, then the 1579 policy reserve rule is terminated without an explicit 1580 notification sent to the agent (besides the successful PER 1581 reply). 1583 The PRR transaction sets the internal endpoint A0 during the 1584 reservation process. In the process of creating a new policy 1585 enable rule, the middlebox may check whether the requested A0 1586 is equal to the reserved A0. The middlebox may reject a PER 1587 request with a requested A0 not equal to the reserved A0 and 1588 must sent an appropriate failure message. The middlebox may 1589 change A0 due to the PER request. 1591 The middlebox generates a middlebox-unique identifier for the 1592 new policy rule. If a policy reserve rule was referenced, then 1593 the identifier of the policy reserve rule is re-used. 1595 The owner of the new policy rule is the authenticated agent 1596 that sent the request. 1598 Checking the policy rule group identifier 1600 If no policy reserve rule was specified, then the policy rule 1601 group parameter is checked. If a non-existing policy rule group 1602 is specified, or if an existing policy rule group is specified 1603 that is not owned by the requesting agent, then no new policy 1604 rule is established and an appropriate failure reply is 1605 generated. 1607 If an already existing policy rule group is specified, then the 1608 new policy rule becomes a member of it. If no policy group is 1609 specified, then a new group is created with the new policy rule 1610 as its only member. 1612 If the transport protocol parameter value is 'any', then the 1613 middlebox enables communication between the specified external IP 1614 address and the specified internal IP address. The addresses to 1615 be used by the communication partners in order to address each 1616 other are returned to the agent as inside IP address and outside 1617 IP address. If the reservation identifier is not empty and if the 1618 reservation used the same transport protocol type, then the 1619 reserved IP addresses are used. 1621 For the transport protocol parameter values 'UDP' and 'TCP' the 1622 middlebox acts analogously to 'ANY' but additionally maps ranges 1623 of port numbers, keeping the port parity if requested. 1625 The configuration of the middlebox may fail because of lack of 1626 resources, such as available IP addresses, port numbers, or 1627 storage for further policy rules. Also it may fail because of a 1628 conflict with an already established policy rule. In case of a 1629 conflict, the first come first serve mechanism is applied. 1630 Already existing policy rules remain unchanged and arriving new 1631 ones are rejected. However, in case of a non-conflicting overlap 1632 of policy rules (including identical policy rules), all policy 1633 rules are accepted. 1635 The middlebox chooses a lifetime value that is greater than zero 1636 and less than or equal to the minimum of the requested value and 1637 the maximum lifetime specified by the middlebox at session 1638 startup, i.e.: 1640 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1642 whereas: 1643 - lt_granted is the actually granted lifetime by the middlebox 1644 - lt_requested is the requested lifetime of the agent 1645 - lt_maximum is the maximum lifetime specified at session 1646 setup 1648 In each case of failure, an appropriate failure reply is 1649 generated. The policy reserve rule that is referenced in the PER 1650 transaction is not affected in case of a failure within the PER 1651 transaction, i.e. the policy reserve rule remains. 1653 After a new policy enable rule was successfully established and 1654 the reply message has been sent to the requesting agent, the 1655 middlebox checks if there are other authenticated agents 1656 participating in open sessions, which can access the new policy 1657 rule. If the middlebox finds one or more of these agents, then it 1658 sends a REN message reporting the new policy rule to each of them. 1660 2.3.10. Policy Rule Lifetime Change (RLC) 1662 transaction-name: policy rule lifetime change 1664 transaction-type: configuration 1666 transaction-compliance: mandatory 1667 request-parameters: 1669 - request identifier: an agent-unique identifier for matching 1670 corresponding request and reply at the agent. 1672 - policy rule identifier: identifying the policy rule for which the 1673 lifetime is requested to be changed. This may identify either a 1674 policy reserve rule or a policy enable rule. 1676 - policy rule lifetime: the new lifetime proposal for the policy 1677 rule. 1679 reply-parameters (success): 1681 - request identifier: an identifier matching the identifier of the 1682 request. 1684 - policy rule lifetime: The remaining policy rule lifetime granted 1685 by the middlebox. 1687 failure reason: 1688 - agent not authorized for this transaction 1689 - agent not authorized for changing lifetime of this policy 1690 rule 1691 - no such policy rule 1692 - lifetime cannot be extended 1694 notification message type: Policy Rule Event Notification (REN) 1696 semantics: 1698 The agent can use this transaction type to request the extension 1699 of an already established policy rule's lifetime, to request 1700 shortening of the life time, or to request policy rule 1701 termination. Policy rule termination is requested by suggesting a 1702 new policy rule lifetime of zero. 1704 The middlebox first checks whether or not the specified policy 1705 rule exists and whether or not the agent is authorized to access 1706 this policy rule. If one of the checks fails, an appropriate 1707 failure reply is generated. If the requested lifetime is longer 1708 than the current one, the middlebox also checks, whether or not 1709 the lifetime of the policy rule may be extended and generates an 1710 appropriate failure message if not. 1712 A failure reply implies that the new lifetime was not accepted, 1713 and the policy rule remains unchanged. A success reply is 1714 generated by the middlebox, if the lifetime of the policy rule was 1715 changed in any way. 1717 The success reply contains the new lifetime of the policy rule. 1718 The middlebox chooses a lifetime value that is greater than zero 1719 and less than or equal to the minimum of the requested value and 1720 the maximum lifetime specified by the middlebox at session 1721 startup, i.e.: 1723 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 1725 whereas: 1726 - lt_granted is the actually granted lifetime by the middlebox 1727 - lt_requested is the requested lifetime of the agent 1728 - lt_maximum is the maximum lifetime specified at session 1729 setup 1731 After sending a success reply with a lifetime of zero, the 1732 middlebox will consider the policy rule to be non-existent. Any 1733 further transaction on this policy rule results in a negative 1734 reply, indicating that this policy rule does not exist anymore. 1736 Please note, that policy rule lifetime may also be changed by the 1737 Group Lifetime Change (GLC) transaction if applied to the group of 1738 which the policy rule is a member. 1740 After the remaining policy rule lifetime was successfully changed 1741 and the reply message has been sent to the requesting agent, the 1742 middlebox checks if there are other authenticated agents 1743 participating in open sessions, which can access the policy rule. 1744 If the middlebox finds one or more of these agents, then it sends 1745 a REN message reporting the new remaining policy rule lifetime to 1746 each of them. 1748 2.3.11. Policy Rule List (PRL) 1750 transaction-name: policy rule list 1752 transaction-type: monitoring 1754 transaction-compliance: mandatory 1756 request-parameters: 1758 - request identifier: an agent-unique identifier for matching 1759 corresponding request and reply at the agent. 1761 reply-parameters (success): 1763 - request identifier: an identifier matching the identifier of the 1764 request. 1766 - policy list: list of policy rule identifiers of all policy rules 1767 that the agent can access. 1769 failure reason: 1770 - transaction not supported 1771 - agent not authorized for this transaction 1773 semantics: 1775 The agent can use this transaction type to list all policies which 1776 it can access. Usually, the agent has this information already, 1777 but in special cases (for example after an agent fail-over) or for 1778 special agents (for example an administrating agent that can 1779 access all policies) this transaction can be helpful. 1781 The middlebox first checks whether or not the agent is authorized 1782 to request this transaction. If the check fails, an appropriate 1783 failure reply is generated. Otherwise a list of all policies the 1784 agent can access is returned indicating the identifier and the 1785 owner of each policy. 1787 This transaction does not have any effect on the policy rule 1788 state. 1790 2.3.12. Policy Rule Status (PRS) 1792 transaction-name: policy rule status 1794 transaction-type: monitoring 1796 transaction-compliance: mandatory 1798 request-parameters: 1800 - request identifier: an agent-unique identifier for matching 1801 corresponding request and reply at the agent. 1803 - policy rule identifier: the middlebox-unique policy rule 1804 identifier. 1806 reply-parameters (success): 1808 - request identifier: an identifier matching the identifier of the 1809 request. 1811 - policy rule owner: an identifier of the agent owning this policy 1812 rule. 1814 - group identifier: a reference to the group of which the policy 1815 rule is a member. 1817 - policy rule action: this parameter has either the value 'reserve' 1818 or the value 'enable'. 1820 - transport protocol: identifies the protocol for which a 1821 reservation is requested, see Section 2.3.5. 1823 - port range: the number of consecutive port numbers, see Section 1824 2.3.5. 1826 - direction: the direction of the communication enabled by the 1827 middlebox. Applicable only to policy enable rules. 1829 - internal IP address version: the version of the internal IP 1830 address (IP version of A0 in Fig. 3) 1832 - external IP address version: the version of the external IP 1833 address (IP version of A3 in Fig. 3) 1835 - internal IP address: the IP address of the internal communication 1836 endpoint (A0 in Fig. 3), see Section 2.3.5. 1838 - internal port number: the port number of the internal 1839 communication endpoint (A0 in Fig. 3), see Section 2.3.5. 1841 - external IP address: the IP address of the external communication 1842 endpoint (A3 in Fig. 3), see Section 2.3.5. 1844 - external port number: the port number of the external 1845 communication endpoint (A3 in Fig. 3), see Section 2.3.5. 1847 - inside interface (optional): the inside interface at the 1848 middlebox, see Section 2.3.7. 1850 - inside IP address: the internal IP address provided at the inside 1851 of the NAT (A1 in Fig. 3), see Section 2.3.5. 1853 - inside port number: the internal port number provided at the 1854 inside of the NAT (A1 in Fig. 3), see Section 2.3.5. 1856 - outside interface (optional): the outside interface at the 1857 middlebox, see Section 2.3.7. 1859 - outside IP address: the external IP address provided at the 1860 outside of the NAT (A2 in Fig. 3), see Section 2.3.5. 1862 - outside port number: the external port number provided at the 1863 outside of the NAT (A2 in Fig. 3), see Section 2.3.5. 1865 - port parity: The parity of the allocated ports. 1867 - service: The selected service in the case of mixed traditional 1868 and twice-NAT middlebox(see section 2.3.8.) 1870 - policy rule lifetime: the remaining lifetime of the policy rule. 1872 failure reason: 1873 - transaction not supported 1874 - agent not authorized for this transaction 1875 - no such policy rule 1876 - agent not authorized for accessing this policy rule 1878 semantics: 1880 The agent can use this transaction type to list all properties of 1881 a policy rule. Usually, the agent has this information already, 1882 but in special cases (for example after an agent fail-over) or for 1883 special agents (for example an administrating agent that can 1884 access all policy rules) this transaction can be helpful. 1886 The middlebox first checks whether or not the specified policy 1887 rule exists and whether or not the agent is authorized to access 1888 this group. If one of the checks fails, an appropriate failure 1889 reply is generated. Otherwise all properties of the policy rule 1890 are returned to the agent. Some of the returned parameters may be 1891 irrelevant, depending on the policy rule action ('reserve' or 1892 'enable') and depending on other parameters, for example the 1893 protocol identifier. 1895 This transaction does not have any effect on the policy rule 1896 state. 1898 2.3.13. Asynchronous Policy Rule Event (ARE) 1900 transaction-name: asynchronous policy rule event 1902 transaction-type: notification 1904 transaction-compliance: mandatory 1906 notification message type: Policy Rule Event Notification (REN) 1908 semantics: 1910 The middlebox may decide at any point in time to terminate a 1911 policy rule. Particularly, this transaction is triggered by 1912 lifetime expiration of the policy rule. Among other events that 1913 may cause this transaction are changes in the policy rule decision 1914 point. 1916 The middlebox sends a REN message to all agents that participate 1917 in an open session with the middlebox and that are authorized to 1918 access the policy rule. The notification is sent to the agents 1919 before the middlebox changes the policy rule's lifetime. The 1920 change of lifetime may be triggered by any other authorized agent 1921 and results in shortening (lt_new < lt_existing), extending 1922 (lt_new > lt_existing), or in terminating the policy rule (lt_new 1923 = 0). 1925 The ARE transaction corresponds to the REN message handling described 1926 in Section 2.3.4. for multiple agents. 1928 2.3.14. Policy Rule State Machine 1930 The state machine for the policy rule transactions is shown in Figure 1931 4 with all possible state transitions. You'll find the used 1932 transaction abbreviations in the headings of the particular 1933 transaction section. 1935 PRR/success +---------------+ 1936 +-----------------+ PRID UNUSED |<-+ 1937 +----+ | +---------------+ | 1938 | | | ^ | | 1939 | v v | | | 1940 | +-------------+ ARE | | PER/ | ARE 1941 | | RESERVED +------------+ | success | RLC(lt=0)/ 1942 | +-+----+------+ RLC(lt=0)/ | | success 1943 | | | success | | 1944 +----+ | v | 1945 RLC(lt>0)/ | PER/success +---------------+ | 1946 success +---------------->| ENABLED +--+ 1947 +-+-------------+ 1948 | ^ 1949 lt = lifetime +-----------+ 1950 RLC(lt>0)/success 1952 Figure 4: Policy Rule State Machine 1954 This state machine exists per policy rule identifier (PRID). 1955 Initially, all policy rules are in state PRID UNUSED, which means 1956 that the policy rule does not exist or is not active. After 1957 returning to state PRID UNUSED, the policy rule identifier is no 1958 longer bound to an existing policy rule and may be re-used by the 1959 middlebox. 1961 A successful PRR transaction causes a transition from the initial 1962 state PRID UNUSED to state RESERVED, where an address reservation is 1963 established. From there, state ENABLED can be entered by a PER 1964 transaction. This transaction can also be used for entering state 1965 ENABLED directly from state PRID UNUSED without a reservation. In 1966 state ENABLED the requested communication between the internal and 1967 the external endpoint is enabled. 1969 The states RESERVED and ENABLED can be maintained by a successful RLC 1970 transactions with a requested lifetime greater than 0. Transitions 1971 from both of these states back to state PRID UNUSED can be caused by 1972 an ARE transaction or by a successful RLC transaction with a lifetime 1973 parameter of 0. 1975 A failed request transactions does not change state at the middlebox. 1977 Please note, transitions initiated by RLC transactions may also be 1978 initiated by GLC transactions. 1980 2.4. Policy Rule Group Transactions 1982 This section describes the semantics for transactions on groups of 1983 policy rules. These transactions are specified: 1985 - Group Lifetime Change (GLC) 1986 - Group List (GL) 1987 - Group Status (GS) 1989 All are request transactions initiated by the agent. GLC is a 1990 convenience transaction. GL and GS are monitoring transactions that 1991 do not have any effect on the group state machine. 1993 2.4.1. Overview 1995 A policy rule group has only one attribute: the list of its members. 1996 All member policies of a single group must be owned by the same 1997 authenticated agent. Therefore, an implicit property of a group is 1998 its owner, which is the owner of the member policy rules. 2000 A group is created implicitly, when its first member policy rule is 2001 established. A group is terminated implicitly, when the last 2002 remaining member policy rule is terminated. Consequently, the 2003 lifetime of a group is the maximum of the lifetimes of all member 2004 policy rules. 2006 A group has a middlebox-unique identifier. 2008 Group transactions are declared as 'optional' by their respective 2009 compliance entry in Section 3. However, they provide some 2010 functionality, like convenience for the agent in sending only one 2011 request instead of several, that is not available if only mandatory 2012 transactions are available. 2014 The Group Lifetime Change (GLC) transaction is equivalent to 2015 simultaneously performed Policy Rule Lifetime Change (RLC) 2016 transactions on all members of the group. The result of a successful 2017 GLC transaction is that all member policy rules have the same 2018 lifetime. Analogously to the RLC transaction, the GLC transaction 2019 can be use for deleting all member policy rules by requesting a 2020 lifetime of zero. 2022 The monitoring transactions Group List (GL) and Group Status (GS) can 2023 be used by the agent for exploring the state of the middlebox and for 2024 exploring its access rights. The GL transaction lists all groups 2025 that the agent may access, including groups owned by other agents. 2026 The GS transaction reports the status on an individual group and it 2027 lists all policy rules of this group by their policy rule 2028 identifiers. The agent can explore the state of the individual 2029 policy rules by using the policy rule identifiers in a policy rule 2030 status (PRS) transaction (see Section 2.3.12). 2032 The GL and GS transactions are particularly helpful in case of an 2033 agent fail-over. The agent taking over the role of a failed one can 2034 use these transactions for retrieving which policies has been 2035 established by the failed agent. 2037 Notifications on group events are generated analogously to policy 2038 rule events. For notifying agents about group events, the Policy 2039 Rule Group Event Notification (GEN) message type is used. GEN 2040 messages contain an agent-unique notification identifier, the policy 2041 rule group identifier and the remaining lifetime of the group. 2043 2.4.2. Group Lifetime Change (GLC) 2045 transaction-name: group lifetime change 2047 transaction-type: convenience 2049 transaction-compliance: optional 2051 request-parameters: 2053 - request identifier: an agent-unique identifier for matching 2054 corresponding request and reply at the agent. 2056 - group identifier: a reference to the group for which the lifetime 2057 is requested to be changed. 2059 - group lifetime: the new lifetime proposal for the group. 2061 reply-parameters (success): 2063 - request identifier: an identifier matching the identifier of the 2064 request. 2066 - group lifetime: The group lifetime granted by the middlebox. 2068 failure reason: 2069 - transaction not supported 2070 - agent not authorized for this transaction 2071 - agent not authorized for changing lifetime of this group 2072 - no such group 2073 - lifetime cannot be extended 2075 notification message type: Policy Rule Group Event Notification (GEN) 2077 semantics: 2079 The agent can use this transaction type to request an extension of 2080 the lifetime of all members of a policy rule group, to request 2081 shortening the lifetime of all members, or to request termination 2082 of all member policies (which implies termination of the group). 2083 Termination is requested by suggesting a new group lifetime of 2084 zero. 2086 The middlebox first checks whether or not the specified group 2087 exists and whether or not the agent is authorized to access this 2088 group. If one of the checks fails, an appropriate failure reply 2089 is generated. If the requested lifetime is longer than the 2090 current one, the middlebox also checks whether or not the lifetime 2091 of the group may be extended and generates an appropriate failure 2092 message if not. 2094 A failure reply implies that the lifetime of the group remains 2095 unchanged. A success reply is generated by the middlebox if the 2096 lifetime of the group was changed in any way. 2098 The success reply contains the new common lifetime of all member 2099 policy rules of the group. The middlebox chooses the new lifetime 2100 less than or equal to the minimum of the requested lifetime and 2101 the maximum lifetime that the middlebox specified at session setup 2102 together with its other capabilities, i.e.: 2104 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2106 whereas: 2107 - lt_granted is the actually granted lifetime by the middlebox 2108 - lt_requested is the requested lifetime of the agent 2109 - lt_maximum is the maximum lifetime specified at session 2110 setup 2112 After sending a success reply with a lifetime of zero, the member 2113 policy rules will be terminated without any further notification 2114 to the agent, and the middlebox will consider the group and all of 2115 its members to be non-existent. Any further transaction on this 2116 policy rule group or on any of its members results in a negative 2117 reply, indicating that this group or policy rule, respectively, 2118 does not exist anymore. 2120 After the remaining policy rule group lifetime was successfully 2121 changed and the reply message has been sent to the requesting 2122 agent, the middlebox checks if there are other authenticated 2123 agents participating in open sessions, which can access the policy 2124 rule group. If the middlebox finds one or more of these agents, 2125 then it sends a GEN message reporting the new remaining policy 2126 rule group lifetime to each of them. 2128 2.4.3. Group List (GL) 2130 transaction-name: group list 2132 transaction-type: monitoring 2134 transaction-compliance: optional 2136 request-parameters: 2138 - request identifier: an agent-unique identifier for matching 2139 corresponding request and reply at the agent. 2141 reply-parameters (success): 2143 - request identifier: an identifier matching the identifier of the 2144 request. 2146 - group list: list of all groups that the agent can access. For 2147 each listed group the identifier and the owner are indicated. 2149 failure reason: 2150 - transaction not supported 2151 - agent not authorized for this transaction 2153 semantics: 2155 The agent can use this transaction type to list all groups which 2156 it can access. Usually, the agent has this information already, 2157 but in special cases (for example after an agent fail-over) or for 2158 special agents (for example an administrating agent that can 2159 access all groups) this transaction can be helpful. 2161 The middlebox first checks whether or not the agent is authorized 2162 to request this transaction. If the check fails, an appropriate 2163 failure reply is generated. Otherwise a list of all groups the 2164 agent can access is returned indicating the identifier and the 2165 owner of each group. 2167 This transaction does not have any effect on the group state. 2169 2.4.4. Group Status (GS) 2171 transaction-name: group status 2173 transaction-type: monitoring 2175 transaction-compliance: optional 2177 request-parameters: 2179 - request identifier: an agent-unique identifier for matching 2180 corresponding request and reply at the agent. 2182 - group identifier: a reference to the group for which status 2183 information is requested. 2185 reply-parameters (success): 2187 - request identifier: an identifier matching the identifier of the 2188 request. 2190 - group owner: an identifier of the agent owning this policy rule 2191 group. 2193 - group lifetime: the remaining lifetime of the group. This is the 2194 maximum of the remaining lifetime of all members policy rules. 2196 - member list: list of all policy rules that are members of the 2197 group. The policy rules are specified by their middlebox-unique 2198 policy rule identifier. 2200 failure reason: 2201 - transaction not supported 2202 - agent not authorized for this transaction 2203 - no such group 2204 - agent not authorized for listing members of this group 2206 semantics: 2208 The agent can use this transaction type to list all member policy 2209 rules of a group. Usually, the agent has this information 2210 already, but in special cases (for example after an agent fail- 2211 over) or for special agents (for example an administrating agent 2212 that can access all groups) this transaction can be helpful. 2214 The middlebox first checks whether or not the specified group 2215 exists and whether or not the agent is authorized to access this 2216 group. If one of the checks fails, an appropriate failure reply 2217 is generated. Otherwise a list of all group members is returned 2218 indicating the identifier of each group. 2220 This transaction does not have any effect on the group state. 2222 3. Conformance Statements 2224 A protocol definition complies with the semantics defined in Section 2225 2 if the protocol specification includes all specified transactions 2226 with all their mandatory parameters. However, concrete 2227 implementations of the protocol may support only some of the optional 2228 transactions, but not all of them. Which transactions are required 2229 for compliancy is different for agent and middlebox. 2231 This section contains conformance statements for MIDCOM protocol 2232 implementations related to the semantics. Conformance is specified 2233 differently for agents and middleboxes. Most probably these 2234 conformance statements will be extended by a concrete protocol 2235 specification. However, such an extension is expected to extend the 2236 statements below in a way that all of them still hold. 2238 The following list shows the transaction-compliance property of all 2239 transactions as specified in the previous section: 2241 - Session Control Transactions 2242 - Session Establishment (SE) mandatory 2243 - Session Termination (ST) mandatory 2244 - Asynchronous Session Termination (AST) mandatory 2246 - Policy Rule Transactions 2247 - Policy Reserve Rule (PRR) mandatory 2248 - Policy Enable Rule (PER) mandatory 2249 - Policy Rule Lifetime Change (RLC) mandatory 2250 - Policy Rule List (PRL) mandatory 2251 - Policy Rule Status (PRS) mandatory 2252 - Asynchronous Policy Rule Event (ARE) mandatory 2254 - Policy Rule Group Transactions 2255 - Group Lifetime Change (GLC) optional 2256 - Group List (GL) optional 2257 - Group Status (GS) optional 2259 3.1. General Implementation Conformance 2261 A compliant implementation of a MIDCOM protocol must support all 2262 mandatory transactions. 2264 A compliant implementation of a MIDCOM protocol may support none, 2265 one, or more of the following transactions: GLC, GL, GS. 2267 A compliant implementation may extend the protocol semantics by 2268 further transactions. 2270 A compliant implementation of a MIDCOM protocol must support all 2271 mandatory parameters of each transaction concerning the information 2272 contained. The set of parameters can be redefined per transaction as 2273 long as the contained information is maintained. 2275 A compliant implementation of a MIDCOM protocol may support the use 2276 of interface specific policy rules. The optional inside and outside 2277 interface parameters in PRR, PER, and PRS must be included both or 2278 none of them when interface specific policy rules are supported. 2280 A compliant implementation may extend the list of parameters of 2281 transactions. 2283 A compliant implementation may replace a single transaction by a set 2284 of more fine-grained transactions. In such a case, it must be 2285 ensured, that requirement 2.1.4 (deterministic behavior) and 2286 requirement 2.1.5 (known and stable state) of [MDC-REQ] are still 2287 met. When a single transaction is replaced by a set of multiple 2288 fine-grained transactions, this set must be equivalent to a single 2289 transaction. This multiple fine-grained transactions must further 2290 meet the atomicity requirement stated in section 2.1.3. 2292 3.2. Middlebox Conformance 2294 A middlebox implementation of a MIDCOM protocol supports a request 2295 transaction if it is able to receive and process all possible correct 2296 message instances of the particular request transaction and if it 2297 generates a correct reply for any correct request it receives. 2299 A middlebox implementation of a MIDCOM protocol supports an 2300 asynchronous transaction if it is able to generate the corresponding 2301 notification message properly. 2303 A compliant middlebox implementation of a MIDCOM protocol must inform 2304 the agent about the list of supported transactions within the SE 2305 transaction. 2307 3.3. Agent Conformance 2309 An agent implementation of a MIDCOM protocol supports a request 2310 transaction if it is able to generate the corresponding request 2311 message properly and if it is able to receive and process all 2312 possible correct replies to the particular request. 2314 An agent implementation of a MIDCOM protocol supports an asynchronous 2315 transaction if it is able to receive and process all possible correct 2316 message instances of the particular transaction. 2318 A compliant agent implementation of a MIDCOM protocol must not use 2319 any optional transaction that is not supported by the middlebox. The 2320 middlebox informs the agent about the list of supported transactions 2321 within the SE transaction. 2323 4. Transaction Usage Examples 2325 This section gives two usage examples of the transactions specified 2326 in Section 2. First it is shown, how an agent can explore all policy 2327 rules and policy rule groups, which it may access at a middlebox. 2328 the second example shows the configuration of a middlebox in 2329 combination with the setup of a voice over IP session with the 2330 Session Initiation Protocol (SIP) [RFC3261]. 2332 4.1. Exploring Policy Rules and Policy Rule Groups 2334 This example assumes an already established session. It shows how an 2335 agent can find out 2337 - which groups it may access and who owns these groups 2338 - the status and member list of all accessible groups 2339 - the status and properties of all accessible policy rules 2341 If there is just a single session, there is no need for any of these 2342 actions, because the middlebox informs the agent about each state 2343 transition of any policy rule or policy rule group. However, after 2344 the disruption of a session or after an intentional session 2345 termination, the agent might want to re-establish the session and 2346 explore, which of the groups and policy rules it established are 2347 still in place. 2349 Also an agent system may fail and another one takes over. Then the 2350 other one need to find out what has already been configured by the 2351 failing system and what still needs to be done. 2353 A third situation where exploring policy rules and groups is useful 2354 is the case of an agent with 'administrator' authorization. This 2355 agent may access any policy rule or group created by any other agent 2356 and modify them. 2358 All of them probably will start their exploration with the Group List 2359 (GL) transaction, as shown in Figure 5. On this request, the 2360 middlebox returns a list of pairs each containing an agent identifier 2361 and a group identifier (GID). The agent gets informed which own 2362 group and which of other agents' groups it may access. 2364 agent middlebox 2365 | GL | 2366 |**********************************************>| 2367 |<**********************************************| 2368 | (agent1,GID1) (agent1,GID2) (agent2,GID3) | 2369 | | 2370 | GS GID2 | 2371 |**********************************************>| 2372 |<**********************************************| 2373 | agent1 lifetime PID1 PID2 PID3 PID4 | 2374 | | 2376 Figure 5: Using the GL and the GS transaction 2378 In Figure 5 three groups are accessible to the agent, and the agent 2379 retrieves information about the second group by using the Group 2380 Status (GS) transaction. It receives the owner of the group, the 2381 remaining lifetime, and the list of member policy rules, in this case 2382 containing four policy rule identifiers (PIDs). 2384 In the following, the agent explores these four policy rules. The 2385 example assumes the middlebox to be a traditional NAPT. Figure 6 2386 shows the exploration of the first policy rule. As reply to a Policy 2387 Rule Status (PRS) transaction, the middlebox always returns the 2388 following list of parameters: 2390 - policy rule owner 2391 - group identifier 2392 - policy rule action (reserve or enable) 2393 - protocol type 2394 - port range 2395 - direction 2396 - internal IP address 2397 - internal port number 2398 - external address 2399 - external port number 2400 - middlebox inside IP address 2401 - middlebox inside port number 2402 - middlebox outside IP address 2403 - middlebox outside port number 2404 - IP address versions (not printed) 2405 - middlebox service (not printed) 2406 - inside and outside interface (optional, not printed) 2407 agent middlebox 2408 | PRS PID1 | 2409 |**********************************************>| 2410 |<**********************************************| 2411 | agent1 GID2 RESERVE UDP 1 | 2412 | ANY ANY ANY ANY | 2413 | ANY ANY IPADR_OUT PORT_OUT1 | 2414 | | 2416 Figure 6: Status report for an outside reservation 2418 The `ANY' parameter printed in Figure 6 is used as a placeholder in 2419 policy rules status replies for policy reserve rules. The policy 2420 rule with PID1 is a policy reserve rule for UDP traffic at the 2421 outside of the middlebox. Since there is no internal or external 2422 address involved yet, these four fields are wildcarded in the reply. 2423 The same holds for the inside middlebox address and port number. The 2424 only address information given by the reply is the reserved outside 2425 IP address of the middlebox (IPADDR_OUT) and the corresponding port 2426 number (PORT_OUT1). Note, that IPADR_OUT and PORT_OUT1 may not be 2427 wildcarded, because the reserve action does not support this. 2429 Applying PRS to PID2 (Figure 7) shows that the second policy rule is 2430 an policy enable rule for inbound UDP packets. The internal 2431 destination is fixed concerning IP address, protocol and port number, 2432 but for the external source, the port number is wildcarded. The 2433 outside IP address and port number of the middlebox are the ones the 2434 external sender needs to use as destination in the original packet it 2435 sends. At the middlebox, the destination address is replaced with 2436 the internal address of the final receiver. During address 2437 translation, the source IP address and the source port numbers of the 2438 packets remain unchanged. This is indicated by the inside address 2439 which is identical to the external address. 2441 agent middlebox 2442 | PRS PID2 | 2443 |**********************************************>| 2444 |<**********************************************| 2445 | agent1 GID2 ENABLE UDP 1 IN | 2446 | IPADR_INT PORT_INT1 IPADR_EXT ANY | 2447 | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | 2448 | | 2450 Figure 7: Status report for enabled inbound packets 2452 For traditional NATs the identity of the inside IP address and port 2453 number with the external IP address and port number always holds 2454 (A1=A3 in Figure 3). For a pure firewall, also the outside IP 2455 address and port number are always identical with the internal IP 2456 address and port number (A0=A2 in Figure 3). 2458 agent middlebox 2459 | PRS PID3 | 2460 |**********************************************>| 2461 |<**********************************************| 2462 | agent1 GID2 ENABLE UDP 1 OUT | 2463 | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | 2464 | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | 2465 | | 2467 Figure 8: Status report for enabled outbound packets 2469 Figure 8 shows enabled outbound UDP communication between the same 2470 host. Here all port numbers are known. Since again A1=A3, the 2471 internal sender uses the external IP address and port number as 2472 destination in the original packets. At the firewall, the internal 2473 source IP address and port number are replaced by the shown outside 2474 IP address and port number of the middlebox. 2476 agent middlebox 2477 | PRS PID4 | 2478 |**********************************************>| 2479 |<**********************************************| 2480 | agent1 GID2 ENABLE TCP 1 BI | 2481 | IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 | 2482 | IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 | 2483 | | 2485 Figure 9: Status report for bi-directional TCP traffic 2487 Finally, Figure 9 shows the status report for enabled bi-directional 2488 TCP traffic. Please note that still A1=A3: For outbound packets, only 2489 the source IP address and port number are replaced at the middlebox, 2490 and for inbound packets, only the destination IP address and port 2491 number are replaced. 2493 4.2. Enabling a SIP-Signaled Call 2495 This elaborated transaction usage example shows the interaction 2496 between a SIP proxy and a middlebox. The middlebox itself is a 2497 traditional Network Address and Port Translation (NAPT) and two SIP 2498 user agents communicate with each other via the SIP proxy and NAPT as 2499 shown in figure 10. The MIDCOM agent is co-located with the SIP 2500 proxy and the MIDCOM server is at the middlebox. Thus the MIDCOM 2501 protocol runs between the SIP proxy and middlebox 2502 +-------------+ 2503 | SIP Proxy | 2504 | for domain ++++ 2505 | example.com | + 2506 +-------------+ + 2507 ^ ^ + 2508 Private | | + Public Network 2509 Network | | + 2510 +----------+ | | +----+------+ +----------------+ 2511 | SIP User |<-+ +->| Middlebox |<------->| SIP User Agent | 2512 | Agent A |<#######>| NAPT |<#######>| B@example.org | 2513 +----------+ +-----------+ +----------------+ 2515 <--> SIP Signaling 2516 <##> RTP Traffic 2517 ++++ MIDCOM protocol 2519 Figure 10: Example SIP Scenario 2521 For the below sequence charts we make these assumptions: 2523 - The NAPT is statically configured to forward SIP signaling from 2524 the outside to the SIP proxy server, i.e. traffic to the NAPT's 2525 external IP address and port 5060 is forwarded to the internal 2526 SIP proxy. 2528 - The SIP user agent A, located inside the private network, is 2529 registered at the SIP proxy with its private IP address. 2531 - User A knows the general SIP URL of user B. The URL is 2532 B@xample.org. However, the concrete URL of the SIP User Agent B, 2533 which user B currently uses is not known. 2535 - Only the RTP paths are configured, but not the RTCP paths. 2537 - The middlebox and the SIP server share an already established 2538 MIDCOM session. 2540 - Some parameters are omitted, like the request identifier (RID) 2542 Furthermore these abbreviations are used: 2544 - IP_AI: Internal IP address of user agent A 2545 - P_AI: Internal port number of user agent A to receive RTP data 2546 - P_AE: External mapped port number of user agent A 2547 - IP_AE: External IP address of the middlebox 2548 - IP_B: IP address of user agent B 2549 - P_B: Port number of user agent B to receive RTP data 2550 - GID: Group identifier 2551 - PID: Policy rule identifier 2553 The abbreviations of the MIDCOM transactions can be found in the 2554 particular section headings. 2556 In our example, user A tries to call user B. Therefore, the user 2557 agent A sends an INVITE SIP message to the SIP proxy server (see 2558 Figure 10). The SDP part of the particular SIP message that is 2559 relevant for the middlebox configuration is shown in the sequence 2560 chart as: 2562 SDP: m=..P_AI.. 2563 c=IP_AI 2565 where the m tag is the media tag which contains the receiving UDP 2566 port number and the c tag contains the IP address of the terminal 2567 receiving the media stream. 2569 The INVITE message forwarded to user agent B must contain a public IP 2570 address and a port number to which user agent B can send its RTP 2571 media stream. The SIP proxy requests a policy enable rule at the 2572 middlebox with a PER request with wildcarded IP address and port 2573 number of user agent B. Since neither IP address nor port numbers of 2574 user agent B are known at this point of time, the address of user 2575 agent B must be wildcarded. The wildcarded IP address and port 2576 number enables the 'early media' capability, but results in some 2577 insecurity, since any outside host can reach user agent A on the 2578 enabled port number through the middlebox. 2580 User Agent SIP Middlebox User Agent 2581 A Proxy NAPT B 2582 | | | | 2583 | INIVTE | | | 2584 | B@example.org | | | 2585 | SDP:m=..P_AI.. | | | 2586 | c=IP_AI | | | 2587 |--------------->| | | 2588 | | | | 2589 | | PER PID1 UDP 1 EVEN IN | | 2590 | | IP_AI P_AI ANY ANY 300s | | 2591 | |*****************************>| | 2592 | |<*****************************| | 2593 | | PER OK GID1 PID1 ANY ANY | | 2594 | | IP_AE P_AE1 300s | | 2596 Figure 11: PER with wildcard address and port number 2598 A successfully PER reply, as shown in Figure 11, results in a NAT 2599 binding at the middlebox. This binding enables UDP traffic from any 2600 host outside of user agent A's private network to reach user agent 2601 A. So user agent B could start sending traffic immediately after 2602 receiving the INVITE message, and so can do any other host. Even 2603 hosts that are not intended to be a participant, like any malicious 2604 host. 2606 In the case the middlebox does not support or does not permit IP 2607 address wildcarding for security reasons, the PER request will be 2608 rejected with an appropriate failure reason, like 'IP wildcarding not 2609 supported'. Nevertheless, the SIP proxy server needs an outside IP 2610 address and port number at the middlebox (the NAPT) in order to 2611 forward the SIP INVITE message. 2613 The IP address of user agent B is still not known yet (it will be 2614 sent by user agent B in the SIP reply message) and IP address 2615 wildcarding is not permitted, the SIP proxy server uses the PRR 2616 transaction. 2618 By using the PRR request the SIP proxy requests an outside IP address 2619 and port number (see Figure 12) without already establishing a NAT 2620 binding or pin hole. The PRR request contains the service parameter 2621 'tw', i.e. the MIDCOM agent chooses the default value. In this 2622 configuration, NAPT and no twice NAT, only an outside address is 2623 reserved. The SIP proxy server replaces in the SDP payload of the 2624 INVITE message the IP address and port number of user agent A by the 2625 reserved IP address and port from PRR reply (see Figure 12). The SIP 2626 INVITE message is forwarded to user agent B with a modified SDP body 2627 containing the outside address and port number, to which user agent B 2628 will send its RTP media stream. 2630 User Agent SIP Middlebox User Agent 2631 A Proxy NAPT B 2632 | | | | 2633 ...PER in Figure 11 has failed, continuing with PRR ... 2634 | | | | 2635 | |PRR tw v4 v4 A UDP 1 EVEN 300s| | 2636 | |*****************************>| | 2637 | |<*****************************| | 2638 | | PRR OK PID1 GID1 EMPTY | | 2639 | | IP_AE/P_AE 300s | | 2640 | | | | 2641 | | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE | 2642 | |-------------------------------------------->| 2643 | |<--------------------------------------------| 2644 | | 200 OK SDP:m=..P_B.. c=IP_B | 2646 Figure 12: Address reservation with PRR transaction 2648 This SIP `200 OK' reply contains the IP address and port number, at 2649 which user agent B will receive a media stream. The IP address is 2650 assumed to be equal to the IP address from which user agent B will 2651 send its media stream. 2653 Now, the SIP proxy server has sufficient information for establishing 2654 the complete NAT binding with a policy enable rule (PER) transaction, 2655 i.e. the UDP/RTP data of the call can flow from user agent B to user 2656 agent A. The PER transaction references the reservation by passing 2657 the PID of the PRR (PID1). 2659 For the opposite direction, UDP/RTP data from user agent A to B, has 2660 to be enabled also. This is done by a second PER transaction with 2661 all the necessary parameters (see figure 13). The request message 2662 contains the group identifier (GID1) the middlebox has assigned in 2663 the first PER transaction. Therefore, both policy rules have become 2664 members of the same group. After having enabled both UDP/RTP streams 2665 the SIP proxy can forward the `200 OK' SIP message to user agent A to 2666 indicate that the telephone call can start. 2668 User Agent SIP Middlebox User Agent 2669 A Proxy NAPT B 2670 | | | | 2671 | | PER PID1 UDP 1 SAME IN | | 2672 | | IP_AI P_AI IP_B ANY 300s | | 2673 | |*****************************>| | 2674 | |<*****************************| | 2675 | | PER OK GID1 PID1 IP_B ANY | | 2676 | | IP_AE P_AE1 300s | | 2677 | | | | 2678 ...media stream from user agent B to A enabled... 2679 | | | | 2680 | | PER GID1 UDP 1 SAME OUT | | 2681 | | IP_AI ANY IP_B P_B 300s | | 2682 | |*****************************>| | 2683 | |<*****************************| | 2684 | | PER OK GID1 PID2 IP_B P_B | | 2685 | | IP_AE P_AE2 300s | | 2686 | | | | 2687 ...media streams from both directions enabled... 2688 | | | | 2689 | 200 OK | | | 2690 |<---------------| | | 2691 | SDP:m=..P_B.. | | | 2692 | c=IP_B | | | 2694 Figure 13: Policy rule establishment for UDP flows 2696 User agent B decides to terminate the call and sends its `BYE' SIP 2697 message to user agent A. The SIP proxy forwards all SIP messages and 2698 terminates the group afterwards using a group lifetime change (GLC) 2699 transaction with a requested remaining lifetime of 0 seconds (see 2700 Figure 14). Termination of the group includes terminating all member 2701 policy rules. 2703 User Agent SIP Middlebox User Agent 2704 A Proxy NAPT B 2705 | | | | 2706 | BYE | BYE | 2707 |<---------------|<--------------------------------------------| 2708 | | | | 2709 | 200 OK | 200 OK | 2710 |--------------->|-------------------------------------------->| 2711 | | | | 2712 | | GLC GID1 0s | | 2713 | |*****************************>| | 2714 | |<*****************************| | 2715 | | GLC OK 0s | | 2716 | | | | 2717 ...both NAT bindings for the media streams are removed... 2719 Figure 14: Termination of Policy Rule Groups 2721 5. Compliance with MIDCOM Requirements 2723 This section explains the compliance of the specified semantics with 2724 the MIDCOM requirements. It is structured according to [MDC-REQ]: 2725 - Compliance with Protocol Machinery Requirements (Section 5.1) 2726 - Compliance with Protocol Semantics Requirements (Section 5.2) 2727 - Compliance with Security Requirements (Section 5.3) 2729 The requirements are referred to using the section number they are 2730 defined in: "requirement x.y.z" refers to the requirement specified 2731 in section x.y.z of [MDC-REQ]. 2733 5.1. Protocol Machinery Requirements 2735 5.1.1. Authorized Association 2737 The specified semantics enable a MIDCOM agent to establish an 2738 authorized association between itself and the middlebox. The agent 2739 identifies itself by the authentication mechanism of the Session 2740 Establishment transaction described in Section 2.2.1. Based on this 2741 authentication the middlebox can make a determination as to whether 2742 or not the agent will be permitted to request a service. Thus, 2743 requirement 2.1.1 is met. 2745 5.1.2. Agent connects to Multiple Middleboxes 2747 As specified in Section 2.2, the MIDCOM protocol allows the agent to 2748 communicate with more than one middlebox simultaneously. The 2749 selection of a mechanism for separating different sessions is left to 2750 the concrete protocol definition. It must provide a clear mapping of 2751 protocol messages to open sessions. Then requirement 2.1.2 is met. 2753 5.1.3. Multiple Agents connect to same Middlebox 2755 As specified in Section 2.2, the MIDCOM protocol allows the middlebox 2756 to communicate with more than one agent simultaneously. The 2757 selection of a mechanism for separating different sessions is left to 2758 the concrete protocol definition. It must provide a clear mapping of 2759 protocol messages to open sessions. Then requirement 2.1.3 is met. 2761 5.1.4. Deterministic Behavior 2763 Section 2.1.2 states, that processing a request of an agent may not 2764 be interrupted by any request of the same or another agent. This 2765 provides atomicity among request transactions. This avoids race 2766 conditions resulting in an unpredictable behavior of the middlebox. 2768 Anyway, the behavior of the middlebox can only be predictable in the 2769 view of its administrators. In the view of an agent, the middlebox 2770 behavior is unpredictable, because the administrator can, for example 2771 at any time modify the authorization of the agent without the agent 2772 being able to observe this change. Consequently, the behavior of the 2773 middlebox is not necessarily deterministic from the point of view of 2774 any agent. 2776 Since predictability of the middlebox behavior is given for its 2777 administrator, requirement 2.1.4 is met. 2779 5.1.5. Known and Stable State 2781 Section 2.1 states that request transactions are atomic with respect 2782 to each other and from the point of view of an agent. All 2783 transactions are defined clearly as state transitions that either 2784 leave the current stable and well defined state and enter a new 2785 stable and well defined one or that remain in the current stable and 2786 well defined state. Section 2.1 clearly demands that intermediate 2787 states are not stable and not reported to any agent. 2789 Furthermore, for each state transition a message is sent to the 2790 corresponding agent, either a reply or a notification. The agent can 2791 uniquely map each reply to one of the requests that it sent to the 2792 middlebox, because request agent-unique request identifiers are used 2793 for this purpose. Notifications are self-explanatory by their 2794 definition. 2796 Furthermore, the Group List transaction (Section 2.4.3), the Group 2797 Status transaction (Section 2.4.4), the Policy Rule List transaction 2798 (Section 2.3.11), and the Policy Rule Status transaction (Section 2799 2.3.12) allow the agent at any time during a session to retrieve 2800 information about 2801 - all policy rule groups it may access, 2802 - the status and member policy rules of all accessible groups, 2803 - all policy rules it may access, 2804 - and the status of all accessible policy rules. 2806 Therefore, the agent is precisely informed about the state of the 2807 middlebox (as far as the services requested by the agent are 2808 affected) and requirement 2.1.5 is met. 2810 5.1.6. Status Report 2812 As argued in the previous section, the middlebox unambiguously 2813 informs the agent about every state transition related to any of the 2814 services requested by the agent. Also the agent can at any time 2815 retrieve full status information about all accessible policy rules 2816 and policy rule groups. Thus, requirement 2.1.6 is met. 2818 5.1.7. Unsolicited Messages (Asynchronous Notifications) 2820 The semantics include asynchronous notifications messages from the 2821 middlebox to the agent, including the Session Termination 2822 Notification message, the Policy Rule Event Notification (REN) 2823 message and the Group Event Notification (GEN) message (see Section 2824 2.1.2). These notifications report every change of state of policy 2825 rules or policy rule groups, that was not explicitly requested by the 2826 agent. Thus, requirement 2.1.7 is met by the semantics specified 2827 above. 2829 5.1.8. Mutual Authentication 2831 As specified in Section 2.2.1, the semantics require mutual 2832 authentication of agent and middlebox, either by using two subsequent 2833 Session Establishment transactions or by using mutual authentication 2834 provided on a lower protocol layer. Thus, requirement 2.1.8 is met. 2836 5.1.9. Session Termination by any Party 2838 The semantics specification states in Section 2.2.2 that the agent 2839 may request session termination by generating the Session Termination 2840 request and that the middlebox may not reject this request. In turn, 2841 Section 2.2.3 states that the middlebox may send the Asynchronous 2842 Session Termination notification at any time and then terminate the 2843 session. Thus, requirement 2.1.9 is met. 2845 5.1.10. Request Result 2847 Section 2.1 states that each request of an agent is followed by a 2848 reply of the middlebox indicating either success of failure. Thus, 2849 requirement 2.2.10 is met. 2851 5.1.11. Version Interworking 2853 Section 2.2.1 states that the agent need to specify the protocol 2854 version number which it is going to use during the session. The 2855 middlebox may accept this and act according to this protocol version 2856 or reject the session if it does not support this version. If the 2857 session setup gets rejected, the agent may try again with another 2858 version. Thus, requirement 2.2.11 is met. 2860 5.1.12. Deterministic Handling of Overlapping Rules 2862 The only policy rule actions specified are 'reserve' and 'enable'. 2863 For firewalls, overlapping enable actions or reserve actions do not 2864 create any conflict, so a firewall will always accept overlapping 2865 rules as specified in Section 2.3.2 (assuming the required 2866 authorization is given). 2868 For NATs reserve and enable may conflict. If a conflicting request 2869 arrives, it is rejected, as stated in Section 2.3.2. If an 2870 overlapping request arrives that does not conflict with the ones it 2871 overlaps, it is accepted (assuming the required authorization is 2872 given). 2874 Therefore, the behavior of the middlebox in the presence of 2875 overlapping rules can be predicted deterministically, and requirement 2876 2.1.12 is met. 2878 5.2. Protocol Semantics Requirements 2880 5.2.1. Extensible Syntax and Semantics 2882 Requirement 2.2.1 explicitly requests extensibility of protocol 2883 syntax. This needs to be addressed by the concrete protocol 2884 definition. The semantics specification is extensible anyway, 2885 because new transaction may be added. 2887 5.2.2. Policy Rules for Different Types of Middleboxes 2889 Section 2.3 explains that the semantics use identical transactions 2890 for all middlebox types and that the same policy rule can be applied 2891 to all of them. Thus requirement 2.2.2 is met. 2893 5.2.3. Ruleset Groups 2895 The semantics explicitly supports grouping of policy rules and 2896 transactions on policy rule groups, as described in Section 2.4. The 2897 group transactions can be used for lifetime extension and termination 2898 of all policy rules being member of the particular group. Thus, 2899 requirement 2.2.3 is met. 2901 5.2.4. Policy Rule Lifetime Extension 2903 The semantics include a transaction for explicit lifetime extension 2904 of policy rules, as described in Section 2.3.3. Thus requirement 2905 2.2.4 is met. 2907 5.2.5. Robust Failure Modes 2909 The state transitions at the middlebox are clearly specified and 2910 communicated to the agent. There is no intermediate state reached by 2911 a partial processing of a request. All requests are always processed 2912 completely, either successful or unsuccessful. All request 2913 transaction include a list of failure reasons. These failure reasons 2914 cover indication of invalid parameters where applicable. In case of 2915 failure one of the specified reasons is returned from the middlebox 2916 to the agent. Thus requirement 2.2.5 is met. 2918 5.2.6. Failure Reasons 2920 The semantics include a failure reason parameter in each failure 2921 reply. Thus requirement 2.2.6 is met. 2923 5.2.7. Multiple Agents Manipulating Same Policy Rule 2925 As specified in Sections 2.3 and 2.4, each installed policy rule and 2926 policy rule group has an owner, which is the authenticated agent that 2927 created the policy rule or group, respectively. The authenticated 2928 identity is input to authorization of access to policy rules and 2929 groups. 2931 If the middlebox is sufficiently configurable, its administrator can 2932 configure it such that one authenticated agent is authorized to 2933 access and modify policy rules and groups owned by another agent. 2934 Because specified semantics does not preclude this, it meets 2935 requirement 2.2.7. 2937 5.2.8. Carrying Filtering Rules 2939 The Policy Enable Rule transaction specified in Section 2.3.8 can 2940 carry 5-tuple filtering rules. It meets requirement 2.2.8. 2942 5.2.9. Parity of Port Numbers 2944 As specified in Section 2.3.6, the agent is able to request keeping 2945 the port parity when reserving port numbers with the PRR transaction 2946 (see Section 2.3.8) and when establishing address bindings with the 2947 PER transaction (see Section 2.3.9). Thus requirement 2.2.9 is met. 2949 5.2.10. Consecutive Range of Port Numbers 2951 As specified in Section 2.3.6, the agent is able to request a 2952 consecutive range of port numbers when reserving port numbers with 2953 the PRR transaction (see Section 2.3.8) and when establishing address 2954 bindings or pinholes with the PER transaction (see Section 2.3.9). 2955 Thus requirement 2.2.10 is met. 2957 5.2.11. Contradicting Overlapping Policy Rules 2959 Requirement 2.2.11 is based on the assumption that contradicting 2960 policy rule actions, such as 'enable'/'allow' and 2961 'disable'/'disallow' are supported. In conformance with decisions 2962 made by the working group after finalizing the requirements document, 2963 this requirement is not met by the semantics, because no 2964 'disable'/'disallow' action is supported. 2966 5.3. Security Requirements 2968 5.3.1. Authentication, Confidentiality, Integrity 2970 The semantics definition support mutual authentication of agent and 2971 middlebox in the Session Establishment transaction (Section 2.2.1). 2972 The use of an underlying protocol like TLS or IPsec is mandatory. 2973 Thus requirement 2.3.1 is met. 2975 5.3.2. Optional Confidentiality of Control Messages 2977 The use of IPsec or TLS allows agent and middlebox to use an 2978 encryption method (including no encryption). Thus requirement 2.3.2 2979 is met. 2981 5.3.3. Operation across Un-trusted Domains 2983 Operation across untrusted domains is supported by mutual 2984 authentication and by the use of TLS or IPsec protection. Thus 2985 requirement 2.3.3 is met. 2987 5.3.4. Mitigate Replay Attacks 2989 The specified semantics mitigates replay attacks and meets 2990 requirement 2.3.4 by requiring mutual authentication of agent and 2991 middlebox, and by mandating the use of TLS or IPsec protection. 2993 Further mitigation can be provided as part of a concrete MIDCOM 2994 protocol definition, for example by requiring consecutively 2995 increasing numbers for request identifiers. 2997 6. Security Considerations 2999 The interaction between a middlebox and an agent is (see [MDC-FRM]) a 3000 very sensitive point with respect to security. The configuration of 3001 policy rules from a middlebox external entity appears to be 3002 contradicting the nature of a middlebox. Therefore, effective means 3003 have to be used to ensure: 3004 - mutual authentication between agent and middlebox 3005 - authorization 3006 - message integrity 3007 - message confidentiality 3009 The semantics define a mechanism to ensure mutual authentication 3010 between agent and middlebox (see section 2.2.1). In combination with 3011 the authentication, the middlebox is able to decide whether an agent 3012 is authorized to request an action at the middlebox or not. The 3013 semantics rely on underlying protocols, like TLS or IPsec, to keep 3014 the message integrity and confidentiality of the transferred data 3015 between both entities. 3017 For the TLS and IPsec use, both sides must use securely-configured 3018 credentials for authentication and authorization. 3020 The configuration of policy rules with wildcarded IP addresses and 3021 port numbers results in certain risks, like opening too much 3022 wildcarded policy rules. A too much wildcarded policy rule is A0 and 3023 A3 with IP address set to 'any' IP address for instance. This type 3024 of pin-hole would render the middlebox, in the sense of security, 3025 useless, since any packet can traverse the middlebox without further 3026 checking. The local policy of the middlebox should reject such policy 3027 rule enable requests. 3029 A reasonable default configuration for wildcarding would be that only 3030 one port number may be wildcarded and all IP addresses must be set 3031 without wildcarding. However, there are some cases where security 3032 needs to be balanced with functionality. 3034 The example described in Section 4.2 shows how SIP-signaled calls can 3035 be served in a secure way without wildcarding IP addresses. But some 3036 SIP-signaled applications make use of early media (see Section 5.5 of 3037 [RFC3398]). For receiving early media, the middleboxes need to be 3038 configured before the second participant in a session is known. 3039 Since it is not known, the IP address of the second participant needs 3040 to be wildcarded. 3042 In such cases and in several similar cases, there is a security 3043 policy decision to be made by the middlebox operator. The operator 3044 can configure the middlebox such that it supports more functionality, 3045 for example, by allowing wildcarded IP addresses, or the operator can 3046 configure the middlebox such that network operation is more secure, 3047 for example, by disallowing wildcarded IP addresses. 3049 7. IAB Considerations on UNSAF 3051 UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as 3052 process at originating endpoints that attempt to determine or fix the 3053 address (and port) by which it is known to another endpoint. UNSAF 3054 proposals, like STUN [RFC3489], are considered as a general class of 3055 workarounds for NAT traversal and as solutions for scenarios with no 3056 middlebox communication (MIDCOM). 3058 This document describes the protocol semantics for such a middlebox 3059 communication (MIDCOM) solution. MIDCOM is not intended as short 3060 term workaround, but more as long term solution for middlebox 3061 communication. In MIDCOM, endpoints are not involved in allocating, 3062 maintaining, and deleting addresses and ports at the middlebox. The 3063 full control of addresses and ports at the middlebox is located at 3064 the MIDCOM server. 3066 Therefore, this document addresses the UNSAF considerations in 3067 [RFC3424] by proposing a longterm alternative solution. 3069 8. Acknowledgments 3071 We like to thank all the people contributing to the semantics 3072 discussion on the mailing list for a lot of valuable comments. 3074 9. References 3076 9.1. Normative References 3078 [MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., 3079 Rayhan, A., "Middlebox Communication Architecture and 3080 Framework", RFC 3303, August 2002 3082 [MDC-REQ] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M., 3083 "Middlebox Control (MIDCOM) Protocol Architecture and 3084 Requirements", RFC 3304, August 2002 3086 [NAT-TERM] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) 3087 Terminology and Considerations", RFC 2663, August 1999. 3089 [NAT-TRAD] Srisuresh,P., and Egevang, K., "Traditional IP Network 3090 Address Translator (Traditional NAT)", RFC 3022, January 3091 2001 3093 9.2. Informative References 3095 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 3096 2246, January 1999. 3098 [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 3099 2402, November 1998. 3101 [RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security 3102 Payload (ESP)", RFC 2406, November 1998. 3104 [RFC3198] Westerinen, A. et al., "Terminology for Policy-Based 3105 Management", RFC 3198, November 2001. 3107 [RFC3261] Rosenberg, J. et al., "SIP: Session Initiation Protocol", 3108 RFC 3261, June 2002. 3110 [RFC3398] Camarillo, G. et al., "Integrated Services Digital Network 3111 (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) 3112 Mapping", RFC 3398, Decembe 2002. 3114 [RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address 3115 Fixing (UNSAF) Across Network Address Translation", RFC 3116 3424, November 2002. 3118 [RFC3489] Rosenberg, J., et al., "STUN - Simple Traversal of User 3119 Datagram Protocol (UDP) Through Network Address Translators 3120 (NATs)", RFC 3489, March 2003. 3122 10. Authors' Addresses 3124 Martin Stiemerling 3125 NEC Europe Ltd. 3126 Network Laboratories 3127 Kurfuersten-Anlage 36 3128 69115 Heidelberg 3129 Germany 3131 Phone: +49 6221 90511-13 3132 Email: stiemerling@netlab.nec.de 3133 Juergen Quittek 3134 NEC Europe Ltd. 3135 Network Laboratories 3136 Kurfuersten-Anlage 36 3137 69115 Heidelberg 3138 Germany 3140 Phone: +49 6221 90511-15 3141 EMail: quittek@netlab.nec.de 3143 Tom Taylor 3144 Nortel Networks 3145 1852 Lorraine Ave. 3146 Ottawa, Ontario 3147 Canada K1H 6Z8 3149 Phone: +1 613 736 0961 3150 Email: taylor@nortelnetworks.com 3152 11. Full Copyright Statement 3154 Copyright (C) The Internet Society (2004). All Rights Reserved. 3156 This document and translations of it may be copied and furnished to 3157 others, and derivative works that comment on or otherwise explain it 3158 or assist in its implementation may be prepared, copied, published 3159 and distributed, in whole or in part, without restriction of any 3160 kind, provided that the above copyright notice and this paragraph are 3161 included on all such copies and derivative works. However, this 3162 document itself may not be modified in any way, such as by removing 3163 the copyright notice or references to the Internet Society or other 3164 Internet organizations, except as needed for the purpose of 3165 developing Internet standards in which case the procedures for 3166 copyrights defined in the Internet Standards process must be 3167 followed, or as required to translate it into languages other than 3168 English. 3170 The limited permissions granted above are perpetual and will not be 3171 revoked by the Internet Society or its successors or assigns. 3173 This document and the information contained herein is provided on an 3174 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3175 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3176 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3177 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3178 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.