160 likes | 454 Views
The Second International Workshop on Network Mobility (WONEMO) SAINT2007, Hiroshima, JAPAN, January 15-19, 2007. HIP-NEMO A HIP based Network Mobility Protocol Szabolcs Nováczki, László Bokor , Sándor Imre Budapest University of Technology and Economics {nszabi, goodzi , imre}@mcl.hu.
E N D
The Second International Workshop onNetwork Mobility (WONEMO)SAINT2007, Hiroshima, JAPAN, January 15-19, 2007 HIP-NEMO A HIP based Network Mobility Protocol Szabolcs Nováczki, László Bokor, Sándor Imre Budapest University of Technology and Economics {nszabi, goodzi, imre}@mcl.hu
Outline • Motivation • Introduction • HIP • HIP based Micromobility • HIP – NEMO • Protocol Basics • Hierarchy Build-up • Signaling Delegation • Connection Tracking • Security Considerations • Conclusions • Future Work
Motivation (1/2) • Network Mobility (NEMO) support is one of the most actual challenges that next generation Internet faces • To allow NEMO in practice several protocols and methods were designed and evaluated • However several novel real life demonstrations and testbeds started to prove the feasibility and usability of NEMO Basic Protocol and its extensions, the searching for new ways of creating an „all-in-one” solution has not stopped
Motivation (2/2) • The Host Identity Protocol is a multi-addressing and mobility solution for the IPv4 and IPv6 Internet • Furthermore, HIP was designed to be resilient of most security threats • In our proposal we extend HIP in order to provide NEMO support by fulfilling the needs of nested and multihomed NEMO scenarios and optimal routes, all in a secure way
Introduction: HIP (1/2) • Host Identity Protocol (HIP) • Proposes a new Internet architecture • A new layer – Host Identity Layer – between the transport and the network layer • A new namespace – Host Identity Namespace – consisting of Host Identifiers (HI) • A Host Identifier is the public part of an asymmetric key-pair (security) • Every Internet host is assigned to at least one key-pair • Applications and transport layer connections are no longer bound to IP addresses but to HIs. • The dual role of IP addresses (locator – identifier) are separated
Introduction: HIP (2/2)
HIP based Micromobility Introduction: • Local Rendezvous Server (LRVS) • A new network entity – HIP enabled gateway router • Serves as a micromobility anchor point • Stores HIT-IP mappings of MNs in it’s service area • MNs register their actual IP address and HIT • MNs update the mappings • Assignes a unique, globally routable IPv6 address (IPg) to the MNs • Functions: • Outgoing packets: the LRVS changes the source address to the IPg • Incomig packets: the LRVS changes the destination address to the actual IP address • While the IP address of a MN frequently changes, the IPg remains the same until it resides in the service area of a given LRVS • Intra-domain handovers are handled locally Further information on HIP based Micromobility: Sz. Nováczki, L. Bokor, S. Imre: “Micromobility Support for HIP: Survey and Extension for Host Identity Protocol”, MELECON 2006, Malaga, Spain, May 2006.
Protocol Basics HIP – NEMO: • The micromobility framework can be extended to serve moving networks • Three issues have to be taken into account: • A hierarchical topology of mobility enabled LRVSs (mLRVS, i.e. the MR in NEMO terminology) • Thus, a hierarchical micromobility configuration has to be managed: based on HIP Service Discovery • MNNs have to delegate their signaling rights to the mLRVS • The right can be further delegated: based on HIP Signaling Delegation • The mLRVS has to track the connections of MNNs in its service area • Connection tracking and signaling delegation enables the mLRVSs to signal on behalf of MNNs
HIP – NEMO: Hierarchy build-up
HIP – NEMO: Hierarchy build-up
HIP – NEMO: Signaling delegation • During the registration process the MNNs delegate their signaling rights to the mLRVS at which they are registered • An mLRVS may further delegate these rights to a higher level one • The root mLRVS will have the right to signal on behalf of all the nodes in the MNET Further information on signaling delegation in HIP: P. Nikander and J. Arkko. “Delegation of Signaling Rights”. In Proc. of the 10th IWSP, pp 203–212, Cambridge, UK, 2002.
HIP – NEMO: Connection tracking • If the root mLRVS changes its point of attachment, it has to inform the CNs of all the MNs • Thus if a MNN establishes communication contexts, the root mLRVS stores information about the partners to be able to signal on behalf of them
HIP – NEMO: Security Considerations • The security strenght is derived from the security provided by HIP • Cryptographical HIs • Authentication, Authorization • Integrity • Confidentiality • Cryptographic certificates – Secure signaling delegation • Security bottleneck – Service Discovery is vulnerable • SDP packets are unprotected
Conclusions • The method provides secure connectivity and reachability for every node and nested subnet in the moving network and supports multihomed scenarios as well • Compared to existing NEMO proposals our solution provides the following advantages • As the proposal is based on HIP, all of its advantages are inherited • The signaling delegation and the hierarchical micromobility architecture provide less signaling and packet overhead in several scenarios compared to the basic MIP6-NEMO solution • However generally this needs to be proved by simulations and further evaluations • There is no need to use tunneling or encapsulation, and data packets (except the first packet of the Base Exchange) are traveling always on the optimal route • Extensions of MIP6-NEMO solve the problems of optimal routes, packet overhead and even security problems, but today none of them provide such a complete framework to address all these issues like our proposal • The advantages of our solution are clear, but there are drawbacks as well: • Our method is not transparent to MNNs, they have to register at mLRVSs • Furthermore, if the whole moving network changes its point of attachment the root mLRVS has to update the CNs of all the MNNs inside
Future Work • Simulation experiments (OMNeT++) • Functional validation • Compare HIP-NEMO to other NEMO proposals • Finalize the protocol specification • Fully functional NEMO framework • Implementation • Evaluate HIP-NEMO in real-life environments
Thank you! Questions…?