RFC 5189
Middlebox Communication (MIDCOM) Protocol Semantics
3. Conformance Statements
A protocol definition complies with the semantics defined in section 2 if the protocol specification includes all specified transactions with all their mandatory parameters. However, it is not required that an actual implementation of a middlebox supports all these transactions. Which transactions are required for compliance is different for agent and middlebox. This section contains conformance statements for MIDCOM protocol implementations related to the semantics. Conformance is specified differently for agents and middleboxes. These conformance statements will probably be extended by a concrete protocol specification. However, such an extension is expected to extend the statements below in such a way that all of them still hold. The following list shows the transaction-compliance property of all transactions as specified in the previous section: - Session Control Transactions - Session Establishment (SE) mandatory - Session Termination (ST) mandatory - Asynchronous Session Termination (AST) mandatory
- Policy Rule Transactions
- Policy Reserve Rule (PRR) mandatory
- Policy Enable Rule (PER) mandatory
- Policy Rule Lifetime Change (RLC) mandatory
- Policy Rule List (PRL) mandatory
- Policy Rule Status (PRS) mandatory
- Asynchronous Policy Rule Event (ARE) mandatory
- Policy Rule Group Transactions
- Group Lifetime Change (GLC) optional
- Group List (GL) optional
- Group Status (GS) optional
3.1. General Implementation Conformance
A compliant implementation of a MIDCOM protocol MUST support all
mandatory transactions.
A compliant implementation of a MIDCOM protocol MAY support none,
one, or more of the following transactions: GLC, GL, GS.
A compliant implementation MAY extend the protocol semantics by
further transactions.
A compliant implementation of a MIDCOM protocol MUST support all
mandatory parameters of each transaction concerning the information
contained. The set of parameters can be redefined per transaction as
long as the contained information is maintained.
A compliant implementation of a MIDCOM protocol MAY support the use
of interface-specific policy rules. Either both or neither of the
optional inside and outside interface parameters in PRR, PER, and PRS
MUST be included if interface-specific policy rules are supported.
A compliant implementation MAY extend the list of parameters of
transactions.
A compliant implementation MAY replace a single transaction by a set
of more fine-grained transactions. In such a case, it MUST be
ensured that requirement 2.1.4 (deterministic behavior) and
requirement 2.1.5 (known and stable state) of [MDC-REQ] are still
met. When a single transaction is replaced by a set of multiple
fine-grained transactions, this set MUST be equivalent to a single
transaction. Furthermore, this set of transactions MUST further meet
the atomicity requirement stated in section 2.1.4.
3.2. Middlebox Conformance
A middlebox implementation of a MIDCOM protocol supports a request transaction if it is able to receive and process all possible correct message instances of the particular request transaction and if it generates a correct reply for any correct request it receives. A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly. A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction.3.3. Agent Conformance
An agent implementation of a MIDCOM protocol supports a request transaction if it can generate the corresponding request message properly and if it can receive and process all possible correct replies to the particular request. An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of the particular transaction. A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that is not supported by the middlebox. The middlebox informs the agent about the list of supported transactions within the SE transaction.4. Transaction Usage Examples
This section gives two usage examples of the transactions specified in section 2. The first shows how an agent can explore all policy rules and policy rule groups that it may access at a middlebox. The second example shows the configuration of a middlebox in combination with the setup of a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261].4.1. Exploring Policy Rules and Policy Rule Groups
This example assumes an already established session. It shows how an agent can find out - which groups it may access and who owns these groups, - the status and member list of all accessible groups, and - the status and properties of all accessible policy rules.
If there is just a single session, these actions are not needed, because the middlebox informs the agent about each state transition of any policy rule or policy rule group. However, after the disruption of a session or after an intentional session termination, the agent might want to re-establish the session and explore which of the groups and policy rules it established are still in place. Also, an agent system may fail and another one may take over. Then the new agent system needs to find out what has already been configured by the failing system and what still needs to be done. A third situation where exploring policy rules and groups is useful is the case of an agent with 'administrator' authorization. This agent may access and modify any policy rule or group created by any other agent. All agents will probably start their exploration with the Group List (GL) transaction, as shown in Figure 5. On this request, the middlebox returns a list of pairs, each containing an agent identifier and a group identifier (GID). The agent is informed which of its own groups and which other agents' groups it may access. agent middlebox | GL | |**********************************************>| |<**********************************************| | (agent1,GID1) (agent1,GID2) (agent2,GID3) | | | | GS GID2 | |**********************************************>| |<**********************************************| | agent1 lifetime PID1 PID2 PID3 PID4 | | | Figure 5: Using the GL and the GS Transactions In Figure 5, three groups are accessible to the agent, and the agent retrieves information about the second group by using the Group Status (GS) transaction. It receives the owner of the group, the remaining lifetime, and the list of member policy rules, in this case containing four policy rule identifiers (PIDs). In the following, the agent explores these four policy rules. The example assumes that the middlebox is a traditional NAPT. Figure 6 shows the exploration of the first policy rule. In reply to a Policy Rule Status (PRS) transaction, the middlebox always returns the following list of parameters:
- policy rule owner
- group identifier
- policy rule action (reserve or enable)
- protocol type
- port range
- direction
- internal IP address
- internal port number
- external address
- external port number
- middlebox inside IP address
- middlebox inside port number
- middlebox outside IP address
- middlebox outside port number
- IP address versions (not printed)
- middlebox service (not printed)
- inside and outside interface (optional, not printed)
agent middlebox
| PRS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 "" |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |
Figure 6: Status Report for an Outside Reservation
The 'ANY' parameter printed in Figure 6 is used as a placeholder in
policy rule status replies for policy reserve rules. The policy rule
with PID1 is a policy reserve rule for UDP traffic at the outside of
the middlebox. Since this is a reserve rule, direction is empty. As
there is no internal or external address involved yet, these four
fields are wildcarded in the reply. The same holds for the inside
middlebox address and port number. The only address information
given by the reply is the reserved outside IP address of the
middlebox (IPADR_OUT) and the corresponding port number (PORT_OUT1).
Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, as the
reserve action does not support this.
Applying PRS to PID2 (Figure 7) shows that the second policy rule is
a policy enable rule for inbound UDP packets. The internal
destination is fixed concerning IP address, protocol, and port
number, but for the external source, the port number is wildcarded.
The outside IP address and port number of the middlebox are what the
external sender needs to use as destination in the original packet it
sends. At the middlebox, the destination address is replaced with
the internal address of the final receiver. During address translation, the source IP address and the source port numbers of the packets remain unchanged. This is indicated by the inside address, which is identical to the external address. agent middlebox | PRS PID2 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 IN | | IPADR_INT PORT_INT1 IPADR_EXT ANY | | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | | | Figure 7: Status Report for Enabled Inbound Packets For traditional NATs, the identity of the inside IP address and port number with the external IP address and port number always holds (A1=A3 in Figure 3). For a pure firewall, the outside IP address and port number are always identical with the internal IP address and port number (A0=A2 in Figure 3). agent middlebox | PRS PID3 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 OUT | | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | | | Figure 8: Status Report for Enabled Outbound Packets Figure 8 shows enabled outbound UDP communication between the same host. Here all port numbers are known. Since again A1=A3, the internal sender uses the external IP address and port number as destination in the original packets. At the firewall, the internal source IP address and port number are replaced by the shown outside IP address and port number of the middlebox.
agent middlebox | PRS PID4 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE TCP 1 BI | | IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 | | IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 | | | Figure 9: Status Report for Bidirectional TCP Traffic Finally, Figure 9 shows the status report for enabled bidirectional TCP traffic. Note that, still, A1=A3. For outbound packets, only the source IP address and port number are replaced at the middlebox, and for inbound packets, only the destination IP address and port number are replaced.4.2. Enabling a SIP-Signaled Call
This elaborated transaction usage example shows the interaction between a back-to-back user agent (B2BUA) and a middlebox. The middlebox itself is a traditional Network Address and Port Translator (NAPT), and two SIP user agents communicate with each other via the B2BUA and a NAPT, as shown in Figure 10. The MIDCOM agent is co- located with the B2BUA, and the MIDCOM server is at the middlebox. Thus, the MIDCOM protocol runs between the B2BUA and the middlebox. +-------------+ | B2BUA | | for domain ++++ | example.com | + +-------------+ + ^ ^ + Private | | + Public Network Network | | + +----------+ | | +----+------+ +----------------+ | SIP User |<-+ +->| Middlebox |<------->| SIP User Agent | | Agent A |<#######>| NAPT |<#######>| B@example.org | +----------+ +-----------+ +----------------+ <--> SIP signaling <##> RTP traffic ++++ MIDCOM protocol Figure 10: Example of a SIP Scenario
For the sequence charts below, we make these assumptions:
- The NAPT is statically configured to forward SIP signaling from
the outside to the B2BUA -- i.e., traffic to the NAPT's external
IP address and port 5060 is forwarded to the internal B2BUA.
- The SIP user agent A, located inside the private network, is
registered at the B2BUA with its private IP address.
- User A knows the general SIP URL of user B. The URL is
B@example.org. However, the concrete URL of the SIP user agent
B, which user B currently uses, is not known.
- The RTP paths are configured, but not the RTP Control Protocol
(RTCP) paths.
- The middlebox and the B2BUA share an established MIDCOM session.
- Some parameters are omitted, such as the request identifier
(RID).
Furthermore, the following abbreviations are used:
- IP_AI: Internal IP address of user agent A
- P_AI: Internal port number of user agent A to receive RTP data
- P_AE: External mapped port number of user agent A
- IP_AE: External IP address of the middlebox
- IP_B: IP address of user agent B
- P_B: Port number of user agent B to receive RTP data
- GID: Group identifier
- PID: Policy rule identifier
The abbreviations of the MIDCOM transactions can be found in the
particular section headings.
In our example, user A tries to call user B. The user agent A sends
an INVITE SIP message to the B2BUA (see Figure 10). The SDP part of
the particular SIP message relevant for the middlebox configuration
is shown in the sequence chart as follows:
SDP: m=..P_AI..
c=IP_AI
where the m tag is the media tag that contains the receiving UDP port
number, and the c tag contains the IP address of the terminal
receiving the media stream.
The INVITE message forwarded to user agent B must contain a public IP address and a port number to which user agent B can send its RTP media stream. The B2BUA requests a policy enable rule at the middlebox with a PER request with the wildcarded IP address and port number of user agent B. As neither the IP address nor port numbers of user agent B are known at this point, the address of user agent B must be wildcarded. The wildcarded IP address and port number enable the 'early media' capability but result in some insecurity, as any outside host can reach user agent A on the enabled port number through the middlebox. User Agent B2BUA Middlebox User Agent A NAPT B | | | | | INVITE | | | | B@example.org | | | | SDP:m=..P_AI.. | | | | c=IP_AI | | | |--------------->| | | | | | | | | PER PID1 UDP 1 EVEN IN | | | | IP_AI P_AI ANY ANY 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID1 ANY ANY | | | | IP_AE P_AE1 300s | | Figure 11: PER with Wildcard Address and Port Number A successful PER reply, as shown in Figure 11, results in a NAT binding at the middlebox. This binding enables UDP traffic from any host outside user agent A's private network to reach user agent A. So user agent B could start sending traffic immediately after receiving the INVITE message, as could any other host -- even hosts that are not intended to participate, such as any malicious host. If the middlebox does not support or does not permit IP address wildcarding for security reasons, the PER request will be rejected with an appropriate failure reason, like 'IP wildcarding not supported'. Nevertheless, the B2BUA needs an outside IP address and port number at the middlebox (the NAPT) in order to forward the SIP INVITE message. If the IP address of user agent B is still not known (it will be sent by user agent B in the SIP reply message) and IP address wildcarding is not permitted, the B2BUA uses the PRR transaction.
By using the PRR request, the B2BUA requests an outside IP address and port number (see Figure 12) without already establishing a NAT binding or pin hole. The PRR request contains the service parameter 'tw' -- i.e., the MIDCOM agent chooses the default value. In this configuration, with NAPT and without a twice-NAT, only an outside address is reserved. In the SDP payload of the INVITE message, the B2BUA replaces the IP address and port number of user agent A with the reserved IP address and port from the PRR reply (see Figure 12). The SIP INVITE message is forwarded to user agent B with a modified SDP body containing the outside address and port number, to which user agent B will send its RTP media stream. User Agent B2BUA Middlebox User Agent A NAPT B | | | | ...PER in Figure 11 has failed, continuing with PRR ... | | | | | |PRR tw v4 v4 A UDP 1 EVEN 300s| | | |*****************************>| | | |<*****************************| | | | PRR OK PID1 GID1 EMPTY | | | | IP_AE/P_AE 300s | | | | | | | | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE | | |-------------------------------------------->| | |<--------------------------------------------| | | 200 OK SDP:m=..P_B.. c=IP_B | Figure 12: Address Reservation with PRR Transaction This SIP '200 OK' reply contains the IP address and port number at which user agent B will receive a media stream. The IP address is assumed to be equal to the IP address from which user agent B will send its media stream. Now, the B2BUA has sufficient information for establishing the complete NAT binding with a policy enable rule (PER) transaction; i.e., the UDP/RTP data of the call can flow from user agent B to user agent A. The PER transaction references the reservation by passing the PID of the PRR (PID1). For the opposite direction, UDP/RTP data from user agent A to B has to be enabled also. This is done by a second PER transaction with all the necessary parameters (see Figure 13). The request message contains the group identifier (GID1) the middlebox has assigned in the first PER transaction. Therefore, both policy rules have become
members of the same group. After having enabled both UDP/RTP streams, the B2BUA can forward the '200 OK' SIP message to user agent A to indicate that the telephone call can start. User Agent B2BUA Middlebox User Agent A NAPT B | | | | | | PER PID1 UDP 1 SAME IN | | | | IP_AI P_AI IP_B ANY 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID1 IP_B ANY | | | | IP_AE P_AE1 300s | | | | | | ...media stream from user agent B to A enabled... | | | | | | PER GID1 UDP 1 SAME OUT | | | | IP_AI ANY IP_B P_B 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID2 IP_B P_B | | | | IP_AE P_AE2 300s | | | | | | ...media streams from both directions enabled... | | | | | 200 OK | | | |<---------------| | | | SDP:m=..P_B.. | | | | c=IP_B | | | Figure 13: Policy Rule Establishment for UDP Flows User agent B decides to terminate the call and sends its 'BYE' SIP message to user agent A. The B2BUA forwards all SIP messages and terminates the group afterwards, using a group lifetime change (GLC) transaction with a requested remaining lifetime of 0 seconds (see Figure 14). Termination of the group includes terminating all member policy rules.
User Agent B2BUA Middlebox User Agent A NAPT B | | | | | BYE | BYE | |<---------------|<--------------------------------------------| | | | | | 200 OK | 200 OK | |--------------->|-------------------------------------------->| | | | | | | GLC GID1 0s | | | |*****************************>| | | |<*****************************| | | | GLC OK 0s | | | | | | ...both NAT bindings for the media streams are removed... Figure 14: Termination of Policy Rule Groups5. Compliance with MIDCOM Requirements
This section explains the compliance of the specified semantics with the MIDCOM requirements. It is structured according to [MDC-REQ]: - Compliance with Protocol Machinery Requirements (section 5.1) - Compliance with Protocol Semantics Requirements (section 5.2) - Compliance with Security Requirements (section 5.3) The requirements are referred to with the number of the section in which they are defined: "requirement x.y.z" refers to the requirement specified in section x.y.z of [MDC-REQ].5.1. Protocol Machinery Requirements
5.1.1. Authorized Association
The specified semantics enables a MIDCOM agent to establish an authorized association between itself and the middlebox. The agent identifies itself by the authentication mechanism of the Session Establishment transaction described in section 2.2.1. Based on this authentication, the middlebox can determine whether or not the agent will be permitted to request a service. Thus, requirement 2.1.1 is met.
5.1.2. Agent Connects to Multiple Middleboxes
As specified in section 2.2, the MIDCOM protocol allows the agent to communicate with more than one middlebox simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.2 is met.5.1.3. Multiple Agents Connect to Same Middlebox
As specified in section 2.2, the MIDCOM protocol allows the middlebox to communicate with more than one agent simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.3 is met.5.1.4. Deterministic Behavior
Section 2.1.2 states that the processing of a request of an agent may not be interrupted by any request of the same or another agent. This provides atomicity among request transactions and avoids race conditions resulting in unpredictable behavior by the middlebox. The behavior of the middlebox can only be predictable in the view of its administrators. In the view of an agent, the middlebox behavior is unpredictable, as the administrator can, for example, modify the authorization of the agent at any time without the agent being able to observe this change. Consequently, the behavior of the middlebox is not necessarily deterministic from the point of view of any agent. As predictability of the middlebox behavior is given for its administrator, requirement 2.1.4 is met.5.1.5. Known and Stable State
Section 2.1 states that request transactions are atomic with respect to each other and from the point of view of an agent. All transactions are clearly defined as state transitions that either leave the current stable, well-defined state and enter a new stable, well-defined one or that remain in the current stable, well-defined state. Section 2.1 clearly demands that intermediate states are not stable and are not reported to any agent. Furthermore, for each state transition a message is sent to the corresponding agent, either a reply or a notification. The agent can uniquely map each reply to one of the requests that it sent to the middlebox, because agent-unique request identifiers are used for this purpose. Notifications are self-explanatory by their definition.
Furthermore, the Group List transaction (section 2.4.3), the Group Status transaction (section 2.4.4), the Policy Rule List transaction (section 2.3.11), and the Policy Rule Status transaction (section 2.3.12) allow the agent at any time during a session to retrieve information about - all policy rule groups it may access, - the status and member policy rules of all accessible groups, - all policy rules it may access, and - the status of all accessible policy rules. Therefore, the agent is precisely informed about the state of the middlebox (as far as the services requested by the agent are affected), and requirement 2.1.5 is met.5.1.6. Status Report
As argued in the previous section, the middlebox unambiguously informs the agent about every state transition related to any of the services requested by the agent. Also, at any time the agent can retrieve full status information about all accessible policy rules and policy rule groups. Thus, requirement 2.1.6 is met.5.1.7. Unsolicited Messages (Asynchronous Notifications)
The semantics includes asynchronous notifications messages from the middlebox to the agent, including the Session Termination Notification (STN) message, the Policy Rule Event Notification (REN) message, and the Group Event Notification (GEN) message (see section 2.1.2). These notifications report every change of state of policy rules or policy rule groups that was not explicitly requested by the agent. Thus, requirement 2.1.7 is met by the semantics specified above.5.1.8. Mutual Authentication
As specified in section 2.2.1, the semantics requires mutual authentication of agent and middlebox, by using either two subsequent Session Establishment transactions or mutual authentication provided on a lower protocol layer. Thus, requirement 2.1.8 is met.5.1.9. Session Termination by Any Party
The semantics specification states in section 2.2.2 that the agent may request session termination by generating the Session Termination request and that the middlebox may not reject this request. In turn, section 2.2.3 states that the middlebox may send the Asynchronous
Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met.5.1.10. Request Result
Section 2.1 states that each request of an agent is followed by a reply of the middlebox indicating either success or failure. Thus, requirement 2.2.10 is met.5.1.11. Version Interworking
Section 2.2.1 states that the agent needs to specify the protocol version number that it will use during the session. The middlebox may accept this and act according to this protocol version or may reject the session if it does not support this version. If the session setup is rejected, the agent may try again with another version. Thus, requirement 2.2.11 is met.5.1.12. Deterministic Handling of Overlapping Rules
The only policy rule actions specified are 'reserve' and 'enable'. For firewalls, overlapping enable actions or reserve actions do not create any conflict, so a firewall will always accept overlapping rules as specified in section 2.3.2 (assuming the required authorization is given). For NATs, reserve and enable may conflict. If a conflicting request arrives, it is rejected, as stated in section 2.3.2. If an overlapping request arrives that does not conflict with those it overlaps, it is accepted (assuming the required authorization is given). Therefore, the behavior of the middlebox in the presence of overlapping rules can be predicted deterministically, and requirement 2.1.12 is met.5.2. Protocol Semantics Requirements
5.2.1. Extensible Syntax and Semantics
Requirement 2.2.1 explicitly requests extensibility of protocol syntax. This needs to be addressed by the concrete protocol definition. The semantics specification is extensible anyway, because new transactions may be added.
5.2.2. Policy Rules for Different Types of Middleboxes
Section 2.3 explains that the semantics uses identical transactions for all middlebox types and that the same policy rule can be applied to all of them. Thus, requirement 2.2.2 is met.5.2.3. Ruleset Groups
The semantics explicitly supports grouping of policy rules and transactions on policy rule groups, as described in section 2.4. The group transactions can be used for lifetime extension and termination of all policy rules that are members of the particular group. Thus, requirement 2.2.3 is met.5.2.4. Policy Rule Lifetime Extension
The semantics includes a transaction for explicit lifetime extension of policy rules, as described in section 2.3.3. Thus, requirement 2.2.4 is met.5.2.5. Robust Failure Modes
The state transitions at the middlebox are clearly specified and communicated to the agent. There is no intermediate state reached by a partial processing of a request. All requests are always processed completely, either successfully or unsuccessfully. All request transactions include a list of failure reasons. These failure reasons cover indication of invalid parameters where applicable. In case of failure, one of the specified reasons is returned from the middlebox to the agent. Thus, requirement 2.2.5 is met.5.2.6. Failure Reasons
The semantics includes a failure reason parameter in each failure reply. Thus, requirement 2.2.6 is met.5.2.7. Multiple Agents Manipulating Same Policy Rule
As specified in sections 2.3 and 2.4, each installed policy rule and policy rule group has an owner, which is the authenticated agent that created the policy rule or group, respectively. The authenticated identity is input to authorize access to policy rules and groups. If the middlebox is sufficiently configurable, its administrator can configure it so that one authenticated agent is authorized to access and modify policy rules and groups owned by another agent. Because specified semantics does not preclude this, it meets requirement 2.2.7.
5.2.8. Carrying Filtering Rules
The Policy Enable Rule transaction specified in section 2.3.8 can carry 5-tuple filtering rules. This meets requirement 2.2.8.5.2.9. Parity of Port Numbers
As specified in section 2.3.6, the agent is able to request keeping the port parity when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings with the PER transaction (see section 2.3.9). Thus, requirement 2.2.9 is met.5.2.10. Consecutive Range of Port Numbers
As specified in section 2.3.6, the agent is able to request a consecutive range of port numbers when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings or pinholes with the PER transaction (see section 2.3.9). Thus, requirement 2.2.10 is met.5.2.11. Contradicting Overlapping Policy Rules
Requirement 2.2.11 is based on the assumption that contradictory policy rule actions, such as 'enable'/'allow' and 'disable'/'disallow', are supported. In conformance with decisions made by the working group after finalizing the requirements document, this requirement is not met by the semantics because no 'disable'/'disallow' action is supported.5.3. Security Requirements
5.3.1. Authentication, Confidentiality, Integrity
The semantics definition supports mutual authentication of agent and middlebox in the Session Establishment transaction (section 2.2.1). The use of an underlying protocol such as TLS or IPsec is mandatory. Thus, requirement 2.3.1 is met.5.3.2. Optional Confidentiality of Control Messages
The use of IPsec or TLS allows agent and middlebox to use an encryption method (including no encryption). Thus, requirement 2.3.2 is met.
5.3.3. Operation across Untrusted Domains
Operation across untrusted domains is supported by mutual authentication and by the use of TLS or IPsec protection. Thus, requirement 2.3.3 is met.5.3.4. Mitigate Replay Attacks
The specified semantics mitigates replay attacks and meets requirement 2.3.4 by requiring mutual authentication of agent and middlebox, and by mandating the use of TLS or IPsec protection. Further mitigation can be provided as part of a concrete MIDCOM protocol definition -- for example, by requiring consecutively increasing numbers for request identifiers.6. Security Considerations
The interaction between a middlebox and an agent (see [MDC-FRM]) is a very sensitive point with respect to security. The configuration of policy rules from a middlebox-external entity appears to contradict the nature of a middlebox. Therefore, effective means have to be used to ensure - mutual authentication between agent and middlebox, - authorization, - message integrity, and - message confidentiality. The semantics defines a mechanism to ensure mutual authentication between agent and middlebox (see section 2.2.1). In combination with the authentication, the middlebox is able to decide whether an agent is authorized to request an action at the middlebox. The semantics relies on underlying protocols, such as TLS or IPsec, to maintain message integrity and confidentiality of the transferred data between both entities. For the TLS and IPsec use, both sides must use securely configured credentials for authentication and authorization. The configuration of policy rules with wildcarded IP addresses and port numbers results in certain risks, such as opening overly wildcarded policy rules. An excessively wildcarded policy rule would be A0 and A3 with IP address set to 'any' IP address, for instance. This type of pinhole would render the middlebox, in the sense of security, useless, as any packet could traverse the middlebox without further checking. The local policy of the middlebox should reject such policy rule enable requests.
A reasonable default configuration for wildcarding would be that only one port number may be wildcarded and all IP addresses must be set without wildcarding. However, there are some cases where security needs to be balanced with functionality. The example described in section 4.2 shows how SIP-signaled calls can be served in a secure way without wildcarding IP addresses. But some SIP-signaled applications make use of early media (see section 5.5 of [RFC3398]). To receive early media, the middleboxes need to be configured before the second participant in a session is known. As it is not known, the IP address of the second participant needs to be wildcarded. In such cases and in several similar ones, there is a security policy decision to be made by the middlebox operator. The operator can configure the middlebox so that it supports more functionality, for example, by allowing wildcarded IP addresses, or so that network operation is more secure, for example, by disallowing wildcarded IP addresses.7. IAB Considerations on UNSAF
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempt to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489], are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication (MIDCOM). This document describes the protocol semantics for such a middlebox communication (MIDCOM) solution. MIDCOM is not intended as a short- term workaround, but more as a long-term solution for middlebox communication. In MIDCOM, endpoints are not involved in allocating, maintaining, and deleting addresses and ports at the middlebox. The full control of addresses and ports at the middlebox is located at the MIDCOM server. Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.8. Acknowledgements
We would like to thank all the people contributing to the semantics discussion on the mailing list for a lot of valuable comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References
[MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [MDC-SEM] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
Appendix A. Changes from RFC 3989
1. The example in section 4.2 used a SIP proxy server modifying the body of a SIP message. This was a violation of RFC 3261. This has been fixed by replacing the SIP proxy server with a back-to- back user agent. 2. Clarifications concerning the used set of transaction types have been added. 3. Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119. 4. Minor editorial changes have been made and references have been updated.Authors' Addresses
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu Tom Taylor Nortel 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8 Phone: +1 613 763 1496 EMail: tom.taylor@rogers.com
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.