Transcript network

Dealing with Mobility -- Mobile
IP
References
 J. Kurose and K. Ross, Computer Networking: A
Top-Down Approach Featuring the Internet, 2nd
edition
•C. Perkins and A. Myles, " Mobile IP. " technical report.
•Alex C. Snoeren and Hari Balakrishnan, " An End-to-End Approach
to Host Mobility." Proc. 6th ACM MOBICOM, August 2000.
Network protocol stack
 application: supporting network
applications

FTP, SMTP, STTP
 transport: host-host data transfer
 TCP, UDP
 network: routing of datagrams from
source to destination

IP, routing protocols
 link: data transfer between
neighboring network elements

PPP, Ethernet
 physical: bits “on the wire”
application
transport
network
link
physical
What is mobility?
 spectrum of mobility, from the network perspective:
no mobility
mobile user, using
same access point
high mobility
mobile user,
connecting/
disconnecting
from network
using DHCP.
mobile user, passing
through multiple
access point while
maintaining ongoing
connections (like cell
phone)
Accommodating Mobility
 A user might want to turn off an office laptop,
bring the laptop home, power up and work from
home. The user is primarily interested in e-mail,
web browsing.
 Not an issue. DHCP provides this functionality.
 DHCP only allows for a limited form of mobility
since it can’t run networked applications while
moving between points of attachment.
 In fact, DHCP requires the rebooting of the
mobile device.
Accommodating Mobility
 If you want to maintain an uninterrupted
TCP connection to a remote application
while zipping along the autobahn, it would
be convenient to maintain the same IP
address.

Remember that an Internet application needs
to know the IP address and port number of the
remote entity with which it is communicating
with.
 Mobility should be invisible from the
application’s viewpoint.
Mobility: Vocabulary
home network: permanent
“home” of mobile
(e.g., 128.119.40/24)
Permanent
address(PA): address
in home network, can
always be used to
reach mobile
e.g., 128.119.40.186
home agent(ha): entity that will
perform mobility functions on
behalf of mobile, when mobile
is remote
wide area
network
Correspondent
Mobility: more vocabulary
Permanent address: remains
constant (e.g., 128.119.40.186)
visited network: network
in which mobile currently
resides (e.g., 79.129.13/24)
Care-of-address(CoA):
address in visited
network.
(e.g., 79,129.13.2)
wide area
network
Correspondent node
(CN): wants to
communicate with
mobile
foreign agent(FA):
entity in visited
network that
performs mobility
functions on behalf
of mobile.
Consider friend frequently changing
addresses, how do you find her?
I wonder where
Alice moved to?
Mobility at Which Layer
 Where can you manage mobility?
 Application
 Transport
 Network
 Data-link
 Mobile-IP: an extension to current IP
architecture
To manage mobility at the IP layer
 To hide mobility from the upper layers

 Alternatively, we can also look at the
transport layer.
Mobility approaches
 Let routing handle it: routers advertise permanent
address of mobile-nodes-in-residence via usual
routing table exchange.
 Routing tables indicate where each mobile located
 No changes to end-systems
 Scalability is a problem
 The routers potentially would have to maintain
forwarding table entries for millions of mobile
nodes.
Mobility approaches
 Let end-systems handle it:
indirect routing: communication from
correspondent to mobile goes through home
agent, then forwarded to remote
 direct routing: correspondent gets foreign
address of mobile, sends directly to mobile
node

Mobility: registration
visited network
home network
2
1
wide area
network
foreign agent contacts home
agent home: “this mobile is
resident in my network”
End result:
 Foreign agent knows about mobile
 Home agent knows location of mobile
mobile contacts
foreign agent on
entering visited
network
Mobility via Indirect Routing
foreign agent
receives packets,
forwards to mobile
home agent intercepts
packets, forwards to
foreign agent
home
network
visited
network
3
wide area
network
correspondent
addresses packets
using home address
of mobile
1
2
4
mobile replies
directly to
correspondent
Indirect Routing: comments
 Mobile uses two addresses:


permanent address: used by correspondent (hence mobile
location is transparent to correspondent)
care-of-address: used by home agent to forward datagrams
to mobile
 Routing is based on tunneling
 Triangle routing: correspondent-home-network-mobile
inefficient when
correspondent, mobile
are in same network

Forwarding datagrams to remote mobile
foreign-agent-to-mobile packet
packet sent by home agent to foreign
agent: a packet within a packet
dest: 79.129.13.2
dest: 128.119.40.186
dest: 128.119.40.186
Permanent address:
128.119.40.186
dest: 128.119.40.186
packet sent by
correspondent
Care-of address:
79.129.13.2
Indirect Routing: moving between networks
 Suppose mobile user moves to another
network
Registers with new foreign agent
 New foreign agent registers with home agent
 Home agent update care-of-address for mobile
 Packets continue to be forwarded to mobile (but
with new care-of-address)

 Mobility, changing foreign networks
transparent: on going connections can be
maintained!
Mobility via Direct Routing
correspondent forwards
to foreign agent
foreign agent
receives packets,
forwards to mobile
home
network
4
wide area
network
2
correspondent
requests, receives
foreign address of
mobile
visited
network
1
3
4
mobile replies
directly to
correspondent
Mobility via Direct Routing: comments
 Overcome triangle routing problem
 non-transparent to correspondent:
correspondent must get care-of-address
from home agent
What happens if mobile changes networks?
 What about security? This approach is not
considered secure enough by the IETF.

Mobile IP
 RFC 3220
 Has many features we’ve seen:
 home agents, foreign agents, foreign-agent
registration, care-of-addresses, encapsulation
(packet-within-a-packet)
 Three components to standard:
 agent discovery
 registration with home agent
 indirect routing of datagrams
Mobile IP: Agent Discovery
 Agent advertisement: foreign/home agents
advertise service by broadcasting ICMP messages
0
type = 9
24
checksum
=9
code = 0
=9
H,F bits: home
and/or foreign agent
R bit: registration
required
16
8
standard
ICMP fields
router address
type = 16
length
registration lifetime
sequence #
RBHFMGV
bits
reserved
0 or more care-ofaddresses
mobility agent
advertisement
extension
Functions of Agent
Advertisement
 Allow for the detection of mobility agents
 Let the mobile node know whether the agent is a
host or foreign agent
 List one or more available care-of addresses
 Inform the MN about special features provided by
FA

Example: Alternative encapsulation techniques (e.g., IP
packet within IP packet, minimal encapsulation)
 MN compares the network portion of the agent’s
IP address with the network portion of its home
address. If the network portion do not match,
then the MN is on a foreign network.
Mobile IP: Registration example
home agent
HA: 128.119.40.7
foreign agent
COA: 79.129.13.2
visited network: 79.129.13/24
ICMP agent adv.
COA: 79.129.13.2
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification: 714
encapsulation format
….
registration req.
COA: 79.129.13.2
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 9999
identification:714
….
registration reply
time
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
encapsulation format
….
registration reply
HA: 128.119.40.7
MA: 128.119.40.186
Lifetime: 4999
Identification: 714
….
Mobile agent
MA: 128.119.40.186
Mobile IP: Registration
 The registration process involves 4 steps:
The MN requests the forwarding service by
sending a registration request to the foreign
agent that the mobile node wants to use.
 The FA relays this request to the mobile node’s
home agent.
 The HA either accepts or denies the request
and sends a registration reply to the FA.
 The FA relays this reply to the MN.

Mobile IP: Registration
 Registration fields include:
 Lifetime: The number of seconds before the registration
is considered expired. A value of 0 is a request for
deregistration.
 Home address: The home IP address of the mobile node.
 Home agent: The IP address of the mobile node’s home
agent.
 Care of Address: The home agent should forward IP
datagrams that it receives with MN’s home address to
this destination address.
 Identification: Generated by MN; used for matching
registration requests to registration replies (for
security). Should be unique for each registration request.
Mobile IP: Registration
 The registration reply message includes
the following fields:
Home address: The home IP address of the
mobile node.
 Home agent: The IP address of the MN’s home
agent.
 Identification: Used for matching registration
requests to registration replies.

Mobile IP: Securing
Registration
 Mobile IP is designed to resist two types
of attacks:
A node may pretend to be a FA and send a
registration request to a home agent so as to
divert traffic intended for a MN to itself.
 A node may replay old registration messages,
effectively cutting the MN from the network.

Mobile IP: Securing
Registration
 Each registration request and reply contains an
authentication extension with the following fields:




Type: Used to designate the type of authentication
extension (mobile-home, mobile-foreign, foreign-home).
Length: 4 + the number of bytes in the authenticator
Security parameter index (SPI): An index that identifies
a security context between a pair of nodes. The security
context is configured so that the two nodes share a
secret key and parameters (e.g. algorithm for computing
the Authenticator field) relevant to this association.
Authenticator: A variable length string calculated by
computing a MD5 message over the shared secret key,
the fixed length portion, and all extensions without the
Authenticator field
Resisting Denial-of-Service
Attack
 A Bad Guy generates a bogus Registration
Request specifying his own IP address as
the COA address for a mobile node. All
packets sent by correspondent nodes would
be tunneled by the node’s HA to the Bad
Guy.
 The HA checks the authenticity of the
received message by comparing the value
of the Authenticator value it computes
with the Authenticator value received.
Resisting Replay Attacks
 A Bad Guy could obtain a copy of a valid
Registration Request message, store and then
“replay” at a later time, thereby registering a
bogus COA address for the mobile node.
 To prevent that the Identification field is
generated in such a way as to allow the home agent
to determine what the next value should be.


Timestamps
Pseudorandom numbers (at least 32 bits)
 If the Bad Guy uses the intercepted message, the
Home Agent will recognize it as being out of date.
Security Issues
 Can’t deal with a Bad Guy sending a tremendous





number of packets to a host that brings the host’s
CPU to its knees.
The current standard uses a similar approach for
FA/HA authentication but this is not required.
Traffic between HA and MN can be eavesdropped
on.
Key distribution
No data privacy
Firewalls
Home Network
 Where Can We Put the Home Agent?
At the router?
 As a separate server?

 At the router
 What if there are multiple routers for the
home network?
 As a separate server
 How can it pick up a packet
Foreign Network
 Where is FA? (Router or Separated
Server?)
 How Can FA deliver MN the packet
[CNMN]

Normally, [CNMN] would go straight to a
router (because MN is foreign)
 Is There Adequate Support at A Foreign
Network
What if there is no FA at the network you
visit?
 Co-located FA

Problems
 Routing inefficiencies
 Firewalls
 Firewalls filter those packets whose source
address is not part of the network; MNs fall
into this category.
 Users perceptions of reliability
 Users expect failures; why bother?
Alternative to Mobile IP
Why an alternative?
 Mobile IP was designed under the principle that
fixed Internet hosts and applications were to
remain unmodified and only the underlying IP
substrate should change.
 An alternative is to require no changes to the IP
substrate. Instead, we should modify transport
protocols and applications and the end hosts.
 Not a hindrance; rather should make it easy to
deploy
 The alternative discussed was developed by
Snoerent and Balakrishnan (MIT)
Characteristics
 Similar to Mobile IP in that the issues of
obtaining an IP address in a foreign domain
from locating and seamlessly
communicating with mobile hosts are
separated.
 The use of DHCP can be assumed.
 No tunneling is required
 DNS is used to provide a level of
indirection between a host’s current
location and an invariant end-point
identifier.
DNS Based Solution
 In Mobile IP, a host’s home address is the
invariant.
 The DNS name is the invariant since a DNS
name identifies a host and does not assume
anything about the network attachment
point to which it may currently be
attached.
 When the mobile node changes its
attachment point, it must detect this and
change the hostname to address mapping in
the DNS.
DNS based solution
 Detecting changes in an attachment point
is similar to Mobile IP and is done through
a daemon process
 Changing the hostname to address mapping
(Arecord) is done through the secure DNS
update protocol
DNS based solution
 DNS provides a mechanism by which name
resolvers can cache name mappings for
some period of time (specified in TTL field
of the Arecord). This can be avoided by
setting the TTL field of zero.
 Not considered a problem by authors since
name lookups for an uncached Arecord do
not have to start from a root name server.
 What to do if binding changes after
connection?
TCP Connection Migration
 TCP connection identified by
 <source address, source port, destination address, dest
port>
 Need an ID that is address independent
• During initial connection establishment a token is
determined.
• Now connection identified by
– <source address, source port, token>

Moving end can send migrate SYN message to other end
• With connection ID and new address

This message not acked
• Next message from stationary end to new address implicitly
acks migrate message
Migrate Architecture
Location Query
(DNS Lookup)
Location Update
(Dynamic DNS Update)
DNS Server
Connection Initiation
Connection Migration
Correspondent
Host
From snoeren’00
Mobile Host
foo.bar.edu
yyy.yyy.yyy.yyy
xxx.xxx.xxx.xxx
TCP
Connection
Migration
1. Initial SYN
2. SYN/ACK
3. ACK (with data)
4. Normal data transfer
5. Migrate SYN
6. Migrate SYN/ACK
(Note typo in proceedings)
From snoeren’00
7. ACK (with data)
Race Conditions
 Occurs when a mobile host moves between
when a corresponding host receives the
result of its its DNS query and when it
initiates a TCP connection
 The failure of the corresponding host to
open a connection to the mobile host will
result in another DNS lookup.
 Both end points migrate at same time

Solution assumes one fixed host
Security Issues
 Third party can change DNS mapping
 Secure DNS needed
 Third party can move connection
 Token prevents this
 Replay attack
 Sequence number of request prevents this
 Denial of service
 SYN Flooding possible since token is known on all
hosts on the route of the migrate message. This
can be handled using a timeout period for a token.
Deployment Issues
 Problem: Both peers cannot move
simultaneously
 Problem: System requires changes to the
transport protocol