ietf working group

27
IETF WG Presentati on 1 <Chinni K. Chimmiri> <MOBILEIP>

Upload: ryann

Post on 14-Jan-2016

33 views

Category:

Documents


0 download

DESCRIPTION

IETF Working Group. CSCI 344 Spring 1998. Presentation. . General Description. This group develops or adopts architectures and protocols to support mobility inside the Internet. General Discussion [email protected] To Subscribe - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: IETF Working Group

IETF WG Presentation 1

<Chinni K. Chimmiri>

<MOBILEIP>

Page 2: IETF Working Group

IETF WG Presentation 2

General Description

• This group develops or adopts architectures and protocols to support mobility inside the Internet.

– General Discussion• [email protected]

– To Subscribe• [email protected]

– Archive• ftp://ftp.smallworks.com/mobile-

ip.archive

Page 3: IETF Working Group

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.

Page 4: IETF Working Group

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

Page 5: IETF Working Group

IETF WG Presentation 5

Current Draft Topics

– Route Optimization– Mobility support for IP– Tunneling– Firewall/security support for

Mobile IP– Roaming

Page 6: IETF Working Group

IETF WG Presentation 6

• 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.

Internet Draft

Page 7: IETF Working Group

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.

Page 8: IETF Working Group

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.

Page 9: IETF Working Group

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.

Page 10: IETF Working Group

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.

Page 11: IETF Working Group

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.

Page 12: IETF Working Group

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.

Page 13: IETF Working Group

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.

Page 14: IETF Working Group

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

Page 15: IETF Working Group

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.

Page 16: IETF Working Group

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.

Page 17: IETF Working Group

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.

Page 18: IETF Working Group

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.

Page 19: IETF Working Group

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.

Page 20: IETF Working Group

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.

Page 21: IETF Working Group

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.

Page 22: IETF Working Group

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.

Page 23: IETF Working Group

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.

Page 24: IETF Working Group

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.

Page 25: IETF Working Group

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.

Page 26: IETF Working Group

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.

Page 27: IETF Working Group

IETF WG Presentation 27

42nd IETF Meeting

• March 29 - April 3rd. 1998.

• Mobile IP group did not meet at this meeting.