entity looks quite counterproductive on the first glimpse, since an
attacker using this can possibly configure the middlebox in such way
that no filtering is applied anymore or that NAT bindings are
configured for malicious use. So the middlebox is not performing the
intended function anymore. Possible threats to SIMCO are:
- Man-in-the-middle attack
A malicious host intercepts messages exchanged between then SIMCO
agent and middlebox and can change the content of the messages on
the fly. This man-in-the-middle attack would result, from the
agent’s view, in a proper middlebox configuration, but the
middlebox would not be configured accordingly. The man in the
middlebox could open pinholes that compromise the protected
network’s security.
- Changing content
The message content could be changed in such a way that the
requested policy rule configuration is not configured in the
middlebox, but that any other unwanted configuration could be.
That way, an attacker can open the firewall for his own traffic.
- Replaying
Already sent messages could be re-sent in order to configure the
middlebox in such a way that hosts could configure policy rules
without the permission of an application-level gateway or system
administrator.
- Wiretapping
An already configured policy rule could be re-used by other hosts
if the policy rule is configured with too broad a wildcarding
(see below). These hosts could send unwanted traffic.
9.2. Securing SIMCO with IPsec
The previous subsection identifies several issues on security for
SIMCO. SIMCO can rely on IPsec mechanisms, as defined in [RFC4302]
and [RFC4303], for ensuring proper operations.
When SIMCO relies on IPsec, it uses IPsec in transport mode with an
authentication header (AH) [RFC4302] and an encapsulating security
payload (ESP) [RFC4303], so that IP traffic between SIMCO agent and
middlebox is protected. The authentication header is used for
protecting the whole packet against content changes and replaying.
The ESP header is used to prevent wiretapping.
At either the agent or middlebox side, the following should be pre-
configured: the IP addresses of the agent or middlebox, TCP (as the
transport protocol), and the port numbers (if possible). Only
packets from the pre-configured address of the agents or middlebox
should be accepted.
The keys for authentication for both the SIMCO agent and middlebox
are pre-configured at each side. For replay protection, the use of a
key management system is recommended. For the Internet Key Exchange
(IKE) protocol, see [RFC4306].
10. 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 a general
class of work-arounds for NAT traversal and solutions for scenarios
with no middlebox communication (MIDCOM).
This document describes a protocol implementation of the MIDCOM
semantics and thus implements a middlebox communication (MIDCOM)
solution. MIDCOM is not intended as a short-term work-around, 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 SIMCO server.
Therefore, this document addresses the UNSAF considerations in
[RFC3424] by proposing a long-term alternative solution.
11. Acknowledgements
The authors would like to thank Sebastian Kiesel and Andreas Mueller
for valuable feedback from their SIMCO implementation and Mary Barnes
for a thorough document review.
12. Normative References
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communications (MIDCOM) Protocol Semantics", RFC 3989,
February 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
13. Informative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 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.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Authors’ Addresses
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-113
EMail: stiemerling@netlab.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-115
EMail: quittek@netlab.nec.de
Cristian Cadar
Muelheimer Strasse 23
40239 Duesseldorf
Germany
EMail: ccadar2@yahoo.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).