Handover mechanisms in next generation heterogeneous wireless ...

More documents

Recommendations

Info

SECURITY FOR HANDOVER ACROSS HETEROGENEOUS WIRELESS NETWORKS protocol, where requests are always initiated by the client, while responses (e.g. challenge or accept/reject) are sent by the server. In Diameter, all data are delivered in the form of Attribute Value Pairs (AVPs). These AVP values can be used by the Diameter protocol itself, and applications that employ Diameter. The Diameter base protocol supports the introduction of new AVPs so as to make Diameter extensible. Instead of using message type (seen as Code field in a RADIUS packet), Diameter defines the concept of “Command”, which is assigned for each command request/answer pair and determines the action to be taken for a particular message. The commands are distinguished by Command Code field in the Diameter message as shown in Figure 3.10. Application ID is four octets and is used to identify to which application the message is applicable for. Hop-by-Hop Identifier is used to match requests and responses on a hop, which is denoted as a Connection to be discussed later in Diameter. The sender must ensure that the hop-by-hop identifier is unique on a given connection at any given time [62]. Another field, End-to-End Identifier, is used to detect duplicate messages. The originator of an answer message must ensure that the end-toend identifier value of the message is the same as the value found in the corresponding request. Diameter AVPs carry specific authentication, authorisation, accounting, routing, and security information for the Diameter transactions. The Diameter base protocol defines a large number of AVPs, e.g. Origin-Host AVP, Origin-Realm AVP, Destination-Host AVP and Destination-Realm AVP. Figure 3.10 Diameter message format - 52 -
SECURITY FOR HANDOVER ACROSS HETEROGENEOUS WIRELESS NETWORKS With various types of Diameter messages, AAA requests/responses can be transported within Diameter. Diameter can be run on both Transmission Control Protocol (TCP) and Stream Control Transmission Protocol (SCTP) transport protocols, in contrast to RADIUS which relies on User Datagram Protocol (UDP). The end to end transmission path between a client and a Diameter server is identified as a session, which is a logical concept at the application layer. A session is processed by end entities and is identified by Session-ID AVP in Diameter. A session is established through a number of individual connections, which is a transport level connection between two peers, and used to send and receive Diameter messages. In the example shown in Figure 3.11, two peer connections are established between the client and Diameter server. The user session X spans from the client NAS to the Diameter server crossing an agent. As noted in the Diameter base protocol [62], there is no relationship between a connection and a session, and Diameter messages for multiple sessions are all multiplexed through a single connection. Figure 3.11 Diameter connections and sessions Unlike the RADIUS protocol, message routing is explicitly defined in the Diameter specification. This effectively addresses the limitations of RADIUS, e.g. vulnerability to attack from external parties, and thus facilitate more secure and scalable roaming in a multi-operator environment. Diameter routing is conducted through the use of “Peer Table” and “Realm-Based Routing Table”, the latter of which is also known as Realm Routing Table. A realm is an administrative domain used for routing purposes, and the concept of it is originated from the NAI specification [64]. Peer table is used in message forwarding, and referenced by realm routing table. Each Diameter node keeps a peer table that maintains an entry for each of its peers. Each entry in the peer table contains information on the host identity of the peer, the state, whether a peer entry was statically configured or dynamically discovered, the expiration time for the dynamically discovered peer entry and whether TLS is enabled for communications. Realm routing - 53 -
Page 1 and 2:
Handover Mechanisms in Next Generat
Page 3 and 4:
ACKNOWLEDGMENT First of all, I woul
Page 5 and 6:
TABLE OF CONTENTS 4.4.2 Power Save
Page 7 and 8:
LIST OF FIGURES LIST OF FIGURES Fig
Page 9 and 10:
LIST OF FIGURES Figure 7.2 A generi
Page 11 and 12:
ABSTRACT New access technologies su
Page 13 and 14: Chapter 1 INTRODUCTION New access t
Page 15 and 16: INTRODUCTION becomes available. Han
Page 17 and 18: INTRODUCTION The above multipliciti
Page 19 and 20: INTRODUCTION network trust pattern
Page 21 and 22: INTRODUCTION 1.3 Related Publicatio
Page 23 and 24: INTRODUCTION TECHNICAL REPORTS XIII
Page 25 and 26: HANDOVER MANAGEMENT horizontally. H
Page 27 and 28: HANDOVER MANAGEMENT The objective o
Page 29 and 30: HANDOVER MANAGEMENT air interface,
Page 31 and 32: HANDOVER MANAGEMENT proposed archit
Page 33 and 34: HANDOVER MANAGEMENT Access point (A
Page 35 and 36: HANDOVER MANAGEMENT users. Moreover
Page 37 and 38: HANDOVER MANAGEMENT For IEEE 802.11
Page 39 and 40: HANDOVER MANAGEMENT The two schemes
Page 41 and 42: HANDOVER MANAGEMENT When a MH is mo
Page 43 and 44: 3.1 Introduction Chapter 3 HANDOVER
Page 45 and 46: SECURITY FOR HANDOVER ACROSS HETERO
Page 63: SECURITY FOR HANDOVER ACROSS HETERO
Page 69 and 70: DYNAMIC NEIGHBOUR TRUST INFORMATION
Page 93 and 94: Chapter 5 TRUST ASSISTED HANDOVER A
Page 95 and 96: TRUST ASSISTED HANDOVER ALGORITHM F
Page 115 and 116:
TRUST ASSISTED HANDOVER ALGORITHM F
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Chapter 6 PROXY BASED AUTHENTICATIO
Page 125 and 126:
PROXY BASED AUTHENTICATION LOCALISA
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
MULTI-INTERFACE MOBILE MODEL FOR ME
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
CONCLUSIONS AND FUTURE RESEARCH WOR
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
ABBREVIATIONS 3G 3rd Generation Wir
Page 177 and 178:
ABBREVIATIONS LS Location Server MH
Page 179 and 180:
ABBREVIATIONS THOA Trust Assisted H
Page 181 and 182:
REFERENCES [12] C. Politis, T. Oda,
Page 183 and 184:
REFERENCES [37] Wi-Fi Alliance, "Wi
Page 185 and 186:
REFERENCES presented at IEEE Intern
Page 187 and 188:
REFERENCES [90] R. Verdone and A. Z
Page 189:
REFERENCES [116] K. E. Malki and H.
show all

Handover mechanisms in next generation heterogeneous wireless ...

Create successful ePaper yourself

Delete template?

Save as template?