idnits 2.17.1 draft-sct-midcom-megaco-02.txt: -(204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(365): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(530): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(567): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 56 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 289 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [RFC1889], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (May 2002) is 8017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 612 looks like a reference -- Missing reference section? '2' on line 613 looks like a reference -- Missing reference section? '4' on line 617 looks like a reference -- Missing reference section? 'RFC1889' on line 483 looks like a reference -- Missing reference section? '3' on line 615 looks like a reference -- Missing reference section? '5' on line 619 looks like a reference -- Missing reference section? '6' on line 620 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Midcom Working Group Sanjoy Sen 3 Internet Draft Cedric Aoun 4 Tom Taylor 5 Category: Informational Nortel Networks 6 Expires on Nov 2002 May 2002 8 Applicability of MEGACO to Middlebox Control 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This draft discusses the applicability of the Megaco/H.248 device 35 control protocol [1] as the Middlebox communication protocol. It 36 discusses the architectural similarities between Megaco and Midcom 37 and how Megaco meets most of the key requirements for the Midcom 38 protocol. Modeling the underlying Middlebox resources (such as, 39 filters, policy rules etc) as separate elements from the Megaco 40 entities allows the usage of the protocol as-is, satisfying some of 41 the resource access control requirements. Minimal extensions in the 42 form of new Termination/Package definition (without impacting the 43 base protocol) are sought for Midcom. The Midcom protocol profile 44 and other extensions/packages will be specified in a separate 45 internet draft. 47 Table of Contents 49 Status of this Memo................................................1 50 Abstract...........................................................1 51 1 Introduction...................................................2 52 2 Conventions used in this document..............................3 53 3 Midcom Terminologies and Concepts..............................3 54 4 Megaco Architectural Model.....................................3 55 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom 56 Architectural Frameworks...........................................4 57 5.1 Midcom Requirements MET by Megaco..............................4 58 5.2 Midcom requirements partially met by Megaco....................9 59 5.3 Midcom Requirements NOT met by Megaco.........................11 60 6 APPENDIX: Modeling Approach.....................................11 61 7 References......................................................13 62 8 Acknowledgments...............................................13 63 9 Author's Address..............................................13 64 10 Intellectual Property Statement...............................14 65 11 Full Copyright Statement......................................14 67 1 Introduction 69 This draft discusses the applicability of the Megaco/H.248 device 70 control protocol [1] as the Middlebox communication protocol. It 71 discusses the architectural similarities between Megaco and Midcom 72 and how Megaco meets most of the key requirements for the Midcom 73 protocol. Modeling the underlying Middlebox resources (e.g., 74 filters, policy rules) as separate elements from the Megaco entities 75 allows the usage of the protocol as-is, satisfying some of the 76 resource access control requirements. Minimal extensions in the form 77 of new Termination / Package definition (without impacting the base 78 protocol) are sought for Midcom. 80 Section 3 introduces some of the key Midcom terminologies and 81 concepts. Section 4 provides an overview of the Megaco architectural 82 model. Section 5 depicts the similarities between Megaco and Midcom 83 frameworks and discusses how Megaco meets most of the key Midcom 84 protocol requirements. This section also points out the requirements 85 that are either partially met or are not met. In Section 6, we 86 discuss an approach to model Middlebox resources that are shared and 87 would need access control, as separate elements from Megaco 88 entities, and provide directions towards minimal protocol extensions 89 in the form of new Midcom-oriented Packages. 91 2 Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC-2119. 97 3 Midcom Terminologies and Concepts 99 All terminologies used in this document are consistent with the 100 terminology defined in [2]. 102 4 Megaco Architectural Model 104 Megaco [1] is a master-slave, transaction-oriented protocol in which 105 Media Gateway Controllers (MGC) control the operation of Media 106 Gateways (MG). Originally designed to control IP Telephony 107 gateways, it is used between an application-unaware device (the 108 Media Gateway) and an intelligent entity (the Media Gateway 109 Controller) having application awareness. 111 The Megaco model includes the following key concepts: 113 1. Terminations: Logical entities on the MG that act as sources or 114 sink of packet streams. Can be physical or ephemeral. A Termination 115 is associated with a single MGC. 117 2. Context: An association between Terminations for sharing media 118 between the Terminations. Terminations can be added, subtracted from 119 a Context and can be moved from one Context to another. A Context 120 and all of the Terminations it contains are associated with a single 121 MGC. 123 3. Virtual Media Gateways: A physical MG can be partitioned into 124 multiple virtual MG's allowing multiple Controllers to interact with 125 disjoint sets of Contexts/Terminations within a single physical 126 device. 128 4. Transactions/Messages: Each Megaco command applies to one 129 Termination within a Context and generates a unique response. 130 (Commands may be replicated implicitly so that they act on all 131 Terminations of a given Context through wildcarding of Termination 132 identifiers.) Multiple commands addressed to different Contexts can 133 be grouped in a Transaction structure. Similarly, multiple 134 Transactions can be concatenated into a Message. 136 5. Descriptors/Properties: A Termination is described by a number of 137 characterizing parameters or Properties, which are grouped in a set 138 of Descriptors that are included in commands and responses. 140 6. Events and signals: A Termination can be programmed to detect 141 certain events and notify the Agent or perform certain actions. 143 7. Packages: Packages are groups of properties, events etc. 144 associated with a Termination. Packages are simple means of 145 extending the protocol to serve various types of devices or 146 Middleboxes. 148 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom 149 Architectural Frameworks 151 In the Midcom architecture, the Middlebox plays the role of an 152 application-unaware device being controlled by the application-aware 153 Agent. The Midcom Agent (MA) and the Middlebox (MB) perform similar 154 roles to those of the Media Gateway Controller and the Media 155 Gateway, respectively, in the Megaco architecture. The following 156 Sections present an analysis of the capabilities of the protocol to 157 meet the Midcom requirements defined in [4] by the Midcom Working 158 Group. Owing to the architectural similarities between the two 159 protocols, the following terms will be used interchangeably in rest 160 of the draft � 161 1) Midcom Agent and Media Gateway Controller 162 2) Middlebox and Media Gateway 164 5.1 Midcom Requirements MET by Megaco 166 �2.1.2. 168 The Midcom protocol must allow a Midcom agent to communicate with 169 more than one Middlebox simultaneously. 171 In any but the most simple network, an agent is likely to want to 172 influence the behavior of more than one middlebox. The protocol 173 design must not preclude the ability to do this.� 175 MEGACO allows an MA to control several Middle Boxes. Each message 176 carries an identifier of the endpoint that transmitted the message 177 allowing the recipient to determine the source. 179 �2.1.3. 181 The Midcom protocol must allow a middlebox to communicate with more 182 than one Midcom agent simultaneously. 184 There may be multiple instances of a single application or multiple 185 applications desiring service from a single middlebox, and differ- 186 ent agents may represent them. The protocol design must not pre- 187 clude the ability to do so.� 188 Megaco has the concept of Virtual Media Gateways (VMG) within a 189 single physical MG that allows multiple MGCs communicate 190 simultaneously with the same MG, sharing resources in a conflict- 191 free manner. 193 �2.1.4. 195 Where a multiplicity of Midcom Agents are interacting with a given 196 middlebox, the Midcom protocol must provide mechanisms ensuring that 197 the overall behavior is deterministic. 199 This states that the protocol must include mechanisms for avoiding 200 race conditions or other situations in which the requests of one 201 agent may influence the results of the requests of other agents in 202 an unpredictable manner.� 204 As discussed under 2.1.3, Megaco supports the concept of VMG�s to 205 make these interactions deterministic and avoid resource access 206 conflicts. Each VMG has a single owner (in a MGC) and there can be 207 no overlap between the sets of Terminations belonging to multiple 208 VMGs. The Megaco protocol messages also include the identifier of 209 the sending entity, so that the MG can easily determine whom to 210 send the response back or whom to asynchronously report certain 211 events that have taken place. 213 �2.1.5. 215 The Midcom protocol must enable the Middlebox and any associated 216 Midcom agent to establish known and stable states. This must 217 include the case of power failure, or other failure, where the 218 protocol must ensure that any resources used by a failed element can 219 be released.� 221 Megaco has extensive Audit capabilities to keep states 222 synchronized between the MG and the MGC. Megaco also provides the 223 MGC with the ability to do mass resets as well as individual 224 resets. MGC can always release resources in MG. The MG can also 225 initiate the release of resources by the MGC. 227 �2.1.6. 229 The middlebox must be able to report its status to a Midcom agent 230 with which it is associated.� 232 Megaco has extensive Audit capabilities for the MG to report 233 status information to the MGC. It can also report some status 234 updates using the ServiceChange command. 236 �2.1.7. 238 The protocol must support unsolicited messages from middlebox to 239 agent, for reporting conditions detected asynchronously at the 240 middlebox. 242 It may be the case that exceptional conditions or other events at 243 the middlebox (resource shortages, intrusion mitigation) will cause 244 the middlebox to close pinholes or release resources without 245 consulting the associated Midcom agent. In that event the protocol 246 must allow the middlebox to notify the agent.� 248 MEGACO supports asynchronous events notification using the Notify 249 command. 251 �2.1.8. 253 The Midcom protocol must provide for the mutual authentication of 254 Midcom agent and middlebox to one another. 256 In addition for the more obvious need for the Midcom agent to 257 authenticate itself to the middlebox, there are some attacks 258 against the protocol which can be mitigated by having the middlebox 259 authenticate to the agent.� 261 MEGACO provides that IPSec be used for all security mechanisms 262 including mutual authentication, integrity check and encryption. 263 Use of IKE is recommended with support of RSA signatures and 264 public key encryption. 266 �2.1.9. 268 The Midcom protocol must allow either the Midcom agent or the 269 middlebox to terminate the Midcom session between a Midcom Agent and 270 a middlebox. This allows either entity to close the session for 271 maintenance, security or other reasons.� 273 The MEGACO protocol allows both peers to terminate the association 274 with proper reason code. 276 �2.1.10. 278 A Midcom agent must be able to determine whether or not a request 279 was successful. 280 This states that a middlebox must return a success or failure 281 indication to a request made by an agent.� 283 Megaco defines a special descriptor called an Error descriptor 284 that contains error code and an optional explanatory string. 286 �2.1.11. 288 The Midcom protocol must contain version interworking capabilities 289 to enable subsequent extensions to support different types of 290 middlebox and future requirements of applications not considered at 291 this stage. 293 We assume that there will be later revisions of this protocol. The 294 initial version will focus on communication with firewalls and 295 NATs, and it is possible that the protocol will need to be modified 296 as support for other middlebox types is added. These version 297 interworking capabilities may include (but not be limited to) a 298 protocol version number.� 300 Version interworking and negotiation are supported both for the 301 protocol and any extension Packages. 303 �2.2.1. 305 The syntax and semantics of the Midcom protocol must be extensible 306 to allow the requirements of future applications to be adopted. 308 This is related to, but different from, the requirement for 309 versioning support. As support for additional middlebox types is 310 added there may be a need to add new message types.� 312 Megaco is easily extensible through new Packages that allow 313 definition of new attributes and behavior of a Termination. 315 �2.2.2. 317 The Midcom protocol must support the ability of an agent to install 318 a policy rule that governs multiple types of middlebox actions (e.g. 319 Firewall and NAT). 321 This states that the protocol must support policy rules and actions 322 for various types of middleboxes. A Midcom agent ought to be able 323 to have a single Midcom session with a middlebox and use the Midcom 324 interface on the middlebox to interface with different middlebox 325 functions on the same middlebox interface.� 327 Megaco supports the aggregation of commands for various 328 Terminations (or Middlebox functions) within a single message 329 transaction. 331 �2.2.3. 333 The protocol must support the concept of a policy rule comprising 334 a multiple of individual {filter, action} pairs to be treated as an 335 aggregate. 337 Applications using more than one data stream may find it more 338 convenient and more efficient to be able to use single messages to 339 tear down, extend, and manipulate all middlebox rulesets being used 340 by one instance of the application.� 342 In Megaco, a Termination can be modeled as a Policy rule 343 comprising of multiple filter and action pairs (see Appendix). A 344 Termination can be created, modified and deleted as a whole. 346 Megaco also supports the ability to aggregate multiple commands 347 into a single transaction and multiple transactions into a single 348 message. 350 �2.2.4. 352 The protocol must allow the midcom agent to extend the lifetime of 353 an existing policy rule that otherwise would be deleted by the 354 middle box.� 356 The MG can report the imminent expiry of a policy rule to the MGC 357 that can then extend or delete the corresponding Termination. 359 �2.2.6. 361 To enable management systems to interact with the Midcom 362 environment, the protocol must include failure reasons that allow 363 the Midcom Agent behavior to be modified as a result of the 364 information contained in the reason. Failure reasons need to be 365 chosen such that they do not make an attack on security easier.� 367 The MG can provide Error codes in response messages allowing the 368 MGC to modify its behavior. 370 Megaco uses transaction identifiers for correlation between a 371 response and a command; in case the same transaction id is 372 received more than once, the receiving entity silently discards 373 the message. This provides some protection against replay attacks. 375 �2.2.8. 377 The Midcom protocol must be able to carry filtering rules, 378 including but not limited to the 5-tuple, from the midcom agent to 379 the middlebox. 381 By "5-tuple" we refer to the standard tuple. 383 Other filtering elements may be carried, as well.� 385 Megaco protocol can carry descriptors and properties defining all 386 types of filters and associated actions. 388 �2.2.11. 390 It should be possible to define policy rules that contain a more 391 specific filter spec than an overlapping policy rule. This should 392 allow agents to request actions for the subset that contradict those 393 of the overlapping set. 395 This should allow the Midcom agent to request to a Midcom server 396 controlling a firewall function that a subset of the traffic that 397 would be allowed by the overlapping policy rule be specifically 398 disallowed.� 400 This requirement would be met if the policy in the Middlebox 401 allows contradictory, overlapping policy rules to be installed. 403 �2.3.1. 405 The Midcom protocol must provide for message authentication, 406 confidentiality, and integrity.� 408 Megaco provides for these functions with the combined usage of 409 IPSEC or TLS. 411 �2.3.2. 413 The Midcom protocol must allow for optional confidentiality 414 protection of control messages. If provided the mechanism should 415 allow a choice in the algorithm to be used.� 417 Megaco provides for these functions with the combined usage of 418 IPSEC or TLS. 420 �2.3.4. 422 The Midcom protocol must define mechanisms to mitigate replay 423 attacks on the control messages.� 425 Megaco commands and responses include matching transaction 426 identifiers. The recipient receiving the same transaction id more 427 than once would discard the message, thus providing some 428 protection against replay attacks. If even stronger protection 429 against replay attack is needed, Megaco provides for the use of 430 IPSec or TLS. 432 5.2 Midcom requirements partially met by Megaco 434 �2.1.12. 436 It must be possible to deterministically predict the behavior of 437 the middlebox in the presence of overlapping rules. 438 The protocol must preclude nondeterministic behavior in the case 439 of overlapping rulesets, e.g. by ensuring that some known 440 Precedence is imposed.� 441 This is met with the help of a model that separates Megaco 442 protocol elements from the overlapping Policy rules (see 443 Appendix). However, new behavior for the Megaco protocol elements 444 needs to be specified as part of a new MIDCOM specific Package. 446 �2.2.5. 448 If a peer does not understand an option it must be clear whether 449 the action required is to proceed without the unknown attribute 450 being taken into account or the request is to be rejected. Where 451 attributes may be ignored if not understood, a means may be 452 provided to inform the client about what has been ignored. 454 This states that failure modes must be robust, providing sufficient 455 information for the agent or middlebox to be able to accommodate 456 the failure or to retry with a new option that is more likely to 457 succeed.� 459 Megaco entities provide Error codes in response messages. If a 460 command marked "Optional" in a transaction fails, the remaining 461 commands will continue. 463 However, the above requirement deals with rules of processing 464 properties that need definition in new Package. 466 �2.2.7. 468 The Midcom protocol must not preclude multiple authorized agents 469 from working on the same policy rule.� 471 In case the Megaco state machine on the Middle Box is decoupled 472 from the Middle Box policy rule management, this requirement is 473 met with local policies on the Middle Box. However, this is in 474 violation of the spirit of the Megaco protocol, hence this is 475 presented under partial compliancy. 477 �2.2.9. 479 When the middlebox performs a port mapping function, the protocol 480 should allow the Midcom agent to request that the external port 481 number have the same oddity as the internal port. 483 This requirement is to support RTP and RTCP [RFC1889] "oddity" 484 requirements.� 486 Megaco can be easily extended using a MIDCOM specific Package to 487 support this feature. 489 �2.2.10. 491 When the middlebox performs a port mapping function, the protocol 492 should allow the Midcom agent to request that a consecutive range 493 of external port numbers be mapped to consecutive internal ports. 495 This requirement is to support RTP and RTCP "sequence" 496 requirements.� 498 Megaco can be easily extended using a MIDCOM specific Package to 499 support this feature. 501 5.3 Midcom Requirements NOT met by Megaco 503 �2.1.1. 505 The Midcom protocol must enable a Midcom agent requiring the 506 services of a middlebox to establish an authorized association 507 between itself and the middlebox. 509 This states that the protocol must allow the middlebox to 510 identify an agent requesting services and make a determination as to 511 whether or not the agent will be permitted to do so.� 513 There is a directionality component implicit in this 514 requirement, i.e., the MA should initiate the establishment 515 of the authorized session. Megaco allows this association to 516 be established in the opposite direction, i.e., the Middlebox 517 (MG) initiates the establishment. But, if one ignores this 518 restriction, then Megaco makes the syntax and semantics 519 available for the endpoint to initiate the connection. 521 6 APPENDIX: Modeling Approach 523 To model the Middlebox functions such as firewall, NAT etc., a new 524 Middlebox Termination type needs to be defined within Megaco. If 525 policy-rule overlap or modification by multiple Agents is NOT 526 required, then a policy rule is equivalent to a Termination (see 527 Figure 1). The various components of a Policy rule such as filter, 528 action, life-time, creator etc. are described as various properties 529 of a Termination. Use of the Virtual Media Gateway (VMG) concept 530 allows for conflict-free interaction of multiple MA�s with the same 531 MB. 533 +-------+ +-------+ 534 | MA-1 | | MA-2 | 535 | | | | 536 +-------+ |IF2 +-------+ 537 | | | 538 +-------------|---------|----------|-----------+ 539 | +---------+ | +-------------+ | 540 IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 541 ----------| |Tx|-------+ +---|Ty|--|Tz|---------------- 542 | | +--+ | | | +--+ +--+ | | 543 | ....| | | +-------------+ | 544 | +---------+ | | 545 | +--------------------------------- 546 | Middlebox | IF4 547 +----------------------------------------------+ 549 Tx: Termination x = Policy rule x 550 Ty: Termination y = Policy rule y 551 Tz: Termination z = Policy rule z 552 MA: Midcom Agent 553 IF: Interface 555 Figure 1. 557 If it is required to allow multiple agents manipulate the same 558 Middlebox resource (e.g., a Policy rule or a filter), the latter 559 needs to be kept separate from the Termination (the Policy rule is 560 manipulated by the MA by manipulating the properties of the 561 associated Termination). For example, if overlapping policy rule 562 manipulation is required, then a Termination shall be associated 563 with a single policy rule, but a policy rule may be associated with 564 more than one Termination. Thus, a Termination can share a policy 565 rule with another Termination, or have a policy rule partially 566 overlapping with that of another Termination. This model allows two 567 MA�s, controlling two distinct Terminations (see Figure 2), 568 manipulate the same or overlapping policy rules. In Figure 2, policy 569 rules 1 and 2 are overlapping and they are shared by MA-1 and MA-2. 571 +-------+ +-------+ 572 | MA-1 | | MA-2 | 573 | | | | 574 +-------+ |IF2 +-------+ 575 | | | MB 576 +-------------|---------|----------|-----------+ 577 | +-----------+ | +-------------+ | 578 IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 579 ------------------|Ty|----+ +---|Tx|--|Tz|---------------- 580 | | +--+ | | | +--+ +--+ | | 581 | .... | | | | +--/------\---+ | 582 | +-------|---+ | / \ | 583 | | +----/----------\------------------ 584 | +------+----+------+ +------+ |IF4 585 | |Policy1 Policy2 | |Policy| | 586 | | | | | | 3 | | 587 | +----+------+------+ +------+ | 588 +----------------------------------------------+ 590 Tx: Termination x 591 Ty: Termination y 592 Tz: Termination z 593 MA: Midcom Agent 594 IF: Interface 595 MB: Middlebox 597 Figure 2. 599 This requires that the Agent and the Middlebox adhere to the 600 following principles: 602 (1) Only one Termination has read/write access to a filter at any 603 time. 604 (2) When the policy rule is being modified by a new agent (i.e. 605 not the one that created the policy) the Middlebox makes a policy 606 decision and decides whether to accept the requested modification 607 or not. In the case the modification is accepted the intial Midcom 608 agent may be notified. 610 7 References 612 [1] "MEGACO Protocol Version 1.0", RFC 3015 613 [2] "Midcom Architecture & Framework", Internet draft, draft-ietf- 614 midcom-framework-03.txt (work in progress) 615 [3] Sen, Aoun, Taylor, "Megaco Middlebox Packages", draft-sct- 616 midcom-package-00.txt, work in progress 617 [4] " Middlebox Communications (midcom) Protocol Requirements", 618 draft-ietf-midcom-requirements-05.txt (work in progress) 619 [5] "IP Authentication Header", RFC 2402 620 [6] "IP Encapsulating Security Payload", RFC 2406 622 8 Acknowledgments 624 The authors would like to thank Mary Barnes and Penno Reinaldo for 625 their useful comments and suggestions related to this draft. 627 9 Author's Address 629 Sanjoy Sen 630 Nortel Networks 631 sanjoy@nortelnetworks.com 633 Cedric Aoun 634 Nortel Networks 635 cedric.aoun@nortelnetworks.com 637 Tom Taylor 638 Nortel Networks 639 taylor@nortelnetworks.com 641 10 Intellectual Property Statement 643 Nortel Networks may be pursuing Intellectual Property Rights for 644 concepts described in this draft. The IPR statement 645 http://www.ietf.org/ietf/IPR/NORTEL-GENERAL is applicable to this 646 draft. 648 11 Full Copyright Statement 650 Copyright (C) The Internet Society (2000). All Rights Reserved. 652 This document and translations of it may be copied and furnished to 653 others, and derivative works that comment on or otherwise explain it 654 or assist in its implementation may be prepared, copied, published 655 and distributed, in whole or in part, without restriction of any 656 kind, provided that the above copyright notice and this paragraph 657 are included on all such copies and derivative works. However, this 658 document itself may not be modified in any way, such as by removing 659 the copyright notice or references to the Internet Society or other 660 Internet organizations, except as needed for the purpose of 661 developing Internet standards in which case the procedures for 662 copyrights defined in the Internet Standards process must be 663 followed, or as required to translate it into languages other than 664 English. The limited permissions granted above are perpetual and 665 will not be revoked by the Internet Society or its successors or 666 assigns. This document and the information contained 667 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 668 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 669 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 670 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 671 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 672 PARTICULAR PURPOSE."