Windows Oriented Mobile IP solution

1. Windows Oriented Mobile IP solution For transparent routing of IP datagram's to Windows oriented mobile nodes.

2. Roles & Responsibilities • Technical adviser: Danny Zadok • Academic adviser: Dr. Yuval Elovici • Project team: Ira Zaitsev Amir Patoka Arie Kozak

3. Background

4. Current situation Public Safety organizations are one of Motorola biggest consumers which have mobile platform (cars with Pocket PCs) that travel to the scene of events (crime scenes, fires …). In case of a public disaster event the usual provider infrastructure usually collapse due to overwhelming demand or damage physical infrastructure, in those cases there is a need to switch to the backup Public Safety organization infrastructure (which is usually slower) without noticing the change.

5. Current situation – (cont.) Our goal is to facilitate in mobile node (Pocket PC, Laptop) to roam in the world, attaching themselves to different points to the internet while maintaining the appearance of always being in the home network.

6. Problem domain IP (Internet Protocol ) requires the location of any host connected to the Internet to be uniquely identified by an assigned IP address. This raises one of the most important issues in mobility, because when a host moves to another physical location, it has to change its IP address. However, the higher level protocols require IP address of a host to be fixed for identifying connections.

7. Problem domain – (cont.) “Connect to 171.68.69.2” Where is 171.68.69.2??? Gateway A 171.68.0.0 Server Internet Gateway C 140.31.0.0 171.68.69.2 Client ? 140.31.70.1 • Gateway A replies to Host B with an ICMP unreachable

8. Proposed solution The Mobile Internet Protocol (Mobile IP) is an extension to the Internet Protocol proposed by the Internet Engineering Task Force (IETF) that addresses this issue. It is a standard communications protocol that is designed to allow mobile device users to move from one network to another while maintaining a permanent IP address.

9. MN System Architecture Mobile IP introduces the following new functional entities: Mobile Node - A host or router that changes its point of attachment from one network or sub network to another. Home Agent - A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Database IP: H IP: B MN IP: A Internet Foreign Network Home Network Client

10. MN System Architecture – (cont.) Src:B Dest:H Src:A Dest:R Home IP: A IP: H Src:A Dest:R Internet Src:A Dest:R IP: B Foreign Network Home Network Remote App IP: R Mobile Node ->Remote Application

11. MN System Architecture – (cont.) Src:H Dest: B Src:R Dest:A Src:H Dest: B Src:R Dest:A Home IP: A IP: H Src:R Dest:A Src:R Dest:A Internet Src:R Dest:A IP: B Foreign Network Home Network Remote App IP: R Remote Application -> Mobile Node

12. Technologies • NDIS (Network Driver Interface Specification) . • Windows CE API for Mobile Node implementation. • Win32 API for HA implementation. • DHCP protocol for IP allocation. • ICMP protocol for HA advertisement. • DB for HA using SQLServer.

13. Functional Requirements

14. Broadcast or multicast with TTL = 1 Mobile Node Advertisement message Main Functional Requirements Home Agent Advertisement: In order to allow Mobile Node to determine whether it is in Home network or Foreign network. Our HA will advertise himself by MN request.

15. Main Functional Requirements – (cont.) Registration: Every Mobile Node that resides in the foreign network needs to register with HA.

16. Main Functional Requirements – (cont.) Deregistration: when MN returns home, it need to deregister himself.

17. Main Functional Requirements – (cont.) Datagram tunneling: when MN is in the foreign networked, in order to hide his real source IP, all the datagrams from/to him to/from Application should be tunneled .

18. Main Functional Requirements – (cont.) Home-IP allocation: HA will have a pool of available Home IP's. Each time HA receives a registration request with Home IP 0.0.0.0 it assigns one of the available IPs in the pool to a Mobile Node that sent the request.

19. Non Functional Requirements

20. Non functional requirements - Performance constraints • Home Agent recovery (restart) less than 1 minute in case of failure. • System reliability – works 99.9% of the time. • Registration/deregistration time: 1sec + network latency. • Packet transmission time: 10msec + network latency. • Packet loss is not exceeded more than by 2% the original. • Maximum number of supported Mobile Nodes per Home Agent is 1000. • Simplest installation: any configuration values with default values won’t participate in installation process and will be set to default. • Maximum number of network interfaces per Mobile Node supported by system is 4.

21. Non functional requirements - SE Project Constraints • The Mobile node might not run on the university network due to firewall limitations. • Home Agent will not run on the university network due to NAPT and Firewall limitations during final presentation, but on the remote network.

22. Major Use-Cases

23. Major Use-Cases – (cont.) Installation of the system on Mobile Node: Primary Actor: Administrator. Precondition: Windows Mobile/XP, support for NDIS. Post condition: the host now supports Mobile IP. Main scenario: • Running the installation program for the driver. • Installing the service. • Configuring the service (Use Case 2). • Registering the Mobile Node to the Home Agent.

24. Major Use-Cases – (cont.) Configuring the service: Primary Actor: Administrator. Precondition: configuration/installation program is running. Post condition: the service is configured. Main scenario: • Configuration of networks’ priorities. • Configuration of encapsulation method (optional). • Configuration of Home Address (default automatic). • Configuration of Home Agent IP, Home Network IP address and ports. • Security configuration (keys, SPI, algorithms, etc). • Networking configuration: delays, rates, etc. for each network. Note: sometimes the configuration of service will require reconfiguration of Home Agent (for the associated information).

25. Major Use-Cases – (cont.) Configuring Home Agent: Primary Actor: Administrator. Precondition: Home Agent is installed/installing. Postcondition: Home Agent is configured. Main scenario: • Configuring registration table of supported Mobile Nodes (Home Address, Security data, networking, etc.). • Defining range of IP’s for supplying Home IP to Mobile Nodes • Provide possibility to allocate/free each Home IP. • Defining logging level. • Configuration of different delays, rates, networking parameters. Note: sometimes the configuration of Home Agent will require reconfiguration of Mobile Node (for the associated information).

26. Major Use-Cases – (cont.) Displaying current state of Home Agent: Primary Actor: Administrator. Precondition: Home Agent is installed and running. Post condition: User receives the information of current network state. Main scenario: • User prompts for type of information he wants: which mobile nodes currently connected (registered), with what care-of-address, registration life-time, different statistics and logging. • Requested information is displayed.

27. Major Use-Cases – (cont.) Forward tunneling: Primary Actor: Remote Application. Secondary Actor: User Application. Precondition: System is installed and configured and there is a network link for both Home Agent and Mobile Node. Postcondition: The packet arrives at the destination (User Application). Main scenario: • Remote application sends a packet. • The packet is intercepted by the Home Agent encapsulated and tunneled to the Mobile Node. • Finally, the packet is decapsulated by the Mobile Node and passed to the User Application.

28. Major Use-Cases – (cont.) Reverse tunneling: Primary Actor: User Application. Secondary Actor: Remote Application. Precondition: System is installed and configured there is a network link for both Home Agent and Mobile Node. Post condition: The packet arrives at the destination (Remote Application) with source IP equal to Home Address. Main scenario: • User application sends a packet. • The packet is intercepted by the Mobile Node encapsulated and tunneled to the Home Agent. • Finally, the packet is decapsulated by Home Agent and sent to destination.

29. Major Use-Cases – (cont.) Attachment Notification: Primary Actor: Internet Service Provider. Precondition: System is installed. Post condition: Mobile Node has a virtual network with his home network. Main scenario: • Internet Service Provider notifies on a new address or a new gateway. • Mobile Node registers himself with the Home Agent.

30. Risks • In case we don't find an open UDP port in the university network we will need two cellular provider modems. • Availability of a Pocket PC with four network interfaces questionable. Capacity test will be done in worst case on laptop. • Testing the system inner network communication with inputs outside the specification (Robustness testing) is difficult due to non existing tools to feed the system with improper inputs, which will require changing working system components to faulty ones. Robustness testing could be done with recording inputs through sniffer programs and sending a modified recorded datagram. • Failing to live up to nonfunctional performance requirement on common platforms will demand adding constraints on components running platform to high end ones.

31. THE END!