| |<*****************************| |
| | GLC OK 0s | |
| | | |
...both NAT bindings for the media streams are removed...
Figure 14: Termination of policy rule groups
5. 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 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’/’disallows’ 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 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
[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.
[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.
9.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[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.
Authors’ Addresses
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-13
EMail: stiemerling@netlab.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
Tom Taylor
Nortel
1852 Lorraine Ave.
Ottawa, Ontario
Canada K1H 6Z8
Phone: +1 613 763 1496
EMail: taylor@nortel.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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 IETF’s procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.