Midcom Working Group Sanjoy Sen Internet Draft Cedric Aoun Tom Taylor Category: Informational Nortel Networks Expires on March 2002 September 2001 Applicability of MEGACO to Middlebox Control Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft discusses the applicability of the Megaco/H.248 device control protocol [1] as the Middlebox communication protocol. It discusses the architectural similarities between Megaco and Midcom and how Megaco meets most of the key requirements for the Midcom protocol. Modeling the underlying Middlebox resources (a.k.a., rulesets) as separate elements from the Megaco entities allows the usage of the protocol as-is, satisfying some of the key resource control requirements. Minimal extensions in the form of new Termination / Package definition (without impacting the base protocol) are sought for Midcom. The Midcom protocol profile and other extensions/packages will be specified in separate internet drafts. Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction ...................................................2 2 Conventions used in this document ..............................3 3 Midcom Terminologies and Concepts [2] ..........................3 4 Megaco Architectural Model .....................................3 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom Architectural Frameworks...........................................4 5.1 Key Midcom Requirements MET by Megaco ..........................5 5.2 Key Midcom Requirements NOT met by Megaco ......................6 6 Modeling Approach ..............................................6 6.1 General Middlebox Structure .....................................6 6.2 Control Dynamics ................................................9 6.3 Capability Discovery ...........................................11 6.4 Example Call Flows - SIP VoIP Call through a Middlebox implementing Firewall service ......................................11 6.4.1 Call Flow Details ............................................13 7 Security Considerations .......................................16 8 References ....................................................17 9 Acknowledgments ...............................................17 10 Author's Address ..............................................17 11 Intellectual Property Statement ...............................17 12 Full Copyright Statement ......................................18 1 Introduction This draft discusses the applicability of the Megaco/H.248 device control protocol [1] as the Middlebox communication protocol. It discusses the architectural similarities between Megaco and Midcom and how Megaco meets most of the key requirements for the Midcom protocol. Modeling the underlying Middlebox resources (a.k.a., rulesets) as separate elements from the Megaco entities allows the usage of the protocol as-is, satisfying some of the key resource control requirements. Minimal extensions in the form of new Termination / Package definition (without impacting the base protocol) are sought for Midcom. Section 3 introduces some of the key Midcom terminologies and concepts. Section 4 provides an overview of the Megaco architectural model. Section 5 depicts the similarities between Megaco and Midcom frameworks and discusses how Megaco meets most of the key Midcom protocol requirements. This section also points out the requirements that are not met. In Section 6, we discuss an approach to modeling Middlebox resources or rulesets as separate elements from Megaco entities, and provide directions towards minimal protocol extensions Sen/Aoun/Taylor Informational - Expires March 2002 [Page 2] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 in the form of new Midcom-oriented Packages. We also provide an example call flow to illustrate the control of a Firewall using Megaco for a SIP VoIP session. Section 7 addresses the security considerations relevant for Midcom. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 Midcom Terminologies and Concepts [2] Middlebox: a device that has router functionality and either alters the content of the IP header, or drops, or forwards packets depending on the filtering rule that is applied. Midcom Agent or Agent: an entity performing an application layer gateway (ALG) function, logically external to a Middlebox. Midcom agents possess a combination of application awareness and knowledge of the Middlebox function. Ruleset: A logical Middlebox resource comprised of a matching expression for packet flows (flow identifiers) and the actions specified on the packets that match the flow identifier (e.g., drop, modify certain fields of the IP header etc.) Midcom protocol: The protocol between a Midcom agent and a Middlebox that allows the Midcom agent to gain access to Middlebox resources and allows the Middlebox to delegate application specific processing to the Agent. The above terminologies are loosely aligned with those currently being used by the Midcom WG and may evolve in time. The draft will be updated to reflect the final terminologies agreed on by the Working Group. 4 Megaco Architectural Model Megaco [1] is a master-slave, transaction-oriented protocol in which Media Gateway Controllers (MGCs) control the operation of Media Gateways (MGs). Originally designed to control IP Telephony gateways, it is used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) having application awareness. The Megaco model includes the following key concepts: Sen/Aoun/Taylor Informational - Expires March 2002 [Page 3] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 1. Terminations: Logical entities on the MG that act as sources or sink of packet streams. Can be physical or ephemeral. A Termination is associated with a single MGC. 2. Context: An association between Terminations for sharing media between the Terminations. Terminations can be added, subtracted from a Context and can be moved from one Context to another. A Context and all of the Terminations it contains are associated with a single MGC. 3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MG's allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device. 4. Transactions/Messages: Each Megaco command applies to one Termination within a Context and generates a unique response. (Commands may be replicated implicitly so that they act on all Terminations of a given Context through wildcarding of Termination identifiers.) Multiple commands addressed to different Contexts can be grouped in a Transaction structure. Similarly, multiple Transactions can be concatenated into a Message. 5. Descriptors/Properties: A Termination is described by a n u m b e r o f characterizing parameters or Properties, which are grouped in a set of Descriptors that are included in commands and responses. 6. Events and signals: A Termination can be programmed to detect certain events and notify the Agent or perform certain actions. 7. Packages: Packages are groups of properties, events etc. associated with a Termination. Packages are simple means of extending the protocol to serve various types of devices or Middleboxes. 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom Architectural Frameworks In the Midcom architecture, the Middlebox plays the role of an application-unaware device being controlled by the application-aware Agent. The Midcom Agent and the Middlebox perform similar roles to those of the Media Gateway Controller and the Media Gateway, respectively, in the Megaco architecture. The following Sections present an analysis of the capabilities of the protocol to meet the Midcom requirements that are being defined by the Working Group. A consolidated summary of key requirements based on the ongoing work is used (Note: as consolidation of the requirements is still in progress in the Working Group, this section reflects only the fundamental ideas based on the requirements-bullets draft [4]. We expect the next version of the draft to reflect the final requirements agreed on by the Working Group). Sen/Aoun/Taylor Informational - Expires March 2002 [Page 4] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 5.1 Key Midcom Requirements MET by Megaco 1. The Midcom protocol must be transaction-oriented and should allow command aggregation. Megaco is transaction-oriented and will allow aggregation of commands and responses through transaction and message structures 2. Actions on failed commands must be clearly specified (proceed or reject) and the protocol should include failure reason codes. Megaco entities provide Error codes in response messages. If a command marked "Optional" in a transaction fails, the remaining commands will continue. 3. The protocol should allow multiple Agents to interact simultaneously with a Middlebox and vice-versa. The Megaco protocol will allow multiple Agents to interact with a Middlebox by demarcation of virtual Middleboxes within a physical Middlebox. The protocol will also allow an Agent to interact with multiple Middleboxes simultaneously. 4. The protocol will allow atomic operation on a ruleset or an aggregate of rulesets. For a single ruleset this is achieved through specification of Middlebox behaviour when processing Megaco requests. Implicit replication of commands to act on all Terminations of a given Context through wildcarding of Termination identifiers is possible (for ruleset to Termination relationship, see Section 6 - Modeling Approach). 5. The protocol must allow multiple Agents to manipulate the same or overlapping ruleset(s). It should support hand-off of a ruleset between the Agents, proper deletion of overlapping rulesets, creation of a ruleset by an agent and deletion by another. See Section 6 - Modeling Approach and Section 6.2 - Control Dynamics 6. Two levels of security association are required: Sen/Aoun/Taylor Informational - Expires March 2002 [Page 5] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 (A) A registration session must exist between the Agent and the Middlebox. Either the Agent or the Middlebox should be able to terminate the registration session. The protocol will allow either the Agent or the Middlebox to terminate an association by using the ServiceChange command. (B) The protocol messages must be securely transported. Megaco specifies that IPSec [5,6] be used as the underlying security mechanism over IP networks. 7. The protocol must allow the Middlebox and the Agent to synchronize state information, perform resource audit and notify the Agent of certain events in the Middlebox. Megaco supports extensive Audit capabilities and asynchronous Event notifications. 8. The protocol must be extensible and provide version interworking capabilities. Megaco is easily extensible through new Terminations /Packages. Both protocol and Package level version interworking are supported. 5.2 Key Midcom Requirements NOT met by Megaco 1. The protocol must allow specification of a flow identifier or pinhole by at least five tuple. A ruleset comprises of a flow identifier and action. 2. The protocol must allow the association of a timer with a ruleset. 3. The Agent must be authenticated by the Middlebox as part of the registration process. 6 Modeling Approach 6.1 General Middlebox Structure To model the Middlebox functions such as firewall, NAT etc., a new Middlebox Termination type needs to be defined within Megaco. Such a Termination can be associated with an interface and MUST contain the Sen/Aoun/Taylor Informational - Expires March 2002 [Page 6] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 following parameters: flow descriptor and action(s). Flow traversal through the Middlebox may require multiple such Terminations linked through a Context (see Figure 1). The lifetime of a Context is expected to be the same as the lifetime of the application flows traversing the Context. The Packages required to define such a Middlebox Termination are described in a separate draft [3]. In order to allow multiple agents to manipulate the same ruleset (a key Midcom requirement), the latter is kept separate from the Termination. A Termination shall be associated with a single ruleset, but a ruleset may be associated with more than one Termination. Thus, a Termination can share a ruleset with another Termination, or have a ruleset partially overlapping with that of another Termination. This model allows two Agents, controlling two distinct Terminations (see Figure 2), manipulate the same or overlapping ruleset(s) as discussed in the next Section. This requires that the Agent and the Middlebox adhere to the following principles: (1) only one Termination has read/write access to a ruleset at any time, and (2) any attempt to modify a ruleset such that it contradicts the existing behavior (action) must be prevented. (This can happen when one of two Agents controlling two different Terminations sharing the same ruleset attempts to modify a property affecting the ruleset.) In all such cases, the requesting Agent shall be informed about the reason for the command failure. A ruleset will be associated with one or more timers implemented through the Terminations that it (the ruleset) is associated with. The ruleset management and handling is left to the underlying operations of the Middlebox. +-------+ | MA | +-------+ | MB +-------------|-----------------------+ | +---|-----------+ | | Context | +--+ + + | | ----------------|Tx| |Ty|------------------- | | +--+ +--+ | | | ........| /\ /\ | | | +-/--\----/--\ + | | +----+ / \ / \ +----+ | | |IF A|--/ +--------+ \--|IF B| | | +----+ |Rule Set| +----+ | | +--------+ | +-------------------------------------+ Sen/Aoun/Taylor Informational - Expires March 2002 [Page 7] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 Tx: Termination x Ty: Termination y MA: Midcom Agent IF: Interface MB: Middlebox Figure 1: Megaco/Midcom Entity Relationships 1. A Midcom Agent(MA) controls a Middlebox (MB). (N-1) 2. A Midcom Agent controls a Context. (1-N) 3. A Midcom Agent controls a Termination. (1-N) 4. A Context associates Terminations. (1-N) 5. A Termination is associated with a ruleset. (N-1) 6. A Termination is associated with an interface. (N-1) 7. A Middlebox contains all of the above except the Midcom Agent (1-N) Sen/Aoun/Taylor Informational - Expires March 2002 [Page 8] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 6.2 Control Dynamics +-------+ | MA 1 | +-------+ | +--------------|----------------------+ | +----|----------+ virtual | |Context c| +--+ +--+ | MB 1 | | | |Tx| |Ty| | | | | +--+ +--+ | | | | \ / | | |---------+---------------+-----------| | \ / | | +---------------+ | | | Rule Set | | | +---------------+ | | / \ | |---------+---------------+-----------| | | / \ | | |Context b| +--+ +--+ | | | | |Ta| |Tz| | | | | +--+ +--+ | virtual | | +-------|-------+ MB 2 | | | | +-----------------|-------------------+ Middlebox | +-----+ |MA 2 + +-----+ Figure 2. Flow traversal through the Middlebox may require multiple Middlebox Terminations linked through a Context. As shown in Figure 2, creating a Context with two Middlebox Terminations (associated with the ingress and egress interfaces, respectively) creates a point-to- point connection for a unidirectional packet flow through the Middlebox matching the flow descriptor defined within the Terminations. A ruleset is created (if necessary) and linked with a Middlebox Termination when the latter is assigned new values for realm (to determine the interface), flow descriptor or action properties (all defined in [3]). This might happen when a new Termination is added to a Context or an existing Termination is modified. In all cases, Sen/Aoun/Taylor Informational - Expires March 2002 [Page 9] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 the request shall be first checked for consistency with the service- authorization policy for the requesting Agent. The detailed rules for ruleset creation are as follows: 1. The Middlebox searches for an exact match between the combination of flow identifier (including wildcards and ranges) and interface given to the Termination, and the corresponding values given to existing rulesets. 2. If an exact match is found the Middlebox compares the action value at the Termination with the action value at the ruleset. If they match, the Termination is linked to the existing ruleset and the procedure is finished. If they do not match, the command creating or modifying the Termination is rejected. 3. If no exact match is found, the Middlebox checks all rulesets whose flow identifiers overlap with that assigned to the Termination to verify that their actions are consistent with the action assigned to the Termination. If this check succeeds, the Middlebox creates a new ruleset with the flow identifier and action the same as those assigned to the Termination and links the Termination to the new Ruleset. If the consistency check fails, the command creating or modifying the Termination is rejected. A ruleset is removed when all the Terminations that it is associated with are deleted. With this logical separation between Termination (or Context) and ruleset, it is possible to satisfy the requirements specified under item 5 in Section 5.1 as follows: 1) Ruleset handoff between Agents: Suppose Agent 1 controls Termination 1 linked to ruleset 1, and Agent 2 controls Termination 2. If Agent 1 wants to hand-off ruleset 1 to Agent 2, the following mechanism is executed: Agent 2 first modifies Termination 2 linking it with ruleset 1. Agent 1 then modifies Termination 1 to delete linkage with ruleset 1. 2) Deletion of overlapping rulesets: The rules on ruleset creation given above permit creation and co-existence of overlapping rulesets. If a ruleset is deleted, there is no effect on any of the rulesets that may overlap it. A ruleset is deleted only when no more Terminations remain associated with it. 3) Creation of a ruleset by an Agent and deletion by another: This requires the following sequence of events, which is permitted by the rules stated above: Sen/Aoun/Taylor Informational - Expires March 2002 [Page 10] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 - the first Agent creates a Termination and associates the ruleset in question with it - the second Agent creates a second Termination associated with the same ruleset - the first Agent deletes its Termination, and finally - the second Agent deletes its Termination. 6.3 Capability Discovery At start-up or service change, the Middlebox capabilities, including all the Terminations and Packages supported, are queried using the Audit Capabilities command. It is assumed that a trust relationship between the Middlebox and the Agent has already been established at this stage using underlying transport-layer mechanism such as IPSec. 6.4 Example Call Flows - SIP VoIP Call through a Middlebox implementing Firewall service In the following call flows, we will assume a Middlebox implementing a firewall service. We further assume that the middlebox is pre- configured to permit SIP calls into the private phone. The following timeline illustrates the operations performed by the Midcom agent to permit RTP/RTCP media stream through the middlebox. User X User Y SIP Phone SIP Proxy Middlebox SIP Phone (Public) (In-Path (FIREWALL (Private) Midcom agent) Service) | | | | F1|----INVITE------>| | | | | | | | Identify flow parameters | | | (from Caller's SDP) | | | for the pri-to-Ext | | | RTP & RTCP sessions | | | | | | | | | | | F2 |++Transc.1{Context ${ | | | |{ADD $}, {ADD $}}} ++>| | | | | | | F3 |<++Reply1{Context 50{ | | | |{ADD T1}, {ADD T2}}+++| | | | | | | | | | | |--------INVITE---------------------->|F4 Sen/Aoun/Taylor Informational - Expires March 2002 [Page 11] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 F5|<---100Trying----| | | | | | | | |<-----180Ringing---------------------|F6 F7|<--180Ringing----| | | | |<-------200OK------------------------|F8 | | | | | Identify flow parameters | | | (from callee's SDP) | | | for the Ext-to-Pri | | | RTP and RTCP sessions | | | | | | | | | | | F9|++Transc.2{Context 50{| | | |{ADD $}, {ADD $}}} ++>| | | | | | | F10|<++Reply2{Context 50{ | | | |{ADD T3}, {ADD T4}}+++| | F11|<---200 OK ------| | | F12|-------ACK------>| | | | |-----------ACK---------------------->|F13 | | | | |<===================RTP/RTCP==========================>| | | | | F14|-------BYE------>| | | | |--------------------------BYE------->| | | | | | |<----------200 OK--------------------|F15 | | | | | F16 |++ Transc.3{ Context50| | | |{{SUBTRACT=ALL}}}++++>| | | | | | | F17 |<+++Reply3{ Context50 | | | |{{SUB.T1},{SUB.T2}, | | | |{SUB.T3},{SUB.T4}}}+++| | | | | | | | | | F18|<---200 OK-------| | | | | | | Legend: ++++ Midcom control traffic ---- SIP control traffic ==== RTP/RTCP media traffic Figure 3. Sen/Aoun/Taylor Informational - Expires March 2002 [Page 12] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 On receiving an INVITE from the public phone, the SIP Proxy (Midcom Agent) sends a Megaco transaction requesting creation of a Context with two ephemeral Middlebox Terminations (Note: one instead of two Terminations can be used, but the call flows are intended to demonstrate protocol flexibility) to allow the RTP/RTCP flow from the private phone to the public phone. On receiving the 200 OK response from the private phone, the Agent requests addition of two more Terminations to the same Context to allow flow from the public phone to the private one. The Context is cleared when a call Termination BYE message is received by the Agent. 6.4.1 Call Flow Details The following message details are based on [3], which describes some proposed Megaco extensions for Midddlebox control in the form of new Middlebox packages. F1. User X sends an INVITE with SDP to user Y via the SIP proxy co- hosted with the Midcom Agent: INVITE sip:y@abc.com SIP/2.0 From: TheXGuy To: TheYGuy v=0 c=IN IP4 47.1.1.1 m=audio 1000 RTP/AVP 0 F2. The SIP Proxy (Midcom Agent) determines the IP address of the called user Y (192.5.5.5) and executes a Megaco transaction to create a Context with two Middlebox Terminations (associated with egress and ingress interfaces) allowing the flow from 192.5.5.5 to 47.1.1.1, port=1000, to pass through the Middlebox: MEGACO/1 [11.11.22.22]:34567 Transaction = 1 { Context = $ { Add = $ { TerminationState = { mb/inrealm = *, mb/srcaddr = "192.5.5.5", mb/srcport = *, mb/egrealm = "public", mb/destaddr = "47.1.1.1", mb/destport = 1000, mb/protoid = "UDP", mb/rtp = TRUE, Sen/Aoun/Taylor Informational - Expires March 2002 [Page 13] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 mb/action = Allow }, Events = 100 { mb/rule-expiry = 300 } } Add = $ { TerminationState = { mb/inrealm = "private", mb/srcaddr = "192.5.5.5", mb/srcport = *, mb/egrealm = *, mb/destaddr = "47.1.1.1", mb/destport = 1000, mb/protoid = "UDP", mb/rtp = TRUE, mb/action = Allow }, Events = 100 { mb/rule-expiry = 300 } } } } F3. The Middlebox creates a Context with two Middlebox Terminations, T1 (associated with an egress interface) and T2 (associated with an ingress interface), and responds with the following: MEGACO/1 [10.10.21.21]:76543 Reply = 1 { Context = 50 { Add = T1, Add = T2 } } F4. The INVITE is forwarded to user Y F5. The Proxy sends a 100 Trying response to user X F6. User Y responds with 180 Ringing F7. Proxy forwards the 180 Ringing to user X F8. User Y answers the phone and a 200 OK is sent towards user X SIP/2.0 200 OK Sen/Aoun/Taylor Informational - Expires March 2002 [Page 14] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 From: TheXGuy To: TheYGuy v=0 c=IN IP4 192.5.5.5 m=audio 2000 RTP/AVP 0 F9. The SIP Proxy (Midcom Agent) determines the receiving port address of the called user Y (port=2000) and executes a Megaco transaction to add two more Middlebox Terminations to the existing Context, allowing the flow from 47.1.1.1 to 192.5.5.5, port=2000, to pass through the Middlebox: MEGACO/1 [11.11.22.22]:34567 Transaction = 2 { Context = 50 { Add = $ { TerminationState = { mb/inrealm = *, mb/srcaddr = "47.1.1.1", mb/srcport = *, mb/egrealm = "private", mb/destaddr = "192.5.5.5", mb/destport = 2000, mb/protoid = "UDP", mb/rtp = TRUE, mb/action = Allow }, Events = 100 { mb/rule-expiry = 300 } } Add = $ { TerminationState = { mb/inrealm = "public", mb/srcaddr = "47.1.1.1", mb/srcport = *, mb/egrealm = *, mb/destaddr = "192.5.5.5", mb/destport = 2000, mb/protoid = "UDP", mb/rtp = TRUE, mb/action = Allow }, Events = 100 { Mb/rule-expiry = 300 } Sen/Aoun/Taylor Informational - Expires March 2002 [Page 15] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 } } } F10. The Middlebox adds two Middlebox Terminations - T3 and T4 - to Context 50, and responds with the following: MEGACO/1 [10.10.21.21]:76543 Reply = 2 { Context = 50 { Add = T3, Add = T4 } } F11. The 200 OK is forwarded by the Proxy to user X. F12, F13. User X sends an ACK message which is forwarded by the Proxy to user Y. Media transmission begins through the firewall. F14. To end the call, user X sends a BYE message, which is forwarded to user Y by the Proxy. F15. User Y responds with a 200 OK F16. The SIP Proxy (Midcom Agent) executes a Megaco transaction to subtract all four Terminations from the Context: MEGACO/1 [11.11.22.22]:34567 Transaction = 3 { Context = 50 { Subtract = ALL } } F17. The Middlebox responds by deleting the Context. F18. The Proxy forwards the 200 OK for the BYE to user X. 7 Security Considerations Security between a Midcom agent and a middlebox has a number of components - authentication, integrity and confidentiality. The security considerations are described in [2], and are briefly discussed under item 6 in Section 5.1 and item 3 in Section 5.2 of this document. Megaco specifies that IPSec [5,6] be the security protocol of choice for IP networks. With IPSec, all requirements discussed under item 6 in Section 5.1 and item 3 in Section 5.2 are met. An interim application layer IPSec AH scheme is supported to allow deployment in IP networks not supporting IPSec. More work is Sen/Aoun/Taylor Informational - Expires March 2002 [Page 16] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 needed if the Midcom protocol needs to support any other security feature. 8 References [1] "MEGACO Protocol Version 1.0", RFC 3015 [2] "Midcom Architecture & Framework", Internet draft, draft-ietf- midcom-framework-03.txt (work in progress) [3] Sen, Aoun, Taylor, "Megaco Middlebox Packages", draft-sct- midcom-package-00.txt, work in progress [4] "Midcom Requirements", midcom-reqs-bullets-010910.txt (work in progress) [5] "IP Authentication Header", RFC 2402 [6] "IP Encapsulating Security Payload", RFC 2406 9 Acknowledgments The authors would like to thank Mark Watson and Penno Reinaldo for their useful comments and suggestions related to this draft. 10 Author's Address Sanjoy Sen Nortel Networks sanjoy@nortelnetworks.com Cedric Aoun Nortel Networks cedric.aoun@nortelnetworks.com Tom Taylor Nortel Networks taylor@nortelnetworks.com 11 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances Sen/Aoun/Taylor Informational - Expires March 2002 [Page 17] Internet Draft Applicability of Megaco to Middlebox Control Sept 2001 of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Sen/Aoun/Taylor Informational - Expires March 2002 [Page 18]