INTERNET-DRAFT "Internet Protocol Five Fields - Mobile TCP", Alexey Eromenko, 2016-09-29, expiration date: 2017-03-29 Intended status: Experimental A.Eromenko September 2016 Mobile Protocol Stack ----------------------------------- for Internet Protocol "Five Fields" Specification draft Abstract This document describes a mechanism, that can be used to live-migrate opened TCP/UDP/other transport sessions between a mobile server and a mobile client. This can work even after a mobile node moved to a different subnet or disconnected, as long as a session did not timeout. It also describes limitations and includes NAT traversal scenarios and guidelines for "middlebox" vendors. 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." Copyright Notice Copyright (c) 2015 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 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.................................................. 2. Comparison of Mobile Protocol Stack to Mobile IP.............. 2.1 Comparison of Mobile TCP to Multipath-TCP.................... 3. Socket creation............................................... 3.1. Initiating a Mobile TCP Session............................ 3.2. Notification on received Source IP address and port........ 4. New ICMP Commands............................................. 4.1 ICMP Migrate................................................. 4.2 ICMP Anycast Server acknowledgement.......................... 4.3 ICMP NAT acknowledgement..................................... 5. Incoming sessions: Dynamic DNS................................ 5.1. Incoming sessions: Destination NATs and Load Balancers...... 6. Limitations................................................... 7. Requirements from middleboxes................................. 8. Requirements from operating systems........................... 9. Security considerations....................................... Appendix A: Simple Mobile TCP scenario........................... Appendix B: Mobile TCP Double NAT traversal scenario............. Author Contacts.................................................. 1. Introduction "basically TCP/UDP/other session migration... of mobile nodes between subnets, without losing connectivity" Mobile Protocol Stack (MOPS) is a solution to the Mobile IP problem. Mobile IP problem derived from IP itself. Traditional IP has chained the "location" and the "identity" of a device by the routing location and traditional socket 5-tuple: (s.port, d.port, s.address, d.address, protocol) Historically, it was never possible in the original TCP/IP design to live-migrate a session or socket. An old socket had to be closed, and a new one had to be opened, and a new session had to be established. This is not a problem for desktop computers, as they always reside in the same particular LAN, and the same subnet. But it becomes a problem, if you want to move "mobile nodes" from one subnet to the next, without losing connectivity. Mobile node can be either a client or a mobile server live- migrating from one subnet to the next. This whole idea comes from "Live Migration" in the virtualization field, where you can migrate a living virtual machine, and it keeps working. MOPS, in fact, will allow me to live-migrate between Ethernet, 4G cellular and WiFi at home, and keep working. Despite the difficulty and limitations, the candy (advantage) of my technology is a big one: Ability to move between different WiFi hotspots, without losing connectivity, even if those are operated by different organizations, without the need to configure routers or WiFi access points. Today, Mobile IP can't do that. 2. Comparison of Mobile Protocol Stack to Mobile IP Traditional Mobile IP solution is way too complex and sub-optimal. For example Mobile IPv6, RFC-6275 spec takes over 400 kilobytes ! Mobile IPv4, RFC-5944 is similar in spirit. Mobile IP requires setting up a Home Agent (Router) and Foreign Agent (Router), making tunnel between them, having access to both, configuring both, and it is way too complex... In the end packets are travelling slowly over the network, via sub-optimal routes, slowing down traffic. Needless to say, that if you *do not* control said routers, there is *no way* to make Mobile IP work. MOPS is a fairly elegant solution, that covers most of the real-world use-cases, that gives optimal routing, doesn't require access to any routers, let alone configuration what-so-ever !!! But it requires changes to the client & server operating systems in question. Mobile Protocol Stack (MOPS) is sub-divided into "Mobile TCP" and "Mobile UDP" parts. This is a clever trick achieved through Internet Control Message Protocol extensions and special sockets and better integration between layers. 2.1 Comparison of Mobile TCP to Multipath TCP A new standard recently popped up, Multipath TCP (MP-TCP). This standard allows nodes to add or remove subflows (i.e. new TCP sockets), allowing for migration between subnets as-long-as-one flow remains intact. I.e. you must have 3G enabled and migrate from WiFi subnet A to WiFi B. MP-TCP will not be able to connect after disconnecting all subflows. Mobile TCP, by contrast, allows re-connecting even after full disconnect, as long as TCP session did not timeout. 3. Socket creation Sockets created with "MOBILE_ALLOWED" flag can later be remapped to a different IP address and/or port. When creating a socket, the application SHOULD optionally specify "MOBILE_ALLOWED" flag to the TCP or UDP protocols. When socket is created with "MOBILE_ALLOWED" flag, it is RECOMMENDED to increase timeout timers for such session. This flag is required for ALL Transport-layer protocols, that want mobility. Design note: Due to experimental nature of MOPS, MOBILE_ALLOWED flag is required to reduce amount of attacks on industry-critical applications, long-lived connections, such as BGP sessions. 3.1. Initiating a Mobile TCP Session This is the same signaling as for initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MOBILE_CAPABLE option. Client Server ------ ------ MOBILE_CAPABLE -> [SYN flag] <- MOBILE_CAPABLE [ACK flag] ACK + MOBILE_CAPABLE -> [SYN+ACK flags] TCP "MOBILE_CAPABLE" Option: +---------+---------+ | Kind=32 |Length=2 | +---------+---------+ Kind: 32 (To be determined by IANA) Length: 2 Design note: This allows middleboxes to be aware of Mobile TCP session, to increase their timeouts, which is important for NATs & Firewalls. This also allows NAT routers to send "ICMP NAT acknowledgements" only if a TCP session has "MOBILE_CAPABLE" flag, reducing noise traffic in corporate environment. 3.2. Notification on received Source IP address and port This feature exists mainly as a source NAT traveral helper. This way the client, behind a source NAT, knows his source port+IP. Upon receiving the first packet any Transport layer protocol, the server must respond with an IP option, that says on which address and port it has received the traffic. For connection-oriented protocols, like TCP, it must be done during the ACK responce by the server. For connection-less protocols, like UDP, several packets needs to respond with IP option, configurable by the server OS vendor. This answer should be encoded into IP-level "Destination Options". The reason is that it is a Transport layer-neutral protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension =n | Len = 10 | Received source port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received source IP address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | reserved... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: n = (number to be determined later by IANA) IP-FF extension class D1 (Destination Discretionary variable). Received source port (16-bit) Client's port from the perspective of the server. Received source IP address (50-bit; pre-padded by 14 zeroes) Client's address from the perspective of the server. NOTE: If there is a destination NAT (like load-balancer), it should intercept and modify this packet. NOTE2: This command logically overlaps with "ICMP NAT acknowledgement". 4. New ICMP Commands 4.1. ICMP Migrate Description This command instructs a remote node to remap the binding of an already opened socket, changing the tuple, allowing the node to send responses to a different IP address and port. Remote node is typically a server, but can be a client. Historically, it was never possible in the original TCP/IP. An old socket had to be closed, and a new one had to be created. The destination port and IP typically do not change, as they belong to the server. If used improperly, this command can be a security-hazard, allowing remote hackers to hijack running sessions. For this reason, two defensive mechanisms were developed: TCP Sequence number and application-supplied Unique ID. TCP Sequence number provides a basic protection against off-path session hijacking, without the need to modify existing applications, as a TCP stack provides built-in protection from remote hackers. It doesn't protect from Man-in-the-middle (MITM) attacks however. Unique ID provides additional protection against Deniel-of-Service attacks, and other session hijacking attempts by evil hackers, and it optionally can use encryption to make session hijacking unbreakable, including MITM hackers. If an application requires "Unique ID", it must be supplied instead of TCP Sequence number. For example, a simple Unique ID can be a "Player ID" for games, or a "Video stream ID" for video-on-demand. Effective for basic defences, but not strong. For encrypted applications, it can be a one-time-generated hash of a newly generated shared secret key. After one successful migration, this hash (and key) must be re-generated, by a predefined deterministic algorithm. This would be much stronger defence. This command is sent by the Mobile Node, after the interface through which packet flow started was disconnected, and after at least one interface was (re)-connected. Acknowledgements are sent by remote server, or by middleboxes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4| CRC32 Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8| Type | Code |Version|Reserve| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Protocol | Previous Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Number of Ports (N) | Migrated Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28| Previous Source Port [1] | Migrated Source Port [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32| Previous Destination Port [1]| Migrated Destination Port [1]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36| | + Sequence number / Unique ID [1] + 40| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44| Previous Source Port [2] | Migrated Source Port [2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 48| Previous Destination Port [2]| Migrated Destination Port [2]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 52| | + Sequence number / Unique ID [2] + 56| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Source Port [n] | Migrated Source Port [n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Destination Port [n]| Migrated Destination Port [n]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sequence number / Unique ID [n] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) ICMP Fields: Checksum (32-bit) The checksum must be computed according to ICMP spec. Type (16-bit) 100 (?) TBD; some number assigned by IANA Code (8-bit) 0 = migrate 1 = migrate atomic (rollback, if one port migration fails) 2 = migration success! 3 = migration failed. Code 0 or 1 is a request by the mobile node client. Code 2 or 3 is a reply by server. Server must send all the details of the migrate command, with all the fields intact, as received. Version (4-bit) 1 Reserved (4-bit) field Should be set to zero by transmitter, ignored by receiver. Protocol (14-bit) Upper-level Protocol, such as TCP or UDP. Same as in IP header. If you want to mass-migrate applications using several protocols, like both TCP and UDP, you will need to issue multiple Mass-migrate commands. Previous Source Address (50-bit) The source IP address, before migration. Must use Translated Source IP, if behind NAT. Number of Ports (14-bit) Amount of ports to be migrated (1...n) Migrated Source Address (50-bit) The new source IP address, where Mobile Node (MN) would like to receive replies of a continued session. NOTE: Node MUST check this command for 999 field limit. According to IP-FF addressing specification, fields values between 1000 and 1023 are invalid. Previous Source Port (16-bit; n fields) The source TCP port of a socket, before migration. Must use Translated Source port, if behind NAT. Migrated Source Port (16-bit; n fields) The new source TCP port of a socket, where Mobile Node (MN) would like to receive replies of a continued session. Sequence number / Unique ID (64-bit; n fields) Sequence number: For TCP protocol, it would be the TCP sequence number. The mobile node must get it from its own TCP stack, as-if preparing the next TCP packet for transmission. Unique ID: It must be an application-supplied value, matching on both ends. While TCP sequence number provides a basic protection, against session hijacking, a Unique ID improves security. If TCP application on the server-side provides "Unique ID" requirements, it *MUST* be supplied, instead of TCP seq. number. If TCP application does not define "Unique ID", then Mobile Node must provide TCP sequence number. UDP: Because UDP protocol lacks a "sequence number", the only way to migrate it, is if server side application asks for a Unique ID, and mobile node matches it. Other transport-layer protocols MAY specify their own Sequence identifier or equivalent. Technical details: Replies: On first attempt, either "ICMP migration failed." or an "ICMP migration success!" should be returned to client. A reply must have the same parameters, with all fields intact, as a request, except Code. If at least one port migration failed, it should inform the mobile node as "ICMP migration failed.", but returning only the ports, that failed to migrate. Typically, request code 0, ports that have migrated successfully should stay migrated (i.e. do not roll-back). But if request was send with code 1 "migrate as one atomic operation", all ports must be rolled-back, if one of the ports failed to migrate (due to Unique ID match failure, TCP sequence number mismatch, port timeout, or otherwise). Retransmission by client: If no reply was received in the next few seconds (I recommend 2 sec), the mobile node should re-send "ICMP migrate" up to 3 times. After this declare old socket as "dead", and report error to the application.(like it would after receiving TCP reset) Timing & Retransmission by server: If "ICMP migrate" command received with the same previous source IP address + source port too often, it should be silently discarded by server, as it indicates either a hacker attempt, or a flapping link. Recommended is 5 seconds interval before accepting new attempt. After timeout expires, server can accept new commands and send new ICMP migration reply. 4.2 ICMP Anycast Server acknowledgement: Description This command informs a mobile node client, how-to re-connect to this particular Anycast server, should TCP connection fail. Only an Anycast server (or its middlebox) can send this message to the Mobile Node, when it got a new incoming TCP session SYN with "MOBILE_CAPABLE" flag. Historically Anycast servers were used, as a connectionless system with UDP, for quick queries such as DNS, or very short TCP requests, because the path could change mid-way. Using Mobile Protocol Stack, it is possible to reconnect again, and run much more complex, connection-oriented services on Anycast servers. This requires that Anycast servers have unicast addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4| CRC32 Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8| Type | Code |Version|Reserve| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| Protocol | Anycast Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| Reserved | Unicast Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28| Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) ICMP Fields: Checksum (32-bit) The checksum must be computed according to ICMP spec. Type (16-bit) 101 (?) some number assigned by IANA Code (8-bit) 0 Version (4-bit) 1 Reserved fields Initialized to zero on transmission, ignored by receiver. Protocol (14-bit) Upper-level Protocol, such as TCP or UDP. Same as in IP header. Anycast Destination Address (50 bits) The IP address of the server, to which MN is currently connected. Unicast Destination Address (50 bits) The unique Unicast IP address of the server, to which Mobile Node can re-connect. Source port (16 bits) Protocol source port (of mobile node) of an ongoing session. Destination port (16 bits) Protocol destination port (of anycast server) of an ongoing session. 4.3 ICMP NAT acknowledgement: Description This command solves NAT traversal problem by instructing a mobile node client, that it's external or translated addresses are different from internal or original. This information will be required down the road to construct a proper ICMP migrate command parameters. Only a NAT Router can send this message to the client, when it intercepts a new TCP session (with TCP SYN and MOBILE_CAPABLE flag), or when it intercepts an ICMP migrate command. NOTE: This command logically overlaps with "Notification on received Source IP address and port". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4| CRC32 Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8| Type | Code |Version| Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16| Protocol | Original Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 20| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24| Number of Ports (N) | Translated Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 28| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32| Original Source Port [1] | Translated Source Port [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36| Original Source Port [2] | Translated Source Port [2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n | Original Source Port [n] | Translated Source Port [n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (bytes) IP Fields: Hops 1 ICMP Fields: Checksum (32-bit) The checksum must be computed according to ICMP spec. Type (16-bit) 102 (?) some number assigned by IANA Code (8-bit) 0 Version (4-bit) 1 NAT Level (4-bit) Typically 1, for one-level of NAT routing. The NAT Router must decide if it is the closest level to client, it would send level = 1, but if it received "NAT acknowledgement" from another router with matching parameters, like this: my NAT table: NAT level=1 original.IP address: A original.port: B translated.IP : C translated.port : D Received ICMP NAT acknowledgement from 2nd router: NAT level=1 original.IP address: C original.port: D translated.IP : E translated.port : F NAT Router sees that your "translated IP + port" fields match a NAT ack from a 2nd router, in it's "original IP address + port" fields, NAT Router knows there is one more level to go. It should increment the NAT level by +1, and send to ICMP NAT acknowledgement client. And add this info to own NAT table, as 2nd level, as more levels may exist. See "Appendix B" for example. Reserved (8-bit) Initialized to zero on transmission, ignored by receiver. Protocol (14-bit) Upper-level Protocol, such as TCP or UDP. Same as in IP header. Original Source address (50 bits) Source IP address of the client, before Network Address Translation. Number of Ports (14-bit) The amount of ports, that were NAT-ted. Typically 1. When a new (TCP) session begins, it is only one port. Multiple ports can be NAT-ted at once, only if NAT router intercepted "ICMP migration success" acknowledgement. Translated Source address (50 bits) Source IP address of the client, after Network Address Translation. Original Source port (16 bits; n fields) Upper-level Protocol port, before Network Address Translation. Translated Source port (16 bits; n fields) Upper-level Protocol port, after Network Address Translation. 5. Incoming sessions: Dynamic DNS In order for the Mobile Node to be able to accept incoming sessions, it must have a Fully Qualified Domain Name (FQDN), and update its own entries via Secure Dynamic DNS. See [RFC-2136] and [RFC-3007] for details. 5.1. Incoming sessions: Destination NATs and Load Balancers When "ICMP Migrate" command is sent, it may reach a destination NAT. For a corporate Web Server, this is typically the load balancer. But if it is the *Mobile Server*, whom migrates to a different subnet then a home router (that is usually source NAT), suddenly becomes a destination NAT, for an incoming traffic from the Internet. Destination NAT cannot remap sockets by itself, since it lacks the secret knowledge of Application-specific "Unique ID". But it can match the request on it's NAT table, and propagate it further. Only when the destination node answers with "ICMP Migration success!", a destination NAT can remap it's own NAT table. In case of a partial failure, where only some sockets were remapped, it should do a partial remapping of it's NAT table. For simplicity, NAT can forward the "ICMP Migrate" command with code 1, "migrate atomic", or rollback if one port fails. 6. Limitations: Protocols, that open TCP ports in reverse direction (like FTP), from server to client, can have trouble. Limitation. So perhaps Mobile IP is still needed for edge cases. I believe, that Application Specific Extensions (ASEs) will need to be written for problematic protocols, just like with NAT. This allows for certain vendor differentiation. Limitations: Protocols that are NAT-alien may fail for MOPS. ...for a similar reason: they exchange IP-level data as application-layer payload. Other limitations includes Firewalls and middleboxes, that have TCP initial sequence number (ISN) randomization. This feature must be disabled. This feature is incompatible with Mobile TCP. In addition, all NATs (and load balancers) need to be Mobile TCP/ MOPS-aware, at both source and destination networks. The good news, is that because Mobile TCP is standardized together with IPFF, old firewalls and NAT Routers must be thrown out-the-window anyway. (or get a major software upgrade...) Obviously, if both ends migrate at the same time, a connection will fail. Dynamic DNS update will let you re-establish it later. 7. Requirements from middleboxes, firewalls and NAT routers: support for ICMP NAT acknowledgement. ability to intercept "ICMP redirect" command. Never modify initial sequence number (ISN) for TCP sessions. "ICMP migrate" command MUST be intercepted by NAT, and modified, just like a new TCP session would. "ICMP NAT acknowledgement" command MUST be implemented in IPFF NAT Routers. Also when "ICMP migrate" command is intercepted by a stateful firewall, a new rule should appear on it's firewall table, something like "TCP, ESTABLISHED", with proper socket. 8. Requirements from operating systems: For MOPS to work, changes the Operating System is required. Ability to change and remap opened sockets on-the-fly. Opening sockets with "MOBILE_ALLOWED" flag. Second, it must provide TCP sequence number to IP/ICMP layer, both to send and to receive "ICMP migrate" command. Third, it must allow to pass Application-level parameters, such as Unique ID down to IP/ICMP layer. 9. Security considerations: With at 1st look it looks very insecure to give anyone an option to hijack a session from remote, but digging deeper we discover the following: If a hacker is off-path (your subnet, or your server's subnet or ISP), not in the middle (on-path), he has no realistic chance to guess both the 50-bit source IP address, and 16-bit port and 32 or 64-bit TCP sequence number, and/or Unique ID by application layer. If he *is* a man-in-the-middle attacker (MITM), then he can hijack TCP session by listening to SYN/ACK, and knowing the next sequence number, spoofing source IP address, and if his computer answers to packet before yours, session will get hijacked with normal TCP (without Mobile TCP). So in this case Mobile TCP is not worse than the standard TCP. The good news, is that sensitive data transmission should be encrypted, and in reality it is. Both SSL (HTTPS) and SSH are commonplace, and if he hijacks an encrypted session, it will be just shut-down, as he does not possess the keys. Mobile nodes should use Initial Sequence Number (ISN) randomization. For best security, use encrypted protocols, and one-time Unique ID. This way, hacker cannot hijack session, even if he is a man-in-the-middle. Spoofed ICMP NAT acknowledgements can be used as a sort-of denial- of-service attacks, preventing migration. Appendix A: Simple Mobile TCP scenario: (without NAT or Firewall) MN = Mobile Node. A typical smartphone, tablet or laptop web client. In reality, a Mobile node can be... a server. But this scenario focuses on Mobile client. Remote Server 8.8.8.8.8, is a typical HTTP server, listening at TCP/80. Organization A 525.8.78.3.x/40 .9 .99 +----------+ +--------+ | Mobile | |Router-A| | Node |------------------| | +----------+ +--------+.2 || | 525.8.78.2.x/40 || | .99 || +----------+ +----------+ || | Internet |-----| Server | || | Cloud | |8.8.8.8.8 | _||_ +----------+ +----------+ \||/ | .99 \/ | 775.2.23.5.x/40 +--------+.5 |Router-B| ------------------| | +--------+ .99 775.2.23.6.x/40 Organization B Mobile Node opened a socket to a remote server. source.port = 1027, source.IP = 525.8.78.3.9, destination.port = 80, destination.IP = 8.8.8.8.8 ...a typical socket tuple. Nothing special. Now Mobile Node decided to go to a different location, and joined a different network: Organization A 525.8.78.3.x/40 .99 +--------+ |Router-A| ------------------| | +--------+.2 || | 525.8.78.2.x/40 || | .99 || +----------+ +----------+ || | Internet |-----| Server | || | Cloud | |8.8.8.8.8 | _||_ +----------+ +----------+ \||/ | .99 \/ | 775.2.23.5.x/40 +----------+ +--------+.5 | Mobile | |Router-B| | Node |------------------| | +----------+ +--------+ .6 .99 775.2.23.6.x/40 Organization B Our Mobile Node got a new IP address via DHCP from Router-B; 775.2.23.6.6 And due to losing previous connecting, it must look it's own sockets table... ohh we have a connection from "525.8.78.3.9", which is no longer our address ! We must migrate this old connection to our new address ! Let's send an "ICMP migrate" command. "ICMP migrate" requires several parameters, including our previous IP+port, and our new IP+port: Protocol = 6 (TCP) TCP sequence number (must query its own OS) - a very long 32-bit number. previous source port = 1027 previous source IP = 525.8.78.3.9 migrated source port = 2098 (or whatever free port it has) migrated source IP = 775.2.23.6.6 Server must compare against it's own opened sockets, and verify TCP seq. number. The socket now will be re-mapped (on both client and server): source port = 1027, source IP = 525.8.78.3.9, destination port = 80, destination IP = 8.8.8.8.8 to: source port = 2098, source IP = 775.2.23.6.6, destination port = 80, destination IP = 8.8.8.8.8 Server will send "ICMP migration success!" And hoopla ! Connection will continue ! Appendix B: Mobile TCP Double NAT traversal scenario: Source Network Address Translation (NAT) with Port Address Translation (PAT) MN = Mobile Node. A typical smartphone, tablet or laptop web client. Remote Server 8.8.8.8.8, is a typical HTTP server, listening at TCP/80. Organization A 10.2.0.0.x/40 10.0.0.0.x/40 .1 .99 .1 .99 +----------+ +--------+ +--------+ | Mobile | |Router-A| |Router-B| | Node |----| +NAT |----| +NAT | +----------+ +--------+ +--------+.2 || | 525.8.78.2.x/40 || | .99 || +----------+ +----------+ || | Internet |-----| Server | || | Cloud | |8.8.8.8.8 | _||_ +----------+ +----------+ \||/ | .99 \/ | 775.2.23.5.x/40 +--------+ +--------+.5 |Router-C| |Router-D| | +NAT |----| +NAT | +--------+ +--------+ .99 .1 .99 192.168.1.1.x/40 172.16.0.0.x/40 Organization B Mobile node will be migrated to a new network. Mobile node now it got a new IP address, 10.2.0.0.1 via DHCP from Organization A. NAT traversal table on Mobile Node: (it must remember it!) (empty) After Router-A got TCP packet, it creates a NAT traversal table: NAT Level | 1 | 2 | 3 | n |------------| | original source port = |1027 | | original source IP = |10.2.0.0.1 | | translated source port = |5050 | | translated source IP = |10.0.0.0.1 | | NOTE: NAT traversal table and NAT table can be the same data structure or different. ...and sends "ICMP NAT acknowledgement" with the highest NAT level, in this case = 1. via Unicast to the address of "original source IP", in this case Mobile Node (MN). Mobile Node, after receiving this NAT traversal table, will have it also. After Router-B got TCP packet, it creates a NAT traversal table: NAT Level | 1 | 2 | 3 | n |------------| | original source port = |5050 | | original source IP = |10.0.0.0.1 | | translated source port = |6050 | | translated source IP = |525.8.78.2.2| | ...and sends "ICMP NAT acknowledgement" with the highest NAT level, in this case =1. via Unicast to the address of "original source IP", in this case Mobile Node (MN). Router-A, after receiving this NAT traversal table, will add a new level to his table. Router-A NAT traversal table: NAT Level | 1 | 2 | 3 | n |------------|------------| | original source port = |1027 |5050 | | original source IP = |10.2.0.0.1 |10.0.0.0.1 | | translated source port = |5050 |6050 | | translated source IP = |10.0.0.0.1 |525.8.78.2.2| | ...and due to this update, Router-A sends "ICMP NAT acknowledgement" with the highest NAT level, in this case =1. via Unicast to the address of "original source IP", in this case Mobile Node (MN). packet looks like: type: ICMP NAT acknowledgement (Unicast) NAT Level | 2 | |------------| original source port = |5050 | original source IP = |10.0.0.0.1 | translated source port = |6050 | translated source IP = |525.8.78.2.2| -------------------------------------------------------------------- Mobile Node now also got the same table as Router-A. So at this stage Mobile Node already knows it's translated source IP & port numbers, which it will use to send "ICMP migrate" command. Mobile Node (MN) now is ready to leave its home subnet, and can send "ICMP migrate" command. Organization A 10.2.0.0.x/40 10.0.0.0.x/40 .99 .1 .99 +--------+ +--------+ |Router-A| |Router-B| | +NAT |----| +NAT | +--------+ +--------+.2 || | 525.8.78.2.x/40 || | .99 || +----------+ +----------+ || | Internet |-----| Server | || | Cloud | |8.8.8.8.8 | _||_ +----------+ +----------+ \||/ | .99 \/ | 775.2.23.5.x/40 +----------+ +--------+ +--------+.5 | Mobile | |Router-C| |Router-D| | Node |----| +NAT |----| +NAT | +----------+ +--------+ +--------+ .1 .99 .1 .99 192.168.1.1.x/40 172.16.0.0.x/40 Organization B In reality, this "NAT learning" will happen in a blink of an eye, under 100 milliseconds. And it will be ready to migrate. Mobile Node has physically migrated to Organization B, and got a new address from the local DHCP server, 192.168.1.1.1. (also NAT Router-C), and lost it's previous address, namely "10.2.0.0.1". At this stage, our Mobile Node must look at all packets sourcing from it's previous address and issue sends "ICMP migrate" to the Server (8.8.8.8.8), with whom it had previously opened sockets (TCP). protocol = TCP TCP sequence number = XYZ previous source port = 6050 previous source IP = 525.8.78.2.2 (the translated IP address and port it learned from "ICMP NAT acknowledgements"). migrated source port = 1027 migrated source IP = 192.168.1.1.1 (new IP address learned via DHCP) ... and at this very moment, client remaps it's socket: source port = 1027, source IP = 10.2.0.0.1, destination port = 80, destination IP = 8.8.8.8.8 to: source port = 1027, source IP = 192.168.1.1.1, destination port = 80, destination IP = 8.8.8.8.8 -------------------------------------------------------------------- Router-C, when receiving "ICMP migrate" command, must intercept it, change it's "migrated" fields. Now: Router-C MUST: 1. add a new entry to his own Network Address Translation (NAT) Table. 2. send "ICMP NAT ack" to "original source IP" from it's NAT table. 3. send the new "ICMP migrate" command to target destination (8.8.8.8.8) 1.+ 2. new NAT entry + NAT ack: NAT Level | 1 | |-------------| original source port = |5050 | original source IP = |192.168.1.1.1| translated source port = |6050 | translated source IP = |525.8.78.2.2 | protocol = TCP TCP sequence number = XYZ (must not touch it) previous source port = 6050 previous source IP = 525.8.78.2.2 migrated source port = 2038 (or whatever random free port it has; was 1027) migrated source IP = 172.16.0.0.1 (was 192.168.1.1.1) -------------------------------------------------------------------- Router-D, when receiving "ICMP migrate" command, must change "migrated" fields to this: protocol = TCP TCP sequence number = XYZ (must not touch it) previous source port = 6050 previous source IP = 525.8.78.2.2 migrated source port = 4128 (or whatever random free port it has; was 2038) migrated source IP = 775.2.23.5.5 (was 172.16.0.0.1) Now Router-D MUST: 1. add a new entry to his own Network Address Translation (NAT) Table. 2. send "ICMP NAT acknowledgement" to "original source IP" from it's NAT table. 3. send the new "ICMP migrate" command to target destination (8.8.8.8.8) -------------------------------------------------------------------- Server (8.8.8.8.8) At this stage, the remote Server (8.8.8.8.8) got it's "ICMP migrate" command. It must look if it has this socket opened, and compare the expected TCP sequence number. If there is a match it will rebind it's TCP socket from: source.port = 6050, source.IP = 525.8.78.2.2, destination.port = 80, destination.IP = 8.8.8.8.8 to: source.port = 4128, source.IP = 775.2.23.5.5, destination.port = 80, destination.IP = 8.8.8.8.8 Keeping the TCP session open ...and sending new data to this new subnet !!! NOTE: this can happen, even if the client disconnected and reconnected later. Server will send either: -"ICMP migration success!" (with the "ICMP migrate" message parameters) -or- -"ICMP migration failed." (with the "ICMP migrate" message parameters) NATs must intercept this command, and send a modified "ICMP migration success!/failed." acknowledgement. Author Contacts Alexey Eromenko Israel Skype: Fenix_NBK_ EMail: al4321@gmail.com Facebook: https://www.facebook.com/technologov INTERNET-DRAFT Alexey expiration date: 2016-07-18