idnits 2.17.1 draft-sct-midcom-megaco-pkg-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: ---------------------------------------------------------------------------- ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 49 characters in excess of 72. ** The abstract seems to contain references ([2], [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 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 2001) is 8259 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-02) exists of draft-sct-midcom-megaco-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-07) exists of draft-ietf-midcom-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-framework (ref. '3') ** Obsolete normative reference: RFC 3015 (ref. '4') (Obsoleted by RFC 3525) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: Standards Track Nortel Networks 6 Expires on March 2002 September 2001 8 MEGACO Middlebox Packages 9 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 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. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This draft is work-in-progress, intended to satisfy some of the 33 requirements in [1] that are not met by the Megaco base protocol as 34 discussed in [2]. It defines three types of Packages: 36 - the base Middlebox Package containing properties and events 37 supported by all Middlebox Terminations 39 - the Firewall Package, extending the base package, containing 40 properties and events supported by Middlebox Terminations 41 supporting firewall functions. 43 - the NAT Package, extending the base package, containing 44 properties and events supported by Middlebox Terminations 45 supporting NAT function 47 A generic model to extend the base Middlebox package and new 48 command error codes for Middlebox control are also discussed. 50 Table of Contents 52 Status of this Memo................................................1 53 Abstract...........................................................1 54 1 Introduction ...................................................2 55 2 Conventions used in this document ..............................3 56 3 Midcom Terminologies and Concepts [3] ..........................3 57 4 ARCHITECTURE ...................................................3 58 5 BASE MIDDLEBOX PACKAGE .........................................4 59 5.1 PROPERTIES ....................................................5 60 5.2 EVENTS ..........................................................9 61 5.3 STATISTICS .....................................................10 62 5.4 SIGNALS ........................................................10 63 5.5 PROCEDURES .....................................................10 64 6 BASIC FIREWALL PACKAGE ........................................10 65 6.1 PROPERTIES .....................................................11 66 6.2 EVENTS .........................................................11 67 6.3 STATISTICS .....................................................11 68 7 BASIC NAT PACKAGE .............................................11 69 7.1 PROPERTIES .....................................................11 70 7.2 EVENTS .........................................................12 71 7.3 STATISTICS .....................................................12 72 8 NEW COMMAND ERROR CODES.........................................12 73 9 Package creation model for new Middlebox functions..............13 74 10 Security Considerations........................................13 75 11 IANA Considerations............................................13 76 12 References.....................................................13 77 13 Acknowledgments................................................14 78 14 Author's Address...............................................14 79 15 Intellectual Property Statement................................14 80 16 Full Copyright Statement.......................................14 82 1 Introduction 84 This draft is work-in-progress, intended to satisfy some of the 85 requirements in [1] that are not met by the Megaco base protocol as 86 discussed in [2]. It defines three types of Packages: 88 - the base Middlebox Package containing properties and events 89 supported by all Middlebox Terminations 91 - the Basic Firewall Package, extending the base Middlebox 92 package, containing properties and events supported by Middlebox 93 Terminations supporting basic packet-filtering functions. 95 - the Basic NAT Package, extending the base Middlebox package, 96 containing properties and events supported by Middlebox 97 Terminations supporting basic Address/Port translation functions. 99 A generic model to extend the Middlebox packages and new command 100 error codes for Middlebox control are also discussed. 102 2 Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 106 this document are to be interpreted as described in RFC-2119. 108 3 Midcom Terminologies and Concepts [3] 110 Middlebox: a device that has router functionality and either 111 alters the content of the IP header or drops or forwards packets 112 depending on the filtering rule that is applied. 114 Midcom Agent or Agent: an entity performing an application layer 115 gateway (ALG) function, logically external to a Middlebox. Midcom 116 agents possess a combination of application awareness and 117 knowledge of the Middlebox function. 119 Ruleset: A logical Middlebox resource comprised of a matching 120 expression for packet flows (flow descriptor) and the actions 121 specified on the packets that match the flow descriptor (e.g., 122 drop, modify certain fields of the IP header etc.) 124 Midcom protocol: The protocol between a Midcom agent and a 125 Middlebox that allows the Midcom agent to gain access to 126 Middlebox resources and allows the Middlebox to delegate 127 application specific processing to Midcom agent. 129 The above terminologies are aligned with the terminologies currently 130 used in the Midcom WG and may evolve in time. The draft will be 131 updated to reflect any modification of the terminology. 133 4 ARCHITECTURE and REQUIREMENTS 135 [3] describes the general Midcom architecture consisting of the Agent 136 and the Middlebox. When the Agent detects the initiation of an 137 application session requiring Middlebox service, it requests the 138 Middlebox to establish a ruleset for the application flow. The 139 request should carry the following information at the minimum: 141 - suitable descriptor (5 elements minimum - source address, source 142 port, destination address, destination port, protocol id) to 143 identify the flow(s) 144 - actions (allow, drop, IP address/port translation, or other IP 145 header manipulation) to be performed on the matched packets 146 - time-to-live(s) to be associated with the ruleset 147 - information (if required) for the Middlebox to determine the 148 interface(s) with which the ruleset should be associated 150 NOTE: The properties discussed in this draft are for the purpose 151 of illustration of key ideas and are likely to change with time. 152 The Midcom WG is in the process of defining the minimum set of 153 information to be carried by the protocol. The next version of the 154 draft should reflect the consensus of the Working Group. 156 The Middlebox should be able to detect Events such as ruleset timer 157 expiry, element failure etc., and report them to the Agent. It 158 should also be able to collect relevant statistics, e.g., the number 159 of packets on which a proposed action has been performed, for 160 reporting them to the Agent. All these parameters are carried in 161 Megaco requests and responses and are defined in these packages. 163 To model the Middlebox functions such as firewall, NAT etc., a new 164 Middlebox Termination type is defined. Such a Termination can be 165 associated with an interface and MUST contain the following 166 parameters - flow descriptor and action(s). In order to allow 167 multiple agents manipulate a ruleset (a key Midcom requirement), the 168 latter is kept separate from the Termination. A Termination shall be 169 associated with a single ruleset, but a ruleset may be associated 170 with more than one Termination. Thus, a Termination can share a 171 ruleset with another Termination, or have a ruleset partially 172 overlapping with that of another Termination. This model allows two 173 Agents, controlling two distinct Terminations manipulate the same or 174 overlapping ruleset(s) as discussed in [2]. A Termination will also 175 support an Event Timer. 177 At start-up or service change, the Middlebox capabilities, including 178 all the Terminations and Packages supported, are queried using the 179 AuditCapabilities command. It is assumed that a trust relationship 180 between the Middlebox and the Agent has already been established at 181 this stage (using IPSec, for example, as the underlying transport 182 mechanism). 184 5 BASE MIDDLEBOX PACKAGE 185 PackageID: mb (serial number TBD) 186 Version: 1 187 Extends: None 188 Description: This package is supported by all Middlebox terminations. 189 It contains the following properties associated with TerminationState 190 descriptor: Ingress Realm, Source Address, Source Port, Egress Realm, 191 Destination Address, Destination Port, Protocol Identifier, RTP 192 Support, and Action. It also contains the following Events: Ruleset 193 Expiry and Element Failure. 195 5.1 PROPERTIES 197 1) Ingress Realm 199 PropertyId: inrealm (0x0001) 201 Description: indicates the realm from which the flow enters the 202 Middlebox. This property can be specified, left unspecified or 203 wildcarded (ALL). The Ingress Realm property, in conjunction with 204 Source Address, is used by the MB to determine the ingress 205 interface(s) with which the ruleset shall be associated. This 206 determination is governed by the following rules: 208 I. If both the Ingress Realm and the Source Address are specified, 209 the MB should be able to uniquely determine the ingress interface 210 with which the ruleset shall be associated. 212 II. If the Ingress Realm is specified and the Source Address is 213 wildcarded, the ruleset shall be associated with all ingress 214 interfaces under the Ingress Realm. 216 III. If the Ingress Realm is left unspecified by the Agent, the 217 ruleset must NOT be associated with any interface unless the Egress 218 Realm is specified. 220 IV. If the Ingress Realm is wildcarded with ALL, the Agent is 221 requesting the MB to determine its interface with which the ruleset 222 shall be associated (from routing table). Note: this assumes that the 223 Source Address be globally routable. If not, the Agent is required to 224 know the Realm. 226 Type: string - syntax TBD 228 Values: as set by the Network Administrator. Can be specified, left 229 unspecified or wildcarded (only ALL). 231 Defined in: TerminationState descriptor 233 Characteristics: read/write 234 2) Source Address 236 PropertyId: srcaddr (0x0002) 238 Description: indicates the source address or range of addresses for 239 identifying flow(s). Source Address can be used in conjunction with 240 the Ingress Realm to determine the interface(s) with which a ruleset 241 shall be associated (See above). 243 Type: string - syntax TBD 245 Values: Can be either specified (as a complete address or address 246 range) or wildcarded (only ALL). 248 Defined in: TerminationState descriptor 250 Characteristics: read/write 252 3) Source Port 254 PropertyId: srcport (0x0003) 256 Description: indicates the source port or range of ports for 257 identifying flow(s). 259 Type: integer 261 Values: Can be either specified (as a complete address or address 262 range) or wildcarded (only ALL). 264 Defined in: TerminationState descriptor 266 Characteristics: read/write 268 4) Egress Realm 270 PropertyId: egrealm (0x0004) 272 Description: indicates the destination realm of the flow from the MB. 273 This property can be specified, left unspecified or wildcarded (ALL). 274 The Egress Realm property, in conjunction with Destination Address, 275 is used by the MB to determine the egress interface(s) with which the 276 ruleset shall be associated. This determination is governed by the 277 following rules: 279 I. If both the Egress Realm and the Destination Address are 280 specified, the MB should be able to uniquely determine the egress 281 interface with which the ruleset shall be associated. 283 II. If the Egress Realm is specified and the Destination Address 284 is wildcarded, the ruleset shall be associated with all egress 285 interfaces under the Egress Realm. 287 III. If the Egress Realm is left unspecified by the Agent, the 288 ruleset must NOT be associated with any interface unless the Ingress 289 Realm is specified. 291 IV. If the Egress Realm is wildcarded with ALL, the Agent is 292 requesting the MB to determine its interface with which the ruleset 293 shall be associated (from routing table). Note: this assumes that the 294 Destination Address be globally routable. If not, the Agent is 295 required to know the Realm. 297 Type: string - syntax TBD 299 Values: as set by the Network Administrator. Can be specified, left 300 unspecified or wildcarded (only ALL). 302 Defined in: TerminationState descriptor 304 Characteristics: read/write 306 5) Destination Address 308 PropertyId: destaddr (0x0005) 310 Description: indicates the destination address or range of addresses 311 for identifying flow(s). Destination Address can be used in 312 conjunction with the Egress Realm to determine the interface(s) with 313 which a ruleset shall be associated (See above). 315 Type: string - syntax TBD 317 Values: Can be either specified (as a complete address or address 318 range) or wildcarded (only ALL). 320 Defined in: TerminationState descriptor 322 Characteristics: read/write 324 6) Destination Port 325 PropertyId: destport (0x0006) 327 Description: indicates the destination port or range of ports for 328 identifying flow(s). 330 Type: integer 332 Values: Can be either specified (as a complete address or address 333 range) or wildcarded (only ALL). 335 Defined in: TerminationState descriptor 337 Characteristics: read/write 339 7) Protocol Identifier 341 PropertyId: protoid (0x0007) 343 Description: identifies the protocol datagram being carried in the IP 344 packet 346 Type: string 348 Values: 350 Defined in: TerminationState descriptor 352 Characteristics: read/write 354 8) RTP Support 356 PropertyId: rtp (0x0008) 358 Description: Specifies whether or not an RTCP flow will be associated 359 with an RTP packet flow in opposite direction. This translates into 360 the MB allocating port bind or opening pinhole for the port 361 consecutive to the RTP port, and that the address translation result 362 is as follows: RTP address a/portx, RTCP address a/portx +1 <-> RTP 363 address b/porty, RTCP address b/porty + 1. It is assumed that if an 364 RTP flow is allowed, the corresponding RTCP flow will always be 365 allowed. The default value is set to FALSE. 366 Type: Boolean 368 Values: TRUE, FALSE 369 Defined in: TerminationState descriptor 371 Characteristics: read/write 373 9) Action 375 PropertyId: action (0x0009) 377 Description: Specifies the action that should be applied by the 378 Middlebox on the matched packets. Extension to this Package will add 379 possible values to action. 381 Type: Enumeration 383 Values: 385 Defined in: TerminationState descriptor 387 Characteristics: read/write 389 5.2 EVENTS 391 1) Ruleset Expiry 393 EventID: rule-expiry (0x0001) 395 Description: Indicates that the ruleset-timer associated with a 396 Termination has expired. 398 EventDescriptor Parameters: 400 Timer 401 ParameterID: timer (0x0001) 402 Description: timer associated with the Termination 403 Type: integer 404 Possible values: in sec 406 ObservedEventDescriptor Parameters: None added to this Package 408 2) Element Failure 410 EventID: mbfail 412 Description: Indicates a failure in the processing of the Middlebox 413 function 414 EventDescriptor Parameters: none added by this package 416 ObservedEventDescriptor Parameters: 418 Error code 419 ParameterID: ec 420 Description: describes the failure reason 421 Type: integer, 0 to 99 422 Possible values: 423 1 Firewall failure 424 2 NAT failure 426 5.3 STATISTICS 428 None 430 5.4 SIGNALS 432 None 434 5.5 PROCEDURES 436 The Agent creates a new Termination in a Context when it wants to 437 create a new ruleset on behalf of the application. It subtracts the 438 Termination from the Context when the ruleset is no longer needed. 440 The Agent associates a Timer Event with a Termination (and 441 implicitly, with a ruleset). Thus, by virtue of the one-to-many 442 association between the ruleset and Terminations (i.e., when a 443 ruleset is shared by multiple Agents), a ruleset may be associated 444 with multiple Timers, each controlled by an Agent. When a Timer 445 expires, the Agent is notified of that Event by the Middlebox. The 446 Agent may choose to refresh the ruleset by sending a MODIFY command 447 to the Termination. 449 6 BASIC FIREWALL PACKAGE 451 PackageID: bas-fw (serial number TBD) 452 Version: 1 453 Extends: mb 455 Description: This package describes the properties required by the 456 Middlebox Termination to perform basic packet filtering function. 458 6.1 PROPERTIES 460 The Property Action in the Base Package is extended to specify 461 possible packet-filtering actions: "Allow" and "Drop". 463 6.2 EVENTS 465 None 467 6.3 STATISTICS 469 1) Packets Dropped 471 ParameterID: pktsdrop (0x0001) 473 Description: Number of packets dropped by the Termination in a 474 session 476 Units: in packets 478 Defined in: Statistics descriptor 480 7 BASIC NAT PACKAGE 482 PackageID: bas-nat (serial number TBD) 483 Version: 1 484 Extends: mb 486 Description: This package provides the properties required by the 487 Middlebox Termination to perform address and port translation (NAPT) 488 function 490 7.1 PROPERTIES 492 1) NAT Action 494 PropertyId: nat-action (0x00010) 496 Description: used by the MB to specify whether only address 497 translation or both address and port translation can be performed by 498 the Termination on matched packets 500 Type: Enumeration 501 Values: "Address", "Address-port" 503 Defined in: TerminationState descriptor 505 Characteristics: read only 507 2) Bind Values 509 PropertyID: Bindvals (0x00011) 511 Description: Allows the MB to specify the translated address/port 512 information to the MA. Also allows the MA to offer hint to the MB 513 about the translated address/port. 515 Type: String - detailed syntax TBD 517 Values: 519 Defined in: TerminationState descriptor 521 Characteristics: read/write 523 7.2 EVENTS 525 None 527 7.3 STATISTICS 529 1) Packets Translated 531 ParameterID: trans (0x0002) 533 Description: Number of packets translated by the Termination in a 534 session 536 Type: Double integer 538 Units: in packets 540 Defined in: Statistics descriptor 542 8 NEW COMMAND ERROR CODES 544 Errors consist of an IANA registered error code and an explanatory 545 string. Megaco consists of a list of IANA registered error codes. 546 Following are the new ones that need to be added to that list for the 547 purpose of Midcom: 549 582 Ports unavailable 550 Description: used by a Middlebox NAPT to indicate to the 551 Agent about unavailability of ports for translation. 553 583 Address and port already in use 554 Description: used by a Middlebox NAPT to indicate to the 555 Agent that the requested Address/port is already in service 557 584 Port already in use 558 Description: used by a Middlebox NAPT to indicate to the 559 Agent that the requested port is already in service 561 585 Resource already in use 562 Description: used to indicate contention when multiple Agents 563 attempt to access/modify the same ruleset 565 9 Package creation model for new Middlebox functions 567 The protocol should be able to incorporate several new types of 568 Middlebox functions. All new functions can be modeled as extensions 569 to the base Middlebox package. The new package will follow the 570 structure of the standard Megaco packages as defined in [4]. 572 10 Security Considerations 574 Please refer to [3] for discussions. 576 11 IANA Considerations 578 The document describes new Packages for Middleboxes providing 579 firewall and NAT functionality. The document also describes new 580 command error codes. Both of the above will need IANA registration. 582 12 References 584 [1] Brim et. al., "Midcom Requirements", midcom-reqs-bullets- 585 010910.txt, work in progress 586 [2] Sen, Aoun, Taylor, "Applicability of Megaco for Middlebox 587 Control", draft-sct-midcom-megaco-00.txt, work in progress 588 [3] Srisuresh, Kuthan, Rosenberg," MIDCOM Architecture & Framework", 589 Internet draft, draft-ietf-midcom-framework-03.txt 590 [4] "MEGACO Protocol Version 1.0", RFC 3015 591 13 Acknowledgments 593 The authors would like to thank Mark Watson for his useful comments 594 related to this draft. 596 14 Author's Address 598 Sanjoy Sen 599 Nortel Networks 600 sanjoy@nortelnetworks.com 602 Cedric Aoun 603 Nortel Networks 604 cedric.aoun@nortelnetworks.com 606 Tom Taylor 607 Nortel Networks 608 taylor@nortelnetworks.com 610 15 Intellectual Property Statement 612 The IETF takes no position regarding the validity or scope of any 613 intellectual property or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; neither does it represent that it 617 has made any effort to identify any such rights. Information on the 618 IETF's procedures with respect to rights in standards-track and 619 standards-related documentation can be found in BCP-11. Copies of 620 claims of rights made available for publication and any assurances 621 of licenses to be made available, or the result of an attempt made 622 to obtain a general license or permission for the use of such 623 proprietary rights by implementors or users of this specification 624 can be obtained from the IETF Secretariat. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights which may cover technology that may be required to practice 629 this standard. Please address the information to the IETF Executive 630 Director. 632 16 Full Copyright Statement 633 Copyright (C) The Internet Society (2000). All Rights Reserved. 635 This document and translations of it may be copied and furnished to 636 others, and derivative works that comment on or otherwise explain it 637 or assist in its implementation may be prepared, copied, published 638 and distributed, in whole or in part, without restriction of any 639 kind, provided that the above copyright notice and this paragraph 640 are included on all such copies and derivative works. However, this 641 document itself may not be modified in any way, such as by removing 642 the copyright notice or references to the Internet Society or other 643 Internet organizations, except as needed for the purpose of 644 developing Internet standards in which case the procedures for 645 copyrights defined in the Internet Standards process must be 646 followed, or as required to translate it into languages other than 647 English. The limited permissions granted above are perpetual and 648 will not be revoked by the Internet Society or its successors or 649 assigns. This document and the information contained 650 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 651 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 652 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 653 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 654 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 655 PARTICULAR PURPOS E."