Transcript Network Mobility

Network Mobility
Yanos Saravanos
Avanthi Koneru
Agenda






Problem Definition
Background
PANA
MOBIKE
Conclusion
References
Yanos
Avanthi
Why Mobility Matters

Cell phones / PDAs





692 million cell phones shipped in 2004
1.7 billion subscribers by end of 2005
Streaming multimedia
Live TV
4G cellular networks being developed


Uses ALL-IP network architecture
Highly scalable

Critical in emergency conditions
4G Network
http://www.eeng.dcu.ie/~arul/4G.html
Problem Definition


No current security protocols is built around
mobility
New protocols must:



Keep session during handoffs
Allow integration between mobile networks
(802.11, cellular, etc)
Not dramatically increase packet size
Benchmarks


Computational intensity
Effect on throughput


Amount of overhead added to the packets
QoS


Packet Loss, Delay
Jitter
PANA
Protocol for carrying Authentication for
Network Access
PANA Goals

Network access authentication protocol


Client-server
Enables EAP to be transported over IP layer


Authentication is a function of the network layer
Link-layer independence
Terminology

PANA Client (PaC)



Authentication, Authorization and Accounting
Client (AAA)
PANA Authentication Agent (PAA)



Laptop, PDA, cell phone
Server for authenticating and authorizing PaCs
Checks AAA to verify PaC’s rights
Enforcement Point (EP)

Access controller to allow/deny client access
PANA Protocol
PANA Phases
PANA Discovery Process

Discovery and handshake phase


PAC discovers PAA in network
Handshake between PaC and PAA to begin PANA session
PANA Authentication Process

Authentication and
authorization phase




PaC and PAA establish PANA
connection
PaC/PAA derive AAA key for
each EP the PAA manages
PAA sends shared key to the
EPs
EPs configure filters so PaC
can connect
PANA Process

Access phase



Traffic between PaC and EP is encrypted using
shared key
Ping occasionally to test PANA session
Re-authentication phase

Before session expires, re-authenticate
PANA Termination Process

Termination phase


PAA notifies EPs that PaC not available
EPs remove filter
PANA Issues

PaC must be able to communicate with
network before being authenticated




AP must forward some traffic (ARP, DHCP, and
PANA) from unauthenticated clients
Use uncontrolled ports in 802.1X before
authentication
Use controlled ports in 802.1X after authentication
PANA does not address network selection by
itself
PANA Issues


PAAs must communicate with each other
Client roaming between PAAs


PANA not currently built to transfer sessions
Separation of EP and PAA


Requires communication between both
Not currently in PANA specification
Proposed Network Architecture
Proposed Network
Architecture


Wireless Clients
Guest Network (GN)




For unauthenticated clients
Uses unencrypted traffic
Isolated from all other networks
User Networks (UN)



For authenticated clients
Uses encrypted traffic
Multiple user networks for separating services
Proposed Network
Architecture

Management Network (MN)




Manages access point for managing entities
Isolated from all other networks
AAA server usually located in MN
Access Point


Connects clients to either GN or UN
Logical traffic separation between networks


Binds client’s MAC address to GN or UN
Cryptographic protection of UN traffic
Proposed Network
Architecture

PAA



Resides in GN to authenticate new guests
Connected to UNs to switch clients from GN to
UN
Connected to MN to securely communicate keys
and network identifiers for authenticated guests to
the AAA
Access Point Implementation

Wireless Module



Wired Module



eth0.3 connected to MN
eth0.0 connected to GN
Bridge


Sends/receives 802.11 frames
Encrypts/decrypts frames
using control module
Forwards frames between
wireless and wired interfaces
Authentication Module

Processes messages from
wlan0.0 and eth0.3
Access Point Database

Database used to maintain association state for
each wireless client




MAC address
Network ID
Key ID
Encryption key
AP Database Operation

Receiving




If MAC address is not entered, discard frame
If MAC exists but key does not, forward frame to GN
If MAC and key exist, forward frame to UN
Sending



If MAC address is not entered, discard frame
If MAC and key exist, encrypt frame with key and key ID
and send on wireless interface (from is from UN)
If MAC exists but key does not, send frame on wireless
interface without encryption (frame is from GN)
PANA Authentication Sequence
PANA Performance


Total delay: 12.01 sec
PANA protocol delay


Re-association delay


Beginning of PANA to beginning of disassociation
Beginning of disassociation to end of 4-way
handshake
Post-PANA DHCP delay

End of 4-way handshake to end of DHCP
PANA Performance



Last two delays can be reduced
If wireless client initiates association immediately
after disassociation, 2nd delay is reduced to 0.48 sec
3rd delay is reduced by initiating DHCP procedure
immediately after re-association


Normal DHCP procedure takes 0.34 sec
Total delay reducible to ~2.7 sec
Additional Work for PANA Network


Test network scalability and roaming
Wireless client implementation must be tuned
to improve system performance


Even more critical when client is roaming
Use of system for wired client authentication

Useful for home access routers
Conclusion




New architecture that uses PANA for
authentication of wireless clients
Provides network separation between AAA
clients and AP
New AP architecture
Delays can be greatly reduced
mobike
IKEv2 Mobility and Multihoming
MOBIKE
•
IKEv2
•
•
Problem:
•
•
The purpose of IKEv2 is to mutually authenticate two hosts,
establish one or more IPsec Security Associations (SAs) between
them, and subsequently manage these SAs.
There are scenarios where one or both of the IP addresses of
this pair may change during an IPsec session. In principle, the
IKE SA and all corresponding IPsec SAs could be re-established
after the IP address has changed.
Solution
•
Mobike provides an automatic mechanism which updates the IP
addresses associated with the IKE SA and the IPsec SAs.
Mobility Scenario
Multihoming Scenario
Focus of current design

Mobike focuses on the tunnel mode, everything going
inside the tunnel has to stay unaffected by the changes
in the tunnel header IP address i.e., the applications
running through the MOBIKE IPsec tunnel cannot
even detect the movement, their IP address etc stay
constant.

The MOBIKE focuses on what two peers need to
agree in IKEv2 level (like new message formats and
some aspects of their processing) for interoperability.
Operations of mobike






Inform the other peer about the peer address set
Inform the other peer about the preferred address
Test connectivity along a path and thereby to detect
an outage situation
Change the preferred address
Change the peer address set
Ability to deal with Network Address Translation
devices
Proposed mobike framework
Design Considerations

Choosing addresses





Inputs and triggers
Connectivity
Discovering connectivity
Decision making
NAT traversal





Constraints
Fundamental restrictions
Moving to behind NAT and back
Responder behind NAT
NAT prevention
Design Considerations (..contd)

Scope of SA changes


MOBIKE protocol decided to move all IPsec SAs implicitly when
the IKE SA address pair changes. If more granular handling of the
IPsec SA is required, then multiple IKE SAs can be created one for
each set of IPsec SAs needed.
Zero Address set functionality


There is no need to transmit IPsec data traffic. IPsec protected data
can be dropped which saves bandwidth. This does not provide a
functional benefit, i.e., nothing breaks if this feature is not
provided.
MOBIKE signaling messages are also ignored. The IKE-SA must
not be deleted and the suspend functionality (realized with the zero
address set) may require the IKE-SA to be tagged with a lifetime
value since the IKE-SA should not be kept in alive for an undefined
period of time.
Design Considerations (..contd)

Return routability test



The addresses a peer is using are part of a certificate. [RFC3554]
introduced this approach. If the other peer is, for example, a
security gateway with a limited set of fixed IP addresses, then the
security gateway may have a certificate with all the IP addresses
appear in the certificate.
A return routability check is performed by the remote peer before
the address is updated in that peer's Security Association Database.
This is done in order provide a certain degree of confidence to the
remote peer that local peer is reachable at the indicated address.
IPsec Tunnel or Transport Mode
Protocol Overview
Mobike Message Exchanges
Protocol detail issues

Indicating support for mobike

In order for MOBIKE to function, both peers must
implement the MOBIKE extension of IKEv2. If one or
none of the peers supports MOBIKE, then, whenever
an IP address changes, IKEv2 will have to be re-run in
order to create a new IKE SA and the respective IPsec
SAs. In MOBIKE, a peer needs to be confident that its
address change messages are understood by the other
peer. If these messages are not understood, it is possible
that connectivity between the peers is lost.
Protocol detail issues

Approaches used to recognize peers which support mobike:



Ensuring that a peer receives feedback on whether or not its
messages are understood by the other peer, is by using IKEv2
messaging for MOBIKE and to mark some messages as "critical".
According to the IKEv2 specification, such messages either have to
be understood by the receiver, or an error message has to be
returned to the sender.
Ensure receipt of the above-mentioned feedback is by using
Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a
given peer supports the MOBIKE protocol.
Use the Notify payload which is also used for NAT detection (via
NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP payloads)
Protocol detail issues


Path Testing and Window size
Complications:



As the IKEv2 has the window of outgoing messages, and the sender
is not allowed to violate that window (meaning, that if the window is
full, then he cannot send packets), it do cause some complications to
the path testing.
once the message is first time sent to the other end, it cannot be
modified in its future retransmissions. This makes it impossible to
know what packet actually reached first to the other end.
The current IKEv2 document says that if NAT-T is enabled the
node not behind NAT SHOULD detect if the IP-address changes
in the incoming authenticated packets, and update the remote peers
addresses accordingly. This works fine with the NAT-T, but it causes
some complications in the MOBIKE, as it needs an ability to probe
the another address pairs, without breaking the old one.
Protocol detail issues

Path Testing and Window size – Solutions:


To add completely new protocol that is outside the IKE SA message
id limitations (window code), outside identical retransmission
requirements, and outside the dynamic address updating of the
NAT-T.
To make the protocol so that it does not violate window restrictions
and does not require changing the packet is sent, and change the
dynamic address updating of NAT-T to MUST NOT in case
MOBIKE is used.
Message presentation



The IP address change notifications can be sent either via
an informational exchange already specified in the IKEv2,
or via a MOBIKE specific message exchange.
The format of the address update notifications. The
address update notifications can include multiple addresses,
of which some may be IPv4 and some IPv6 addresses.
MOBIKE decided to use IKEv2 NOTIFY payloads, and
put only one data item per notify, i.e. there will be one
NOTIFY payload for each item to be sent.
Updating address list



Because of the initiator decides, the initiator needs to know all the addresses used by
the responder. The responder needs also that list in case it happens move to the
address unknown by the initiator, and needs to send address update notify to the
initiator, and it might need to try different addresses for the initiator.
MOBIKE could send the full peer address list every time any of the IP addresses
changes (either addresses are added, removed, the order changes or the preferred
address is updated) or an incremental update.
MOBIKE decided to use protocol format, where both ends can send full list of their
addresses to the other end, and that list overwrites the previous list. To support NATT the IP-addresses of the received packet is added to the list (and they are not present
in the list).
Security Considerations


The main goals of MOBIKE are to maintain the security
offered by usual IKEv2 procedures and to counter mobilityrelated threats in an appropriate manner.
Traffic Redirection and Hijacking


MOBIKE payloads relating to updating addresses are encrypted,
integrity protected, and replay protected using the IKE_SA. This
assures that no one except the participants can, for instance, give a
control message to change the addresses.
IPsec Payload Protection

The use of IPsec protection on payload traffic protects the
participants against disclosure of the contents of the traffic, should
the traffic end up in an incorrect destination or be eavesdropped
along the way.
Security Considerations

Denial-of-Service Attacks Against Third Parties


Spoofing Network Connectivity Indications


Traffic redirection may be performed not just to gain access to the
traffic (not very interesting because it is encrypted) or to deny
service to the peers, but also to cause a denial-of-service attack for a
third party.
Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are
or are not working.
Address and Topology Disclosure

MOBIKE address updates & ADDITIONAL_IP4/6_ADDRESS
notifications reveal information about which networks the peers are
connected to.
Conclusions


MOBIKE also supports more complex scenarios where the
VPN gateway also has several network interfaces: these
interfaces could be connected to different networks or ISPs,
they may be a mix of IPv4 and IPv6 addresses, and the
addresses may change over time. Furthermore, both parties
could be VPN gateways relaying traffic for other parties.
The base version of the MOBIKE protocol does not cover
all potential future use scenarios, such as transport mode,
application to securing SCTP, or optimizations desirable in
specific circumstances.
References

Tanizawa et al, “A Wireless LAN Architecture Using PANA for Secure
Network Selection”, IEEE 2005.

Pagliusi et al, “PANA-GSM Authentication for Internet Access”, IEEE 2003.

D.Johnson, C. Perkins and J.Arkko, “Mobility Support in IPv6”, RFC 3775.
URL:http://www.ietf.org/rfc/rfc3775.txt

Arkko et al, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile
Nodes and Home Agents”, RFC 3776. URL:
http://www.ietf.org/rfc/rfc3776.txt

IKEv2 Mobility and Multihoming (mobike), IETF Working Groups.
URL:http://www1.ietf.org/proceedings_new/04nov/mobike.html
References

Jari Arkko, “Introduction to multihoming, address selection, failure detection, and
recovery”, IETF Proceedings.
URL:http://www1.ietf.org/proceedings_new/04nov/slides/mobike-1/sld1.htm

“Design of the MOBIKE protocol”, Internet Draft, draft-ietf-mobike-design00.txt , June 2004.
URL:http://www1.ietf.org/proceedings_new/04nov/IDs/draft-ietf-mobikedesign-00.txt

Internet Key Exchange (IKEv2) Protocol, Internet Draft, draft-ietf-ipsec-ikev217.txt, September 2004. URL:http://www.ietf.org/internet-drafts/draft-ietf-ipsecikev2-17.txt

IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft, draft-ietfmobike-protocol-02.txt, September 2005. URL:http://www.ietf.org/internetdrafts/draft-ietf-mobike-protocol-02.txt
References





Tanizawa et al, “A Wireless LAN Architecture Using PANA for Secure
Network Selection”, IEEE 2005.
Pagliusi et al, “PANA-GSM Authentication for Internet Access”, IEEE
2003.
D.Johnson, C. Perkins and J.Arkko, “Mobility Support in IPv6”, RFC
3775. URL:http://www.ietf.org/rfc/rfc3775.txt
Arkko et al, “Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents”, RFC 3776. URL:
http://www.ietf.org/rfc/rfc3776.txt
IKEv2 Mobility and Multihoming (mobike), IETF Working Groups.
URL:http://www1.ietf.org/proceedings_new/04nov/mobike.html
References

Jari Arkko, “Introduction to multihoming, address selection, failure
detection, and recovery”, IETF Proceedings.
URL:http://www1.ietf.org/proceedings_new/04nov/slides/mobike1/sld1.htm

“Design of the MOBIKE protocol”, Internet Draft, draft-ietf-mobikedesign-00.txt , June 2004.
URL:http://www1.ietf.org/proceedings_new/04nov/IDs/draft-ietf-mobikedesign-00.txt

Internet Key Exchange (IKEv2) Protocol, Internet Draft, draft-ietf-ipsecikev2-17.txt, September 2004. URL:http://www.ietf.org/internetdrafts/draft-ietf-ipsec-ikev2-17.txt

IKEv2 Mobility and Multihoming Protocol (MOBIKE), Internet Draft,
draft-ietf-mobike-protocol-02.txt, September 2005.
URL:http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-02.txt