Mobile IP Firewall Support: Securing Internet Mobility

1. IETF Working Group CSCI 344 Spring 1998 Presentation <Chinni K. Chimmiri> <MOBILEIP> IETF WG Presentation

2. General Description • This group develops or adopts architectures and protocols to support mobility inside the Internet. • General Discussion • mobile-ip@smallworks.com • To Subscribe • majordomo@smallworks.com • Archive • ftp://ftp.smallworks.com/mobile-ip.archive IETF WG Presentation

3. Near-Term goals • Establish protocols for supporting transparent host “roaming” among different subnetworks and different media. • Be consistent with new and/or revised protocols at (inter)network layer. • Propose modifications to higher-layer protocols if needed. IETF WG Presentation

4. Long-Term Goals • Address different types of mobility • Mobile subnets • a traveling circus • Mobile clusters of subnets • a traveling circus with a collection of subnets IETF WG Presentation

5. Current Draft Topics • Route Optimization • Mobility support for IP • Tunneling • Firewall/security support for Mobile IP • Roaming IETF WG Presentation

6. Internet Draft • Fire Wall Support for Mobile IP • Allowing a mobile node on a public sector of Internet to negotiate access past a SKIP firewall and construct a secure channel into it’s home private network. • A mobile node can be established via local ISP or a LAN network. • Mobility without a firewall • obtain an address • Will use a co-located address instead of using a separate foreign agent’s care-of address. IETF WG Presentation

7. Restrictions imposed by a Firewall • Firewalls imposes restriction on packets entering or leaving the private network. • The packet must conform to a filtering specification or some form of authentication to go through the firewall. • All packets coming into the private network form the general Internet must be targeted to firewall if you seek entry. • Two types of firewall available • SOCKS • the mobile node establishes a TCP session with the FW. • Uses it’s library to encapsulates the traffic meant for the FW. • The steps required to accomplish this • TCP connection established to port. • Version identified/method selection negotiation. • Method-dependent negotiation. IETF WG Presentation

8. SOCKS - Continued • Establish authenticated connections • Can’t encrypt the traffic • Disadvantage is that each step makes a number of round trips. • SKIP • A session-less IP security mechanism that encrypts and authenticates the traffics from the mobile node to the firewall. • Steps • FW can relay messages for mobile node as soon as it receives the first one. • It has an authentication information (AH) in each packet. • (ESP) Encryption that provides both authentication & encryption. In which case AH is not needed. IETF WG Presentation

9. SKIP - Continued • Support Nomadic Applications • Uses IP address for security • Skip allows for use of a key id to receive an appropriate certificate • Key Id - Composed off • Name Space Identifier (NSID) • Masker Key Identifier (MKID) • Another approach for nomadic apps • Use a control list entry • Filter by key id instead of IP. • Incoming packets must have an AH so that the firewall establishes a “current address” or “dynamic binding” for the nomadic host. Agents and Mobile Node Config. IETF WG Presentation

10. Agents and Mobile Node Config • Mobile IP specifies two ways in which a mobile node can register a mobility binding with a home agent (HA). • A. An address advertised for this purpose by the foreign agent (FA). • B. An address belonging to one of the mobile node’s interfaces. • FW needs to which one is used. • The authors believes B is best solution. • FW need to get the Diffie-Hellman public component of the node that creates the outermost SKIP header in an incoming packet. So it needs to which node created the packet. Can be guaranteed using B. • If you use A the foreign agent need to examine the packet and modify it for agent services. • A also requires that you modify code at the HA, the FW, and the FA. IETF WG Presentation

11. Secure Channel Configurations • Mobile node participates in two types of traffic: • Mobile IP registration protocol and data. • Evaluation of secure channel configs using initial registration request by mobile nod. • I: Encryption only Outside of Private Network. • The traffic is only encrypted between mobile node out on the general internet and firewall. Only encrypt on private network if necessary. • II: End-to-End Encryption • extends the encrypted tunnel through the FW. • This makes the FW into a relay or a gateway function. • Authentication not carried out by FW but by the HA. IETF WG Presentation

12. III: End-to-End Encryption, Intermediate Auhtentication • FW is the security association between the HA and the mobile node (MN). After verifying AH, the FW forwards the (ESP) to the HA. • Skip is used to provide the intermediate authentication with end-to-end security. This means that both the HA and MN disclose their pairwise long-term Diffie-Hellman shared secret. • IV: Encryption Inside and Outside • Traffic is encrypted on the public as well as on the private network. • Public Network encryption between MN and FW. • Private Network encryption between HA and FW. IETF WG Presentation

13. Mobile IP Registration Procedure with a SKIP Firewall • MN encapsulates Registration Request in a SKIP packet destined for FW. • MN distinguishes between “inside” and “outside” addresses. Hard to tell. • Human input might make it easy for MN to distinguish between them. • HA must also distinguish between “inside” and “outside” addresses. • Can’t use human input for help. • MN can inform the HA of the diiffernce by defining a Traversal Extension to the Registration Requests and Replies. * • Also useful when traversing multiple firewalls. IETF WG Presentation

14. The MN after arriving at the foreign net and receiving a care-of address, it must first initiate a registration procedure. • An authenticated exchange by the MN informs the HA of it’s whereabouts. • Then receives an acknowledgement. • This allows the SKIP FW to dynamically configure it’s packet filter. • Registration Request through the FW IETF WG Presentation

15. Registration Request through the FW • MN is at a foreign net. • Realizing that it’s not at home requests a local address • Composes a registration request for HA. • Decides if needs to be processed by SKIP or not. • A. The mobile node is using a care-of address that doesn’t belong to the private network, and • B. either • B1. The source address of the packet is the mobile node’s home address. • B2. The source address of the packet is the care-of address and the destination address belongs to the private network. IETF WG Presentation

16. On the Outside (Public Network) • SKIP module uses the FW destination address and the FW’s certificate in order to address and encrypt the packet. • Encryption is done using ESP protocol and possibly the AH protocol. • The SKIP header’s source NSID is set equal to 1 to indicate that MKID is the mobile node’s home address. • On the Inside (Private Network) • The SKIP FW’s dynaimc packet filtering uses this info to establish a dynamic binding between the care-of-address and the MN’s permanent home address. • The SKIP header’s source NSID is set to 0 to prompt the FW to process the SKIP header and recover the internal packet and deliver it to another outbound interface. IETF WG Presentation

17. Registration Reply through the FW • HA processes the registration request. • Composes a Registration Reply • Examines the care-of address reported by the mobile node to determine whether or not it corresponds to an outside address. • If so • HA need to send all traffic through the firewall. • Done by encapsulating the original Registration Reply in a SKIP packet destined to the FW. IETF WG Presentation

18. On the Inside (Private Network) • Destination is mobile node’s care-of address • NSID is set to 0 with no MKID for SKIP. • On the Outside (Public Network) • The SKIP FW recovers the original Registration Reply packet and looks at the destination address: The MN’s care-of address. • Forwards the Registration Reply after it is encrypted with the MN’s public component. • The SKIP FW’s dynamic packet filtering used the initial registration request to establish a dynamic mapping between the care-of address and the MN’s MKID. • This requires that the reply go back through the same FW. • If MN’s permanent address is obtained from the Registration Reply then this make the FW stateless allowing you to use any FW. IETF WG Presentation

19. Traversal Extension • An explicit notification that there are one or more traversal points between the MN and it’s HA. • A MN should include one Traversal Extension per traversal point in it’s Registration requests. • If present • Their order MUST match the order in which packets encounter them as they flow from the MN to the HA. • Note-> other FWs may be present, but the list should contain only the FWs where negotiation is necessary. • HA should include one Traversal Extension per traversal point in it’s Registration Replies. Order in which they are encountered must match. IETF WG Presentation

20. MN to HA Traversal Address • The IP address of the intermediate system or FW encountered by datagrams sent by the MN to the HA. Usually the external address of a FW. • This field must be initialized in Registration Requests. • In Registration Replies this field is typically all 0’s other the mobile node should interpret it as a hint. • HA to MN Traversal Address • The IP address of an intermediate system or FW encountered by datagrams sent by the HA to the MA. Usually the internal address of a FW. IETF WG Presentation

21. Data Transfer • almost the same as Registration Requests • Data Packet From the MN to the a Correspondent Node. • The MN creates a packet destined for the Correspondent Node (CN) with the private network. • Make sure it matches condition A and B1 of Registration Requests. • MN requests the proper services of SKIP. • The MN send encrypted message to the FW. • SKIP FW intercepts the packet. • Decrypts and checks the destination address. IETF WG Presentation

22. The packet is routed into the Private Net. • The MN may need to construct a bi-directional tunnel with its HA if the packet needs to go through other FW in the Private Net. • The MN need to use a bi-directional tunnel in the Public Net. • Data packet from a CN to the MN • The HA intercepts the packet from the CN to the MN. • Encapsulates it such that the Mobile IP encapsulating IP header’s source and destination addresses are the home agent and care-of addresses, respectively. • This will work for delivery within the Private Net. IETF WG Presentation

23. Delivery is made thought the FW for the Public Net. • Encapsulate the datagram in a SKIP packet to the FW. • On the Outside (Public) Network • The SKIP FW intercepts the packet and recover the Mobile IP encapsulated datagram. • The Dynamic Packet Filter starts the encryption of this packt. • The Dynamic Packet Filter is configured by the original Registration Request. • At the MN SKIP process the packet sent by the FW. IETF WG Presentation

24. Request For Comments • Applicability Statement for IP Mobility Support. • Protocol Overview • Provides an efficient mechanism to allows nodes to change their location to the Internet without changing their IP address. • Tunneling • Packet send for Mobile IP are routed to it’s home network. • The home network the mobile node’s (MN) home agent (HA) intercepts the packet and tunnels it to the MN’s most recent care-of address. IETF WG Presentation

25. Mobile IP protocol define the following • An authenticated registration procedure by which a MN informs its HA of it’s care-of address. • An extension to ICMP Router Discovery which allows mobile nodes to discover prospective home agents and foreign agents • The rules for routing packets to and from mobile nodes, including specification of one mandatory tunneling mechanism and server optional tunneling mechanisms. • Applicability • Mobile IP is intended to solve node mobility across changes in IP subnet. • Security • Mobile IP mandates the use of strong cryptographic authentication for all registration messages exchanged between MN and it’s HA. • Due to unavailability of an Internet Key Management Protocol agent discovery messages are not required to be authenticated. IETF WG Presentation

26. All Mobile IP implementations are required to support, at a minimum, keyed MD5 authentication with manual key distribution. • Mobile IP defines security mechanisms only for the registration protocols. • Implementations • Companies that have Mobile IP implemented • CMU • FTP Software • IBM • Motorola • Nokia • SUN • Telxon • Implementation Experience • list of thing that were tested and worked. IETF WG Presentation

27. 42nd IETF Meeting • March 29 - April 3rd. 1998. • Mobile IP group did not meet at this meeting. IETF WG Presentation