idnits 2.17.1 draft-taylor-midcom-semantics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1048 has weird spacing: '....) The retur...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 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) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 46 looks like a reference -- Missing reference section? '3' on line 1106 looks like a reference -- Missing reference section? '4' on line 1107 looks like a reference -- Missing reference section? '5' on line 1061 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Middlebox Communications (midcom) 3 Internet Draft Tom Taylor 4 Document: draft-taylor-midcom-semantics-00.txt Nortel Networks 5 Expires: December 2002 June 2002 7 Semantics Which The MIDCOM Protocol Must Support 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 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 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document is written to aid the process of selecting and 32 completing the definition of the MIDCOM protocol, which will operate 33 between MIDCOM Agents and Middleboxes such as firewalls and NATs. It 34 describes the semantics which the protocol must support. These 35 semantics are derived from the MIDCOM requirements and the MIDCOM 36 usage scenarios which helped to inspire the requirements. 38 This is intended to be a working document of the IETF Middlebox 39 Communications (MIDCOM) Working Group. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [2]. 47 The notation [X:y] (example [3:2.14]) denotes section y of reference 48 X. 50 In message flows, A->M indicates information passed from the MIDCOM 51 Agent to the Middlebox. M->A indicates information passed from the 52 Middlebox to the MIDCOM Agent. 54 Table of Contents 56 1. Introduction...................................................3 57 1.1 Terminology................................................3 58 1.2 Open Issues................................................3 59 2. Semantic Implications Of The MIDCOM Framework..................5 60 2.1 Agent Identity.............................................5 61 2.2 MIDCOM Session.............................................5 62 2.3 Filters, Policy Actions, Policy Rules......................5 63 2.4 MIDCOM Scenarios...........................................6 64 2.5 MIDCOM Timers.............................................10 65 3. Semantic Implications Of The MIDCOM Requirements..............10 66 4. MIDCOM Semantics: Pulling It All Together.....................15 67 4.1 MIDCOM Session Initiation.................................15 68 4.2 Policy Rule Installation..................................16 69 4.3 Rule Delete...............................................17 70 4.4 Rule Reset................................................17 71 4.5 Rule Query................................................18 72 4.6 Policy Rule Bundling......................................19 73 4.7 Bundle Delete.............................................20 74 4.8 Autonomous Rule Deactivation..............................20 75 4.9 Middlebox Status..........................................21 76 4.10 Session Audit............................................21 77 4.11 Session Termination......................................22 78 5. Formal Syntax.................................................23 79 Security Considerations..........................................24 80 References.......................................................24 81 Acknowledgments..................................................24 82 Author's Addresses...............................................24 84 1. Introduction 86 This document presents the semantics which must be supported by the 87 MIDCOM protocol. The purpose and framework within which this 88 protocol will operate are described in [3]. The detailed 89 requirements which the protocol must satisfy are described in [4]. 91 This document first reviews the framework and requirements and draws 92 out their implications for the semantics of the protocol. It then 93 summarizes the results as a series of possible information flows 94 between the MIDCOM Agent and Middlebox and associated behaviour. 95 Finally it specifies the semantics formally using ABNF. 97 1.1 Terminology 99 "MIDCOM Agent" and "Middlebox" have the meanings given in [3]. 101 Terminology is inconsistent between the framework and the 102 requirements documents. This document assumes that the term "Policy 103 Rule" defined in [3] is the same concept as "ruleset" in [4]. 105 1.2 Open Issues 107 The ideas in this initial version of this document were originally 108 presented to the MIDCOM E-mail list for discussion. A number of 109 issues were raised during that discussion, and others have been 110 identified during the writing of this document. 112 1.2.1 Support for failover between Agents 114 The requirements [4:2.2.7] include the ability for more than one 115 Agent to work on the same ruleset. This requirement was inserted at 116 least in part to support failover between Agents. The open question 117 is whether failover must be supported on a per-session basis or on a 118 per-ruleset basis. It is still necessary to share rulesets because 119 of the possibility of load sharing between Agents, as one example. 121 1.2.2 Meaning Of multiple filter tuples in the same Policy Rule 123 [3] allows for multiple filter tuples in the same Policy Rule, but 124 does not say what this means. It is proposed that the intent be that 125 the tuples are combined by a Boolean AND. 127 1.2.3 Need To Support Address Ranges Within Filters 129 Is there such a need, and how should ranges be expressed if they are 130 required? 132 1.2.4 Meaning of "deterministic result" 134 List discussion did not conclude on what a deterministic result 135 [4:2.1.12] would mean in the case of conflicting rules. The basic 136 problem is this: current NAT and firewall behaviour is based on 137 queuing a set of rules and evaluating successive members of the queue 138 for applicability on a per-packet basis. As a result, the Middlebox 139 is unaware if conflict amongst its rules exists: the first applicable 140 rule prevails. 142 From the point of view of the Middlebox, its behaviour is indeed 143 deterministic in the presence of conflict. However, an individual 144 MIDCOM Agent can never know in advance whether a rule it is adding 145 will have the effect it desires. 147 There are three possible resolutions to this dilemma. The first is 148 to say that it is sufficient for outcomes to be deterministic from 149 the point of view of the Middlebox. The second is to require the 150 Middlebox to perform an analysis of its installed rules whenever a 151 rule is added, changed, or deleted, and characterize the packets for 152 which each Agent's rules will fail to apply. The final possibility 153 is for the Agent to be able to learn the complete set of active rules 154 so it can apply its own analysis. 156 Requiring additional analytical capability on the Middlebox may not 157 be practical, on grounds of device cost. Giving each Agent access to 158 the full set of active rules will raise privacy concerns. Hence the 159 only viable alternative may be to say that requirement [4:2.1.12] is 160 satisfied if a particular sequence of rules always has the same 161 result at the Middlebox, even if that result is not predictable by an 162 Agent. This conclusion needs to be confirmed by the MIDCOM Working 163 Group. 165 1.2.5 Support For Symmetric Mapping 167 Is there a requirement to force a mapping for bidirectional flows 168 such that the mapped address and port are identical for the outgoimg 169 and the incoming flow? 171 1.2.6 Meaning Of End Of Session 173 Does the ending of a MIDCOM session uninstall all of the Policy Rules 174 installed during that session? 176 1.2.7 Indefinite Policy Rule Life 178 Related to the previous question: should the protocol allow 179 installation of rules which never expire? This would be especially 180 useful to open a permanent pinhole for incoming calls. 182 1.2.8 Scope Of Queries 184 As the scenarios illustrate, it is necessary that the Agent be 185 allowed to query installed rules, to determine existing address 186 mappings. The question is whether the Agent is allowed to learn of 187 rules which were not installed within its MIDCOM session. The answer 188 is propobably that the scope of a query is determined by local 189 policy. 191 2. Semantic Implications Of The MIDCOM Framework 193 2.1 Agent Identity 195 The framework speaks of the ability for a MIDCOM Policy Decision 196 Point to revoke authorization for a MIDCOM Agent [3:2.9], and of 197 MIDCOM Agent profiles [3:2.11]. For these concepts to be 198 enforceable, the MIDCOM Agent must be associated with an identifier 199 which must be presented at least at the start of a MIDCOM session and 200 which must be associated with its profile. 202 2.2 MIDCOM Session 204 [3:2.12] speaks of the MIDCOM session. [3:4] provides a requirement 205 for a formal information exchange to start up or to terminate a 206 MIDCOM session. Start-up is initiated by the MIDCOM Agent, while 207 either the Agent or Middlebox may terminate the session. This 208 requirement raises the possibility of using a session identifier in 209 subsequent messages to indicate the session to which each is related. 210 This is not a hard requirement: the Agent identifier could be used 211 instead to represent the association between the Agent and the 212 Middlebox. The advantages of separately identifying the session are 213 that: 215 . more than one session could be supported between the same Agent- 216 Middlebox pair; 218 . it may be easier to hand off a session than an Agent identity in 219 the case of failover between Agents. 221 2.3 Filters, Policy Actions, Policy Rules 223 [3:2.15] defines a Policy Rule as a combination of one or more 224 filters and an action. The basic idea is that packets matching the 225 filter have the action applied to them. 227 By redistributing the semantic content of the Policy Rule between the 228 filter and action portions, it is possible to come up with a unified 229 semantic representation which has the same form for all the 230 applications intended for the MIDCOM protocol. The filter becomes 231 more complex, but the actions reduce to "permit" and "deny" only. 232 (Secondary action qualifiers such as "log", "alarm", and "ignore" may 233 also be needed.) 235 The proposed representation of the filter part has the form: 237 {source address, mapped address, destination address, protocol} 239 Each of the three addresses has the same sub-structure, except that 240 the mapped address has additional components (see section 2.4 second 241 scenario). The semantic components of an address are: 243 . address type (IPv4, IPv6, tunnel ID, ...) 245 . address space identifier. The initial address space 246 identifiers "public" and "private" are defined to support 247 the MIDCOM applicability statement [3:9]. 249 . address value. For IP addresses, this includes a port 250 component. It is an open issue, whether the MIDCOM 251 protocol should be able to express address ranges. 253 The address value in any address may be the wildcard "ANY". This 254 allows rule setup in circumstances where an endpoint is not yet known 255 or mapping is inapplicable or irrelevant. In Policy Rules sent from 256 the Agent to the Middlebox, the mapped address value may also be the 257 wildcard "CHOOSE", indicating that a mapping is desired. 259 Note that this definition of a filter is unidirectional. Where the 260 MIDCOM protocol needs to express requests applying to both directions 261 of a bidirectional flow, additional semantic elements will have to be 262 added. 264 The possibility of multiple filter tuples in one Policy Rule is 265 problematic: the semantics need definition. The Boolean OR is not 266 needed, since it can be achieved by having multiple rules, each with 267 one filter tuple and all with the same action. It is therefore 268 proposed that if multiple filter tuples are present within the same 269 Policy Rule they are to be ANDed. Where the mapped address value is 270 "CHOOSE", an additional semantic is proposed: that the requested 271 mapping shall be the same in each filter term, so that the overall 272 meaning is that the mapping applies to an ANDed filter condition on 273 the flow endpoints. 275 2.4 MIDCOM Scenarios 277 [3:7] presents three scenarios for the operation of the MIDCOM 278 protocol in mid-session. 280 Scenario [3:7.1], firewall control 282 The messaging sequence includes three MIDCOM operations: 284 a) A->M: Open up the firewall to outgoing flows of RTP and RTCP. 285 M->A: OK. 287 b) A->M: Open up the firewall to incoming flows of RTP and RTCP. 288 M->A: OK. 290 c) A->M: Close firewall to the previously enabled incoming and 291 outgoing flows. 292 M->A: OK. 294 Operations a) and b) have the semantics of Policy Rule Activation. 295 One Policy Rule is set for RTP, a second for RTCP, in each case. 296 Operation c) uninstalls the four rules installed by a) and b). 297 Middlebox return codes are discussed in section 3 below. 299 Scenario [3:7.2], NAPT control 301 The messaging sequence includes the following MIDCOM operations: 303 a) A->M: Query Port-BIND for mapped address (assumed known), port 304 5060. 305 M->A: returns Port-BIND. 307 b) A->M: Query NAT session descriptor for SIP flow from external 308 to private endpoint. 309 M->A: returns session descriptor. 311 c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP. 312 Link sessions to SIP control session. 313 M->A: returns session descriptor. 315 d) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent 316 ports). 317 M->A: returns Port-BINDs. 319 e) A->M: Create NAT session for incoming flows of RTP and RTCP 320 (adjacent ports). Link session to SIP control session. 321 M->A: returns session descriptor. 323 f) A->M: end session bundle. 324 M->A: OK. 326 Operations a) and b) allow the Agent to determine the private address 327 of the internal endpoint. In terms of the filter semantics defined 328 above, these operations are equivalent to a single query requesting 329 the return of any active Policy Rules matching a filter of the form: 331 {external address, mapped address + port 5060, ANY, ANY} 333 Note the wildcarded protocol in this expression. Presumably the 334 Middlebox will consult with the MIDCOM PDP to determine the permitted 335 scope of the query. The returned Policy Rule (probably only one in 336 this example) should be associated with an identifier so that it can 337 be referred to in later operations. Issue: should queries return 338 rules set by administration? In general, what is the relationship of 339 query scope to the MIDCOM session within which the query is made? Is 340 this a local policy issue? 342 Operation c) is similar to operation a) in the previous case, except 343 that operation c) requires a further transaction to create a session 344 bundle. The Agent provides the identifier of the rule returned in 345 the query (operations a) and b)) and the identifiers of the new rules 346 just installed, and asks that they be grouped. The Middlebox returns 347 a group identifier. 349 Operations d) and e) are semantically equivalent to activating a 350 single Policy Rule, provided that additional semantics are present to 351 indicate that adjacent ports are required. Accordingly, the semantic 352 description of the part of the filter as presented 353 in section 2.3 is augmented as follows. If the address type is IPv4 354 or IPv6 and the address value is "CHOOSE", then the following 355 additional components may be present: 357 . port count. Requests mappings for this number of 358 consecutive ports. If port count is absent, 1 port is 359 requested. 361 . parity. Requests that the first port of the series has the 362 given parity. If parity is absent the first port may be of 363 either parity. 365 With these additions, operations d) and e) are equivalent to a 366 request to install a rule of the form: 368 filter={external endpoint address, 369 {type=IPv4, space="public", value="CHOOSE", count=2, parity=even}, 370 internal endpoint address + port, UDP}, 371 action="permit" 373 The port part of the external endpoint address has content 'ANY', 374 since in general the source port for RTP/RTCP transmission will be 375 unknown. The internal endpoint address contains a port value for the 376 receiving RTP port. The Middlebox MUST assume that the internal 377 endpoint receives RTCP at the next higher port. 379 The Middlebox returns the same rule with the mapped address value 380 assigned. An additional information exchange groups the with the 381 others in the same session bundle. 383 Operation f) requires an information exchange where the Agent 384 supplies the session bundle identifier and requests deactivation of 385 all rules in the session bundle. 387 Scenario [3:7.3]: Middlebox implementing NAPT and firewall 389 The messaging sequence includes the following MIDCOM operations: 391 a) A->M: Query Port-BIND for mapped address (assumed known), port 392 5060. 393 M->A: returns Port-BIND. 395 b) A->M: Query NAT session descriptor for SIP flow from external to 396 private endpoint. 397 M->A: returns session descriptor. 399 c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP. 400 Link sessions to SIP control session. 401 M->A: returns session descriptor. 403 d) A->M: Open up the firewall to outgoing flows of RTP and RTCP. 404 M->A: OK. 406 e) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent 407 ports). 408 M->A: returns Port-BINDs. 410 f) A->M: Create NAT session for incoming flows of RTP and RTCP. 411 Link session to SIP control session. 412 M->A: returns session descriptor. 414 g) A->M: Open up the firewall to incoming flows of RTP and RTCP. 415 M->A: OK. 417 h) A->M: end NAPT session bundle. 418 M->A: OK. 420 i) A->M: Close firewall to the previously enabled incoming and 421 outgoing flows. 422 M->A: OK. 424 a) and b) are the same as in the previous case. 426 Using the filter semantics described in section 2.3, the NAPT 427 operations in c) and the firewall operations in d) are both implied 428 by the same Policy Rules. For example, the outgoing RTP flow is 429 enabled by specifying a Policy Rule of the form: 431 filter={ internal endpoint address (port = ANY), 432 {type=IPv4, space="public", value="CHOOSE"}, 433 external endpoint address + port, UDP}, 434 action="permit" 436 In a similar way, f) and g) are both accomplished by the same 437 information exchange as for operations d) and e) in the previous 438 case. 440 Finally, h) and i) are semantically equivalent to deactivation of the 441 bundle of rules created in the previous steps. 443 Summary Of Observations 445 In summary, the three scenarios have demonstrated the need for 446 information exchanges supporting querying of active rules against a 447 pattern, activating Policy Rules (generally with wildcards), creating 448 bundles of Policy rules, deactivating individual policy rules, and 449 deactivating bundles of Policy Rules. In addition, semantic content 450 had to be added to the mapped address portion of the filter to 451 express requirements for consecutive port numbers and their parity. 453 2.5 MIDCOM Timers 455 [3:8.3] talks about the potential usefulness of timers in the MIDCOM 456 protocol, to facilitate resource cleanup. This raises the question 457 of whether the timer values should be visible to the Agent. Given 458 that their intended use is to compensate for Agent outages, an 459 information exchange prior to timer expiry seems indicated. 461 3. Semantic Implications Of The MIDCOM Requirements 463 This section reviews the semantic implications of the requirements 464 documented in [4]. 466 [4:2.1.1]: authorization. 468 This requirement implies the need for credentials in any request the 469 Agent sends to the Middlebox, sufficient to allow the latter to 470 determine the Agent's scope of authority. 472 [4:2.1.2]: one MIDCOM Agent dealing with multiple Middleboxes 474 This implies that a parameter must be present in each message coming 475 from a Middlebox, identifying that Middlebox uniquely. The session 476 identifier discussed in section 2.2 might serve that purpose, beyond 477 the initial setup of the session. 479 [4:2.1.3]: one Middlebox dealing with multiple MIDCOM Agents 481 Similarly, this implies that a parameter must be present in each 482 message coming from a MIDCOM Agent, identifying that MIDCOM Agent 483 instance uniquely. MIDCOM Agent identifiers were discussed in 484 section 2.1. Again, the session identifier may serve the purpose 485 after initial session setup. 487 [4:2.1.4]: deterministic Middlebox behaviour when multiple MIDCOM 488 Agents interact with it. 490 This implies several points: 492 . well-defined Middlebox behaviour when it processes 493 requests, particularly when conflicts are encountered; 495 . the behavioural equivalent of mutual exclusion, such that 496 requests affecting the same resources (for example, 497 involving overlapping filter specifications) are required 498 to be processed serially; 500 . requests can be of sufficiently large extent that the Agent 501 can accomplish what it needs in a single request, thus 502 avoiding deadlock. 504 [4:2.1.5]: known and stable state 506 The explanation of this requirement suggests that a request 507 identifier parameter is needed for each request, that each request 508 must have a reply, and that the reply must include the request 509 identifier parameter as well as the result of the request. 511 The requirement also appears to imply the need for a MIDCOM Agent to 512 be able to audit the Middlebox state as it relates to requests made 513 in the past by that Agent. As an optimization, the audit request may 514 include parameters limiting the scope of the audit. The response 515 includes a state parameter expressed as a sequence of Policy Rules. 516 In view of the potential volume of information, provision should be 517 made for segmentation of the response. 519 Auditing can be seen as an additional use of the query exchange 520 documented as part of the scenario analysis in section 2.4. 522 [4:2.1.6]: Middlebox reporting status 524 This implies a a need for a Middlebox to send autonomous 525 notifications to a MIDCOM Agent. It is assumed that [4:2.1.6] 526 relates to the operational status of the Middlebox as a whole, and 527 possibly also the state it retains on behalf of a given Agent. 528 Accordingly, the status notification should be able to express the 529 following situations: 530 . Middlebox going out of service 531 . Middlebox returned to service, having retained all state 532 (i.e. sessions, Policy Rules and associated timers) 533 . Middlebox returned to service, state information lost or 534 stale 535 . Middlebox congested. 537 [4:2.1.7]: autonomous reporting of conditions and autonomous actions 539 The main thrust of the explanation of this requirement is that the 540 Middlebox be able to report autonomously actions taken with regard to 541 particular Policy Rules. The information passed must therefore 542 include the Policy Rule identifier(s), the action taken, and the 543 reason for the action. 545 [4:2.1.8]: mutual authentication 547 This requirement bears upon session startup in the first place, with 548 proper follow-up to maintain the integrity of the session in 549 subsequent messages. 551 [4:2.1.9]: either entity can terminate a session 553 This implies a formal exchange to terminate a session. Issue: does 554 the end of a session uninstall all Policy Rules installed during that 555 session? 557 [4:2.1.10]: MIDCOM Agent can determine success or failure of a 558 request 560 This implies that every request must have a reply, and the reply must 561 indicate the outcome of the request. 563 [4:2.1.11]: version interworking 565 There seems to be agreement to include protocol version in each 566 message, governing the content of that message. It is possible the 567 initial message of a session should include an additional parameter 568 listing the versions supported by the originator. 570 If the protocol has identifiable options the initial message of the 571 session in each direction should include a parameter indicating what 572 options the message sender supports. 574 [4:2.1.12]: deterministic behaviour for overlapping rulesets 576 There is some dispute over what deterministic means in this case. 577 The issue is described at length in section 1.2.4 above. In keeping 578 with existing implementation, we postulate an aggregate model of 579 Middlebox operation as follows: 581 a) rules are retained in their original form (including mappings) 582 rather than aggregated; 584 b) as each packet passes through the Middlebox, it is checked 585 against the filter portion of each active rule in turn; 587 c) if a match is found, the action associated with that rule is 588 applied; 590 d) if no match is found, the default action set by the Middlebox 591 administrator is applied; 593 e) rules are evaluated in the order in which they were installed 594 (first-come, first-served). 596 For a given sequence of rules this always gives the same per-packet 597 outcomes. In that sense it is deterministic, even if the Agent 598 installing a given rule cannot know in advance what the effect of 599 that rule will be unless it knows the complete sequence of rules 600 installed at the Middlebox. 602 [4:2.2.1]: extensibility 604 It would be possible to add content to the semantic description as a 605 placeholder for new material, but there doesn't seem to be much point 606 in doing so. 608 [4:2.2.2]: control of multiple functions 610 The semantic content of firewall and NAT/NAPT control have been 611 captured in the Policy Rule description in section 2.3. This 612 formulation may also be applicable to other Middlebox types. 614 [4:2.2.3]: ruleset groups 616 The need for information exchanges to create such groups (referred to 617 as session bundles) has been documented above in connection with the 618 scenarios. 620 [4:2.2.4]: ruleset lifetime extension 622 This implies a possible need for several information exchanges: 624 . allowing the Agent to associate a lifetime (and perhaps a 625 grace period) with a Policy rule at the time of 626 installation 628 . allowing the Agent to audit the remaining lifetime for a 629 Policy Rule (most reasonably as a parameter of a general 630 Policy Rule audit capability) 632 . allowing the Middlebox to indicate when a Policy Rule is 633 about to expire 635 . allowing the Agent to reset the remaining lifetime. 637 [4:2.2.5]: action on unknown attributes 639 This requires a sub-field within certain attributes indicating 640 whether the attribute can be ignored if not understood or stops the 641 request from being processed. It also implies that the 642 responses to individual requests must identify components of the 643 request which have caused failure or which have been ignored. 645 [4:2.2.6]: failure reasons 647 A failure reason element must be a potential part of responses. 648 Possible failure reasons are listed in the next section. 650 [4:2.2.7]: multiple authorised Agents working on the same ruleset 652 This implies a requirement either that Policy Rule identifiers are 653 unique across MIDCOM sessions or else that they are always associated 654 with a specific session and the session identifier has to be provided 655 in all messages dealing with Policy Rules. The latter is probably 656 the better approach, because it supports the idea that the 657 termination of a MIDCOM session uninstalls all rules associated with 658 that session. Of course, all of this discussion masks a set of 659 requirements on operations outside of the MIDCOM protocol: sharing of 660 Policy Rule and MIDCOM session identifiers between Agents, and 661 authorization of one Agent to intervene in a session set up by 662 another one. 664 [4:2.2.8]: transport of filtering rules 666 The filters of this semantic analysis are not, of course, the 667 concrete expression of filters in the protocol itself. This analysis 668 indicates within which information exchanges filters will have to be 669 carried. 671 [4:2.2.9]: matching parity ("oddity") 673 This requirement has already been recognized and incorporated in the 674 semantic representation of a Policy Rule filter in section 2.4. See 675 the discussion of the [3:7.2] scenario. 677 [4:2.2.10]: ranges of ports 679 Also covered in section 2.4. The requirement extends beyond RTP/RTCP 680 pairs to sequences of such pairs required for layered encoding. 682 [4:2.2.11]: contradictory actions for sub-filters 684 Assuming that the contradictory actions are represented by separate 685 Policy Rules, and assuming the model of Middlebox operation described 686 in the discussion of requirement [4:2.1.12], this requirement is met 687 provided that the rule with the sub-filter is installed before the 688 main rule. This is an operational requirement given semantics 689 already defined. 691 Requirements For Security 693 The security-related requirements postulated in [4:2.3] will have 694 semantic consequences, but the details depend on the chosen 695 mechanisms. 697 4. MIDCOM Semantics: Pulling It All Together 699 This section describes the required MIDCOM information exchanges in 700 detail. The exchanges shown here will not necessarily map one-to-one 701 into the messages of the MIDCOM protocol which realize them. 703 4.1 MIDCOM Session Initiation 705 A->M: Session Initiate Request 706 M->A: Session Initiate Answer 708 The Session Initiate Request initiates an association between a 709 MIDCOM Agent and a Middlebox. As required by [3:4], this is always 710 sent by the Agent. Required parameters include: 711 . the Agent identifier, 712 . authenticating information, 713 . MIDCOM protocol version information, and 714 . information on MIDCOM extensions supported by the Agent. 716 The Session Initiate Answer indicates the Middlebox acceptance or 717 rejection of the proposed session. It must contain the following 718 information: 720 . the Middlebox identifier, 721 . authenticating information 722 . MIDCOM protocol version information, and 723 . result indicator. Possible results are "successful", "not 724 authorized", "too busy", "version not supported", and "request 725 error". The latter result covers syntax errors, protocol 726 errors, and unrecognized elements. 728 If the request was successful, the response must also contain: 730 . a MIDCOM session identifier unique at the Middlebox, and 731 . information on MIDCOM extensions supported by the Middlebox. 733 4.2 Policy Rule Installation 735 A->M: Rule Install Request 736 M->A: Rule Install Answer 738 The Rule Install Request is a request to the Middlebox to add the 739 rule presented in the request. It is assumed that the Middlebox 740 implements the aggregate model of rule application described in the 741 discussion of requirement [4:2.1.12] in section 3. 743 The Rule Install Request must contain the following information: 745 . Agent identifier 746 . authenticating information 747 . MIDCOM session identifier 748 . a Policy Rule identifier unique to the session 749 . the Policy Rule itself. The content of the Policy Rule has been 750 discussed in sections 2.3 and 2.4 above, and is summarized 751 formally in section 5. 752 . requested rule lifetime. Issue: should the range of possible 753 values include a value for "forever", which means that the rule 754 could outlast the session? 756 Upon receiving a Rule Install Request, the Middlebox must first 757 determine whether the requesting Agent has the authority to make this 758 request, taking into account the filter(s) specified within the rule. 759 If the mapped address component of the filter(s) contains CHOOSE 760 elements, the Middlebox must if possible make concrete address and/or 761 port assignments to these elements. In any event it must return a 762 Rule Install Answer. 764 The Rule Install Answer must contain the following information: 766 . Middlebox identifier 767 . authenticating information 768 . MIDCOM session identifier, copied from the request 769 . the Policy Rule identifier, copied from the request 770 . a result indicator. Possible results are "successful", "not 771 authorized", "too busy", "out of resources", or "request 772 error". 773 . if successfully installed, the Policy Rule itself, with any 774 CHOOSE components replaced by actual assignments. If multiple 775 ports were requested, the response provides the first (lowest- 776 numbered) port of the assigned sequence and echoes back the 777 number of requested (and assigned) ports. 778 . if the rule was successfully installed, the granted rule 779 lifetime. 781 4.3 Rule Delete 783 A->M: Rule Delete Request 784 M->A: Rule Delete Answer 786 The Rule Delete Request asks the Middlebox to uninstall the indicated 787 Policy Rule. The requesting Agent may ask for deletion of a rule 788 created in a session different from its own. It is a matter of local 789 policy, whether such a request will be granted. It is possible to 790 delete rules individually even when they are contained in a bundle; 791 deletion automatically removes the Policy Rule identifier from the 792 bundle. The Rule Delete Request must contain the following 793 information: 795 . Agent identifier 796 . authenticating information 797 . session identifier of the MIDCOM session in which the Policy 798 Rule was created 799 . Policy Rule identifier of the rule to be uninstalled. 801 The Middlebox responds with a Rule Delete Answer. This must contain 802 the following information: 804 . Middlebox identifier 805 . authenticating information 806 . MIDCOM session identifier, copied from the request 807 . the Policy Rule identifier, copied from the request 808 . a result indicator. Possible results are "successful", "not 809 authorized", "too busy", or "request error". 811 4.4 Rule Reset 813 A->M: Rule Reset Request 814 M->A: Rule Reset Answer 816 The Rule Reset Request asks the Middlebox to rest the remaining 817 lifetime of the indicated Policy Rule. The requesting Agent may ask 818 for reset of a rule created in a session different from its own. It 819 is a matter of local policy, whether such a request will be granted. 820 The Rule Reset Request must contain the following information: 822 . Agent identifier 823 . authenticating information 824 . session identifier of the MIDCOM session in which the Policy 825 Rule was created 826 . Policy Rule identifier of the rule to be reset 827 . Requested new lifetime 829 The Middlebox responds with a Rule Reset Answer. This must contain 830 the following information: 832 . Middlebox identifier 833 . authenticating information 834 . MIDCOM session identifier, copied from the request 835 . the Policy Rule identifier, copied from the request 836 . a result indicator. Possible results are "successful", "not 837 authorized", "too busy", or "request error" 838 . if the request was successful, the new lifetime granted to the 839 rule. 841 4.5 Rule Query 843 A->M: Rule Query Request 844 M->A: Rule Query Answer 846 The Rule Query Request is used to determine installed rules matching 847 a specific pattern. The permitted scope of the query is assumed to 848 be a matter of local policy, although an issue has been raised about 849 this (issue 1.2.8). The Rule Query Request must contain the 850 following information: 852 . Agent identifier 853 . authenticating information 854 . MIDCOM session identifier 855 . a filter expression of the same form as that permitted in a 856 Policy Rule, except that within the mapped address component 857 CHOOSE wildcards are not permitted. 859 The Middlebox must respond with a Rule Query Answer. The Rule Query 860 Answer must contain the following information: 862 . Middlebox identifier 863 . authenticating information 864 . MIDCOM session identifier, copied from the request 865 . a result indicator. Possible results are "successful", "not 866 authorized", "too busy", or "request error". 867 . zero or more Policy Rules. The reported Policy Rules are 868 restricted to those which local policy permits the Agent to 869 know about. A Policy Rule is reported if its filter matches or 870 overlaps the given filter. "Overlap" is defined as a condition 871 where for the filters being compared each of the source 872 endpoint address, mapped address, destination endpoint address, 873 and protocol have a non-empty intersection. 875 For each reported Policy Rule, the Middlebox must also report 877 . remaining lifetime 878 . if allowed by local policy, the Policy Rule identifier and the 879 session identifier for the MIDCOM session in which the Policy 880 Rule was created. 882 4.6 Policy Rule Bundling 884 A->M: Rule Bundle Request 885 M->A: Rule Bundle Answer 887 The Rule Bundle Request asks that a set of Policy Rules created 888 within the same session be bundled together to share a common fate. 889 The information required in the request is: 891 . Agent identifier 892 . authenticating information 893 . MIDCOM session identifier 894 . bundle identifier, unique within the MIDCOM session. If the 895 bundle identifier does not already exist, this request has the 896 semantics of bundle creation; otherwise it implies addition of 897 the listed Policy Rule(s) to the existing bundle. 898 . one or more Policy Rule identifiers, of Policy Rules which have 899 been installed within this MIDCOM session. 901 The Middlebox must respond with the Rule Bundle Answer. This must 902 contain the following information: 904 . Middlebox identifier 905 . authenticating information 906 . MIDCOM session identifier, copied from the request 907 . a result indicator. Possible results are "successful", "not 908 authorized", "too busy", or "request error". 910 If the request is successful, the following additional information 911 must be provided: 913 . the bundle identifier 914 . the complete list of all Policy Rule identifiers in the bundle. 916 4.7 Bundle Delete 918 A->M: Bundle Delete Request 919 M->A: Bundle Delete Answer 921 The Bundle Delete Request asks the Middlebox to uninstall the 922 indicated bundle. The requesting Agent may ask for deletion of a 923 bundle created in a session different from its own. It is a matter 924 of local policy, whether such a request will be granted. The Bundle 925 Delete Request must contain the following information: 927 . Agent identifier 928 . authenticating information 929 . session identifier of the MIDCOM session in which the bundle was 930 created 931 . bundle identifier of the bundle to be uninstalled. 933 The Middlebox responds with a Bundle Delete Answer. This must 934 contain the following information: 936 . Middlebox identifier 937 . authenticating information 938 . MIDCOM session identifier, copied from the request 939 . the bundle identifier, copied from the request 940 . a result indicator. Possible results are "successful", "not 941 authorized", "too busy", or "request error". 943 4.8 Autonomous Rule Deactivation 945 M->A: Rule Removal Notification 946 A->M: Rule Removal Acknowledgement 948 The Rule Removal Notification is issued by the Middlebox when a rule 949 is removed for any reason other than a request from the Agent that 950 created it. The notification must contain the following information: 952 . Middlebox identifier 953 . authenticating information 954 . MIDCOM session identifier of the session in which the rule was 955 created 956 . Policy Rule identifier of the uninstalled rule 957 . Reason information. Possible reasons may include lifetime 958 expiry, removal by other authorized entity, change in local 959 policy, or Middlebox problem. 961 The Agent must respond with a Rule Removal Acknowledgement. This 962 must contain the following information: 964 . Agent identifier 965 . authenticating information 966 . MIDCOM session identifier copied from the notification 967 . Policy Rule identifier copied from the notification. 969 4.9 Middlebox Status 971 M->A: Middlebox Status Notification 972 A->M: Middlebox Status Acknowledgement 974 The Middlebox Status Notification is sent to advise of a material 975 change in Middlebox status. The notification must contain the 976 following information: 978 . Middlebox identifier 979 . authenticating information 980 . MIDCOM session identifier of the MIDCOM session the Middlebox 981 believes is in progress with the target agent 982 . status change information. Possible changes include pending 983 shutdown, return to service with no loss of information, return 984 to service with loss of Policy Rule state, congestion onset, 985 end of congested condition. 986 . for pending shutdown, the time remaining until shutdown. 988 A notification of congestion onset indicates that during the 989 congested period the Middlebox may reject requests because it is 990 overloaded. 992 The Agent responds with a Middlebox Status Acknowledgement. This 993 must contain the following information: 995 . Agent identifier 996 . authenticating information 997 . MIDCOM session identifier copied from the notification. 999 4.10 Session Audit 1001 A->M: Session Audit Request 1002 M->A: Session Audit Answer 1004 The Session Audit Request asks for information on all Policy Rules 1005 and bundles installed in the given session. An Agent other than the 1006 Agent which created the session may issue this request (e.g. to take 1007 over from a failed Agent). Local policy at the Middlebox governs the 1008 response. The request must contain: 1010 . Agent identifier 1011 . authenticating information 1012 . session identifier of the MIDCOM session being audited. 1014 The Session Audit Answer contains the following information: 1016 . Middlebox identifier 1017 . authenticating information 1018 . MIDCOM session identifier copied from the request 1019 . the Policy Rule identifier, Policy Rule itself, and remaining 1020 lifetime of each Policy Rule installed within the session 1021 . the bundle identifier and list of Policy Rule identifiers for 1022 each bundle created within the session. 1024 It is particularly likely that the actual implementation of the 1025 Session Audit Answer within the protocol uses multiple messages. 1027 4.11 Session Termination 1029 A->M or M->A: Session Termination Request 1030 M->A or A->M: Session Termination Answer 1032 The Session Termination Request asks that the peer delete the MIDCOM 1033 session and consider all Policy Rules installed in the session to be 1034 deleted. Issue, previously raised: can persistent rules be defined 1035 that will outlast a session? This request can be issued by an Agent 1036 other than the Agent which created the session; local policy at the 1037 Middlebox determines whether it will be acted on in this case. The 1038 request must contain the following information: 1040 . Requestor identifier 1041 . autheticating information 1042 . session identifier of the session to be terminated. 1044 If a valid request is issued by the Agent which created the session, 1045 the Middlebox must honour and acknowledge it. If the request is 1046 issued by the Middlebox, the Agent may either accept or refuse it. 1047 (The Middlebox has a definitive means of halting a session by issuing 1048 a notification of shutdown if it must do so.) The returned Session 1049 Termination Answer must contain the following information: 1051 . Responder identifier 1052 . authenticating information 1053 . session identifier copied from the request 1054 . result information. Possible results include success, refused, 1055 not authorized (see below), too busy (Middlebox only), or 1056 request error. 1058 5. Formal Syntax 1060 The following syntax specification uses the augmented Backus-Naur 1061 Form (BNF) as described in RFC-2234 [5]. In keeping with the fact 1062 that this is a semantic specification only, the specification 1063 contains no literals. 1065 request = sessionInitiateReq / ruleInstallReq / ruleDeleteReq / 1066 ruleResetReq /ruleQueryReq / ruleBundleReq / 1067 bundleDeleteReq / ruleRemovalNotif / mbStatusNotif / 1068 sessionAuditReq / sessionTerminationReq 1070 response = sessionInitiateAns / ruleInstallAns / ruleDeleteAns / 1071 ruleResetAns /ruleQueryAns / ruleBundleAns / 1072 bundleDeleteAns / ruleRemovalAck / mbStatusAck / 1073 sessionAuditAns / sessionTerminationAns 1075 [ ... to be completed after discussion ] 1077 policyRule = 1*filter action ; filters are ANDed 1079 filter = source mapped destination protocol 1081 source = addressTuple 1083 mapped = (addressTuple / mapRequest) [portCount] [parity] 1084 ; mapRequest may only be present in Rule Install Request 1086 destination = addressTuple 1088 addressTuple = addrType addrSpace addrValue [portValue] 1089 ; portValue is required when addrType is an IP address type 1091 mapRequest = addrType addrSpace (addrValue / CHOOSE) CHOOSE 1093 addrType = IPv4 / IPv6 1095 addrSpace = PUBLIC / PRIVATE 1097 addrValue = address / ANY 1099 portValue = portNumber / ANY 1101 action = PERMIT / DENY 1103 Security Considerations 1105 This draft may receive its own discussion of security considerations, 1106 but for the moment these are well covered by the discussion in [3] 1107 and specific requirements in [4]. 1109 References 1111 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1112 9, RFC 2026, October 1996. 1114 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1115 Levels", BCP 14, RFC 2119, March 1997. 1117 3 P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, 1118 "Middlebox communication architecture and framework", draft-ietf- 1119 midcom-framework-07.txt, February 2002 (approved as RFC). 1121 4 R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 1122 Communications (midcom) Protocol Requirements", draft-ietf-midcom- 1123 requirements-05.txt, November 2001 (approved as RFC). 1125 5 D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1126 Specifications: ABNF", RFC 2234, November 1997. 1128 Acknowledgments 1130 Cedric Aoun contributed to the initial version of this document, 1131 begun before list discussion of the topic of MIDCOM semantics. The 1132 list discussion itself benefited from interventions by Ben Campbell, 1133 Bob Penfield, Paul Sijben, Martin Stiemerling, Christian Huitema, 1134 Scott Brim, Juergen Quittek, Ted Hardie, John LaCour, Andrew Molitor, 1135 Reinaldo Penno, Sanjoy Sen, Jiri Kuthan, James Renko, Joel Halprin, 1136 Cullen Jennings, and Adina Simu. 1138 Author's Addresses 1140 Tom Taylor 1141 Nortel Networks 1142 Ottawa, Canada 1143 Phone: +1 613 736 0961 1144 Email: taylor@nortelnetworks.com