idnits 2.17.1 draft-stiemerling-midcom-semantics-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2403 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 (August 2002) is 7924 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) == Unused Reference: 'NAT-TERM' is defined on line 2357, but no explicit reference was found in the text ** 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') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Stiemerling 2 Document: draft-stiemerling-midcom-semantics-02.txt J. Quittek 3 Expires: February 2003 NEC Europe Ltd. 5 August 2002 7 MIDCOM Protocol Semantics 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this document is unlimited. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This memo specifies semantics for a Middlebox Communication (MIDCOM) 39 protocol to be used by MIDCOM agents for interacting with 40 middleboxes, such as firewalls and NATs. The semantics discussion 41 does not include any specification of a concrete syntax or a 42 transport protocol. However, a concrete protocol is expected to 43 implement the specified semantics or a superset of it. The MIDCOM 44 protocol semantics is derived from the MIDCOM requirements, from the 45 MIDCOM framework, and from working group decisions. 47 Table of Contents 49 1 Introduction ................................................. 2 50 1.1 Terminology ................................................ 3 51 1.2 Transaction Definition Template ............................ 3 52 2 Semantics Specification ...................................... 5 53 2.1 General Protocol Design .................................... 5 54 2.1.1 Session, Policy, and Policy Group ........................ 5 55 2.1.2 Atomicity ................................................ 5 56 2.1.3 Access Control ........................................... 6 57 2.1.4 Conformance .............................................. 6 58 2.2 Session Control Transactions ............................... 7 59 2.2.1 Session Establishment (SE) ............................... 7 60 2.2.2 Session Termination (ST) ................................. 9 61 2.2.3 Asynchronous Session Termination (AST) ................... 10 62 2.2.4 Session Termination by Interruption of Connection ........ 11 63 2.2.5 Session State Machine .................................... 11 64 2.3 Policy Group Transactions .................................. 12 65 2.3.1 Group Establishment (GE) ................................. 13 66 2.3.2 Group Lifetime Change (GLC) .............................. 14 67 2.3.3 Group List (GL) .......................................... 15 68 2.3.4 Group Status (GS) ........................................ 16 69 2.3.5 Asynchronous Group Deletion (AGD) ........................ 17 70 2.3.6 Group State Machine ...................................... 18 71 2.4 Policy Rule Transactions ................................... 19 72 2.4.1 Policy Reserve Rule (PRR) ................................ 20 73 2.4.2 Policy Allow Rule (PAR) .................................. 23 74 2.4.3 Policy Lifetime Change (PLC) ............................. 27 75 2.4.4 Policy Status (PS) ....................................... 28 76 2.4.5 Asynchronous Policy Deletion (APD) ....................... 31 77 2.4.6 Policy Rule State Machine ................................ 31 78 3 Conformance Statements ....................................... 32 79 3.1 General Implementation Conformance ......................... 33 80 3.2 Middlebox Conformance ...................................... 33 81 3.3 Agent Conformance .......................................... 34 82 4 Transaction Usage Examples ................................... 34 83 4.1 Exploring Policies and Policy Groups ....................... 34 84 4.2 Enabling a SIP-Signaled Call ............................... 38 85 5 Compliance with MIDCOM Requirements .......................... 42 86 5.1 Protocol Machinery Requirements ............................ 42 87 5.1.1 Authorized Association ................................... 42 88 5.1.2 Agent connects to Multiple Middleboxes ................... 42 89 5.1.3 Multiple Agents connect to same Middlebox ................ 43 90 5.1.4 Deterministic Behavior ................................... 43 91 5.1.5 Known and Stable State ................................... 43 92 5.1.6 Status Report ............................................ 44 93 5.1.7 Unsolicited Messages (Asynchronous Notifications) ........ 44 94 5.1.8 Mutual Authentication .................................... 44 95 5.1.9 Session Termination by any Party ......................... 44 96 5.1.10 Request Result .......................................... 44 97 5.1.11 Version Interworking .................................... 45 98 5.1.12 Deterministic Handling of Overlapping Rules ............. 45 99 5.2 Protocol Semantics Requirements ............................ 45 100 5.2.1 Extensible Syntax and Semantics .......................... 45 101 5.2.2 Policy Rules for Different Types of Middleboxes .......... 45 102 5.2.3 Ruleset Groups ........................................... 45 103 5.2.4 Policy Lifetime Extension ................................ 46 104 5.2.5 Robust Failure Modes ..................................... 46 105 5.2.6 Failure Reasons .......................................... 46 106 5.2.7 Multiple Agents Manipulating Same Policy ................. 46 107 5.2.8 Carrying Filtering Rules ................................. 46 108 5.2.9 Oddity of Port Numbers ................................... 46 109 5.2.10 Consecutive Range of Port Numbers ....................... 46 110 5.2.11 Contradicting Overlapping Policies ...................... 47 111 5.3 Security Requirements ...................................... 47 112 5.3.1 Authentication, Confidentiality, Integrity ............... 47 113 5.3.2 Optional Confidentiality of Control Messages ............. 47 114 5.3.3 Operation across Un-trusted Domains ...................... 47 115 5.3.4 Mitigate Replay Attacks .................................. 47 116 6 Security Considerations ...................................... 47 117 7 Acknowledgments .............................................. 48 118 8 Open Issues .................................................. 48 119 9 Acknowledgements ............................................. 48 120 10 References .................................................. 48 121 11 Authors' Address ............................................ 49 122 12 Full Copyright Statement .................................... 49 124 1. Introduction 126 The MIDCOM working group has defined a framework [MDC-FRM] for the 127 middle box communication as well as a list of requirements [MDC-REQ]. 128 But for specifying a concrete protocol, the clear semantics need to 129 be defined. The documents mentioned above are not completely 130 sufficient for this purpose. Some required capabilities are not 131 mentioned explicitly in the framework or requirements document, but 132 are inherent to the problem. 134 This memo suggests a semantics for the MIDCOM protocol. It is fully 135 compliant with the requirements listed in [MDC-REQ] and with the 136 working groups consensus on semantical issues. 138 In conformance with the working group charter, the semantics is 139 targeted at packet filters and network address translators (NATs) and 140 it supports applications that require dynamic configuration of these 141 middleboxes. 143 The semantics are defined in terms of transactions. Two basic types 144 of transactions are used: request-reply transactions and notification 145 transactions. For each transaction the semantics is specified by 146 describing (1) the parameters of the transaction, (2) the processing 147 (of request transactions) at the middlebox, and (3) the state 148 transitions at the middlebox caused by the transactions. 150 The semantics can be implemented by any protocol that supports these 151 two transaction types and that is sufficiently flexible concerning 152 transaction parameters. Different implementations for different 153 protocols might need to extend the semantics described below by 154 adding further transactions and/or adding further parameters to 155 transactions. Anyway, the semantics below will still be a subset of 156 the implemented semantics. 158 The document contains four major sections. Section 2 describes the 159 protocol semantics. It is structured in four subsections: 161 - General Protocol Issues (Section 2.1) 162 - Session Control (Section 2.2) 163 - Policy Groups (Section 2.3) 164 - Policy Rules (Section 2.4) 166 Section 3 contains conformance statements for MIDCOM protocol 167 definitions and MIDCOM protocol implementations with respect to the 168 semantics defined in Section 2. Section 4 gives two elaborated usage 169 examples. Finally, Section 5 explains how the semantics meets the 170 MIDCOM requirements. 172 1.1. Terminology 174 The terminology in this memo follows the definitions given in the 175 framework [MDC-FRM] and requirements [MDC-REQ] document. 177 In addition the following terms are used: 179 request transaction A request message transfer from the agent 180 and to the middlebox followed by a reply 181 message transfer from the middlebox to the 182 agent. 184 notification transaction An asynchronous message transfer from the 185 middlebox and to the agent. 187 agent unique An agent unique value is unique in the 188 context of the agent. This context 189 includes all MIDCOM session the agent 190 participates in. An agent unique value is 191 assigned by the agent. 193 middlebox unique A middlebox unique value is unique in the 194 context of the middlebox. This context 195 includes all MIDCOM session the middlebox 196 participates in. A middlebox unique value 197 is assigned by the middlebox. 199 1.2. Transaction Definition Template 201 In the following sections semantics of the MIDCOM protocol is 202 specified per transaction. A transaction specification contains the 203 following entries. (Parameter entities are only specified if 204 applicable.) 206 transaction-name 207 A description name for this type of transaction. 209 transaction-type 210 The transaction type is either 'request' or 'notification'. See 211 above for the description of request transaction and notification 212 transaction. 214 transaction-compliance 215 This entry contains either 'mandatory' or 'optional'. For details 216 see Section 2.1.4. 218 request-parameter 219 This entry lists all parameters that are necessary for this 220 request. A description for each parameter is given. 222 reply-parameter (success) 223 This entry lists all parameters that are sent back from the 224 middlebox to the agent as positive response to the prior request. 225 A description for each parameter is given. 227 reply-parameter (failure) 228 This entry lists all parameters that are sent back from the 229 middlebox to the agent as negative response to the prior request. 230 A description for each parameter is given. 232 notification parameters 233 This entry lists all parameters that are used by the middlebox to 234 notify the agent about any asynchronous event. A description for 235 each parameter is given. 237 semantics 238 This entry describes the actual semantics of the transaction. 240 2. Semantics Specification 242 2.1. General Protocol Design 244 A major goal of the semantics is finding a good balance between 245 properly support of applications that require dynamic configuration 246 of middleboxes and simplicity of specification and implementation of 247 the protocol. 249 The MIDCOM protocol will be subdivided into three phases as specified 250 in Section 4 of [MDC-FRM]: 251 - session setup phase 252 - run-time phase 253 - session termination phase 255 In all phases two kinds of state transitions may occur at the 256 middlebox: State transactions either are initiated by a requests from 257 the agent to the middlebox, or they are initiated by any other event. 258 In the first case the middlebox informs the agent by sending a reply 259 on the actual state transition, in latter case the middlebox sends a 260 notification to the agent. Requests and replies contain an agent 261 unique request identifier that allows the agent to determine to which 262 sent request a received reply corresponds. 264 2.1.1. Session, Policy, and Policy Group 266 An analysis of the requirements showed that three kinds of 267 transactions are required: transactions for session control, 268 transactions for controlling of policies, and transaction for 269 controlling policy groups. Policy groups can be used to indicated 270 relationships between policies and to simplify transactions on a set 271 of policies by using a single one per group instead of one per 272 policy. 274 Requirement analysis also showed that session state, policy state, 275 and policy group state can be separated. The separation simplifies 276 the specification of the semantics as well as a protocol 277 implementation. Therefore, the semantics specification is structured 278 accordingly and we use three separated state machines to illustrate 279 the semantics. Please note, that state machines of concrete protocol 280 designs and implementations will most probably more complex than the 281 state machines presented here. However, the protocol state machines 282 are expected to be a superset of the state machines in this document. 284 2.1.2. Atomicity 286 All request transactions are atomic with respect to each other. This 287 means that processing a request at the middlebox is never interrupted 288 by another arriving or already queued request. This particularly 289 applies when the middlebox concurrently receives requests originating 290 in different session. However, asynchronous notification transactions 291 may interrupt and terminate processing of a request at any time. 293 All request transactions are atomic from the point of view of the 294 agent. Processing of a request does not start before the complete 295 request arrived at the middlebox. No intermediate state is stable at 296 the middlebox and no intermediate state is reported to any agent. 298 The number of transactions specified in this document is rather 299 small. Again for simplicity we reduced it close to a minimal set 300 that still meets the requirements. For a real implementation of the 301 protocol, it might be required to split some of the transactions 302 specified below into two or more transactions of the respective 303 protocol. Reasons for this might be constraints of the particular 304 protocol or the desire for more flexibility. In general this should 305 not be a problem. However, it should be considered that this might 306 change atomicity of the affected transactions. 308 2.1.3. Access Control 310 Access to policies and policy groups is based on ownership. When a 311 policy or a group is created, a middlebox unique identifier is 312 generated for identifying it in further transactions. Beyond the 313 identifier, each group has an owner. The owner is the authenticated 314 agent that established the policy or group. The middlebox uses the 315 owner attribute of a policy or group for controlling access to it: 316 each time an authenticated agent requests to modify an existing 317 policy or group, the middlebox determines the owner of the policy or 318 group and checks if the requesting agent is authorized to perform 319 transactions on the owning agent's policies or groups. 321 By configuring the middlebox, certain authenticated agents may get 322 authorized to access and modify groups with certain owner. 323 Certainly, a reasonable default configuration would be that each 324 agent can access its own groups. Also, it might be a good idea, to 325 have an agent identity configured to act as administrator being 326 allowed to modify all policies owned by any agent. Anyway, the 327 configuration of authorization is not subject of the MIDCOM protocol 328 semantics. 330 2.1.4. Conformance 332 The MIDCOM requirements in [MDC-REQ] demand certain capabilities of 333 the MIDCOM protocol, which are met by the set of transactions 334 specified below. However, an actual implementation of a middlebox 335 may support only a subset of these transactions. Support limitation 336 may be different for different authenticated agents. At session 337 establishment, the middlebox informs the authenticated agent by 338 capability exchange, which transactions the agent is authorized to 339 perform. Some transactions need to be offered to every authenticated 340 agent. 342 Each transaction definitions below has a conformance entry which 343 contains either 'mandatory' or 'optional'. A mandatory transaction 344 need to be implemented by every middlebox offering MIDCOM service. A 345 mandatory request transaction must be offered to each of the 346 authenticated agents. An optional transaction does not necessarily 347 need to be implemented by a middlebox. An implemented optional 348 request transaction does not necessarily need to be offered to every 349 authenticated agent. Whether or not an agent is allowed to use an 350 optional request transaction is determined by the middlebox's 351 authorization procedure which is not further specified by this 352 document. 354 2.2. Session Control Transactions 356 Before any transaction on policy rules or policy groups is possible, 357 a valid MIDCOM session must be established. A MIDCOM session is an 358 authorized association between agent and middlebox. Sessions are 359 initiated by agents and can be terminated by any party. Both agent 360 and middlebox may participate in several sessions at the same time. 361 For distinguishing different sessions each party uses local session 362 identifiers. 364 Session control is supported by three transactions: 366 - Session Establishment (SE) 367 - Session Termination (ST) 368 - Asynchronous Session Termination (AST) 370 The first two are request transactions initiated by the agent, the 371 last one is a notification transaction initiated by the middlebox. 373 2.2.1. Session Establishment (SE) 375 transaction-name: session establishment 377 transaction-type: request 379 transaction-compliance: mandatory 381 request-parameters: 383 - request identifier: an agent unique identifier for matching 384 corresponding request and reply at the agent. 386 - version: the version of the MIDCOM protocol 388 - middlebox authentication challenge (mc): an authentication 389 challenge token for the middlebox authentication. 391 - agent authentication (aa): an authentication token to 392 authenticate the agent to the middlebox. 394 - encryption method: an identifier of an encryption method. Also 395 'no encryption' may be specified. 397 reply-parameters (success): 399 - request identifier: an identifier matching the identifier 400 request. 402 - middlebox authentication (ma): an authentication token to 403 authenticate the middlebox to the agent. 405 - agent challenge token (ac): an authentication challenge token for 406 the agent authentication. 408 - middlebox capabilities: a parameter set describing the 409 middlebox's capabilities. The set includes 410 - type of the middlebox 411 for example: FW, NAT, NATFW, NAPT, NAPTFW, NAT-PT, NAT-PTFW, 412 ...) 413 - IP address wildcard support 414 - port wildcard support 415 - supported IP version(s) for internal network: 416 IPv4, IPv6, or both 417 - supported IP version(s) for external network: 418 IPv4, IPv6, or both 419 - list of supported optional MIDCOM protocol transactions 420 - policy rule persistency: persistent or not persistent 421 - maximum remaining lifetime of a policy rule or policy group 423 reply-parameters (failure): 425 - request identifier: an identifier matching the identifier 426 request. 428 - failure reason: the reason why the session establishment 429 transaction failed. The list of possible reasons includes but is 430 not restricted to: 431 - authentication failed 432 - no authorization 433 - protocol version of agent and middlebox do not match 434 - encryption method not supported 435 - lack of resources 437 semantics: 439 This session establishment transaction is used to establish a 440 MIDCOM session. For mutual authentication of both parties two 441 subsequent session establishment transactions are required as 442 shown in Figure 1. 444 agent middlebox 445 | session establishment request | 446 | (with middlebox challenge mc) | 447 |-------------------------------------------->| 448 | | 449 | successful reply (with middlebox | 450 | authentication ma and agent challenge ac) | 451 |<--------------------------------------------| 452 | | 453 | session establishment request | 454 | (with agent authentication aa) | 455 |-------------------------------------------->| 456 | | 457 | successful reply | 458 |<--------------------------------------------| 459 | | 461 Figure 1: Mutual authentication of agent and middlebox 463 Session establishment may be simplified by using only a single 464 transaction. In this case server challenge and agent challenge 465 are omitted by the sender or ignored by the receiver, and 466 authentication must be provided by other means, for example by TLS 467 [RFC2246] or IPSEC [RFC2402][RFC2406]. 469 The middlebox checks with its policy decision point if the 470 requesting agent is authorized to open a MIDCOM session. If not a 471 negative reply with 'no authorization' as failure reason is 472 generated by the middlebox. If authentication and authorization 473 are successful, the session is established and the agent may start 474 with requesting transactions on policy rules and policy groups. 476 Part of the successful reply is an indication of the middlebox's 477 capabilities. The list of capabilities to be included needs to be 478 further elaborated. 480 The agent specifies an encryption method for the session including 481 the option of not using encryption. The middlebox can accept this 482 suggestion or reject it. In case of rejection, the session 483 establishment fails and an appropriate failure reason is indicated 484 by the middlebox in the reply message. Then the agent may try 485 session setup again with a different encryption method. 487 2.2.2. Session Termination (ST) 489 transaction-name: session termination 490 transaction-type: request 492 transaction-compliance: mandatory 494 request-parameters: 496 - request identifier: an agent unique identifier for matching 497 corresponding request and reply at the agent. 499 reply-parameters (success only): 501 - request identifier: an identifier matching the identifier 502 request. 504 semantics: 506 This transaction is used to close the MIDCOM session on behalf of 507 the agent. After session termination the middlebox keeps all 508 established policy groups and policy rules until their lifetime 509 expires or until an event occurs on which the middlebox terminates 510 them. 512 The middlebox generates always a successful reply. After sending 513 the reply, the middlebox will not send any further messages to the 514 agent within the current session. It also will not process any 515 further request within this session, which it has received while 516 it was processing the session termination request, or which it 517 receives later. 519 2.2.3. Asynchronous Session Termination (AST) 521 transaction-name: asynchronous session termination 523 transaction-type: notification 525 transaction-compliance: mandatory 527 notification-parameters: 529 - termination reason: The reason why the session is terminated 530 without any request from the agent. 532 semantics: 534 The middlebox may decide at any point in time to terminate a 535 MIDCOM session. Before terminating the actual session the middle 536 box generates this notification transaction. After sending the 537 notification, the middlebox will not process any further request 538 by the agent, even if it is already queued at the middlebox. 540 After session termination the middlebox keeps all established 541 policy groups and policy rules until their lifetime expires or 542 until an event occurs on which the middlebox terminates them. 544 2.2.4. Session Termination by Interruption of Connection 546 If a MIDCOM session is based on an underlying network connection, 547 then the session can also be terminated by an interruption of this 548 connection. If the middlebox detects this, it immediately terminates 549 the session. The effect on established policy groups and policy 550 rules is the same as for the Asynchronous Session Termination. 552 2.2.5. Session State Machine 554 A state machine illustrating the semantics of the session 555 transactions is shown in Figure 2. The used transaction 556 abbreviations can be found in the headings of the particular 557 transaction section. 559 All sessions start in state CLOSED. A successful SE transaction can 560 cause a state transition to state OPEN, if mutual authentication is 561 already provided by other means. Otherwise, it causes a transition 562 to state NOAUTH. From this state a failed SE transaction returns to 563 state closed, as well as a successful ST transaction. A successful 564 SE transaction causes a transition to state OPEN. At any time an AST 565 transaction may occur causing a transition to state CLOSED. 567 mc = middlebox challenge 568 SE/failure ma = middlebox authentication 569 +-------+ ac = agent challenge 570 | v aa = agent authentication 571 +----------+ 572 | CLOSED |----------------+ 573 +----------+ | SE(mc!=0)/ 574 | ^ ^ | success(ma,ac) 575 SE(mc=0, | | | AST | 576 aa=OK)/ | | | SE/failure v 577 success | | | ST/success +----------+ 578 | | +------------| NOAUTH | 579 | | +----------+ 580 | | AST | SE(mc=0, 581 v | ST/success | aa=OK)/ 582 +----------+ | success 583 | OPEN |<---------------+ 584 +----------+ 586 Figure 2: Session State Machine 588 2.3. Policy Group Transactions 590 This section describes the semantics for transactions on groups of 591 policies. The following transactions are specified: 593 - Group Establishment (GE) 594 - Group Lifetime Change (GLC) 595 - Group List (GL) 596 - Group Status (GS) 597 - Asynchronous Group Deletion (AGD) 599 The first four are request transactions initiated by the agent, the 600 last one is a notification transaction initiated by the middlebox. 601 The status information transactions (GL and GS) do not have any 602 effect on the group state machine. 604 Group transactions are redundant in the sense that a transaction on a 605 group can be replaced by the corresponding transaction on each member 606 of a group (except for the GE transaction). They can be removed 607 easily from the semantics specification without changing the set of 608 possible middlebox configurations an agent can request. Therefore 609 all of them are declared as 'optional' by their respective compliance 610 entry. 612 Before any group request can be processed a valid MIDCOM session must 613 have been established. The establishment of groups is a premise of 614 any further policy establishment. However, there is a default group 615 which is automatically established by the middlebox for every 616 authenticated agent. This group has unlimited lifetime and cannot be 617 controlled by a GE or GLC transaction. It has to be used by the 618 agent if the middlebox does not offer group transactions. But it may 619 be used by the agent at any time. It is addressed by a fixed group 620 identifier value. 622 Each policy is member of exactly one group, and membership does not 623 change during policy lifetime. 625 Each group that is not a default group has its individual lifetime. 626 If the group lifetime expires, the group and all member policies will 627 be deleted at the middlebox. A group lifetime change (GLC) 628 transaction may extend the lifetime of the group up to the limit 629 specified at session setup, when the middlebox informs the agent 630 about its capabilities. Also a GLC transaction may be used for 631 deleting a group by requesting a lifetime of 0. After a successful 632 GLC transaction, all member policies have the same lifetime as the 633 group. Please note that by policy-specific transactions, the 634 lifetime of an individual policy may be set to other values than the 635 group lifetime, but an individual policy lifetime may never exceed 636 the group lifetime. 638 The status information transactions GL and GS can be used by the 639 agent for exploring the state of the middlebox and for exploring its 640 access rights. The GL transaction lists all groups that the agent 641 may access, including groups owned by other agents. The GS 642 transaction reports the status of an individual group and it lists 643 all policies of this group by their policy identifers. The agent can 644 explore the state of the individual policies by using the policy 645 identifiers in a policy information transaction (see Section 2.4.4). 647 2.3.1. Group Establishment (GE) 649 transaction-name: group establishment 651 transaction-type: request 653 transaction-compliance: optional 655 request-parameters: 657 - request identifier: an agent unique identifier for matching 658 corresponding request and reply at the agent. 660 - group lifetime: a lifetime proposal to the middlebox for the 661 requested group. 663 reply-parameters (success): 665 - request identifier: an identifier matching the identifier 666 request. 668 - group identifier: a middlebox unique group identifier. It is 669 assigned by the middlebox and used as group handle in further 670 group transactions and in policy transactions adding policies to 671 the group. 673 - group lifetime: the group lifetime granted by the middlebox. 675 reply-parameters (failure): 677 - request identifier: an identifier matching the identifier 678 request. 680 - failure reason: the reason why the group establishment was 681 rejected. The list of possible reasons includes but is not 682 restricted to: 683 - transaction not supported 684 - agent not authorized for this transaction 685 - lack of resources 687 semantics: 689 This transaction creates an empty group with no policy being 690 member of. The middlebox generates a middlebox unique identifier 691 for the new group and assigns the requesting agent to be the group 692 owner. The lifetime of the group is proposed by the agent. In 693 case of a success reply, the middlebox chooses a lifetime value 694 that is greater than zero and smaller than or equal to the 695 proposed value. If the middlebox decides not to create a new 696 group, a failure reply is generated containing a specification of 697 the reason for failure. 699 2.3.2. Group Lifetime Change (GLC) 701 transaction-name: group lifetime change 703 transaction-type: request 705 transaction-compliance: optional 707 request-parameters: 709 - request identifier: an agent unique identifier for matching 710 corresponding request and reply at the agent. 712 - group identifier: a reference to the group for which the lifetime 713 is requested to be changed. 715 - group lifetime: the new lifetime proposal for the group. 717 reply-parameters (success): 719 - request identifier: an identifier matching the identifier 720 request. 722 - group lifetime: The remaining group lifetime granted by the 723 middlebox. 725 reply-parameters (failure): 727 - request identifier: an identifier matching the identifier 728 request. 730 - failure reason: the reason why the lifetime change was rejected. 731 The list of possible reasons includes but is not restricted to: 732 - transaction not supported 733 - agent not authorized for this transaction 734 - agent not authorized for changing lifetime of this group 735 - no such group 736 - this transaction cannot be applied to the default group 737 - lifetime cannot be extended 739 semantics: 741 The agent can use this transaction type to request an extension 742 the lifetime of an already established group, to request 743 shortening of the life time, or to request group termination which 744 includes termination of all member policies. Group termination is 745 requested by suggesting a new group lifetime of zero. 747 The middlebox first checks whether or not the specified group 748 exists and whether or not the agent is authorized to access this 749 group. If one of the checks fails, an appropriate failure reply 750 is generated. Also a failure reply is generated if the 751 transaction is applied to the agent's default group. If the 752 requested lifetime is longer than the current one, the middlebox 753 also checks, whether or not the lifetime of the group may be 754 extended and generates an appropriate failure message if not. 756 A failure reply is implies that the lifetime of the group remains 757 unchanged. A success reply is generated by the middlebox, if the 758 lifetime of the group was changed in any way. 760 The success reply contains the new lifetime of the group. The 761 middlebox chooses the lifetime within the interval limited by the 762 lifetime of the group at arrival of the request and by the 763 suggested lifetime. The granted remaining lifetime must not 764 exceed the maximum lifetime that the middlebox specified at 765 session setup together with its other capabilities. 767 A changed lifetime is applied to each member of the group. After 768 sending a success reply with a lifetime of zero, the member 769 policies will be deleted without any further notification to the 770 agent, and the middlebox will consider the group and its members 771 to be non-existent. It will not process any further transaction 772 on this group or on any of its members. 774 2.3.3. Group List (GL) 776 transaction-name: group list 778 transaction-type: request 780 transaction-compliance: optional 782 request-parameters: 784 - request identifier: an agent unique identifier for matching 785 corresponding request and reply at the agent. 787 reply-parameters (success): 789 - request identifier: an identifier matching the identifier 790 request. 792 - group list: list of all groups that the agent can access. For 793 each listed group the identifier and the owner are indicated. 795 reply-parameters (failure): 797 - request identifier: an identifier matching the identifier 798 request. 800 - failure reason: the reason why the request for listing groups was 801 rejected. The list of possible reasons includes but is not 802 restricted to: 803 - transaction not supported 804 - agent not authorized for this transaction 806 semantics: 808 The agent can use this transaction type to list all groups which 809 it can access, including default groups. Usually, the agent has 810 this information already, but in special cases (for example after 811 an agent failover) or for special agents (for example an 812 administrating agent that can access all groups) this transaction 813 can be helpful. 815 The middlebox first checks whether or not the agent is authorized 816 to request this transaction. If the checks fails, an appropriate 817 failure reply is generated. Otherwise a list of all groups the 818 agent can access is returned indicating the identifier and the 819 owner each group. The shortest possible list to be replied 820 contains just the requesting agent's default group. 822 This transaction does not have any effect on the group state. 824 2.3.4. Group Status (GS) 826 transaction-name: group status 828 transaction-type: request 830 transaction-compliance: optional 832 request-parameters: 834 - request identifier: an agent unique identifier for matching 835 corresponding request and reply at the agent. 837 - group identifier: a reference to the group for which status 838 information is requested. 840 reply-parameters (success): 842 - request identifier: an identifier matching the identifier 843 request. 845 - group owner: an identifier of the agent owning this policy group. 847 - group lifetime: the remaining lifetime of the group. 849 - member list: list of all policies that are members of the group. 850 The policies are specified by their middlebox unique policy 851 identifier. 853 reply-parameters (failure): 855 - request identifier: an identifier matching the identifier 856 request. 858 - failure reason: the reason why the request for a status report 859 was rejected. The list of possible reasons includes but is not 860 restricted to: 861 - transaction not supported 862 - agent not authorized for this transaction 863 - no such group 864 - agent not authorized for listing members of this group 866 semantics: 868 The agent can use this transaction type to list all member 869 policies of a group. Usually, the agent has this information 870 already, but in special cases (for example after an agent 871 failover) or for special agents (for example an administrating 872 agent that can access all groups) this transaction can be helpful. 874 The middlebox first checks whether or not the specified group 875 exists and whether or not the agent is authorized to access this 876 group. If one of the checks fails, an appropriate failure reply 877 is generated. Otherwise a list of all group members is returned 878 indicating the identifier of each group. If the list of member 879 policies is empty, a successful reply is returned containing an 880 empty list. 882 This transaction does not have any effect on the group state. 884 2.3.5. Asynchronous Group Deletion (AGD) 886 transaction-name: asynchronous group deletion 888 transaction-type: notification 889 transaction-compliance: optional 891 notification-parameters: 893 - group identifier: a reference to the group that will be deleted. 895 - deletion reason: the reason why the middlebox will delete the 896 group including all member policies. 898 semantics: 900 The middlebox may decide at any point in time to delete a group. 901 Particularly, this transaction is triggered by lifetime expiration 902 of the group. Among other events that may cause this transaction 903 are changes in the policy decision point. 905 If this notification is generated, it is sent to all agents that 906 are in an open session with the middlebox and that are authorized 907 to access the group. The notification is sent to the agents 908 before the middlebox deletes the group and its member policies. 909 The member policies will be deleted without any further 910 notification to the agents. After sending the notification, the 911 middlebox will consider the group and all its members to be non- 912 existent. It will not process any further transaction on the 913 group or on any of its members. 915 2.3.6. Group State Machine 917 A state machine illustrating the semantics of the transactions on 918 groups is shown in Figure 3. The used transaction abbreviations can 919 be found in the headings of the particular transaction section. 921 This state machine exists per group identifier. Initially, all 922 groups are in state GROUP UNUSED, which means that the group does not 923 exist. A successful GE transaction causes a transition to state 924 GROUP INUSE. From there the state returns to GROUP UNUSED with a 925 successful GLC transaction requesting a lifetime of zero and with an 926 AGD transaction. After returning to state GROUP UNUSED, the group 927 identifier is not anymore bound to an existing group and may be re- 928 used by the middlebox. 930 GE/failure 931 +--------+ 932 | v 933 +----------+ 934 | GROUP | 935 | UNUSED | 936 +----------+ 937 | ^ 938 GE/success | | GLC(lt=0)/success 939 | | AGD 940 v | 941 +----------+ 942 | GROUP | 943 | INUSE | 944 +----------+ 945 | ^ 946 +--------+ 947 GLC(lt>0)/ 948 success lt = lifetime 949 GLC/failure 951 Figure 3: Group State Machine 953 2.4. Policy Rule Transactions 955 This section describes the semantics for transactions on policies. 956 The following transactions are specified: 958 - Policy Reserve Rule (PRR) 959 - Policy Allow Rule (PAR) 960 - Policy Lifetime Change (PLC) 961 - Policy Status (PS) 962 - Asynchronous Policy Deletion (APD) 964 The first four are request transactions initiated by the agent, the 965 last one is a notification transaction initiated by the middlebox. 966 The status information transaction (PS) does not have any effect on 967 the policy state machine. 969 Policy transactions PAR and PLC constitute the core of the MIDCOM 970 protocol. Both are mandatory. They serve for 972 - configuring NAT bindings (PAR) 973 - configuring firewall pinholes (PAR) 974 - extending the lifetime of established policies (PLC) 975 - deleting policies (PLC) 977 In some cases it is required to know in advance which IP address (and 978 port number) would be chosen by NAT in a PAR transaction. This 979 information is required before sufficient information for performing 980 a complete PAR transaction is required (see example in Section 4.2). 981 For supporting such cases, the core transactions are extended by the 982 Policy Reserve Rule (PRR) transaction serving for 984 - reserving addresses and port numbers at NATs (PRR) 986 A policy rule contains either a reserve action or an allow action. 987 The reserve action allocates IP addresses and port numbers at a NAT. 988 It does not have any function at a firewall. The allow action is 989 interpreted as as bind action at a NAT for establishing bindings 990 between internal and external addresses. At a firewall, the allow 991 action is interpreted as one or more allow actions. The number of 992 allow actions depends on the parameters of the request and the 993 implementation of the firewall. For a more detailed description, see 994 Sections 2.4.1. and 2.4.2. below. 996 When a policy is established, it immediately becomes a member of one 997 of the groups the agent may access. Each policy is member of exactly 998 one group, and membership does not change during policy lifetime. If 999 an agent does not need to group policies, it may just use its default 1000 group and have all policies being member of it. A default group is 1001 automatically generated by the middlebox for each authenticated 1002 agent. 1004 Each policy has its individual lifetime. If the policy lifetime 1005 expires, the policy will be deleted at the middlebox. A policy 1006 lifetime change (PLC) transaction may extend the lifetime of the 1007 policy up to the limit specified at session setup. Also a PLC 1008 transaction may be used for deleting a policy by requesting a 1009 lifetime of 0. Pease note that policy lifetime may also be modified 1010 by the group lifetime change transaction. 1012 The agent can explore the status of any policy by using the Policy 1013 Status (PS) transaction. 1015 2.4.1. Policy Reserve Rule (PRR) 1017 transaction-name: policy reserve rule 1019 transaction-type: request 1021 transaction-compliance: optional 1023 request-parameters: 1025 - request identifier: an agent unique identifier for matching 1026 corresponding request and reply at the agent. 1028 - group identifier: a reference to the group of which the reserve 1029 policy should be a member. 1031 - protocol identifier: identifies the protocol for which a 1032 reservation is requested. Examples are 'IP', 'UDP', and 'TCP'. 1034 - port range: the number of consecutive ports numbers to be 1035 reserved. This parameter is irrelevant, if the protocol 1036 identifier does not have the value 'TCP' or 'UDP'. 1038 - port oddity: the requested oddity of the port number to be 1039 reserved. Allowed values of this parameter are 'odd', 'even', 1040 and 'any'. 1042 - side of middlebox: the value of this parameter is either 'inside' 1043 or 'outside'. For an outside reservation, a reservation of an 1044 external address at the middlebox is requested, for an inside 1045 reservation, an internal address reservation at the middlebox is 1046 requested. 1048 - policy lifetime: a lifetime proposal to the middlebox for the 1049 requested policy. 1051 reply-parameters (success): 1053 - an identifier matching the identifier request. 1055 - policy identifier: a middlebox unique policy rule identifier. It 1056 is assigned by the middlebox and used as policy rule handle in 1057 further policy transactions. 1059 - reserved IP address: The reserved IPv4 or IPv6 address. 1061 - reserved port number: The reserved port number. In case of a 1062 port range greater than 1, it is the lowest port number of a 1063 consecutive sequence of reserved port numbers. This parameter is 1064 irrelevant, if the in the protocol identifier of the request 1065 parameters does not have the value 'TCP' or 'UDP'. 1067 - policy lifetime: the policy lifetime granted by the middlebox. 1069 reply-parameters (failure): 1071 - an identifier matching the identifier request. 1073 - failure reason: the reason why the reserve policy was rejected. 1074 The list of possible reasons includes but is not restricted to: 1075 - agent not authorized for this transaction 1076 - agent not authorized for adding members to this group 1077 - no such group 1078 - no reservation of inside addresses supported 1079 - no reservation of outside addresses supported 1080 - lack of IP addresses 1081 - lack of port numbers 1082 - lack of resources 1084 semantics: 1086 The agent can use this transaction type to reserve an IP address 1087 or a combination of IP address, transport type, port number and 1088 port range at the middlebox. In some scenarios it is required to 1089 perform such a reservation before sufficient parameters for a 1090 complete policy allow rule transaction are available. See section 1091 4.2 for an example. The reservation can be made for either side 1092 of the NAT but not for both of them. So far, not scenario has 1093 been found where reservation on both sides of the middlebox is 1094 required. Typically reservations will be requested for external 1095 addresses of a single-NAT. But for twice-NAT middleboxes, also 1096 reservations of internal addresses are supported. 1098 The middlebox first checks whether or not the specified group 1099 exists and whether or not the agent is authorized to add members 1100 to this group. If one of the checks fails, an appropriate failure 1101 reply is generated. 1103 In case of success, this transaction creates a new policy that 1104 becomes a member of the specified group. The middlebox generates 1105 a middlebox unique identifier for the new policy. The owner of 1106 the new policy is the owner of the group. The middlebox chooses a 1107 lifetime value that is greater than zero and smaller than or equal 1108 to the proposed value and that is smaller than or equal to the 1109 maximum lifetime specified at session setup. 1111 If the protocol identifier is 'IP', then the middlebox reserves an 1112 available internal or external IP address, depending on the 1113 specified direction. Depending on the specified side of the 1114 middlebox, either and internal address is reserved at the inside 1115 of the middlebox or an external address is reserved at the outside 1116 of the middlebox. The reserved address is returned to the agent. 1117 In this case the request-parameters port range and port oddity and 1118 the reply-parameter port number are irrelevant. 1120 If the protocol identifier is 'UDP' or 'TCP', then a combination 1121 of an IP address and a consecutive sequence of port numbers 1122 starting with the specified oddity is reserved. As for the 1123 protocol identifier 'IP', now the IP address is reserved as an 1124 internal one or an external one depending on the specified side of 1125 the middlebox. The IP address and the first reserved port number 1126 of the consecutive sequence are returned to the agent. 1128 If the reservation fails because of lack of resources, such as 1129 available IP addresses, port numbers, or storage for further 1130 policies, then an appropriate failure reply is generated. 1132 2.4.2. Policy Allow Rule (PAR) 1134 transaction-name: policy allow rule 1136 transaction-type: request 1138 transaction-compliance: mandatory 1140 request-parameters: 1142 - request identifier: an agent unique identifier for matching 1143 corresponding request and reply at the agent. 1145 - group identifier: a reference to the group of which the allow 1146 policy should be a member. 1148 - reservation identifier: a reference to an already existing 1149 reserve policy. As reference the policy identifier can be used. 1150 The reference may be empty. 1152 - protocol identifier: identifies the protocol for which a 1153 reservation is requested. Examples are 'IP', 'UDP', and 'TCP'. 1155 - port range: the number of consecutive ports numbers to be 1156 reserved. This parameter is irrelevant, if the protocol 1157 identifier does not have the value 'TCP' or 'UDP'. 1159 - port oddity: the requested oddity of the port number(s) to be 1160 mapped. Allowed values of this parameter are 'same' and 'any'. 1162 - topology: location of reservation or direction of communication. 1163 For the reserve action, this parameter specifies the side of the 1164 middlebox, either 'inside' or 'outside'. For allow actions, this 1165 parameter specifies the direction of allowed communication, 1166 either 'inbound', 'outbound', or 'bi-directional'. 1168 - internal IP address: the IP address of the internal communication 1169 endpoint (A0 in Fig. 4). The address may be wildcarded, for 1170 example by carrying a network mask. 1172 - internal port number: the port number of the internal 1173 communication endpoint (A0 in Fig. 4). The port number may be 1174 wildcarded. This parameter is irrelevant, if the in the protocol 1175 identifier does not have the value 'TCP' or 'UDP'. 1177 - external IP address: the IP address of the external communication 1178 endpoint (A3 in Fig. 4). The address may be wildcarded, for 1179 example by carrying a network mask. 1181 - external port number: the port number of the external 1182 communication endpoint (A3 in Fig. 4). The port number may be 1183 wildcarded. This parameter is irrelevant, if the in the protocol 1184 identifier does not have the value 'TCP' or 'UDP'. 1186 - policy lifetime: a lifetime proposal to the middlebox for the 1187 requested policy. 1189 reply-parameters (success): 1191 - an identifier matching the identifier request. 1193 - policy identifier: a middlebox unique policy rule identifier. It 1194 is assigned by the middlebox and used as policy rule handle in 1195 further policy transactions. 1197 - inside IP address number: the internal IP address provided at the 1198 inside of the NAT (A1 in Fig. 4). The address may be wildcarded, 1199 for example by carrying a network mask. 1201 - inside port number: the internal port number provided at the 1202 inside of the NAT (A1 in Fig. 4). In case of a port range 1203 greater than 1, it is the lowest port number of a consecutive 1204 sequence of mapped port numbers. The port number may be 1205 wildcarded. This parameter is irrelevant, if the in the protocol 1206 identifier of the request parameters does not have the value 1207 'TCP' or 'UDP'. 1209 - outside IP address number: the external IP address provided at 1210 the outside of the NAT (A2 in Fig. 4). The address may be 1211 wildcarded, for example by carrying a network mask. 1213 - outside port number: the external port number provided at the 1214 outside of the NAT (A2 in Fig. 4). In case of a port range 1215 greater than 1, it is the lowest port number of a consecutive 1216 sequence of mapped port numbers. The port number may be 1217 wildcarded. This parameter is irrelevant, if the in the protocol 1218 identifier of the request parameters does not have the value 1219 'TCP' or 'UDP'. 1221 - policy lifetime: the policy lifetime granted by the middlebox. 1223 reply-parameters (failure): 1225 - an identifier matching the identifier request. 1227 - failure reason: the reason why the allow policy was rejected. 1228 The list of possible reasons includes but is not restricted to: 1229 - agent not authorized for this transaction 1230 - no such group 1231 - agent not authorized for adding members to this group 1232 - no such reserve policy 1233 - the reserve policy is not member of the specified group 1234 - agent not authorized for accessing this reserve policy 1235 - mismatching protocol identifier in reserve policy 1236 - conflict with already existing policy rule 1237 - lack of IP addresses 1238 - lack of port numbers 1239 - lack of resources 1241 semantics: 1243 This transactions can be used by an agent for enabling 1244 communication between an internal endpoint and an external 1245 endpoint independent of the type of middlebox (NAT, NAPT, 1246 firewall, NAT-PT, combined devices, ... ) for uni-directional or 1247 bi-directional traffic. 1249 The agent sends an allow request specifying the endpoints 1250 (optionally including wildcards) and the direction of 1251 communication (inbound, outbound, bi-directional). The 1252 communication endpoints are displayed in Figure 4. They are 1253 addressed by the address tuples A0 and A3, respectively. An 1254 address tuple includes a protocol identifier, an IP address, and 1255 optionally a port number and a port number range. The middlebox 1256 replies to the allow request with a pair of communication address 1257 tuples A1 and A2 to be used by the partners for addressing each 1258 other. 1260 +----------+ +----------+ 1261 | internal | A0 A1 +-----------+ A2 A3 | external | 1262 | endpoint +----------+ middlebox +----------+ endpoint | 1263 +----------+ +-----------+ +----------+ 1265 Policy Allow Rule (PAR) Transaction: 1266 agent -> middlebox: A0, A3, direction 1267 middlebox -> agent: A1, A2 (in case of success) 1269 Figure 4: Communication endpoints in the PAR transaction 1271 In case of a pure packet filtering firewall, the returned address 1272 tuples are the same than the ones in the request: A2=A0 and A1=A3. 1273 Each partner uses the other one's real address. In case of a 1274 traditional NAT the internal endpoint may use the real address of 1275 the external endpoint (A1=A3), but the external endpoint uses an 1276 address tuple provided by the NAT (A2!=A0). In case of a twice- 1277 NAT device, both endpoints uses address tuples provided by the NAT 1278 for addressing their communication partner (A3!=A1 and A2!=A0). 1280 If a firewall is combined with a NAT or a twice-NAT, the replied 1281 address tuples will be the same as for pure traditional NAT or 1282 twice-NAT, respectively, but the middlebox will configure its 1283 packet filter in addition to the performed NAT bindings. In case 1284 of a firewall combined with a traditional NAT, more than one allow 1285 action might be required for the firewall configuration, because 1286 incoming and outgoing packets use different source-destination 1287 pairs. 1289 The middlebox first checks whether or not the specified group 1290 exists and whether or not the agent is authorized to add members 1291 to this group. If the reservation identifier is not empty, then 1292 the middlebox also checks whether or not the reference policy 1293 exists whether or not it is member of the specified group, and 1294 whether or not the agent is authorized to modify this policy. If 1295 one of the checks fails, an appropriate failure reply is 1296 generated. 1298 In case of success, this transaction creates a new policy that 1299 becomes a member of the specified group. If a reservation policy 1300 was referenced, then the identifier of the reservation policy will 1301 be used for the new allow policy. Otherwise, the middlebox 1302 generates a middlebox unique identifier for the new policy. The 1303 owner of the new policy is the owner of the group. The middlebox 1304 chooses a lifetime value that is greater than zero and smaller 1305 than or equal to the proposed value and that is smaller than or 1306 equal to the maximum lifetime specified at session setup. 1308 If the protocol identifier is 'IP', then the middlebox allows 1309 communication between the specified external IP address and the 1310 specified internal IP address. The addresses to be used by the 1311 communication partners in order to address each other are returned 1312 to the agent as inside IP address and outside IP address. If the 1313 reservation identifier is not empty and if the reservation used 1314 the same protocol type, then the reserved IP address is used 1315 either as inside or as outside IP address (depending on the 1316 reservation). 1318 For the protocol identifiers 'UDP' and 'TCP' the middlebox acts 1319 analogously to 'IP' with additionally mapping ranges of port 1320 numbers and keeping the port oddity if requested. 1322 The configuration of the middlebox may fail because a specified 1323 reservation policy does not have a matching protocol identifier or 1324 because of lack of resources, such as available IP addresses, port 1325 numbers, or storage for further policies. Also it may fail 1326 because of a conflict with an already established policy. In case 1327 of a conflict, the first come first serve mechanism is applied. 1328 Already existing policies remain unchanged and arriving new ones 1329 are rejected. However, in case of a non-conflicting overlap of 1330 policies (including identical policies), all policies are 1331 accepted. 1333 In each case of failure, an appropriate failure reply is 1334 generated. 1336 2.4.3. Policy Lifetime Change (PLC) 1338 transaction-name: policy lifetime change 1340 transaction-type: request 1342 transaction-compliance: mandatory 1344 request-parameters: 1346 - request identifier: an agent unique identifier for matching 1347 corresponding request and reply at the agent. 1349 - policy identifier: identifying the policy for which the lifetime 1350 is requested to be changed. 1352 - policy lifetime: the new lifetime proposal for the policy. 1354 reply-parameters (success): 1356 - request identifier: an identifier matching the identifier 1357 request. 1359 - policy lifetime: The remaining policy lifetime granted by the 1360 middlebox. 1362 reply-parameters (failure): 1364 - request identifier: an identifier matching the identifier 1365 request. 1367 - failure reason: the reason why the lifetime change was rejected. 1368 The list of possible reasons includes but is not restricted to: 1369 - agent not authorized for this transaction 1370 - agent not authorized for changing lifetime of this policy 1371 - no such policy 1372 - lifetime cannot be extended 1374 semantics: 1376 The agent can use this transaction type to request an extension 1377 the lifetime of an already established policy, to request 1378 shortening of the life time, or to request policy termination. 1379 Policy termination is requested by suggesting a new policy 1380 lifetime of zero. 1382 The middlebox first checks whether or not the specified policy 1383 exists and whether or not the agent is authorized to access this 1384 policy. If one of the checks fails, an appropriate failure reply 1385 is generated. If the requested lifetime is longer than the 1386 current one, the middlebox also checks, whether or not the 1387 lifetime of the policy may be extended and generates an 1388 appropriate failure message if not. 1390 A failure reply is implies that the lifetime of the policy remains 1391 unchanged. A success reply is generated by the middlebox, if the 1392 lifetime of the policy was changed in any way. 1394 The success reply contains the new lifetime of the policy. The 1395 middlebox chooses the lifetime within the interval limited by the 1396 lifetime of the policy at arrival of the request and by the 1397 suggested lifetime. The granted remaining lifetime must not 1398 exceed the maximum lifetime that the middlebox specified at 1399 session setup together with its other capabilities. it also must 1400 not exceed the lifetime of the group of which the policy is a 1401 member. 1403 After sending a success reply with a lifetime of zero, the 1404 middlebox will consider the policy to be non-existent. It will 1405 not process any further transaction on this policy. 1407 Please note, that policy lifetime may also be changed by the Group 1408 Lifetime Change (AGD) transaction if applied to the group of which 1409 the policy is a member. 1411 2.4.4. Policy Status (PS) 1413 transaction-name: policy status 1415 transaction-type: request 1417 transaction-compliance: optional 1419 request-parameters: 1421 - request identifier: an agent unique identifier for matching 1422 corresponding request and reply at the agent. 1424 - policy identifier: the middlebox unique policy identifier. 1426 reply-parameters (success): 1428 - request identifier: an identifier matching the identifier 1429 request. 1431 - policy owner: an identifier of the agent owning this policy. 1433 - group identifier: a reference to the group of which the policy is 1434 a member. 1436 - policy action: this parameter has either the value 'reserve' or 1437 the value 'allow'. 1439 - protocol identifier: identifies the protocol for which a 1440 reservation is requested. Examples are 'IP', 'UDP', and 'TCP'. 1442 - port range: the number of consecutive ports numbers. This 1443 parameter is irrelevant, if the protocol identifier does not have 1444 the value 'TCP' or 'UDP'. 1446 - direction: the direction of the communication allowed by the 1447 middlebox. The value of this parameter is either 'inbound', 1448 'outbound', or 'bi-directional'. 1450 - internal IP address: the IP address of the internal communication 1451 endpoint (A0 in Fig. 4). The address may be wildcarded, for 1452 example by carrying a network mask. 1454 - internal port number: the port number of the internal 1455 communication endpoint (A0 in Fig. 4). The port number may be 1456 wildcarded. This parameter is irrelevant, if the in the protocol 1457 identifier does not have the value 'TCP' or 'UDP'. 1459 - external IP address: the IP address of the external communication 1460 endpoint (A3 in Fig. 4). The address may be wildcarded, for 1461 example by carrying a network mask. 1463 - external port number: the port number of the external 1464 communication endpoint (A3 in Fig. 4). The port number may be 1465 wildcarded. This parameter is irrelevant, if the in the protocol 1466 identifier does not have the value 'TCP' or 'UDP'. 1468 - inside IP address number: the internal IP address provided at the 1469 inside of the NAT (A1 in Fig. 4). The address may be wildcarded, 1470 for example by carrying a network mask. 1472 - inside port number: the internal port number provided at the 1473 inside of the NAT (A1 in Fig. 4). In case of a port range 1474 greater than 1, it is the lowest port number of a consecutive 1475 sequence of mapped port numbers. The port number may be 1476 wildcarded. This parameter is irrelevant, if the in the protocol 1477 identifier of the request parameters does not have the value 1478 'TCP' or 'UDP'. 1480 - outside IP address number: the external IP address provided at 1481 the outside of the NAT (A2 in Fig. 4). The address may be 1482 wildcarded, for example by carrying a network mask. 1484 - outside port number: the external port number provided at the 1485 outside of the NAT (A2 in Fig. 4). In case of a port range 1486 greater than 1, it is the lowest port number of a consecutive 1487 sequence of mapped port numbers. The port number may be 1488 wildcarded. This parameter is irrelevant, if the in the protocol 1489 identifier of the request parameters does not have the value 1490 'TCP' or 'UDP'. 1492 - policy lifetime: the remaining lifetime of the policy. 1494 reply-parameters (failure): 1496 - request identifier: an identifier matching the identifier 1497 request. 1499 - failure reason: the reason why the request for a status report 1500 was rejected. The list of possible reasons includes but is not 1501 restricted to: 1502 - transaction not supported 1503 - agent not authorized for this transaction 1504 - no such policy 1505 - agent not authorized for accessing this policy 1507 semantics: 1509 The agent can use this transaction type to list all properties of 1510 a policy. Usually, the agent has this information already, but in 1511 special cases (for example after an agent failover) or for special 1512 agents (for example an administrating agent that can access all 1513 policies) this optional transaction can be helpful. 1515 The middlebox first checks whether or not the specified policy 1516 exists and whether or not the agent is authorized to access this 1517 group. If one of the checks fails, an appropriate failure reply 1518 is generated. Otherwise all properties of the policy are returned 1519 to the agent. Some of the returned parameters may be irrelevant, 1520 depending on the policy action ('reserve' or 'allow') and 1521 depending on other parameters, for example the protocol 1522 identifier. 1524 This transaction does not have any effect on the policy state. 1526 2.4.5. Asynchronous Policy Deletion (APD) 1528 transaction-name: asynchronous policy deletion 1530 transaction-type: notification 1532 transaction-compliance: mandatory 1534 notification-parameters: 1536 - policy identifier: the policy that will be deleted. 1538 - deletion reason: the reason why the middlebox will delete the 1539 policy. 1541 semantics: 1543 The middlebox may decide at any point in time to delete a policy. 1544 Particularly, this transaction is triggered by lifetime expiration 1545 of the policy. Among other events that may cause this transaction 1546 are changes in the policy decision point. 1548 If this notification is generated, it is sent to all agents that 1549 are in an open session with the middlebox and that are authorized 1550 to access the policy. The notification is sent to the agents 1551 before the middlebox deletes the policy. After sending the 1552 notification, the middlebox will consider the policy to be non- 1553 existent. It will not process any further transaction on the 1554 policy. 1556 Please note that asynchronous policy termination may also be 1557 indicated by an Asynchronous Group Deletion (AGD) transaction 1558 without an individual APD for each member of the group. 1560 2.4.6. Policy Rule State Machine 1562 The state machine for the policy rule transactions is shown in Figure 1563 5 with all possible state transitions. You'll find the used 1564 transaction abbreviations in the headings of the particular 1565 transaction section. After returning to state POLICY UNUSED, the 1566 policy identifier is not anymore bound to an existing policy and may 1567 be re-used by the middlebox. 1569 PRR/failure 1570 PAR/failure 1571 +-----------+ 1572 | v 1573 PRR/success +-+-------------+ 1574 +-----------------+ POLICY UNUSED |<-+ 1575 +----+ | +---------------+ | 1576 | | | ^ | | 1577 | v v APD | | | 1578 | +-------------+ PAR/failure| | PAR/ | APD 1579 | | RESERVED +------------+ | success | PLC(lt=0)/ 1580 | +-+----+------+ PLC(lt=0)/ | | success 1581 | | | success | | 1582 +----+ | v | 1583 PLC(lt>0)/ | PAR/success +---------------+ | 1584 success +---------------->| POLICY INUSE +--+ 1585 PLC/failure +-+-------------+ 1586 | ^ 1587 +-----------+ 1588 lt = lifetime PLC(lt>0)/success 1589 PLC/failure 1591 Figure 5: Policy Rule State Machine 1593 This state machine exists per policy identifier. Initially, all 1594 policies are in state POLICY UNUSED, which means that the policy does 1595 not exist or is not active. A successful PRR transaction causes a 1596 transition to state RESERVED, where an address reservation is 1597 established. From there, state POLICY INUSE can be entered by a PAR 1598 transaction. This transaction can also be used for entering state 1599 POLICY INUSE directly from state POLICY UNUSED without a reservation. 1600 In state POLICY INUSE the requested communication between the 1601 internal and the external endpoint is allowed. 1603 The states RESERVED and POLICY INUSE can be maintained by a 1604 successful PLC transactions with a requested lifetime greater than 0. 1605 Transitions from both of these states back to state POLICY UNUSED can 1606 be caused by an APD transaction or by a successful PLC transaction 1607 with a lifetime parameter of 0. Additionally, a failed PAR 1608 transaction causes a transition from state RESERVED to POLICY UNUSED. 1610 Please note, transitions initiated by APD transactions may also be 1611 initiated by AGD transactions. Analogously, transitions initiated by 1612 PLC transactions may also be initiated by GLC transactions. 1614 3. Conformance Statements 1616 A protocol definition complies with the semantics defined in Section 1617 2 if the protocol specification includes all specified transactions 1618 with all their parameters. However, concrete implementations of the 1619 protocol may not support some of the optional transactions. Which 1620 transactions are required for compliancy is different for agent and 1621 middlebox. 1623 This section contains conformance statements for MIDCOM protocol 1624 implementations related to the semantics. Conformance is specified 1625 differently for agents and middleboxes. Most probably these 1626 conformance statements will be extended by a concrete protocol 1627 specification. However, such an extension is expected to extend the 1628 statements below in a way that all of them still hold. 1630 The following list shows the transaction-compliance property of all 1631 transactions as specified in the previous section: 1633 - Session Control Transactions 1634 - Session Establishment (SE) mandatory 1635 - Session Termination (ST) mandatory 1636 - Asynchronous Session Termination (AST) mandatory 1638 - Policy Group Transactions 1639 - Group Establishment (GE) optional 1640 - Group Lifetime Change (GLC) optional 1641 - Group List (GL) optional 1642 - Group Status (GS) optional 1643 - Asynchronous Group Deletion (AGD) optional 1645 - Policy Rule Transactions 1646 - Policy Reserve Rule (PRR) optional 1647 - Policy Allow Rule (PAR) mandatory 1648 - Policy Lifetime Change (PLC) mandatory 1649 - Policy Status (PS) optional 1650 - Asynchronous Policy Deletion (APD) mandatory 1652 3.1. General Implementation Conformance 1654 A compliant implementation of a MIDCOM protocol must support all 1655 mandatory transactions. 1657 A compliant implementation of a MIDCOM protocol must support either 1658 the entire set of the group transactions GE, GLC, and AGD, or none of 1659 them. 1661 A compliant implementation of a MIDCOM protocol may support none, 1662 one, or more of the following transactions: GL, GS, PRR, PS. 1664 3.2. Middlebox Conformance 1666 A middlebox implementation of a MIDCOM protocol supports a request 1667 transaction if it is able to receive and process all possible correct 1668 message instances of the particular request transaction and if it 1669 generates a correct reply for any correct request it receives. 1671 A middlebox implementation o a MIDCOM protocol supports a 1672 notification transaction if it is able to to generate the 1673 corresponding notification message properly. 1675 A compliant middlebox implementation of a MIDCOM protocol must inform 1676 the agent about the list of supported transactions within the SE 1677 transaction. 1679 3.3. Agent Conformance 1681 An agent implementation of a MIDCOM protocol supports a request 1682 transaction if it is able to generate the corresponding request 1683 message properly and if it is able to receive and process all 1684 possible correct replies to the particular request. 1686 An agent implementation of a MIDCOM protocol supports a notification 1687 transaction if it is able to receive and process all possible correct 1688 message instances of the particular transaction. 1690 A compliant agent implementation of a MIDCOM protocol must not use 1691 any optional transaction that is not supported by the middlebox. The 1692 middlebox informs the agent about the list of supported transactions 1693 within the SE transaction. 1695 4. Transaction Usage Examples 1697 This section gives two usage examples of the transactions specified 1698 in Section 2. First it is shown, how an agent can explore all 1699 policies and policy groups, which it may access at a middlebox. Then 1700 the middlebox configuration for enabling a SIP-signaled call is 1701 demonstrated. 1703 4.1. Exploring Policies and Policy Groups 1705 This example precludes an already established session. It shows how 1706 an agent can find out 1708 - which groups it may access and who owns these groups 1709 - the status and member list of all accessible groups 1710 - the status and properties of all accessible policies 1712 If there is just a single session, there is no need for any of these 1713 actions, because the middlebox informs the agent about each state 1714 transition of any policy or policy group. However, after the 1715 disruption of a session or after an intentional session termination, 1716 the agent might want to re-establish the session and explore, which 1717 of the groups and policies it established are still in place. 1719 Also an agent system may fail and another one takes over. Then the 1720 other one need to find out what has already been configured by the 1721 failing system and what still needs to be done. 1723 A third situation where exploring policies and groups is useful is 1724 the case of an agent with 'administrator' authorization. This agent 1725 may access any policy or group created by any other agent and modify 1726 them. 1728 All of them probably will start their exploration with the Group List 1729 (GL) transaction, as shown in Figure 6. On this request, the 1730 middlebox returns a list of pairs each containing an agent identifier 1731 and a group identifier (GID). The agent gets informed which own 1732 group and which of other agents' groups it may access. 1734 agent middlebox 1735 | GL | 1736 |**********************************************>| 1737 |<**********************************************| 1738 | (agent1,GID1) (agent1,GID2) (agent2,GID3) | 1739 | | 1740 | GS GID2 | 1741 |**********************************************>| 1742 |<**********************************************| 1743 | agent1 lifetime PID1 PID2 PID3 PID4 | 1744 | | 1746 Figure 6: Using the GL and the GS transaction 1748 In Figure 6 three groups are accessible to the agent, and the agent 1749 retrieves information about the second group by using the Group 1750 Status (GS) transaction. It receives the owner of the group, the 1751 remaining lifetime, and the list of member policies, in this case 1752 containing four policy identifiers (PIDs). 1754 In the following, the agent explores these four policies. The 1755 example assumes the middlebox to be a traditional NAPT. Figure 7 1756 shows the exploration of the first policy. As reply to a Policy 1757 Status (PS) transaction, the middlebox always returns the following 1758 list of parameters: 1760 - policy owner 1761 - group identifier 1762 - policy action (reserve or allow) 1763 - protocol type 1764 - port range 1765 - direction 1766 - internal IP address 1767 - internal port number 1768 - external address 1769 - external port number 1770 - NAT inside IP address 1771 - NAT inside port number 1772 - NAT outside IP address 1773 - NAT outside port number 1775 agent middlebox 1776 | PS PID1 | 1777 |**********************************************>| 1778 |<**********************************************| 1779 | agent1 GID2 RESERVE UDP 1 OUTSIDE | 1780 | ANY ANY ANY ANY | 1781 | ANY ANY IPADR_OUT PORT_OUT1 | 1782 | | 1784 Figure 7: Status report for an outside reservation 1786 The policy with PID1 is a reserve policy for UDP traffic at the 1787 outside of the middlebox. Since there is no internal or external 1788 address involved yet, these four fields are wildcarded in the reply. 1789 The same holds for the inside NAT address and port number. The only 1790 address information given by the reply is the reserved outside IP 1791 address of the NAT (IPADDR_OUT) and the corresponding port number 1792 (PORT_OUT1). Note, that IPADR_OUT and PORT_OUT1 may not be 1793 wildcarded, because the reserve action does not support this. 1795 Applying PS to PID2 (Figure 8) shows that the second policy is an 1796 allow policy for inbound UDP packets. The internal destination is 1797 fixed concerning IP address, protocol and port number, but for the 1798 external source, the port number is wildcarded. The outside IP 1799 address and port number of the middlebox are the ones the external 1800 sender needs to use as destination in the original packet it sends. 1801 At the middlebox, the destination address is replaced with the 1802 internal address of the final receiver. During address translation, 1803 the source IP address and the source port numbers of the packets 1804 remain unchanged. This is indicated by the inside address which is 1805 identical to the external address. 1807 agent middlebox 1808 | PS PID2 | 1809 |**********************************************>| 1810 |<**********************************************| 1811 | agent1 GID2 ALLOW UDP 1 IN | 1812 | IPADR_INT PORT_INT1 IPADR_EXT ANY | 1813 | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | 1814 | | 1816 Figure 8: Status report for allowed inbound packets 1818 For traditional NATs the identity of the inside IP address and port 1819 number with the external IP address and port number always holds 1820 (A1=A3 in Figure 4). For a pure firewall, also the outside IP 1821 address and port number are always identical with the internal IP 1822 address and port number (A0=A2 in Figure 4). 1824 agent middlebox 1825 | PS PID3 | 1826 |**********************************************>| 1827 |<**********************************************| 1828 | agent1 GID2 ALLOW UDP 1 OUT | 1829 | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | 1830 | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | 1831 | | 1833 Figure 9: Status report for allowed outbound packets 1835 Figure 9 shows allowed outbound UDP communication between the same 1836 host. Here all port numbers are known. Since again A1=A3, the 1837 internal sender uses the external IP address and port number as 1838 destination in the original packets. At the firewall, the internal 1839 source IP address and port number are replaced by the shown outside 1840 IP address and port number of the middlebox. 1842 agent middlebox 1843 | PS PID4 | 1844 |**********************************************>| 1845 |<**********************************************| 1846 | agent1 GID2 ALLOW TCP 1 BI | 1847 | IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 | 1848 | IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 | 1849 | | 1851 Figure 10: Status report for bi-directional TCP traffic 1853 Finally, Figure 10 shows the status report for allowed bi-directional 1854 TCP traffic. Please note that still A1=A3: For outbound packets, only 1855 the source IP address and port number are replaced at the middlebox, 1856 and for inbound packets, only the destination IP address and port 1857 number are replaced. 1859 4.2. Enabling a SIP-Signaled Call 1861 This elaborated transaction usage example shows the interaction 1862 between a SIP proxy and a middlebox. The middlebox itself is a 1863 traditional NAPT and two user agents communciate with each other via 1864 the SIP proxy and NAPT as shown in figure 11. 1866 +----------+ 1867 |SIP Proxy | 1868 |for domain| 1869 | mb.com | 1870 +----------+ 1871 Private ^ ^ Public Network 1872 Network | | 1873 +----------+ | | +---------+ +----------+ 1874 |User Agent|<-+ +->|Middlebox|<------->|User Agent| 1875 | A |<#######>| NAPT |<#######>| B | 1876 +----------+ +---------+ +----------+ 1878 <--> SIP Signalling 1879 <##> RTP Traffic 1881 Figure 11: Example SIP Scenario 1883 For the below sequence charts we make these assumptions: 1885 - The NAPT is statically configured to forward SIP signalling from 1886 the outside to the SIP proxy server, i.e. traffic to the NAPT's 1887 external IP address and port 5060 is forwarded to the internal 1888 SIP proxy. 1890 - The user agent A, located inside the private network, is 1891 registered at the SIP proxy with its private IP address. 1893 - User A knows the general SIP URL of user B. The URL is B@b.de. 1894 However, the concrete URL of the SIP User Agent B, which user B 1895 currently uses, is not known. 1897 - Only the RTP paths are configured, but not the RTCP paths. 1899 - The middlebox and the SIP server share an already established 1900 MIDCOM session. 1902 Furthermore these abbreviations are used: 1904 - IP_AI: Internal IP address of user agent A 1905 - P_AI: Internal port number of user agent A to receive RTP data 1906 - P_AE: External mapped port number of user agent A 1907 - IP_AE: External IP address of the middlebox 1908 - IP_B: IP address of user agent B 1909 - P_B: Port number of user agent B to receive RTP data 1910 - GID: Group identifier 1911 - PID: Policy rule identifier 1913 The abbreviations of the MIDCOM transactions can be found in the 1914 particular section headings. 1916 In our example, user A tries to call user B. Therefore, the user agent A 1917 sends an INVITE SIP message to the SIP proxy server (see Figure 13). The 1918 SDP part of the particular SIP message that is relevant for the middlebox 1919 configuration is shown in the sequence chart as: 1921 SDP: m=..P_AI.. 1922 c=IP_AI 1924 Whereas the m tag is the media tag which contains the receiving udp 1925 port number and the c tag contains the IP address of the terminal 1926 receiving the media stream. 1928 On receiving the SIP INVITE message, the SIP proxy server 1929 allocates a group for this call with the group establishment (GE) 1930 transaction. All following policy rules for this call will be bound to 1931 this group. 1933 The INVITE message forwarded to user agent B must contain a public IP address 1934 and a port number to which user agent B can send its RTP media stream. 1935 Therefore, the SIP proxy server needs an outside IP address and port 1936 number at the middlebox (the NAPT) to be available for this purpose. 1937 However, since the IP address of user agent B is not known yet (it will 1938 be sent by user agent B in the reply message), the porxy server cannot 1939 just request an address binding. Instead it just reserves an outside 1940 IP address and port number with the policy reserve rule (PRR). 1942 The PRR reply delivers the reserved IP address and port number. Now the SIP 1943 proxy server replaces in the SDP payload of the INVITE message the IP address 1944 and port number of user agent A by the reserved address and port 1945 (see Figure 12). 1946 Then the SIP INVITE message is forwarded to user agent B with a modified 1947 SDP body containing the outside address and port number, to which user agent B 1948 will send its RTP media stream. 1950 User Agent SIP Middlebox User Agent 1951 A Proxy NAPT B 1952 | | | | 1953 | INIVTE B@B.DE | | | 1954 | SDP:m=..P_AI.. | | | 1955 | c=IP_AI | | | 1956 |--------------->| GE 600s | | 1957 | |*****************************>| | 1958 | |<*****************************| | 1959 | | GE OK GID 600s | | 1960 | | | | 1961 | | PRR GID UDP 1 EVEN IN 300s | | 1962 | |*****************************>| | 1963 | |<*****************************| | 1964 | | PRR OK PID1 IP_MB/P_AE 300s | | 1965 | | | | 1966 | | INVITE B@B.DE SDP:m=..P_AE.. c=IP_MB | 1967 | |-------------------------------------------->| 1968 | |<--------------------------------------------| 1969 | | 200 OK SDP:m=..P_B.. c=IP_B | 1971 Figure 12: Group establishment and rule reservation 1973 This SIP `200 OK' reply contains the IP address and port number, at which 1974 user agent B will receive a media stream. The IP address is assumed to be 1975 equal to the IP address from which user agwent B will send its media stream. 1977 Now, the SIP proxy server has sufficient information for estblishing 1978 the complete NAT binding with a policy allow rule (PAR) transaction, i.e. 1979 the UDP/RTP data of the call can flow from user agent B to user agent A. 1980 For the opposite direction, UDP/RTP data from user agent A to B, has to be 1981 allowed also. This is done by a second PAR transaction 1982 with all the necessary parameters (see figure 13). After having allowed 1983 both UDP/RTP streams the SIP proxy can forward the `200 OK' SIP message 1984 to user agent A to indicate that the telephone call can start. 1986 User Agent SIP Middlebox User Agent 1987 A Proxy NAPT B 1988 | | | | 1989 | | PAR GID PID1 UDP 1 EVEN IN | | 1990 | | IP_AI P_AI IP_B ANY 300s | | 1991 | |*****************************>| | 1992 | |<*****************************| | 1993 | | PAR OK PID1 NONE NONE | | 1994 | | IP_MB P_AE1 300s | | 1995 | | | | 1996 ...media stream from user agent B to A allowed... 1997 | | | | 1998 | | PAR GID PID2 UDP 1 EVEN OUT | | 1999 | | IP_AI ANY IP_B P_B 300s | | 2000 | |*****************************>| | 2001 | |<*****************************| | 2002 | | PAR OK PID2 NONE NONE | | 2003 | | IP_MB P_AE2 300s | | 2004 | | | | 2005 ...media streams from both directions allowed... 2006 | | | | 2007 | 200 OK | | | 2008 |<---------------| | | 2009 | SDP:m=..P_B.. | | | 2010 | c=IP_B | | | 2012 Figure 13: Policy rule establishment for UDP flows 2014 User agent B decides to terminate the call and sends its `BYE' 2015 SIP message to user agent A. The SIP proxy forwards all SIP messages 2016 and deletes the group afterwards using a group lifetime change (GLC) 2017 transaction with a requested remaining lifetime of 0 seconds (see 2018 Figure 14). Deletion of the group includes deleting all member policies. 2020 User Agent SIP Middlebox User Agent 2021 A Proxy NAPT B 2022 | | | | 2023 | BYE | BYE | 2024 |<---------------|<--------------------------------------------| 2025 | | | | 2026 | 200 OK | 200 OK | 2027 |--------------->|-------------------------------------------->| 2028 | | | | 2029 | | GLC GID 0s | | 2030 | |*****************************>| | 2031 | |<*****************************| | 2032 | | GLC OK 0s | | 2033 | | | | 2034 ...both NAT bindings for the media streams are removed... 2036 Figure 14: Deletion of Policy Groups 2038 5. Compliance with MIDCOM Requirements 2040 This section explains the compliance of the specified semantics with 2041 the MIDCOM requirements. It is structured according to [MDC-REQ]: 2042 - Compliance with Protocol Machinery Requirements (Section 5.1) 2043 - Compliance with Protocol Semantics Requirements (Section 5.2) 2044 - Compliance with Security Requirements (Section 5.3) 2046 The requirements are referred to using the section number they are 2047 defined in: "requirement x.y.z" refers to the requirement specified 2048 in section x.y.z of [MDC-REQ]. 2050 5.1. Protocol Machinery Requirements 2052 5.1.1. Authorized Association 2054 The specified semantics enable a MIDCOM agent to establish an 2055 authorized association between itself and the middlebox. The agent 2056 identifies itself by the authentication mechanism of the Session 2057 Establishment transaction described in Section 2.2.1. Based on this 2058 authentication the middlebox can make a determination as to whether 2059 or not the agent will be permitted to request a service. Thus, 2060 requirement 2.1.1 is met. 2062 5.1.2. Agent connects to Multiple Middleboxes 2064 As specified in Section 2.2, the MIDCOM protocol allows the agent to 2065 communicate with more than one middlebox simultaneously. The 2066 selection of a mechanism for separating different sessions is left to 2067 the concrete protocol definition. It must provide a clear mapping of 2068 protocol messages to open sessions. Then requirement 2.1.2 is met. 2070 5.1.3. Multiple Agents connect to same Middlebox 2072 As specified in Section 2.2, the MIDCOM protocol allows the middlebox 2073 to communicate with more than one agent simultaneously. The 2074 selection of a mechanism for separating different sessions is left to 2075 the concrete protocol definition. It must provide a clear mapping of 2076 protocol messages to open sessions. Then requirement 2.1.3 is met. 2078 5.1.4. Deterministic Behavior 2080 Section 2.1.2 states, that processing a request of an agent may not 2081 be interrupted by any request of the same or another agent. This 2082 provides atomicity among request transactions. This avoids race 2083 conditions resulting in an unpredictable behavior of the middlebox. 2085 Anyway, the behavior of the middlebox can only be predictable in the 2086 view of its administrators. In the view of an agent, the middlebox 2087 behavior is unpredictable, because the administrator can, for example 2088 at any time modify the authorization of the agent without the agent 2089 being able to observe this change. Consequently, the behavior of the 2090 middlebox is not necessarily deterministic from the point of view of 2091 any agent. 2093 Since predictability of the middlebox behavior is given for its 2094 administrator, requirement 2.1.4 is met. 2096 5.1.5. Known and Stable State 2098 Section 2.1.2 states that request transactions are atomic with 2099 respect to each other and from the point of view of an agent. All 2100 transactions are defined clearly as state transitions that either 2101 leave the current stable and well defined state and enter a new 2102 stable and well defined one or that remain in the current stable and 2103 well defined state. Section 2.1 clearly demands that intermediate 2104 states are not stable and not reported to any agent. 2106 Furthermore, for each state transition a message is sent to the 2107 corresponding agent, either a reply or a notification. The agent can 2108 uniquely map each reply to one of the requests that it sent to the 2109 middlebox, because request agent unique request identifiers are used 2110 for this purpose. Notifications are self-explanatory by their 2111 definition. 2113 Furthermore, the Group List transaction (Section 2.3.3), the Group 2114 Status transaction (Section 2.3.4), and the Policy Status transaction 2115 (Section 2.4.4) allow the agent at any time during a session to 2116 retrieve information about 2117 - all policy groups it may access, 2118 - the status and member policies of all accessible groups, 2119 - and the status of all accessible policies. 2121 Therefore, the agent is precisely informed about the state of the 2122 middlebox (as far as the services requested by the agent are 2123 affected) and requirement 2.1.5 is met. 2125 5.1.6. Status Report 2127 As argued in the previous section, the middlebox unambiguously 2128 informs the agent about every state transition related to any of the 2129 services requested by the agent. Also the agent can at any time 2130 retrieve full status information about all accessible policies and 2131 policy groups. Thus, requirement 2.1.6 is met. 2133 5.1.7. Unsolicited Messages (Asynchronous Notifications) 2135 The semantics include asynchronous notifications from the middlebox 2136 to the agent, including Asynchronous Session Termination (Section 2137 2.2.3), Asynchronous Group Deletion (Section 2.3.5), and Asynchronous 2138 Policy Deletion (Section 2.4.5). These notifications report every 2139 change of state, that was not explicitly requested by the agent. 2140 Thus, requirement 2.1.7 is met by the semantics specified above. 2142 5.1.8. Mutual Authentication 2144 As specified in Section 2.2.1, the semantics require mutual 2145 authentication of agent and middlebox, either by using two subsequent 2146 Session Establishment transactions or by using mutual authentication 2147 provided on a lower protocol layer. Thus, requirement 2.1.8 is met. 2149 5.1.9. Session Termination by any Party 2151 The semantics specification states in Section 2.2.2 that the agent 2152 may request session termination by generating the Session Termination 2153 request and that the middlebox may not reject this request. In turn, 2154 Session 2.2.3 states that the agent may send the Asynchronous Session 2155 Termination notification at any time and then terminate the session. 2156 Thus, requirement 2.1.9 is met. 2158 5.1.10. Request Result 2160 Section 2.1 states that each request of an agent is followed by a 2161 reply of the middlebox indicating either success of failure. Thus, 2162 requirement 2.2.10 is met. 2164 5.1.11. Version Interworking 2166 Section 2.2.1 states that the agent need to specify the protocol 2167 version number which it is going to use during the session. The 2168 middlebox may accept this and act according to this protocol version 2169 or reject the session if it does not support this version. If the 2170 session setup gets rejected, the agent may try again with another 2171 version. Thus, requirement 2.2.11 is met. 2173 5.1.12. Deterministic Handling of Overlapping Rules 2175 The only policy rule actions specified are 'reserve' and 'allow'. 2176 For firewalls, overlapping allow actions or reserve actions do not 2177 create any conflict, so a firewall will always accept overlapping 2178 rules as specified in Sections 2.4.1 and 2.4.2 (assuming the required 2179 authorization is given). 2181 For NATs reserve and allow may conflict. If a conflicting request 2182 arrives, it is rejected, as stated in Sections 2.4.1 and 2.4.2. If 2183 an overlapping request arrives that does not conflict with the ones 2184 it overlaps, it is accepted (assuming the required authorization is 2185 given). 2187 Therefore, the behavior of the middlebox in the presence of 2188 overlapping rules can be predicted deterministically, and requirement 2189 2.1.12 is met. 2191 5.2. Protocol Semantics Requirements 2193 5.2.1. Extensible Syntax and Semantics 2195 requirement 2.2.1 explicitly requests extensibility of protocol 2196 syntax. This needs to be addressed by the concrete protocol 2197 definition. The semantics specification is extensible anyway, 2198 because new transaction may be added. 2200 5.2.2. Policy Rules for Different Types of Middleboxes 2202 Section 2.4 explains that the semantics use identical transactions 2203 for all middlebox types and that the same policy rule can be applied 2204 to all of them. Thus requirement 2.2.2 is met. 2206 5.2.3. Ruleset Groups 2208 The semantics explicitly supports grouping of policies and 2209 transactions on policy groups, as described in Section 2.3. The 2210 group transactions can be used for lifetime extension and deletion of 2211 all policies being member of the particular group. Thus, requirement 2212 2.2.3 is met. 2214 5.2.4. Policy Lifetime Extension 2216 The semantics include a transaction for explicit lifetime extension 2217 of policies, as described in Section 2.4.3. Thus requirement 2.2.4 2218 is met. 2220 5.2.5. Robust Failure Modes 2222 The state transitions at the middlebox are clearly specified and 2223 communicated to the agent. There is no intermediate state reached by 2224 a partial processing of a request. All requests are always processed 2225 completely, either successful or unsuccessful. All request 2226 transaction include a list of failure reasons. These failure reasons 2227 cover indication of invalid parameters where applicable. In case of 2228 failure one of the specified reasons is returned from the middlebox 2229 to the agent. Thus requirement 2.2.5 is met. 2231 5.2.6. Failure Reasons 2233 The semantics include a failure reason parameter in each failure 2234 reply. Thus requirement 2.2.6 is met. 2236 5.2.7. Multiple Agents Manipulating Same Policy 2238 As specified in Sections 2.3 and 2.4, each installed policy rule and 2239 policy group has an owner, which is the authenticated agent that 2240 created the policy or group, respectively. The authenticated 2241 identity is input to authorization of access to policies and groups. 2243 If the middlebox is sufficiently configurable, its administrator can 2244 configure it such that one authenticated agent is is authorized to 2245 access and modify policies and groups owned by another agent. 2246 Because specified semantics does not preclude this, it meets 2247 requirement 2.2.7. 2249 5.2.8. Carrying Filtering Rules 2251 The Policy Allow Rule transaction specified in Section 2.4.2 can 2252 carry 5-tuple filtering rules. It meets requirement 2.2.8. 2254 5.2.9. Oddity of Port Numbers 2256 As specified in Section 2.4.2, the agent is able to request to keep 2257 the port oddity. Thus requirement 2.2.9 is met. 2259 5.2.10. Consecutive Range of Port Numbers 2261 The Policy Allow Rule transaction (PAR, Section 2.4.2) allows the 2262 agent to specify a range of consecutive port numbers to be mapped. 2263 This can be used for mapping a consecutive range of external port 2264 numbers to consecutive internal ports. Thus requirement 2.2.10 is 2265 met. 2267 5.2.11. Contradicting Overlapping Policies 2269 requirement 2.2.11 is based on the assumption that contradicting 2270 policy actions, such as 'allow' and 'disallow' are supported. In 2271 conformance with decisions made by the working group after finalizing 2272 the requirements document, this requirement is not met by the 2273 semantics, because not 'disallow' action is supported. 2275 5.3. Security Requirements 2277 5.3.1. Authentication, Confidentiality, Integrity 2279 The semantics definition support mutual authentication of agent and 2280 middlebox and the selection of an encryption method in the Session 2281 Establishment transaction (Section 2.2.1). Encryption can be used 2282 for achieving confidentiality of messages as well as for ensuring 2283 integrity. Thus requirement 2.3.1 is met. 2285 5.3.2. Optional Confidentiality of Control Messages 2287 The Session Establishment transaction (Section 2.2.1) allows the 2288 agent to suggest an encryption method (including 'no encryption'). 2289 Thus requirement 2.3.2 is met. 2291 5.3.3. Operation across Un-trusted Domains 2293 Operation across un-trusted domains is supported by mutual 2294 authentication and by encryption. Thus requirement 2.3.3 is met. 2296 5.3.4. Mitigate Replay Attacks 2298 The specified semantics mitigates replay attacks and meets 2299 requirement 2.3.4 by requiring mutual authentication of agent and 2300 middlebox, and by supporting message encryption. Further mitigation 2301 can be provided as part of a concrete MIDCOM protocol definition, for 2302 example by requiring consecutively increasing numbers for request 2303 identifiers. 2305 6. Security Considerations 2307 The interaction between a middlebox and an agent is (see [MDC-FRM]) a 2308 very sensitive point with respect to security. The configuration of 2309 policy rules from a middlebox external entity appears very 2310 contradictive to the nature of a middlebox. Therefore, effective 2311 means have to be used to ensure: 2312 - mutual authentication between agent and middlebox 2313 - authorization 2314 - message integrity 2315 - message confidentiality 2317 The semantics define a mechanism to ensure mutual authentication 2318 between agent and middlebox (see section 2.2.1). In combination with 2319 the authentication, the middlebox is able to decide wether an agent 2320 is authorized to request an action at the middlebox or not. The 2321 semantics rely on underlying protocols, like TLS or IPSEC, to keep 2322 the message integrity and confidentiality of the transfered data 2323 between both entities. 2325 7. Acknowledgments 2327 We like to thank all the people contributing to the semantics 2328 discussion on the mailing list for a lot of valuable comments. 2330 8. Open Issues 2332 Here is the list of open issues and to do issues: 2334 - The capability information send from the middlebox to the agent 2335 at session setup need to be modeled. What further capability 2336 items should be sent? 2338 - Define behavior for ICMP, IGMP, RSVP, ... 2340 - Complete section on security considerations. 2342 9. Acknowledgements 2344 We like to thank all the people contributing to the semantics 2345 discussion on the mailling list and especially Tom Taylor. 2347 10. References 2349 [MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., 2350 Rayhan, A., "Middlebox Communication Architecture and 2351 framework", RFC 3303, August 2002 2353 [MDC-REQ] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M., 2354 "Middlebox Control (MIDCOM) Protocol Architecture and 2355 Requirements", RFC 3304, August 2002 2357 [NAT-TERM] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) 2358 Terminology and Considerations", RFC 2663, August 1999. 2360 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2361 2246, January 1999. 2363 [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2364 2402, November 1998. 2366 [RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security 2367 Payload (ESP)", RFC 2406, November 1998. 2369 11. Authors' Address 2371 Martin Stiemerling 2372 NEC Europe Ltd. 2373 Network Laboratories 2374 Adenauerplatz 6 2375 69115 Heidelberg 2376 Germany 2378 Phone: +49 6221 90511-13 2379 Email: stiemerling@ccrle.nec.de 2381 Juergen Quittek 2382 NEC Europe Ltd. 2383 Network Laboratories 2384 Adenauerplatz 6 2385 69115 Heidelberg 2386 Germany 2388 Phone: +49 6221 90511-15 2389 EMail: quittek@ccrle.nec.de 2391 12. Full Copyright Statement 2393 Copyright (C) The Internet Society (2002). All Rights Reserved. 2395 This document and translations of it may be copied and furnished to 2396 others, and derivative works that comment on or otherwise explain it 2397 or assist in its implementation may be prepared, copied, published 2398 and distributed, in whole or in part, without restriction of any 2399 kind, provided that the above copyright notice and this paragraph are 2400 included on all such copies and derivative works. However, this 2401 document itself may not be modified in any way, such as by removing 2402 the copyright notice or references to the Internet Society or other 2403 Internet organizations, except as needed for the purpose of 2404 developing Internet standards in which case the procedures for 2405 copyrights defined in the Internet Standards process must be 2406 followed, or as required to translate it into languages other than 2407 English. 2409 The limited permissions granted above are perpetual and will not be 2410 revoked by the Internet Society or its successors or assigns. 2412 This document and the information contained herein is provided on an 2413 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2414 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2415 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2416 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2417 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.