One document matched: draft-yamamoto-v6tc-security-considerations-00.txt
Tunnel Configuration (TC) S. Yamamoto
Internet-Draft H. Yokota
Expires: January 11, 2006 C. Williams
KDDI R&D Labs
F. Parent
Hexago
July 10, 2005
Security Considerations for the Tunnel Broker Model
draft-yamamoto-v6tc-security-considerations-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Tunnel brokers must implement protections against a wide variety of
threats. This draft discusses the security considerations for a
configured tunneling configuration mechanism such as that described
by the Tunnel Broker. The emphasis in this document is on
protocol-related security issues.
Yamamoto, et al. Expires January 11, 2006 [Page 1]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tunnel Configuration (TC) Security Requirements . . . . . . . 4
4. Security considerations for non-authenticated mode . . . . . . 4
5. Security considerations for authenticated mode . . . . . . . . 5
6. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6
6.1 Signalling . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2 Data path . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Normative references . . . . . . . . . . . . . . . . . . . 6
7.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Yamamoto, et al. Expires January 11, 2006 [Page 2]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
1. Introduction
The transition period from IPv4 to IPv6 will span a decade or more
and is still in its early stags. A major impediment is the high cost
and technical complexity to move complete network cores, servers and
applications to dual stack and the perspective of Return on
Investment. The Tunnel Broker model is specifically designed to
break this logjam, by enabling IPv6 anywhere in an enterprise network
without a major upgrade of the infrastructure.
TSP (Tunneling Setup Protocol) is an implementation of the Tunnel
Broker. TSP is a signalling protocol specifically designed to
enhance and add flexibility to the IPv6 transition mechanisms defined
by the IETF. The protocol is used by the server and client to
perform specific operations. Various security threats are introduced
with these set of signalling operations. The operations by TSP are
as follows:
1. exchange their capabilities (i.e., security, IPv4, IPv6, etc)
2. authenticate the client
3. request and delegate IPv6 addresses to the client
4. request and delegate IPv6 prefixes to the client and its networks
5. register AAAA, PTR and NS records in the DNS
6. traverse one or many IPv4 NAT in the path between the client and
the broker
7. maintain a permanent IPv6 address even when the IPv4 address
changes
It is the purpose of this document to provide security threat
analysis to this tunnel configuration model. This includes
operational security issues as a result of deployment.
2. Terminology
Tunnel Broker - The TB is the place where the user connects to
register and activate tunnels. The TB manages tunnel creation,
modification and deletion on behalf of the user.
Tunnel Server - A TS is a dual-stack (IPv4 & IPv6) routing entity
connected to the global Internet. Upon receipt of a configuration
order coming from the TB, it creates, modifies or deletes the server
side of each tunnel. It may also maintain usage statistics for every
Yamamoto, et al. Expires January 11, 2006 [Page 3]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
active tunnel.
3. Tunnel Configuration (TC) Security Requirements
Tunnel broker is a mechanism that includes a tunnel setup protocol to
tunnel IPv6 in IPv4 packets (as an example) from a dual-stack client
to a Tunnel server somewhere in the network. Both the control and
data packets of the Tunnel Broker model are vulnerable to attack. An
example of a tunnel broker implementation is the TSP protocol. We
will use the term Tunneling Configuration (TC) as a generic protocol
mechanisms that implements the Tunnel Broker model. TSP then would
be an instance of the TC protocol. Examples of attacks include:
1. An adversary may try to discover user identities by snooping data
packets.
2. An adversary may try to modify packets (both control and data).
3. An adversary may try to hijack the IPv6 in IPv4 tunnel.
4. An adversary can launch denial of service attacks by terminating
TSP created tunnels.
5. An adversary may attempt to disrupt the user negotiation with the
tunnel broker in order to weaken or remove confidentiality
protection. Alternatively, an adversary may wish gain access to user
passwords.
6. An adversary may impersonate the Tunnel broker to intercept
traffic ("rogue" tunnel broker).
To address these threats, the Tunneling Configuration (TC) security
protocol MUST be able to provide authentication, integrity and replay
protection for control packets. In addition, it SHOULD be able to
protect confidentiality for control packets. It MUST be able to
provide integrity and replay protection of data packets, and MAY be
able to protect confidentiality of data packets. An Tunneling
Configuration (TC) security protocol MUST also provide a scalable
approach to key management.
4. Security considerations for non-authenticated mode
Assisted tunneling can be provided in two different modes, a simple
mode, unauthenticated, as well as an authenticated mode aimed at
production deployment. The non-authenticated mode relies
"out-of-band" authentication; for example, the IP source address. Or
in the case where we global unique IPv4 addresses are not used, an
NAI of some sort may also be used. This is the deployment case
Yamamoto, et al. Expires January 11, 2006 [Page 4]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
whereby ISPs will likely not use authentication for their own users,
but instead rely on IP-address based filtering. There are various
well-known attacks as a result. In addition, the non-authenticated
mode relies on security of provider network; otherwise, the Tunnel
Broker will be open to a variety of DoS attacks. For instance, in
TSP anonymous mode, one can filter TSP requests to his own autonomous
system. This is really just a management function, not related to
the TSP protocol itself but an operation security consideration none
the less. Finally, the non-authenticated mode must be intra-provider
only deployment. Here again, because of the out-of-band
authentication both the client and the tunnel broker are suspectible
to DoS and man in the middle attacks.
5. Security considerations for authenticated mode
User authentication will most likely be dominant in deployments.
User authentication requires the user and the ISP have to set up some
kind of authentication to ensure that nobody else can hijack the
tunnel. Using the authenticated mode allows you to always keep the
same IPv6 address and prefix, even if your IPv4 address changes.
Areas of security requirements and/or issues specific to
authenticated mode are:
- user authentication prior to tunnel establishment
In Authentication mode the Tunnel Configuration (TC) scheme assumes
that the endpoints are already known and authenticated prior to
tunnel establishment. As a result, any user with access to one of
the endpoint machines can use the tunnel.
If connecting to an untrusted tunnel broker is a concern, mutual
authentication is necessary.
- user "owns" IPv6 address/prefix (broker database)
Here the protocol must be able to support servers willing to offer
stable IPv6 prefixes to the authenticated customers.
- User authentication must be compatible with methods generally
deployed (RADIUS)
The authentication mechanism supported should be compatible with
standardized methods that are generally deployed. In order to assure
interoperability, at least one common authentication method must be
supported. Other authentication may be supported and should be
negotiated between the client and server.
Yamamoto, et al. Expires January 11, 2006 [Page 5]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
6. Security Threats
This section details the different areas of security threats
6.1 Signalling
User authentication must be protected. If data in signalling is
considered sensitive (ex: IP address?) signaling must be protected
(encrypted). Encryption should be used when the plaintext password
is needed and sent as part of the session management protocol, such
as when using the password to register with the tunnel broker.
6.2 Data path
The data path is defined to be the tunnel itself as compared to the
signaling. If tunnel data is to be protected, the tunnel broker
should allow the use of security on the tunnel. For example, IPsec
over IPv6 should be possible. This is a requirement for those
roaming users outside of a protected domain (i.e., enterprise users)
that will need to tunnel back into the protected domain from an
untrusted access network.
7. References
7.1 Normative references
[1] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
Broker", RFC 3053, January 2001.
[2] Huitema, C., Austein, R., Satapati, S. and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References
[4] Parent, F., "Goals for Registered Assisted Tunneling",
Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01
, October 2004.
[5] Palet, J., "Goals for Tunneling Configuration",
Internet-Draft draft-palet-v6tc-goals-tunneling-00, February
2005.
[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC2461 , December 1998.
Yamamoto, et al. Expires January 11, 2006 [Page 6]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
[7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC3056 , Feb. 2001.
Authors' Addresses
Shu Yamamoto
KDDI R&D Labs
Kamifukuoka-Shi
Saitama 356-8502
Japan
Phone: 81 (49) 278-7894
Email: shu@kddilabs.jp
Hidetoshi Yokota
KDDI R&D Labs
Kamifukuoka-Shi
Saitama 356-8502
Japan
Phone: 81 (49) 278-7894
Email: yokota@kddlabs.co.jp
Carl Williams
KDDI R&D Labs
Palo Alto, CA 94301
USA
Phone: +1.650.279.5903
Email: carlw@mcsr-labs.org
Florent Parent
Hexago
2875 boul. Laurier, Suite 300
Sainte-Foy, QC GIV 2M2 94301
Canada
Email: florent.parent@hexago.com
Yamamoto, et al. Expires January 11, 2006 [Page 7]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Yamamoto, et al. Expires January 11, 2006 [Page 8]
Internet-Draft Security Considerations for the Tunnel Broker Model July 2005
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yamamoto, et al. Expires January 11, 2006 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 13:41:51 |