Transcript SKIP

<Chinni K. Chimmiri>
<MOBILEIP>
IETF WG Presentation
1
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/mobileip.archive
IETF WG Presentation
2
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 higherlayer protocols if needed.
IETF WG Presentation
3
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
4
Current Draft Topics
–
–
–
–
Route Optimization
Mobility support for IP
Tunneling
Firewall/security support for
Mobile IP
– Roaming
IETF WG Presentation
5
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
6
– 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
7
– 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
8
– 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
9
– 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
10
– 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
11
– 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 endto-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
12
– 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
13
– 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
14
– 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
15
• 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
16
– 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
17
• 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
18
– 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
19
• 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
20
– 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
21
• The packet is routed into the Private
Net.
• The MN may need to construct a bidirectional 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
22
• 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
23
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
24
• 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
25
– 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
26
42nd IETF Meeting
• March 29 - April 3rd. 1998.
• Mobile IP group did not meet at
this meeting.
IETF WG Presentation
27