Internet Draft M. Stiemerling Document: draft-stiemerling-midcom-semantics-01.txt J. Quittek Expires: November 2002 NEC Europe Ltd. June 2002 MIDCOM Protocol Semantics Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo discusses semantics for a Middlebox Communication (midcom) protocol, without specifing the concrete syntax or any transport protocol. The intention of this memo is to give input to the discussion on midcom protocol semantics and to provide background material for protocol evaluation. Table of Contents 1 Introduction ................................................. 2 1.1 Terminology ................................................ 4 Stiemerling & Quittek [Page 1] Internet-Draft MIDCOM Protocol Semantics April 2002 1.2 Transaction Defintion Template ............................. 4 2 Protocol Design .............................................. 5 3 Session Control Transactions ................................. 6 3.1 Session Establishment (SE) ................................. 6 3.2 Session Termination (ST) ................................... 8 3.3 Session Termination Asynchronous (STA) ..................... 8 3.4 Session Termination by interruption of Connection .......... 9 3.5 Session State Machine ...................................... 9 4 Group Transactions ........................................... 10 4.1 Group Establishment (GE) ................................... 10 4.2 Group Keep-Alive (GKA) ..................................... 11 4.3 Group Delete (GD) .......................................... 12 4.4 Group Deleted Asynchronous (GDA) ........................... 13 4.5 Group Behaviour on Asynchronous Session Termination ........ 13 4.6 Group State Machine ........................................ 14 5 Policy Rule Transactions ..................................... 14 5.1 Resource Reservation (RR) .................................. 15 5.2 Policy Rule Configuration (PRC) ............................ 16 5.3 Policy Rule Keep-Alive (PKA) ............................... 18 5.4 Policy Rule Delete (PRD) ................................... 19 5.5 Policy Rule Deleted Asynchronous (PRDA) .................... 20 5.6 Behaviour on Asynchronous Session Termination .............. 20 5.7 Policy Rule State Machine .................................. 21 6 Open Issues .................................................. 21 7 Changes ...................................................... 21 7.1 Differences to -00 Version ................................. 21 8 References ................................................... 22 9 Authors' Address ............................................. 22 10 Full Copyright Statement .................................... 23 1. Introduction The MIDCOM working group has defined a framework [1] for the middle box communication as well as a list of requirements [2]. But for specifying a concrete protcol, the clear semantics need to be defined. The documents mentioned above might not be completely sufficient for this purpose. The protocol might need certain capabilities that are not mentioned in the framework or requirements document, but which are inherent to the problem. This memo suggests a semantics for the MIDCOM protocol and it is intended to be a foundation for further discussions on this issue. In conformance with the working group charter, the semantics are targeted at packet filters and network address translators (NATs). The semantics described in this document meet all requirements specified in [2] except requirement 2.2.11. Requirement 2.2.11 is not met, or only partially met. Stiemerling & Quittek [Page 2] Internet-Draft MIDCOM Protocol Semantics April 2002 A major goal of the semantics specification was simplicity and close relation to actual and real problems. They are not intended to provide solutions for many future or rare problems, but to provide a solid foundation of basically required semantics. When specifying the semantics, we used a prototype implementation of based on the SIMCO protocol [3]. The protocol was tested in different scenarios, mostly with applications using SIP signaling. Basically we made two observations which had a major impact on our semantics specification: 1. There were very few cases, where a 'deny' action would have been of use. We found deny action beneficial to have for general middlebox configuration, but not for setting up concrete configurations for pinholes/mappings requested by end- user applications. Only for network management applications there is a clear need to use deny actions. However, we consider management applications configuring NATs to be out of our scope. We found further, that without deny actions, the protocol semantics and the state machine at the PEP can be simplified significantly. Overlapping rules are not a problem anymore for firewalls, because an allow request that completely or partially overlaps with another allow request does not imply any conflict. At a NAT, overlapping requests still may produce conflicts, for example different requests for mapping the same external address to different internal ones. However, only requests may overlap, not configurations. Because overlapping request cannot be configured at the same time, only one of the overlapping requests can be granted at a time. Therefore, also NAT configuration gets significantly simplified in the absence of deny actions. 2. Our second observation was that if a middlebox included NAT and FW functionality, then always both were configured at the same time with analogous requests for FW and NAT configuration, respectively. Our conclusion was that FW and NAT configuration does not necessarily need to be separated by a midcom protocol. We defined the semantics of configuration requests in a way that covers FW and NAT configuration in a single request independent of the capabilities of the middlebox. This again reduces complexity of the protocol and of the related state machines, because (1) the agent does not have to distinguish middleboxes and send them different commands depending on their type, and (2) in case of a combined FW/NAT the combined request for configuring both can be handled as a single transaction. Stiemerling & Quittek [Page 3] Internet-Draft MIDCOM Protocol Semantics April 2002 After modifying our semantics based on these two observations, there is only one mismatch with the requirements: the missing 'deny' action, addressed in the framework and in requirement 2.2.11. This mismatch allowed us to define compaprably simple semantics and state machines. We suggest that a full definition of semantics matching all requirements still will allow a middlebox to support this simple subset. This would allow to also build simple and cheap implementations of midcom-compliant middleboxes. They can state their limitation of not supporting deny actions when indicating their capabilities at session setup. Anyway, adding the missing support of deny actions to the semantics specified in this document does only require defining a few more transactions. We intend to define implement and test them in the near future, but still we think that the transactions defined below are sufficient for most applications and that they constitute a consistent subset of the complete midcom semantics. The next section introduces the needed terminology used throughout this memo. Section 3 explains the general ideas behind the protocol design. The semantics for controlling MIDCOM sessions is specified in section 3, and section 4 introduces the transactions for controling groups of policy rules. Section 5 deals with the actual policy rule configuration process. Open issues and questions are raised in section 6. 1.1. Terminology The general terminology in this memo follows the defintions given in the framework [1] and requirements [2] document. In addition the following terms are used. Request Transaction: A request/reply message transfer from the agent and to the middle box. Notification Transaction: An asychronous message transfer from the middle box and to the agent. Agent unique: A value assigned by the agent. The agent takes care that this value is unique in its context. The context includes all MIDCOM sessions. Middle box unique: A value assigned by the middle box. The middle box takes care that this value is unique in its context. The context includes all MIDCOM sessions. Stiemerling & Quittek [Page 4] Internet-Draft MIDCOM Protocol Semantics April 2002 1.2. Transaction Defintion Template The semantics are specified per transaction and for each transaction the following entities are specified (Parameter entities are only specified if applicable). transaction-name A description name for this type of transaction. transaction-type The transaction type is either 'request' or 'notification'. See above for the description of request transaction and notification transaction. request-parameter This entry lists all parameters that are neccessary for this request. A description for each parameter is given. reply-parameter (success) This entry lists all parameters that are sent back from the middle box to the agent as positive response to the prior request. A description for each parameter is given. reply-parameter (failure) This entry lists all parameters that are sent back from the middle box to the agent as negative response to the prior request. A description for each parameter is given. notification parameters This entry lists all parameters that are used by the middle box to notifiy the agent about any asynchronous event. A description for each parameter is given. semantics This section describes the actual protocol behaviour. 2. Protocol Design The MIDCOM protocol will be subdivided into three phases (see [1], section 4): - Session setup phase - Run-time phase - Session termination phase The session setup and termination phases deal mainly with the MIDCOM Stiemerling & Quittek [Page 5] Internet-Draft MIDCOM Protocol Semantics April 2002 session control. The handling of the actual policy rules, and the corresponding groups, is done in the run-time phase. Whereas some handling of rules and groups may be done during the termination phase too. Hence a handlig of sessions, groups and policy rules is required and this leads to three control groups: - a session control - a group control - a policy rule control These control groups can be handled by far more indepent as in the case of mixing these three controls and thus result in a simplified protocol design. Requests for NATs and packet filters can be handled through different transactions. But this has the obvious drawback that the agent allows has to know what kind of middlebox it is talking to and it has to choose the appropriate set of transactions to request policy rules. To preserve the agent from dealing with this issue, we propose unified transactions for both packet filters and NATs. Since both need the same input information as argued in section 1. The result is only one policy rule transaction set in the semantics. As mentioned in section policy rule transactions the action for the policy rule is always ALLOW. In the context of not defining a complete middlebox management protocol, this restriction of the filter actions make sense: Application proxies have only the need to open pin holes in middleboxes and not to deny certain possible pin holes. This leads again to a simplified processing with respect to the policy rule handling. The next sections introduce the transactions divided by session, groups, and policy rules. 3. Session Control Transactions Before any group or policy rule can be requested, a valid MIDCOM session must exist, i.e. establishing an authorized associaten between agent and server. Therefore agent and middle box control their sessions with establishing or termination transactions. Stiemerling & Quittek [Page 6] Internet-Draft MIDCOM Protocol Semantics April 2002 3.1. Session Establishment (SE) transaction-name : session establishment transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the corresponding request/reply pair at the agent. - version: The version of the MIDCOM protocol - server authentication challenge (sc): A authentication challenge token for the server authentication. - agent authentication (aa): An authentication token to authenticate the agent to the middle box. reply-parameters (success): - request identifier: The request identifier from the request. - middle box authentication (ma): An authentication token to authenticate the middle box to the agent. - agent challenge token (ac): An authentication challenge token for the agent authentication. - middle box capabilities: The agent may need some informationen about the capabilities of the middle box, e.g. to determine which IP protocol it supports. In this reply parameter the middle box may be able to tell various details (to be discussed), e.g.: - type of the middle box (NAT, packet filter, combination of both, etc) - address wildcard support - supported IP version, e.g. IPv6 only - Set or list of supported midcom protocol transactions reply-parameters (failure): - request identifier: The request identifier from the request. - failure reason: A reason why the session establishment transaction failed. The reason may be: Stiemerling & Quittek [Page 7] Internet-Draft MIDCOM Protocol Semantics April 2002 - authentication failed - protocol version of agent and middle box do not match semantics: This session establishment transaction is used to establish a MIDCOM session. For establishing the MIDCOM session both sides authenticate them mutually to avoid man in the middle attacks. This authentication is done via a challenge/response procedure initated by the agent as shown in figure 1: Agent Server | session establishment (parameter with | | challenge sc ) | |-------------------------------------------->| | | | successful reply (parameter with ma & ac) | |<--------------------------------------------| | | | session establishment (parameter with | | agent authentication aa) | |-------------------------------------------->| | | | successful reply (parameter) | |<--------------------------------------------| | | Figure 1: Successful Agent/Server Authentication The authentication may be simplified by using only one session establishment request in case the authentication can be provided by means of a lower layer, e.g. TLS [4] or IPSEC [5][6]. The middle box itself checks with the policy decision point if the requesting agent is authorized to open a MIDCOM session. The agent starts with requesting groups and policy rules after the authentication and authorization is done successfully. 3.2. Session Termination (ST) transaction-name : session termination transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the corresponding request/reply pair at the agent. Stiemerling & Quittek [Page 8] Internet-Draft MIDCOM Protocol Semantics April 2002 reply-parameters (only success): - request identifier: The request identifier from the request. semantics: This transaction type is used to close the MIDCOM session on behalf of the agent. The middle box keeps the groups and policy rules of the requesting agent until their timeout expires, i.e. the groups and policy rules will not be deleted immediately due to this termination request. The middle box generates always a successful reply, independent of any failures in the middle box. Should there be any failure during the termination period, the middle box solves the problem without any notification to the agent. 3.3. Session Termination Asynchronous (STA) transaction-name : session termination asynchronous transaction-type : notification notification-parameters: - termination reason: The reason why the session is terminated without any request from the agent. semantics: The middle box may decided at any point of time to terminate a MIDCOM session. Before terminating the actual session the middle box generates this notification transaction. The impact on groups and policy rules is described in section 4.5 and section 5.6. 3.4. Session Termination by interruption of Connection The network connection between agent and server can be interrupted at any time due to several reasons. The MIDCOM session bound to this connection is not longer associated with agent at this point of time. The server will keep the groups and policy rules of this interrupted session until their timeouts expires and deletes them afterwards. 3.5. Session State Machine The state machine for the session transactions is shown in figure 2.You'll find the transaction abbreviations in the headings of the particular transaction section. Stiemerling & Quittek [Page 9] Internet-Draft MIDCOM Protocol Semantics April 2002 SE/Not_OK +-------+ | v +----------+ | CLOSE |---------------+ +----------+ | SE(sc!=0) | ^ ^ | /OK(ma, ac) | | | | SE | | | auth. | (sc=0, | | | failed/Not_OK v aa=OK)/OK| | | +----------+ | | +-----------| NOAUTH | | | +----------+ | | ST/OK | | | STA | | | | SE(sc=0, v | | aa=OK)/OK +----------+ | | OPEN |<--------------+ +----------+ Figure 2: Session State Machine 4. Group Transactions This section describes the semantics for grouping different policy rules into a single group. Three transactions are required to work with groups: - establishing - timeout extension, called keep-alive - deleting Before any group request can be processed a valid MIDCOM session must exist. The establishment of groups is the premise of any further poliy rule establishment. But it is possible to establish only one group and link all rules to this single group. For the sake of simplicity each policy rule has to belong to one group. 4.1. Group Establishment (GE) transaction-name : group establishment transaction-type : request request-parameters: Stiemerling & Quittek [Page 10] Internet-Draft MIDCOM Protocol Semantics April 2002 - request identifier: Agent unique identifier for matching the corresponding request/reply pair at the agent. - group timeout: A timeout proposal to the middle box for the requested group. reply-parameters (success): - request identifier: The request identifier from the request. - group identifier: A middle box unique group identifier. This is the handle to add or remove policy rules to the group. - group timeout: The group timeout granted by the middle box. reply-parameters (failure): - request identifier: The request identifier from the request. - failure reason: A reason why the group establishment failed. semantics: Prior to any policy rule establishment, a group for keeping these policy rules has to be established. This group establishment transaction generates the necessary structure at the middle box for storing the policy rules. The actual timeout for this group is choosen by the middle box, the proposed timeout of the agent should be considered in this. Should the middle box not be able to fulfill this request, perhaps due to lack of resources, it rejects the request completely and no group is generated. 4.2. Group Keep-Alive (GKA) transaction-name : group keep-alive transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the corresponding request/reply pair at the agent. - group identifier: This identifies the group for which the timeout should be extended. Stiemerling & Quittek [Page 11] Internet-Draft MIDCOM Protocol Semantics April 2002 - group timeout: A new timeout proposal to the middle box for the requested group. reply-parameters (success) : - request identifier: The request identifier from the request. - group identifier: A middle box unique group identifier. - group timeout: The new group timeout granted by the middle box. reply-parameters (failure): - request identifier: The request identifier from the request. - failure reason: A reason why the extensions of the timeout failed. semantics: The agent uses this transaction type to extend the timeout of an already established group. The middle box chooses, as in the group establishment transaction, a timeout value and grants the extension. The timeout of every policy rule belonging to this group is set to the group timeout. Any timeout extension is interpreted as a successful completition of the request. The middle box is allowed to reject the timeout extension with a failure reason. In this case the group and the corresponding policy rules will be removed without any further notification about the deletion of the policy rules of this group. 4.3. Group Delete (GD) transaction-name : group delete transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the corresponding request/reply pair at the agent. - group identifier: This identifies the group which should be deleted. Stiemerling & Quittek [Page 12] Internet-Draft MIDCOM Protocol Semantics April 2002 reply-parameters (only success) : - request identifier: The request identifier from the request. - group identifier: The group identifier from the request. semantics: On behalf of this transaction the middle box deletes immediately all policy rules belonging to this group and afterwards the group itself. The middle box generates always a successfully reply, independent of any failures in the middle box. Should there be any failure during the deletion process, the middle box solves the problem on its own. 4.4. Group Deleted Asynchronous (GDA) transaction-name : group delete asynchronous transaction-type : notification notification-parameters: - group identifier: The group that will be deleted. - deletion reason: The reason why the middle box will delete the group and corresponding policy rules. semantics: The middle box may decide at any point of time to delete a group. The reason may be changes in the policy decision point or resource conflicts. The middle box sends this notifcation to the agent before it deletes the group and the corresponding policy rules. The policy rules belonging to this group will be deleted wihtout any further notification to the agent. 4.5. Group Behaviour on Asynchronous Session Termination As mentioned in section 3.3 the server may terminated the session at any time. In this asynchronous termination case the server will terminate the session and will lookup all groups belonging to this session. These groups will be deleted. For the deletion of policy rules belonging to these groups,see section 5.6. Stiemerling & Quittek [Page 13] Internet-Draft MIDCOM Protocol Semantics April 2002 4.6. Group State Machine The state machine for the group transactions is shown in figure 3 with all possible state transistions. You'll find the used transaction abbreviations in the headings of the particular transaction section. GE/Not_OK +--------+ | v +----------+ | GROUP | | UNUSED | +----------+ | ^ GE/OK | | | | | | GD/OK | | GDA | | GKA/Not_OK v | +----------+ | GROUP | | INUSE | +----------+ | ^ +--------+ GKA/OK Figure 3: Group State Machine 5. Policy Rule Transactions This section describes the semantics for working with policy rules. These actions are required to work with policy rules: - reserve resources in the middle box - configure a policy rule - timeout extension, called keep-alive - deleting As mentioned in section 5, each single policy rule belongs to a group. Therefore a least one group needs to be established before any policy rule allocation. The rule processing itself follows these guide lines: Stiemerling & Quittek [Page 14] Internet-Draft MIDCOM Protocol Semantics April 2002 - the middle box uses "default to deny", i.e. everything will be rejected by the middle box - the policy rules will be processed by the middle box in a first come first server manner - the policy rule is checked whether the requesting agent is allowed to request this policy rule or not. The request is rejected when the agent isn't allowed. - The rule allocation follows the "all or nothing" principle, i.e. either the complete request can be fulfilled or it will be rejected. - The middle box rejects any policy rule request that would result in an overlapping policy rule. - The action of each policy rule is ALLOW, there is no DENY action. - The server keeps the port oddity of the ports in the request. 5.1. Resource Reservation (RR) transaction-name : resource reservation transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the request/reply pair at the agent. - group identifier: A middle box unique group identifier (see section 5). - protocol identifer: Identifies the protocol level for the packet handling in the middle box. Examples are IP, UDP or TCP. - original IP address: The IP address that must be mapped into another IP address realm. - original port number: The port number that must be mapped into another port number realm. - port range: The number of ports that will be allocated subsequently. reply-parameters (success): Stiemerling & Quittek [Page 15] Internet-Draft MIDCOM Protocol Semantics April 2002 - request identifier: The request identifier from the request. - group identifier: The group identifier from the request. - rule identifier: A middle box unique rule identifier. This identifier will be used later to identify the policy rule for which this resource reservation has been made. This rule identifier may be only unique per agent, i.e. the middle box may assign the same value to another agent and policy rule. This rule ID may be different from the actual NAT binding or packet filter pin-hole ID in the middle box. - protocol identifer: Identifies the protocol level for the packet handling in the middle box. Examples are IP, UDP or TCP. - mapped IP address: The reserved mapped IP address. - mapped port number: The reserved mapped port number. Left blank in the case of IP. - port range: The reserved number of ports that will be allocated subsequently. reply-parameters (failure): - request identifier: The request identifier from the request. - failure reason: A reason why the resource reservation request failed. semantics: The MIDCOM agent uses this to request a resource reservation at the middle box. In the NAT case the address binding is reserved and the mapped IP address and mapped port numbers are returned to the agent. In the packet filter case the original IP address and port number are solely returned to the agent, but the packet filter may allocate any needed resources. 5.2. Policy Rule Configuration (PRC) transaction-name : policy rule configuration transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the request/reply pair at the agent. Stiemerling & Quittek [Page 16] Internet-Draft MIDCOM Protocol Semantics April 2002 - group identifier: A middle box unique group identifier (see section 5). - rule identifier: A middle box unique rule identifier. This identifier is assigned during the resource reservation process or filed with a value that requests a new rule identifier. The policy rule is bound to this rule identifier. - rule timeout: A timeout proposal to the middle box for the requested policy rule. - protocol identifer: Identifies the protocol level for the packet handling in the middle box. Examples are IP, UDP or TCP. - source IP address: The IP address of the source. In TCP this is the host which initiates the TCP connection, i.e. the one who starts the three way hand shake. In UDP this indicates the direction of the UDP flow, i.e. out of this source to the destination. - source port number: The UDP or TCP port number at the source, or the first port number out of a port range. Left blank in the case of IP. - destination IP address: The IP address of the destination. In TCP this is the host which listens for the incoming TCP connection, i.e. the one who accepts the initially SYN packet. In UDP this indicates the direction of the UDP flow, i.e. UDP is transmitted towards this address. - destination port number: The UDP or TCP port number at the destination, or the first port number out of a port range. Left blank in the case of IP. - port range: The number of ports that will be allocated subsequently. reply-parameters (success): - request identifier: The request identifier from the request. - group identifier: The group identifier from the request. - rule identifier: The rule identifier from the request. - rule timeout: The timeout for this policy rule granted by the middle box. The middle box selects a timeout for this rule and should consider the timeout proposal of the agent. The upper limit of the policy rule timeout is equal to the group timeout. Stiemerling & Quittek [Page 17] Internet-Draft MIDCOM Protocol Semantics April 2002 reply-parameters (failure): - request identifier: Agent unique identifier for matching the request/reply pair at the agent. - failure reason: A reason why the configuration of the policy failed. semantics: The agent requests the configuration of the policy rule at the middle box with this transaction. The middle box checks for an existing resource reservation, identified by the rule identifier, and continues processing the policy rule. The address information (IP addresses and port numbers) are checked, whether the agent is allowed to request this combination or if the request must be rejected. The middle box configures the policy rule depending on the resource reservation transaction and the parameters < source IP, source port, destination IP, destination port, port range, timeout>. 5.3. Policy Rule Keep-Alive (PKA) transaction-name : policy rule keep-alive transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the request/reply pair at the agent. - group identifier: A middle box unique group identifier (see section 5). - rule identifier: The identifier of the policy rule. - rule timeout: A timeout proposal to the middle box for the requested policy rule. reply-parameters (success): - request identifier: The request identifier from the request. - group identifier: The group identifier from the request. Stiemerling & Quittek [Page 18] Internet-Draft MIDCOM Protocol Semantics April 2002 - rule identifier: The identifier of the policy rule. - rule timeout: The granted timeout about how much the timeout of this policy rule is extended.The middle box selects a new timeout for this rule and should consider the timeout proposal of the agent. The upper limit of the policy rule timeout is equal to the group timeout. reply-parameters (failure) : - request identifier: The request identifier from the request. - failure reason: A reason why the timeout couldn't be extended. semantics: The agent keeps the policy rule alive in the middle box by generating this transaction. The middle box decides whether the policy rule will be kept and extends the timeout if possible. If the middle box does decide not to extend the timeout, the middle box generates a failure reply and the policy rule will be removed after this transaction. 5.4. Policy Rule Delete (PRD) transaction-name : policy rule delete transaction-type : request request-parameters: - request identifier: Agent unique identifier for matching the request/reply pair at the agent. - group identifier: A middle box unique group identifier (see section 5). - rule identifier: The identifier of the policy rule that will be deleted. reply-parameters (only success): - request identifier: The request identifier from the request. Stiemerling & Quittek [Page 19] Internet-Draft MIDCOM Protocol Semantics April 2002 - group identifier: The group identifier from the request. - rule identifier: The identifier of the policy rule from the request. semantics: The middle box removes the policy rule, identified by the rule identifier, immediately after receiving this transaction. The reply indicates always a successful processing of this request. Should there be any failure during the deletion process, the middle box solves the problem on its own. 5.5. Policy Rule Deleted Asynchronous (PRDA) transaction-name : policy rule delete asynch transaction-type : notification notification-parameters: - group identifier: The group identifier of the deleted policy rule - rule identifier: The identifier of the deleted policy rule. - deletion reason: The reason why the policy rule has been deleted. semantics: The middle box may decide at any point of time to delete a policy rule. The reason may be changes in the policy decision point or resource conflicts. The middle box sends this notification prior to the deletion process of the policy rule. 5.6. Behaviour on Asynchronous Session Termination Since the groups will be deleted due to a asynchronous session termination, the poolicy rules belonging to these groups will be delete as well. Again the sever first terminates the session with the agent and afterwards deletes the policy rules. Stiemerling & Quittek [Page 20] Internet-Draft MIDCOM Protocol Semantics April 2002 5.7. Policy Rule State Machine The state machine for the policy rule transactions is shown in figure 2 with all possible state transistions. You'll find the used transaction abbreviations in the headings of the particular transaction section. RR/Not_OK PRC/Not_OK +-----------+ | v RR/OK +-------------+ +-----------------| PR_UNUSED |<-+ | +-------------+ | +---- | ^ | | | v v PRDA | | PRC/OK | PRD/OK | +-------------+ PRD/OK | | | PRDA | | PR_RES |------------+ | | PKA/Not_OK | +-------------+ PRC/Not_OK | | | | | PKA/Not_OK | | ----+ | PRC/OK v | PKA/OK | +-------------+ | +---------------->| PR_INUSE |--+ +-------------+ | ^ +---------+ PKA/OK Figure 4: Policy Rule State Machine 6. Open Issues Here is the list of open issues: - Is a 'show all' request needed, to allow the agent to retrieve information about its session, groups and policy rules? - The capability information send from the middlebox to the agent at session setup need to be modeled. What capability items need to be sent? 7. Changes 7.1. Differences to -00 Version Stiemerling & Quittek [Page 21] Internet-Draft MIDCOM Protocol Semantics April 2002 - Added state machines for session, group and policy rule control. - Modified Introduction. 8. References [1] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, A., "Middlebox Communication Architecture and framework", Internet Draft, work in progress, , December 2001 [2] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M., "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet Draft, work in progress, , November 2001 [3] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) Terminology and Considerations", RFC 2663, August 1999 [4] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999 [5] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [6] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 9. Authors' Address Martin Stiemerling NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@ccrle.nec.de Juergen Quittek NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Stiemerling & Quittek [Page 22] Internet-Draft MIDCOM Protocol Semantics April 2002 Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de 10. Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Stiemerling & Quittek [Page 23] Internet-Draft MIDCOM Protocol Semantics April 2002