An Approach for the Administration and Security of IPv6 Transition Mechanisms: An SNMP MIB for 6to4 Georgios Koutepas, Athanasios Douitsis, Demetris Philippides, and Vasilis Maglaris Network Management and Optimal Design Lab (NETMODE) Dept. of Electrical and Computer Engineering National Technical University of Athens, Greece {gkoutep, aduitsis, demphilip}@netmode.ntua.gr,
[email protected]
Abstract A number of transitional mechanisms are being offered to allow the gradual adoption of IPv6 and prolong the useful operating time of legacy systems and applications. The transition mechanisms perform conversions between versions 4 and 6 of the IP protocol, offer tunnelling functionality and act as connection points between isolated (in the sense of IP versioning) network segments. In this paper we examine IPv6 transition mechanisms (focusing in tunnelling mechanisms) and their management requirements. Specifically, we examine in the most widely used mechanism, 6to4. We present its operational characteristics and identify its main management requirements. These requirements are then used to define corresponding objects for an SNMP Management Information database (MIB). Our aim is to use the SNMP methodology to address the most important IPv6 transition mechanism issues in a unified network administration environment. Our effort has resulted in a working prototype SNMP agent that implements most of our management object suggestions. We briefly describe the implementation challenges we faced and its main operational characteristics.*
1. Introduction IPv6 [1] offers significant new features that will bring IP networking to the new century. However, IPv6 still lacks universal deployment. A number of transitional mechanisms are being offered to allow the gradual adoption of the new protocol and prolong the useful operating time of legacy systems and applications. The transition mechanisms perform conversions between versions 4 and 6 of the IP protocol, offer tunnelling *
functionality and act as connection points between isolated (in the sense of IP versioning) network segments. In this paper we analyse the 6to4 mechanism to identify its network management requirements and fulfil them using the SNMP paradigm. We present the main operational characteristics of this service and convert them to objects of a Management Information database (MIB) structure that can be deployed, under an SNMP agent, to manage any 6to4 node. The rest of this paper is organized as follows: in Section 2 we make a brief overview of IPv6 transition mechanisms, we focus in tunnelling functionality and we introduce 6to4. Section 3 discusses some of the main administrative and security requirements posed by 6to4 and as a result by any IPv6 transitional service of this type. We present the elements that we have chosen to implement in the proposed administrative scheme in Section 4 that illustate the MIB outline. Finally, Section 5 gives our experiences with implementation, deployment and operation of the 6to4 agent and MIB.
2. IPv6 Transition Mechanisms and 6to4 Since the start of IPv6 it had been clear that transition to the new protocol would be a long and gradual process. Considering current the IPv4 deployment and overall investment in legacy systems and applications IETF had already predicted and designed a number of requirements for the support of transition within the new protocol: • Gradual site transition: a site may have only some of its systems supporting IPv6 • Minimum transition requirements: a site can support IPv6 just by offering DNS services without any upgrade in the rest of the infrastructure • IP address compatibility: the v4 addresses can be converted to "corresponding" v6 addresses, allowing the system to operate in both environments
This work has been partially supported by the 6Net European Project (5th FP/IST)
Proceedings of the International Multi-Conference on Computing in the Global Information Technology (ICCGI'06) 0-7695-2629-2/06 $20.00 © 2006
0-7695-2629-2/06/$20.00 (c) 2006 IEEE
• Ease of installation: Operating Systems should support IPv6 straightforwardly, without need for software upgrades. These requirements are met with the SIT (Simple Internet Transition) mechanisms included in the IPv6 specification [2]. SIT offers a scheme for: the conversion of IPv4 addresses to IPv6, dual stack OS operations and tunnelling mechanisms. Based upon the SIT technical characteristics transition to IPv6 may follow three different paths: (a) Operation of Dual Stack systems (supporting both IPv4 and IPv6) (b) Packet Translation mechanisms, e.g. NAT-PT (Network Address Translation – Protocol Translation), or (c) Tunnelling Mechanisms The last category includes manually as well as automatically configured tunnels. Dynamic tunnelling, the focus of this paper, is offered by a number of mechanisms, the most notable of which is 6to4 [3]. Some others, also widely used include: - Tunnel Brokers: systems that receive requests from dual stacked systems and (with or without authentication) configure all the necessary details (DNS etc.) for setting up the requesting system as part of a native IPv6 network, via a tunnel. - ISATAP (Intra Site Automatic addressing Tunnel Protocol) [4]: Operates similarly to 6over4 but without requiring an operating multicast layer. It supports connection behind NAT. - Teredo [5]: enables IPv6 hosts behind NAT to connect to IPv6 networks using tunnels terminated at a Teredo-relay. - 6over4 [6]: it enables single IPv6 systems to connect over IPv4 multicast and via a v4/v6 router (also on the multicast network) to the native IPv6 network. Currently being phased out. Almost all of the above mechanisms use 6to4 for their low level implementation. We therefore have chosen to analyse the management of 6to4 as a general test case for the management of any such mechanism. 6to4 is an automatic tunnelling mechanism that enables isolated IPv6 "clouds" (networks) as well as single IPv6 systems to communicate with native IPv6 networks. It basic elements are 6to4 Routers and 6to4 Relay Routers. In a nutshell its operation is as follows: Single IPv6 systems or whole isolated networks that have chosen to operate with IPv6 are connected to their IPv4 surroundings via a dual-stack 6to4 Router. This isolated subnet is assigned special IPv6 addresses derived from the 6to4 Router's IPv4 address in the form of 2002:V4Address::/48. A 6to4 Relay Router is used as a connection point between a native IPv6 network segment and the IPv4
network. It is assigned an Anycast address from the reserved IPv4 subnet 192.88.99.0/24 supported by [7]. The usage of Anycast enables automatic 6to4 Relay Router detection and automatic termination of tunnels. The 6to4 Routers create tunnels that encapsulate v6 packets within v4 ones when passing over v4 clouds. The connections may be to a native IPv6 network connection point (i.e. the 6to4 Relay router), or another 6to4 subnet. The tunnel endpoints are determined by the destination v6 IP: if it is a native IPv6 the endpoint will be the closest Anycast system; if it is "6to4 type" it will be the 6to4 Router's v4 address. An overview of the 6to4 connection method is given in Figure 1.
Figure 1: Overview of the 6to4 Mechanism
3. Analysis of 6to4 Administrative and Security requirements A number 6to4 characteristics necessitate the existence of interactive administration capability for the mechanism as well as facilities for accounting. Also, the system where the 6to4 mechanism is deployed should itself provide the appropriate management elements to assess its operational status and resource availability. As part of a dynamically configured mechanism, 6to4 Routers should accept packets from any Relay Router without verifying the validity of the source or even its real existence. A 6to4 end-host is not in the position to know if a Relay Router sending packets should be trusted. In the same way a Relay Router has to accept packets from all 6to4 Routers as well as native IPv6 nodes and en(de-)capsulate them accordingly without content checks. Furthermore, in the process of encapsulation and transmission over the IPv4 tunnel the IPv6 packets get rewritten and significant information concerning their true origin may be lost. 6to4 can therefore be utilized [8]: • To relay malicious packets to a target host • As an intermediary for a "Reflection" Denial of Service (DoS) attack in the IPv4 or IPv6 networks.
Proceedings of the International Multi-Conference on Computing in the Global Information Technology (ICCGI'06) 0-7695-2629-2/06 $20.00 © 2006
0-7695-2629-2/06/$20.00 (c) 2006 IEEE
•
To initiate "amplification" ("broadcast") attacks in the IPv4 network. • To make Neighbour Discovery IPv6 attacks. Additionally: • A malicious site/node/user may use the Relay Router's services without any authorization (service theft). • The system hosting the 6to4 mechanism may itself become a DoS attack target limiting its availability. Consequently, we may divide 6to4 management requirements in the following three broad categories: 1. Interface configuration parameters: providing control, monitoring and accounting of 6to4 interfaces and tunnels. Even though 6to4 is a dynamic mechanism, the manager should be aware of current and past tunnels and their usage characteristics (endpoint, traffic passed through them, user initiating them etc.). This information will illustrate resource utilization and will track usage (or possible misuse). Also number of "Sanity Checks" have been specified and should be performed on the transmitted packets to ensure the correct operation of the mechanism and avoid some misuse aspects. Such checks include rejection of packets with broadcast and multicast v4 and v6 addresses, rejection of packets with non-unicast IPs etc. These checks should be incorporated in the configuration control of the 6to4 mechanism. 2. Security controls to protect the host system, prevent misuse of the mechanism and create a policy enforcement point (at the 6to4 router or relay router) that will reflect site trust policies and priorities Routing of packets through tunnels can "hide" possible malicious content from the usual network defence mechanisms, e.g. Network Intrusion Detection Systems or Firewalls, unless these have the capability to examine payloads within encapsulated traffic. Access Control Lists should therefore be available to the mechanism's admin to control traffic according to local policies. 3. Management of the host system
This section provides information on the 6to4 Interfaces and relays. It includes the following information: •
•
•
Whether the system is capable to deploy 6to4 interfaces. It should be noted that the MIB is designed for any type of 6to4 system including a single host, which does not have the IPv4-IPv6 tunnel device. A table with the characteristics of the currently operating 6to4 interfaces (active tunnels): their assigned v4 and v6 IPs, the characteristics of packets they create for sending through the tunnelling mechanism (MTU, Hop Limit, usage of IPSec, etc). A table for the management of routes to the Relay Routers used by each 6to4 interface. This table has been necessary since each interface may configure more than one relay. It provides information on the relay's IP address (Unicast or Anycast), the destination IP addresses handled by each relay, and the route metric. Since this table is manager writable, Relay Routers may be added or removed, assignments to different operating 6to4 interfaces changed, and their routing characteristics controlled according to the site needs. Another possibility would the specific (instead of dynamic under 6to4) assignment a Relay to a 6to4 interface.
B. The security section This section provides the necessary functionality to acquire operational information and effectively control the security of the 6to4 system. The first part of this functionality is the definition and configuration of Access Control Lists (ACL) A different ACL table is used for each case of IP packets reaching the 6to4 system. These may be IPv6 packets coming in or out or IPv4 packets coming in or out. The different cases of traffic are illustrated in Figure 2.
4. MIB Architecture Overview The 6to4 Management Information Base (MIB) has been designed based on the management requirements above. The 6to4 MIB has been designed according to the SNMPv2 SMI and consists of 97 objects that have been grouped according to their functions in two sections†: A. The configuration section †
The complete (ASN.1 encoded) 6to4 MIB is available at: http://www.netmode.ntua.gr/~gkoutep/docs/6to4_ȂǿǺ.txt
Figure 2: Four Cases of Traffic for which ACLs may be Deployed For each one of these traffic types/directions, the ACLs can control (allow or deny – hence create complex policies, e.g. "deny unless allowed", etc.) traffic based
Proceedings of the International Multi-Conference on Computing in the Global Information Technology (ICCGI'06) 0-7695-2629-2/06 $20.00 © 2006
0-7695-2629-2/06/$20.00 (c) 2006 IEEE
on the 6to4 interface used, source and destination addresses, and protocol (e.g. TCP, UDP, etc). The ACL tables are also writable to enable direct manager deployment and configuration of security and access policies. The 6to4 interfaces are also supposed to implement the traffic "Sanity Checks" (mentioned above). If however they do not, the manager can still configure such checks (or even others according to the site's evolving needs) in the ACLs. Another MIB table is keeping current and historical information on tunnels operating in the system. As it can be supposed, this section is vital for a system that starts and stops tunnels dynamically, to infer, through statistical analysis, resource requirements and to identify misuse. For a limited time the source and destination IPs (v4 or v6) that have initiated a tunnel can be traced back and possible malicious usage identified. The table can be configured on the size of the historical data log it will keep. Specific information provided by the table includes: • Remote address used for the tunnel termination • Local interface (address) used • Tunnel initiation and termination times • Relay Router used if the communication was terminated in a native IPv6 network. It should be noted that some information used in the 6to4 MIB already exists in the tunnel MIB [9]. Our aim however has been to create a tool focusing in the specific requirements of a 6to4 system. Thus, we have grouped all the corresponding parameters that can provide an effective management platform and replicated tunnel MIB information in the few places that has been necessary. We have also tried to avoid replication of information already available in IPv6MIB and focus in specific 6to4 elements.
5. Implementation and Results The SNMP agent providing 6to4 system management by the 6to4 MIB has been implemented on a Linux system, with kernel version 2.6.8, using the Net-SNMP toolkit [10]. The implementation however has shown that IPv6 is still in an initial/research stage of development (at least in the Linux systems), being only partially supported and lacking important documentation. These difficulties have limited the development of the agent to partial functionality that demonstrates however, the advantages of a managed 6to4 system and the usability of the current 6to4 MIB design. The operating agent is capable to automatically detect whether the 6to4 system has tunnelling capability. Once the system has been established as operational, the list of available 6to4 interfaces along with their
specific routes is populated. At any moment the manager is able to retrieve tunnel configuration and usage information and set up ACLs to control traffic flow through the 6to4 system. As next steps in the development of the 6to4 MIB, we envision experiments that will lead to the complete integration of a 6to4 system in a traditional network management environment, using automatic SNMP data gathering, tunnel state indicators, as well as alarms, and possibly a graphical tool for the configuration of operational parameters and Access Lists. We also intend to circulate the MIB and get comments from the IPv6 and Network Management communities to further refine the objects and management operations. We also consider submission of the MIB to IETF, as a contribution towards a possible common 6to4 management standard.
6. References [1] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998. [2] R. Gilligan, E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April 1996 [3] B. Carpenter and K.Moore, Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001 [4] F. Templin, T. Gleeson, M. Talwar, and D. Thaler, IntraSite Automatic Tunnel Addressing Protocol (ISATAP), RFC 4214, October 2005 [5] C. Huitema, Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs), RFC 4380, February 2006 [6] B. Carpenter, C. Jung, Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, RFC 2529, March 1999 [7] C. Huitema, An Anycast Prefix for 6to4 Relay Routers, RFC 3068, June 2001 [8] P. Savola, C. Patel, Security Considerations for 6to4, RFC 3964, December 2004. [9] D. Thaller, IP Tunnel MIB, RFC 2667, August 1999 [10] Net-SNMP tool, http://www.net-snmp.org/
Proceedings of the International Multi-Conference on Computing in the Global Information Technology (ICCGI'06) 0-7695-2629-2/06 $20.00 © 2006
0-7695-2629-2/06/$20.00 (c) 2006 IEEE
