idnits 2.17.1 draft-taylor-midcom-semgen-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 677 has weird spacing: '...cy Rule and p...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (September 2002) is 7887 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: '1' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 724, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 735, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-framework (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-requirements (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '5') Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Middlebox Communications (midcom) T. Taylor 3 Internet Draft Nortel Networks 4 Document: draft-taylor-midcom-semgen-00.txt 5 Expires: March 2003 September 2002 7 General Considerations For MIDCOM Semantics 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 [i]. 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 document was derived from draft-taylor-midcom-semantics-00.txt. 39 The present version incorporates tentative conclusions reached in 40 discussion at the IETF 54 meeting of the MIDCOM WG. It removes the 41 concrete expression of the MIDCOM requests, responses, and 42 notifications in favour of those presented in draft-stiemerling- 43 midcom-semantics-xx.txt. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [ii]. 51 The notation [X:y] (example [3:2.14]) denotes section y of reference 52 X. 54 In message flows, A->M indicates information passed from the MIDCOM 55 Agent to the Middlebox. M->A indicates information passed from the 56 Middlebox to the MIDCOM Agent. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1 Terminology.................................................3 62 1.2 Changes From The Predecessor Documents......................3 63 1.3 New Issues..................................................4 65 2. Semantic Implications Of The MIDCOM Framework..................4 66 2.1 Agent Identity..............................................4 67 2.2 MIDCOM Session..............................................4 68 2.3 Filters, Policy Actions, Policy Rules.......................5 69 2.4 MIDCOM Scenarios............................................7 70 2.5 MIDCOM Timers..............................................11 72 3. Semantic Implications Of The MIDCOM Requirements..............11 74 4. Security Considerations.......................................16 75 5. References....................................................16 76 6. Acknowledgments...............................................16 77 7. Author's Addresses............................................17 79 1. Introduction 81 This document presents the semantics which must be supported by the 82 MIDCOM protocol. The purpose and framework within which this 83 protocol will operate are described in [iii]. The detailed 84 requirements which the protocol must satisfy are described in [iv]. 86 This document first reviews the framework and requirements and draws 87 out their implications for the semantics of the protocol. It then 88 summarizes the results as a series of possible information flows 89 between the MIDCOM agent and middlebox and associated behaviour. It 90 demonstrates that these proposed information flows do indeed meet the 91 requirements. Finally it specifies the semantics formally using 92 ABNF. 94 1.1 Terminology 96 "MIDCOM agent" (or simply "agent") and "middlebox" have the meanings 97 given in [3]. "Agent" in this document always denotes a MIDCOM 98 agent. 100 Terminology is inconsistent between the framework and the 101 requirements documents. This document assumes that the term "policy 102 rule" defined in [3] is the same concept as "ruleset" in [4]. The 103 term "rule" is often used to denote "policy rule". 105 1.2 Changes From The Predecessor Documents 107 The previous list of issues has been cleared on the basis of 108 discussion at the MIDCOM meeting at IETF 54. As a result of that 109 discussion, the following changes have been made in this document: 111 i) Policy rule takeover is now on an individual policy rule rather 112 than session basis. To facilitate this, policy rule identifiers 113 are now specified to be globally unique rather than unique per 114 session. 116 ii) Policy rule life has no relationship to the life of the session 117 in which the rule was created. If the session terminates, the 118 policy rules created in that session remain until they expire. 120 iii) A policy rule is assigned to a group (given a group identifier) 121 when it is created. Group identifiers are also specified to be 122 globally unique. 124 iv) Only the "allow" action is supported. The "deny" action is no 125 longer seen as a requirement. (It is viewed as an 126 administrative rather than MIDCOM function.) 128 v) A policy rule contains only one filter. 130 vi) Address ranges are supported in filter expressions. 132 In addition to these changes: 134 vii) The filter expression has been extended to handle twice-NAT 135 configurations. 137 viii) The "Policy Rule Request" operation in the previous version of 138 this document has been replaced with "Enable Request", to make 139 clear the restricted scope of the operation. This is a follow- 140 on from (iv) above. 142 1.3 New Issues 144 1.3.1 Purpose Of Groups 146 There seemed to be some debate over the role of groups. This 147 document currently assumes that a group is a shortcut reference to 148 the individual policy rules assigned to it. 150 2. Semantic Implications Of The MIDCOM Framework 152 2.1 Agent Identity 154 The framework speaks of the ability for a MIDCOM Policy Decision 155 Point to revoke authorization for a MIDCOM Agent [3:2.9], and of 156 MIDCOM Agent profiles [3:2.11]. For these concepts to be 157 enforceable, the MIDCOM Agent must be associated with an identifier 158 which must be presented at least at the start of a MIDCOM session and 159 which must be associated with its profile. 161 2.2 MIDCOM Session 163 [3:2.12] speaks of the MIDCOM session. [3:4] provides a requirement 164 for a formal information exchange to start up or to terminate a 165 MIDCOM session. Start-up is initiated by the MIDCOM Agent, while 166 either the Agent or Middlebox may terminate the session. This 167 requirement raises the possibility of using a session identifier in 168 subsequent messages to indicate the session to which each is related. 169 However, the present document assumes that the Agent (or Middlebox) 170 identifier and accompanying credentials provide an adequate 171 representation of the session in messages between the two entities. 173 2.3 Filters, Policy Actions, Policy Rules 175 [3:2.15] defines a policy rule as a combination of one or more 176 filters and an action. The basic idea is that packets matching the 177 filter have the action applied to them. The canonical form of the 178 filter in [3] is the 5-tuple: 180 {source address, source port, destination address, destination 181 port, protocol} 183 The MIDCOM meeting at IETF 54 decided that "deny" actions are 184 currently out of scope. This decision is obviously subject to 185 further testing on the Working Group list, but assuming that it 186 stands, the actions we must define are those that allow flows through 187 NATs and firewalls. 189 The 5-tuple shown above is sufficient to identify the packet flows to 190 be enabled if and only if the internal and external address spaces 191 are non-overlapping. In the general case there may be such overlap. 192 To cover this general case, the filter must include a direction, "IN" 193 or "OUT". 195 For a pure firewall operation, the filter itself provides enough 196 information to enable the flow. When the Middlebox performs a NAT or 197 NAPT operation, however, additional information is needed. 199 The discussion which follows uses the term "address-port" for 200 brevity, but address and port should be considered as separate 201 components to be specified in any concrete policy rule. In 202 particular, in some situations one of these components may be 203 specified while the other is left wildcarded. 205 The possibilities are illustrated in Figure 1. 207 ------------- 208 | Middlebox | 209 S | | D 210 Flow A +--------------------->-------------------+ 211 | | 212 S D'| | D 213 Flow B +---------------+----->-------------------+ 214 | | 215 S | |S' D 216 Flow C +--------------------->-----+-------------+ 217 | | 218 S D'| |S' D 219 Flow D +---------------+----->-----+-------------+ 220 | | 221 ------------- 223 Figure 1: Possible Flow Arrangements Through The Middlebox 225 In Figure 1, Flow A represents a pure firewall operation. The source 226 and destination for the incoming packets will be passed on without 227 change in the packets as forwarded. 229 Flow B represents a typical public-to-private flow through a NAT. 230 The source is S in both the arriving and forwarded packets, but the 231 destination is changed from public address-port D' to private 232 address-port D. 234 Flow C represents a typical private-to-public flow through a NAT. 235 The destination is D for the arriving and forwarded packets, but the 236 source is changed from the private address-port S to the public 237 address-port S'. 239 Finally, Flow D represents a twice-NAT situation. Arriving packets 240 have source address-port S, destination address-port D'. Forwarded 241 packets have source address-port S', destination address-port D. 243 To cover all these cases, it is clear that the policy rule has to be 244 augmented by two more components: the source address-port and the 245 destination address-port for the forwarded packet. 247 In some cases it is necessary to enable flows before (typically) the 248 external address-port is known. Thus the policy rule semantics 249 should allow the use of an "ANY" wildcard for either S or D in the 250 notation of Figure 1. 252 In other cases it is necessary to reserve the address-port binding 253 without enabling the flow, since it is contrary to local policy to 254 open a pinhole before the external address is known. The flow is 255 enabled subsequently when the missing information becomes available. 256 Thus the semantics of the MIDCOM protocol must allow for two separate 257 operations: an address-bind request and an enable request, where the 258 latter may update the policy rule by specifying an S or D address- 259 port which was wildcarded in the address-bind request. To tie the 260 two requests together, it is necessary to have a policy rule 261 identifier which the Middlebox can use to correlate them. Further 262 requirements on the policy rule identifier are noted below. 264 Finally, it is sometimes necessary to reserve bindings for a sequence 265 of destination ports, beginning with a port of specified parity (e.g. 266 particularly in the case of RTP/RTCP). 268 Summing up, the complete policy rule consists of a filter part and a 269 mapping part. The filter part consists of the classical 5-tuple 270 describing the arriving packet plus the flow direction. The mapping 271 part consists of the address and port for the source and destination 272 of the packet as forwarded, and the port count where a sequence of 273 ports must be enabled. In addition, the address-bind request may 274 indicate that the first port of a sequence must have a specified 275 parity. 277 2.4 MIDCOM Scenarios 279 [3:7] presents three scenarios for the operation of the MIDCOM 280 protocol in mid-session. 282 Scenario [3:7.1], firewall control 284 The messaging sequence includes three MIDCOM operations: 286 a) A->M: Open up the firewall to outgoing flows of RTP and RTCP. 287 M->A: OK. 289 b) A->M: Open up the firewall to incoming flows of RTP and RTCP. 290 M->A: OK. 292 c) A->M: Close firewall to the previously enabled incoming and 293 outgoing flows. 294 M->A: OK. 296 Operations a) and b) have the semantics of address binding and flow 297 enabling where the source and destination address-ports in the 298 mapping part of the rule are identical to the source and destination 299 address-ports in the filter part. The protocol is UDP, the direction 300 is OUT in the case of a) and IN in the case of b), and no wildcarding 301 is necessary because all of the addresses are known at the time of 302 rule instantiation. Each rule specifies a sequence of two ports. 303 (Specification of parity is unnecessary because the forwarded 304 destination port value is specified explicitly in the mapping part.) 306 Operation c) uninstalls the two rules installed by a) and b). 308 Scenario [3:7.2], NAPT control 310 The messaging sequence includes the following MIDCOM operations: 312 a) A->M: Query Port-BIND for port 5060 incoming to the Middlebox 313 public address. 314 M->A: returns Port-BIND. 316 b) A->M: Query NAT session descriptor for SIP flow from external 317 to private endpoint (where address of latter came from the 318 first query). 320 M->A: returns session descriptor. 322 c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP 323 (adjacent ports). Link sessions to SIP control session. 324 M->A: returns session descriptor. 326 d) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent 327 ports). 328 M->A: returns Port-BINDs. 330 e) A->M: Create NAT session for incoming flows of RTP and RTCP 331 (adjacent ports). Link session to SIP control session. 332 M->A: returns session descriptor. 334 f) A->M: end session bundle. 335 M->A: OK. 337 Operations a) and b) allow the Agent to determine the private address 338 of the internal endpoint. In terms of the filter semantics defined 339 above, these operations are equivalent to a single query requesting 340 the return of any active Policy Rules for which the filter includes 341 the following in its scope: 343 { source address = Ea (the external endpoint address), 344 source port = ANY, 345 destination address = Ma (the external address at the Middlebox), 346 destination port = 5060, 347 protocol = ANY, 348 direction = IN 349 } 351 Note the wildcarded protocol in this expression. Presumably the 352 Middlebox will consult with the MIDCOM PDP to determine the permitted 353 scope of the query. The returned Policy Rule (probably only one in 354 this example) should be associated with an identifier so that it can 355 be referred to in later operations. 357 Operation c) is similar to operation a) in the previous case, except 358 that the address-port values in the mapping part of the policy rule 359 are no longer identical to the corresponding values in the filter 360 part. The address-binding request has a filter part with the 361 content: 363 { source address = Pa (the internal endpoint address), 364 source port = ANY, 365 destination address = CHOOSE, 366 destination port = CHOOSE, 367 protocol = UDP, 368 direction = OUT 370 } 372 The mapping part of the address-binding request is as follows: 374 { source address = CHOOSE, 375 source port = CHOOSE, 376 destination address = Ea (the external endpoint address), 377 destination port = , 378 port count = 2 379 } 381 It is unnecessary to specify parity of the first port in the request 382 because the destination port is specified explicitly. 384 The Middlebox is expected to supply values for the CHOOSE components 385 in its reply. In a twice-NAT configuration it will assign a private 386 address and port to the destination in the filter part; otherwise it 387 will copy the destination address and port from the mapping part. In 388 any event it assigns values to the source address and port in the 389 mapping part. It maintains all of these values as part of the its 390 record of the policy rule, and applies them when the rule is 391 activated (flow enabled). 393 The above expressions for the address-binding filter and mapping 394 parts in fact provide all the information the Middlebox needs even in 395 a pure firewall operation. This makes it clear that it is 396 unnecessary to specify either the filter part destination address- 397 port or the mapping part source address-port in an address-binding 398 request. These can be implicitly assumed to be CHOOSE in all cases. 399 The Middlebox takes appropriate action based on its own 400 configuration, without the Agent needing to be aware of that 401 configuration. 403 Operations d) and e) are semantically equivalent to operation c), 404 except that they apply in the inbound direction with the appropriate 405 filter part source address and mapping part destination address-port. 407 Operations c), d), and e) also require the assignment of the new 408 rules to the same session bundle as the previously installed SIP 409 control Policy Rules. This introduces the concept of a session 410 bundle identifier, which must be supplied at the address-bind stage 411 in case the session is aborted before the flow is ever activated. 412 Since it is the Agent that is aware of the scope of a session, the 413 session bundle identifier is provided in the address-bind request. 415 Operation f) requires an information exchange where the Agent 416 supplies the session bundle identifier and requests deactivation of 417 all rules in the session bundle. 419 Scenario [3:7.3]: Middlebox implementing NAPT and firewall 421 The messaging sequence includes the following MIDCOM operations: 423 a) A->M: Query Port-BIND for mapped address (assumed known), port 424 5060. 425 M->A: returns Port-BIND. 427 b) A->M: Query NAT session descriptor for SIP flow from external to 428 private endpoint. 429 M->A: returns session descriptor. 431 c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP. 432 Link sessions to SIP control session. 433 M->A: returns session descriptor. 435 d) A->M: Open up the firewall to outgoing flows of RTP and RTCP. 436 M->A: OK. 438 e) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent 439 ports). 440 M->A: returns Port-BINDs. 442 f) A->M: Create NAT session for incoming flows of RTP and RTCP. 443 Link session to SIP control session. 444 M->A: returns session descriptor. 446 g) A->M: Open up the firewall to incoming flows of RTP and RTCP. 447 M->A: OK. 449 h) A->M: end NAPT session bundle. 450 M->A: OK. 452 i) A->M: Close firewall to the previously enabled incoming and 453 outgoing flows. 454 M->A: OK. 456 a) and b) are the same as in the previous case. 458 c) is equivalent to the address-bind phase of operation c) in the 459 previous case, while d) corresponds to the flow enabling phase of 460 that operation. Similarly, e) and f) correspond to the address-bind 461 phase of operations d) and e) in the previous case, and g) 462 corresponds to the flow enabling phase of those operations. 464 Finally, h) and i) are semantically equivalent to deactivation of the 465 bundle of rules created in the previous steps. 467 Summary Of Observations 469 In summary, the three scenarios have demonstrated the need for 470 information exchanges supporting querying of instantiated policy 471 rules against a pattern, activating Policy Rules (generally with 472 wildcards), creating bundles of Policy rules, deactivating individual 473 policy rules, and deactivating bundles of Policy Rules. 475 2.5 MIDCOM Timers 477 [3:8.3] talks about the potential usefulness of timers in the MIDCOM 478 protocol, to facilitate resource cleanup. This raises the question 479 of whether the timer values should be visible to the Agent. Given 480 that their intended use is to compensate for Agent outages, an 481 information exchange prior to timer expiry seems indicated. 483 3. Semantic Implications Of The MIDCOM Requirements 485 This section reviews the semantic implications of the requirements 486 documented in [4]. 488 [4:2.1.1]: authorization. 490 This requirement implies the need for credentials in any request the 491 Agent sends to the Middlebox, sufficient to allow the latter to 492 determine the Agent's scope of authority. 494 [4:2.1.2]: one MIDCOM Agent dealing with multiple Middleboxes 496 This implies that a parameter must be present in each message coming 497 from a Middlebox, identifying that Middlebox uniquely. The session 498 identifier discussed in section 2.2 might serve that purpose, beyond 499 the initial setup of the session. 501 [4:2.1.3]: one Middlebox dealing with multiple MIDCOM Agents 503 Similarly, this implies that a parameter must be present in each 504 message coming from a MIDCOM Agent, identifying that MIDCOM Agent 505 instance uniquely. MIDCOM Agent identifiers were discussed in 506 section 2.1. Again, the session identifier may serve the purpose 507 after initial session setup. 509 [4:2.1.4]: deterministic Middlebox behaviour when multiple MIDCOM 510 Agents interact with it. 512 This implies several points: 514 . well-defined Middlebox behaviour when it processes 515 requests, particularly when conflicts are encountered; 517 . the behavioural equivalent of mutual exclusion, such that 518 requests affecting the same resources (for example, 519 involving overlapping filter specifications) are required 520 to be processed serially; 522 . requests can be of sufficiently large extent that the Agent 523 can accomplish what it needs in a single request, thus 524 avoiding deadlock. 526 [4:2.1.5]: known and stable state 528 The explanation of this requirement suggests that a request 529 identifier parameter is needed for each request, that each request 530 must have a reply, and that the reply must include the request 531 identifier parameter as well as the result of the request. 533 The requirement also appears to imply the need for a MIDCOM Agent to 534 be able to audit the Middlebox state as it relates to requests made 535 in the past by that Agent. As an optimization, the audit request may 536 include parameters limiting the scope of the audit. The response 537 includes a state parameter expressed as a sequence of Policy Rules. 538 In view of the potential volume of information, provision should be 539 made for segmentation of the response. 541 Auditing can be seen as an additional use of the query exchange 542 documented as part of the scenario analysis in section 2.4. 544 [4:2.1.6]: Middlebox reporting status 546 This implies a a need for a Middlebox to send autonomous 547 notifications to a MIDCOM Agent. It is assumed that [4:2.1.6] 548 relates to the operational status of the Middlebox as a whole, and 549 possibly also the state it retains on behalf of a given Agent. 550 Accordingly, the status notification should be able to express the 551 following situations: 552 . Middlebox going out of service 553 . Middlebox returned to service, having retained all state 554 (i.e. sessions, Policy Rules and associated timers) 555 . Middlebox returned to service, state information lost or 556 stale 557 . Middlebox congested. 559 [4:2.1.7]: autonomous reporting of conditions and autonomous actions 561 The main thrust of the explanation of this requirement is that the 562 Middlebox be able to report autonomously actions taken with regard to 563 particular Policy Rules. The information passed must therefore 564 include the Policy Rule identifier(s), the action taken, and the 565 reason for the action. 567 [4:2.1.8]: mutual authentication 569 This requirement bears upon session startup in the first place, with 570 proper follow-up to maintain the integrity of the session in 571 subsequent messages. 573 [4:2.1.9]: either entity can terminate a session 575 This implies a formal exchange to terminate a session. Based on 576 discussion at IETF 54, the end of a session does not affect the life 577 of policy rules created during that session. 579 [4:2.1.10]: MIDCOM Agent can determine success or failure of a 580 request 582 This implies that every request must have a reply, and the reply must 583 indicate the outcome of the request. 585 [4:2.1.11]: version interworking 587 There seems to be agreement to include protocol version in each 588 message, governing the content of that message. It is possible the 589 initial message of a session should include an additional parameter 590 listing the versions supported by the originator. 592 If the protocol has identifiable options the initial message of the 593 session in each direction should include a parameter indicating what 594 options the message sender supports. 596 [4:2.1.12]: deterministic behaviour for overlapping rulesets 598 There is some dispute over what deterministic means in this case. 599 The issue is described at length in section 1.2.4 above. In keeping 600 with existing implementation, we postulate an aggregate model of 601 Middlebox operation as follows: 603 a) rules are retained in their original form (including mappings) 604 rather than aggregated; 606 b) as each packet passes through the Middlebox, it is checked 607 against the filter portion of each active rule in turn; 609 c) if a match is found, the action associated with that rule is 610 applied; 612 d) if no match is found, the default action set by the Middlebox 613 administrator is applied; 615 e) rules are evaluated in the order in which they were installed 616 (first-come, first-served). 618 For a given sequence of rules this always gives the same per-packet 619 outcomes. In that sense it is deterministic, even if the Agent 620 installing a given rule cannot know in advance what the effect of 621 that rule will be unless it knows the complete sequence of rules 622 installed at the Middlebox. 624 [4:2.2.1]: extensibility 626 It would be possible to add content to the semantic description as a 627 placeholder for new material, but there doesn't seem to be much point 628 in doing so. 630 [4:2.2.2]: control of multiple functions 632 The semantic content of firewall and NAT/NAPT control have been 633 captured in the Policy Rule description in section 2.3. This 634 formulation may also be applicable to other Middlebox types. 636 [4:2.2.3]: ruleset groups 638 The need for information exchanges to create such groups (referred to 639 as session bundles) has been documented above in connection with the 640 scenarios. 642 [4:2.2.4]: ruleset lifetime extension 644 This implies a possible need for several information exchanges: 646 . allowing the Agent to associate a lifetime (and perhaps a 647 grace period) with a Policy rule at the time of 648 installation 650 . allowing the Agent to audit the remaining lifetime for a 651 Policy Rule (most reasonably as a parameter of a general 652 Policy Rule audit capability) 654 . allowing the Middlebox to indicate when a Policy Rule is 655 about to expire 657 . allowing the Agent to reset the remaining lifetime. 659 [4:2.2.5]: action on unknown attributes 660 This requires a sub-field within certain attributes indicating 661 whether the attribute can be ignored if not understood or stops the 662 request from being processed. It also implies that the 663 responses to individual requests must identify components of the 664 request which have caused failure or which have been ignored. 666 [4:2.2.6]: failure reasons 668 A failure reason element must be a potential part of responses. 669 Possible failure reasons are listed in the next section. 671 [4:2.2.7]: multiple authorised Agents working on the same ruleset 673 This implies a requirement that Policy Rule identifiers are unique 674 within the Middlebox, hence should be assigned by the Middlebox in 675 the reply to the address-bind request. Of course, this masks a set 676 of requirements on operations outside of the MIDCOM protocol: sharing 677 of Policy Rule and possibly session bundle identifiers between 678 Agents, and authorization of one Agent to operate on policy rules set 679 up by another one. 681 [4:2.2.8]: transport of filtering rules 683 The filters of this semantic analysis are not, of course, the 684 concrete expression of filters in the protocol itself. This analysis 685 indicates within which information exchanges filters will have to be 686 carried. 688 [4:2.2.9]: matching parity ("oddity") 690 This requirement has already been recognized and incorporated in the 691 semantic representation of a Policy Rule filter in section 2.3. 693 [4:2.2.10]: ranges of ports 695 Also covered in section 2.3. The requirement extends beyond RTP/RTCP 696 pairs to sequences of such pairs required for layered encoding. 698 [4:2.2.11]: contradictory actions for sub-filters 700 Assuming that the contradictory actions are represented by separate 701 Policy Rules, and assuming the model of Middlebox operation described 702 in the discussion of requirement [4:2.1.12], this requirement is met 703 provided that the rule with the sub-filter is installed before the 704 main rule. This is an operational requirement given semantics 705 already defined. 707 Requirements For Security 709 The security-related requirements postulated in [4:2.3] will have 710 semantic consequences, but the details depend on the chosen 711 mechanisms. 713 4. Security Considerations 715 This draft may receive its own discussion of security considerations, 716 but for the moment these are well covered by the discussion in [3] 717 and specific requirements in [4]. 719 5. References 721 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 722 BCP 9, RFC 2026, October 1996. 724 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 725 Levels", BCP 14, RFC 2119, March 1997. 727 [3] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, 728 "Middlebox communication architecture and framework", draft- 729 ietf-midcom-framework-07.txt, RFC 3303, August 2002. 731 [4] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 732 Communications (midcom) Protocol Requirements", draft-ietf- 733 midcom-requirements-05.txt, RFC 3304, August 2002. 735 [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 736 (NAT) Terminology and Considerations", RFC 2663, August 1999. 738 6. Acknowledgments 740 Cedric Aoun contributed to the initial version of this document, 741 begun before list discussion of the topic of MIDCOM semantics. The 742 list discussion itself benefited from interventions by Ben Campbell, 743 Bob Penfield, Paul Sijben, Martin Stiemerling, Christian Huitema, 744 Scott Brim, Juergen Quittek, Ted Hardie, John LaCour, Andrew Molitor, 745 Reinaldo Penno, Sanjoy Sen, Jiri Kuthan, James Renko, Joel Halprin, 746 Cullen Jennings, and Adina Simu. 748 7. Authors Address 750 Tom Taylor 751 Nortel Networks 752 Ottawa, Canada 753 Phone: +1 613 736 0961 754 Email: taylor@nortelnetworks.com