Network Working Group A. Ebalard Internet-Draft EADS Intended status: Informational August 06, 2010 Expires: February 7, 2011 MIPv6 from IPv4-only networks draft-ebalard-mext-m6t-00 Abstract MIPv6 [RFC3775] protocol has been designed to work on IPv6 networks: nothing was initially provisioned in the specification to support movement of Mobile Nodes to IPv4-only networks (with or without NAT) or the communication with IPv4 peers. DSMIPv6 [RFC5555] is the official solution specified to address those needs. It requires IPv4/NAT-awareness by the MIPv6 module, IKE module and IPsec stack. The global approach selected by DSMIPv6 requires changes to implementations and increase complexity. This memo presents an alternative approach to support operations of a mobile nodes from an IPv4-only network. It does not require changes to MIPv6 modules, IKE module and IPsec stack. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Ebalard Expires February 7, 2011 [Page 1] Internet-Draft m6t August 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Initial thoughts . . . . . . . . . . . . . . . . . . . . . 3 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems and solutions . . . . . . . . . . . . . . . . . . . . 4 2.1. UDP port to use on the tunnel GW . . . . . . . . . . . . . 4 2.2. MN's CoA on the tunnel interface . . . . . . . . . . . . . 5 2.3. Maintaining NAT states . . . . . . . . . . . . . . . . . . 6 2.4. Route management on the tunnel GW . . . . . . . . . . . . 6 2.5. Multiple tunnel interfaces on a MN . . . . . . . . . . . . 7 2.6. MTU considerations . . . . . . . . . . . . . . . . . . . . 7 2.7. Miscellanous . . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol operations . . . . . . . . . . . . . . . . . . . . . 8 4. Pros and cons . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Preventing DoS . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Against the MN . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Against the HA . . . . . . . . . . . . . . . . . . . . 10 5.1.3. Against the GW . . . . . . . . . . . . . . . . . . . . 10 5.1.4. Against the Infrastructure . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Ebalard Expires February 7, 2011 [Page 2] Internet-Draft m6t August 2010 1. Introduction 1.1. Initial thoughts MIPv6 [RFC3775] protocol has been designed to work on IPv6 networks: nothing was initially provisioned in the specification to support movement of Mobile Nodes to IPv4-only networks (with or without NAT) or the communication with IPv4 peers. In order to address the need to support those use cases, DSMIPv6 [RFC5555] has been published: it provides a global solution to support the movement of mobile nodes to IPv4 only networks with and without NAT and their communication with IPv4 peers via the Home Agent. The use of DSMIPv6 inhibits Route Optimization mechanism. The approach selected by DSMIPv6 is to implement IPv4 and NAT awareness on the MN and its HA. Even if this probably has advantages (efficient on-wire format), this IPv4/NAT-awareness also adds a lot of complexity to the MIPv6 process and in its relationships with IPsec and IKE. Considering the initial problems at hand: 1. Supporting the use of MIPv6 for MN stuck in IPv4-only networks. 2. Supporting the communication of MIPv6 MN with IPv4 peers. the following separate approaches are possible: 1. Use of a simple tunnel (over IPv4/UDP) between the MN and its HA 2. Use of NAT64 mechanism in the Home Network. This document tries and address the first problem by covering the first approach. 1.2. Rationale MIPv6 works fine when IPv6 connectivity is available because its logic remains quite simple. The absence of NAT on IPv6 networks (i.e. flat routing) has made it possible to greatly simplify the protocol and its deployment, compared to MIPv4. IPsec and IKE have seen limited deployment in IPv4 networks (in favor of TLS) partly due to the difficulty or inability to use them in ubiquitous NAT environments. When IPv6 connectivity is available, IPsec and IKE work and interoperate easily. The interactions with MIPv6 in order to secure the operation of the protocol are quite simple (see [MIGRATE]). Ebalard Expires February 7, 2011 [Page 3] Internet-Draft m6t August 2010 Basically, if it is possible to mask the existence of IPv4 and NAT to MIPv6, IPsec and IKE, it may be possible to allow its use from IPv4- only networks without invasive and costly changes in the implementation. Additionally, the rationale for this work also results from: o Considerations on the limited set of flows associated with MIPv6 protocol: when RO is not used, MN's traffic is always tunneled via the HA. o The use of Teredo by the author on IPv4 networks as an alternative solution to DSMIPv6 (due to its unavailability on most platform). o Considerations on the architectural requirements and drawbacks of Teredo (qualification procedure, reliance on Teredo servers, MTU considerations, ...) in the specific context of a MIPv6 MN. 2. Problems and solutions As discussed above, the idea is to provide IPv6 connectivity via a simple tunnel over IPv4 and UDP to the HA. On the MN, the tunnel interface hides the existence of IPv4/NAT and makes it possible to operate MIPv6 in a transparent fashion. On a gateway in front of the HA (or on the HA), this provides the same benefit. Nonetheless, creating, using and maintaining this tunnel both on the MN and the gateway in front of the HA requires some care. Problems and selected solutions are discussed below. 2.1. UDP port to use on the tunnel GW Clients of the tunnel gateway (MN or MR) need to access it on a fixed port. It is nonetheless not worth asking IANA to allocate a dedicated port for that purpose. Basically, the tunnel mechanism described in this memo is a custom version of what STUN [RFC5389] or Teredo [RFC4380] provide. As the tunnel GW is a closed service dedicated to the MN, it may be possible to have the GW listen on STUN or Teredo ports (respectively 3478/udp and 3544/udp). As filtering may be in place in the IPv4 networks the MN found themselves, it could be possible to use a destination port associated with a protocol which is usually authorized, like 4500/udp, 500/udp or 53/udp. As the choice of the specific ports to be used for a given MN community highly depends on the habits of the MN and the foreign networks they are usually in, the choice of the port on which the Ebalard Expires February 7, 2011 [Page 4] Internet-Draft m6t August 2010 tunnel qateway should listen is left as a local decision. The service of the gateway may be available on different ports. 2.2. MN's CoA on the tunnel interface A MN needs an IPv6 address to use as source for the packets it sends to the HA, i.e. to be configured on the MN's tunnel interface. Because this address will be the one seen by the HA for the MN, it needs to be unique among all the MN. Additionally, all the addresses used by the MN for their tunnel connectivity needs to be routed to the tunnel gateway. The MN has a unique address available: its HoA. Nonetheless, it is not directly usable over the tunnel because the associated prefix is also the home prefix. Using this would create additional routing complexities on the HA and may create additional attack vectors. As the addresses used by the MN will never be directly routed over the Internet, it is possible to use a Unique Local prefix for that purpose. Generation of an ULA prefix should be performed as described in [RFC4193]. The remaining of the address after the 48 bits ULA prefix are set as follows. The 16 bits directly following the first 48 bits of ULA prefix are available for the administrator to configure additional subnets if needed. The interface identifier is constructed in the following fashion by a MN: o the first 16 bits are filled with the MN ID, a value known by the MN. It does not need to be known by the tunnel GW or the HA. It is just required to be unique among the set of MN using the /64 prefix. o the following 48 bits are filled with random bits by the MN each time it changes its point of attachment in the IPv4 infrastructure. The rationale for this random value is given later in the document. From a theroretical standpoint, the combination of the subnet ID and the MN ID allows an administrator to support up to 2**32 MN, i.e. those are not a limiting factors. In the end, the tunneling component on the MN should be provided directly with the /80 prefix. To summarize, the prefix has the following format: Ebalard Expires February 7, 2011 [Page 5] Internet-Draft m6t August 2010 +---------------------+---------+---------+-------------------+ | /48 ULA prefix | 16 bits | 16 bits | 48 bits | | |subnet ID| MN ID | random value | +---------------------+---------+---------+-------------------+ 2.3. Maintaining NAT states The MN needs to maintain states in the NAT GW which handles its traffic in order to remain reachable from the HA (i.e. by peers which use the MN-HA tunnel). The MN basically needs to exchange keep-alive messages with the tunnel GW in order for the states in the NAT GW to be maintained. Those exchanges are required only when no traffic is exchanged between the MN and its HA. If the MN has not sent and received traffic via the tunnel for 30 seconds (default refresh interval borrowed from Teredo specification), the tunneling component on the MN will send an empty IPv6 packet (Next Header in IPv6 header set to 59) via the tunnel. The IPv6 source address of the packet is set to the tunnel interface address and the destination address is set to fe80::1. When the tunnel component receives the IPv6 packet over the tunnel, the specific destination address (fe80::1) and the absence of upper layer (next header set to 59) indicate the packet is a keep-alive message. It verifies an active state exists for the source address in the packet and that the IPv4 parameters match the state. If this is the case, it replies with a similar message but with the addresses reversed. Otherwise, it silently drops the packet. 2.4. Route management on the tunnel GW Route management on the tunnel gateway is implementation dependent but reflects the status of active states. An active state is created only from a temporary state (a packet was recently forwarded from the tunnel gateway to the HA) when the HA replies with traffic to the MN. Regarding the removal of old states or routes, an invalidation timer should be use in order to garbage collect old states. This timer should be refreshed each time traffic (data or keep-alive messages) is exchanged with a MN over the tunnel. In practice, the protocol does not offer a way for a MN to deregister a state. When the MN registers from a new IPv4-only network, it generates a new IPv6 address and uses it. As no traffic is exchanged after some point via the unnel for that address, it is garbage collected automatically. Ebalard Expires February 7, 2011 [Page 6] Internet-Draft m6t August 2010 2.5. Multiple tunnel interfaces on a MN A MN may want to use multiple tunnel interfaces simultaneously, via the same tunnel gateway. The addressing scheme and the protocol does not prevent that. This is mainly a matter of preference among the different interfaces. Additionally, if the same prefix, subnet ID and MN ID are used for all the tunnel interfaces of the MN (i.e. the same /80 prefix), then some local syncrhonization is required to prevent the 48 simultaneous use of identical 48 bits random values. 2.6. MTU considerations Proposed approach is based on UDP tunneling. As for Teredo protocol, implementation of this specification SHOULD NOT set the DF bit of the encapsulating IPv4 header. Nonetheless, packets exchanged between the MN and its HA via the tunnel may undergo PMTUD both at the IPv6 level (between the tunnel GW and the HA) and at the IPv4 level (between the MN and the tunnel GW). When implementing the mechanism, PMTUD should be one of the first things to validate. Teredo does not provide a mechanism for a Teredo client to control the MTU of its Teredo interface and the one on the relay. It is statically set to 1280, which is a safe bet to counter the possible filtering of ICMP messages in the IPv4 internet. In the protocol described in this memo, a different approach is selected. The MTU of the tunnel interface is initially set to a default value of 1472 bytes on both sides (on the MN and on its tunnel GW). Reception of ICMP Packet too big messages from IPv4 routers on the path. For use in specific environments, implementations should provide a mean for admnistrator to set the default MTU to a different value. 2.7. Miscellanous This subsection covers additional miscellanous points: o HA reachability via the tunnel GW: monitoring the reachability of the HA via the tunnel gateway is outside the scope of the protcol but may be implemented if needed. The reachability will usually depends on the UDP ports used for contacting the GW, i.e. on the filtering implemented by the IPv4 network (probably by the NAT GW). Ebalard Expires February 7, 2011 [Page 7] Internet-Draft m6t August 2010 o Teredo automatic sunset equivalent: Teredo provides an automatic sunset mechanism. The protocol does not provide one. This is left has an implementation decision. It should be noted that the use of the tunnel from an fast IPv4-only network (ethernet access) may be more efficient in some case than the use of a native IPv6- enabled connection mean via an slower network (3G). o Usability from a public address: when a public IPv4 address is available at the MN, other transition mechanisms (e.g. 6to4) may be used to get IPv6 connectivity. From an encapsulation standpoint, 6to4 is more efficient (8 bytes gain per packet). Additionally, unlike 6to4, current approach require (no matter the characteristics of the available IPv4 address) to implement and use the keep-alive mechanism described above. Nonetheless, compared to 6to4, proposed approach may provide a shorter path to join the HA via the tunnel GW. o Behavior on IPv6-enabled networks: the mechanism is useful from IPv4-only networks (with or without NAT) but also works when IPv6 and IPv4 are both available. When usable (i.e. IPv4 is available), the mechanism provides an additional IPv6 interface on the system that the MIPv6 module can consider. The activation of the mechanism does not inhibit other existing interfaces. 3. Protocol operations This short section describe the operation of the protocol. The tunnel component on a MN is initially configured with: o The IPv4 address of the tunnel gateway associated with its HA o A /80 prefix created as described in previous section. When a MN gets IPv4 connectivity (IPv4 address and route), it selects a random 48 bits value. It concatenates this values to its configured /80 prefix and installs the address on the tunnel interface. A default route is configured for IPv6 traffic to flow via this tunnel. A UDP socket is created for further emission to the HA IPv4 address. At that point, if the MIPv6 module decides to use the newly configured address as CoA (e.g. this is the only one available at the moment on the MN), it sends an IPsec-protected Binding Update message to its HA (or an IKE packet for negotiating IPsec SA for protecting the Binding Update message). The packet is routed via the tunnel interface and sent to the tunnel GW via the UDP socket. The tunnel GW in front (or on) the HA receives the IPv4 packet and process it after some sanity checks on the addresses (as described in Ebalard Expires February 7, 2011 [Page 8] Internet-Draft m6t August 2010 previous section). It creates a temporary state containing the addresses and ports and forwards the packet to the final destination (the HA). The HA processes the packet and sends a reply to the MN (IPsec protected BA, IKE packet, ...). The tunnel gateway handles that packet and first verifies if an active state exists for that destination. If it is the case, the packet is forwarded to the remote IPv4 NAT GW using the parameters available in the state. If no active state exists, then, a lookup in the temporary states is performed: if one is found, it is marked active and used. Temporary states are garbage-collected often. Active states are garbage-collected less often and updated when traffic is exchanged in both directions. 4. Pros and cons This short section provides the pros and cons of the approach. The approach described in this memo is simple, standalone and transparent both on the MN and the HA. It does not require any changes to the MIPv6, IKE or IPsec code running on both compoments. It is fully compatible with NEMO. Unlike DSMIPv6, as the approach does not modify MIPv6 implementations, it does not extend MIPv6 protocol to support communications with IPv4 peers. NAT64 may be used at the edge of the Home Network to allow communications with IPv4 peers. Additionally, DSMIPv6 provides IPv4 address stability to the MN (i.e. an IPv4 HoA). The approach described in this memo does not provide that either. In most environments, IPv4 address stability is usually not needed or useful because nodes are usually provisioned with private IPv4 address and have for that reason limited reachability outside their private domain. 5. Security Considerations 5.1. Preventing DoS 5.1.1. Against the MN Nothing is done to prevent an attacker located on the path between the MN and the tunnel GW. Because such an attacker has access to all the traffic exchanged with the tunnel GW and the HA, there is not much that can be done. Ebalard Expires February 7, 2011 [Page 9] Internet-Draft m6t August 2010 Nonetheless, the protocol provides protection for the MN against off- path attackers. This is done in order to avoid such an attacker to redirect traffic expected for the MN to a controlled location. Protection against such attacks is obtained by randomizing the last 48 bits of the interface identifier. A new value is selected each time the MN changes its point of attachment to the IPv4 network. It would also be possible to change that value more often if needed. 5.1.2. Against the HA The access via the tunnel GW is not expected to open additional DoS possibilities against the HA. 5.1.3. Against the GW The Gateway is basically a single point of failure for the MN which use it as their connection mean to their HA from IPv4 network. If an attacker manages to perform a DoS against the tunnel GW, this may prevent legitimate peers to access their HA. In order to prevent that, care is needed when implementing the tunnel GW. Rate limiting and garbage collection can be used for that purpose. When a packet is received from a new IPv4 address (port does not matter), some initial sanity checks are performed on the packet (IPv4 address is public, IPv6 destination address is HA address, IPv6 address is from the configured ULA prefix, ...). After that initial validation of the packet, a state is recorded, containing the IPv4 source @, the UDP source port and the IPv6 source address of the packet. Such a state should be associated a very low (few ms) garbage collection timer. The value should be configured based on the environment in which the tunnel GW is deployed: it should basically match the expected processing time of a packet on the HA (first IKE packet, BU, ...). Creation of such states should also be rate-limited on a per IPv4 address basis (not considering the source port): this would prevent an individual attacker to perform a DoS against the service. It would basically require her to have access to a set of bot. The upper limit to use per IPv4 address is not specified in this memo. It should be configured locally based on the environment. It may be possible for some deployments to expect multiple simultaneous connections originatig from the same NAT GW. In all cases, that number is expected to be low. Ebalard Expires February 7, 2011 [Page 10] Internet-Draft m6t August 2010 When a packet is received by the tunnel GW from the HA, a lookup is performed to check if a valid state exists for the IPv6 destination address. If one is found, it provides the IPv4 destination address and port of the NAT GW associated with that IPv6 address. If it does not yet exist, then a lookup for the address in the pending states is performed. If one is found, it becomes active. The packet is forwarded to the remote GW on the given IPv4 address and UDP port. Garbage collecting for that state is activated: the purpose is for state to be removed if no traffic is exchanged in both direction for more than the expected NAT GW timeout. The maintenance of the state is left to the MN as described in a previous section of the document. 5.1.4. Against the Infrastructure An attacker may want to use the tunnel GW to create amplification attacks against elements of the IPv4 infrastructure. For the reasons explained above, an attacker will not be able to redirect a MN's traffic to a controlled address. But the HA is still expected to reply to some unauthenticated probes. For instance, if an attacker targets it's IKE daemon via the tunnel GW, it will get an answer. If it is able to spoof its source address, the response will be sent to the spoofed source address. This kind of attack is still already possible on the IPv4 infrastructure and the attacker would not get additional gain in using the tunnel GW for such a scenario. 6. References 6.1. Normative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 6.2. Informative References [MIGRATE] Ebalard, A. and S. Decugis, "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in progress), August 2008. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, Ebalard Expires February 7, 2011 [Page 11] Internet-Draft m6t August 2010 February 2006. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Author's Address Arnaud Ebalard EADS Innovation Works 12, rue Pasteur - BP76 Suresnes 92152 France Phone: +33 1 46 97 30 28 Email: arnaud.ebalard@eads.net Ebalard Expires February 7, 2011 [Page 12]