Zueyong Zhu† and J. William Atwood‡ Workshop on Peer-to-Peer Multicasting IEEE CCNC 2007 A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol Zueyong Zhu† and J. William Atwood‡ †University of Science and Technology of China ‡Concordia University, Montreal, Canada

Secure Multicast Using HIP Contents Introduction Motivation HIP Architecture Multicast Architectures Group Identification System Operation Validation Conclusion 2007/01/11 Secure Multicast Using HIP

Introduction Figure 1: Present IP Multicast Architecture IGMP Message Keep Membership Information Determine Best Path to Forward Data Multicast Routing Messages Transmit Data AR CR AR Receiver Sender CR AR Receiver Figure 1: Present IP Multicast Architecture 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP Motivation Some applications need per-instance charging Not enough demand for multicast yet, to do this in native multicast Application Layer Multicast, Overlay Multicast Although general solutions may come, it is worthwhile to look at specific cases Two examples xDSL Collaboration 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP xDSL DSLAN <-> user is on a separate physical path Unicast gives same performance We gain: Authentication Secure access Potential for accounting (revenue generation) 2007/01/11 Secure Multicast Using HIP

Wide Area Collaboration Strong need for authentication and authorization No need for accounting No revenue generation No benefit from multicast data transmission Overlay (p2p) multicasting is appropriate 2007/01/11 Secure Multicast Using HIP

No native multicast support When there is no native multicast support, we must use overlay or p2p 2007/01/11 Secure Multicast Using HIP

Host Identity Protocol Internet has two name spaces (Fully Qualified) Domain Name IP Address Role as locator Role as end-point identifier HIP separates these two roles Host Identifier (public key, end-point id) Host Identity Tag (128-bit hash, fixed-size end-point id) 32-bit version exists for IPv4 environments IP address continues to serve as locator 2007/01/11 Secure Multicast Using HIP

Host Identity Protocol ..2 Authenticate participant hosts Establish limited relationship of trust Four-packet Exchange Initial packet (I1) 3-packet Diffie-Hellman exchange (I2, R1, R2) 2007/01/11 Secure Multicast Using HIP

Multicast Architectures Overlay Multicast Among participants Independent of topology All at application layer Native Multicast Routers do it all Source-based tree Shared tree Agents Packet duplication Tree Management Key Management Authenticate group members Collect accounting information 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP Our Cases P2P HIP allows establishment of trust (security association) between the two unicast-linked nodes Use any convenient tree-construction algorithm DSLAN Unicast path Host is initiator Multicast Agent is on the DSLAN Authentication via HIP 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP Advantages The security provided by HIP is just what we need Use of a Multicast Agent improves control in DSLAN 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP New Architecture Two-layer architecture (or n-layer) New interactions No need for IGMP or PIM-SM Absolute control of membership 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP New Architecture HIP Forward protocol Group Receivers R Source Local Server Receiver Local Server Group Source S Multicast Agent Group’s Root HIP Responder HIP Initiator to S HIP Responder to R host 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP Identifying the Group Need a Group Identifier Structured identically to the Host Identifier and Host Identifier Tag: Group Identifier and Group Identifier Tag Extend I1 and R2 to carry the GIT I2 and R1 do not need to be changed 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP System Operation Join Start HIP with your initiator (group receiver or MA) Initiators join tree and receive multicast traffic Responder joins tree or forwards to source Leave Add “leaving request” parameter to HIP exchange Create Add “create request” parameter to HIP exchange Two levels are independent 2007/01/11 Secure Multicast Using HIP

An example of application R15 ISP 2 Local Server Group1 Receiver R16 ISP 1 Group1 Receiver R11 R12 R13 R21 R23 Group2 Receiver R22 R14 ISP A ISP B R26 R25 Group2 Receiver R24 Group2 Source S22 S21 S12 Group1 Source S11 Internet Local network Multicast Agent Group2’s Root HIP Responder Group1’s Root HIP Initiator to S HIP Responder to R host 17

Constructing Multicast Distribution Trees xDSL: One level of HIP-based control---MA joins the “native” multicast tree It is “trusted”, or native tree must be secure multicast Two-layer needs multiple unicast transmissions, or “snooping” in the network Can be extended to n-layer in the total absence of network support for multicast 2007/01/11 Secure Multicast Using HIP

Validation of the Model PROMELA + SPIN + Embeded C-code 32 receivers (Initiators) Some Intruders 2 Downstream MAs 1 Upstream MA 2 Senders Some routers 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP Results No assertion violation No invalid end-state No unreachable state No real, valid or successful attack Embeded C-code to test file transfer and simple encryption Load not too great Transfer is delayed, but not invalidated 2007/01/11 Secure Multicast Using HIP

Conclusion and future work Two new specialized architectures for multicast access control One for peer-to-peer networks One for xDSL environments Formal validation of its operation Future goals: Incorporate into the global system that we are building 2007/01/11 Secure Multicast Using HIP

Secure Multicast Using HIP For more information High Speed Protocols Laboratory of Concordia University is doing extensive research on IP multicast, http://users.encs.concordia.ca/~bill/hspl/ For questions and comments: zhuxy@ustc.edu.cn bill@cse.concordia.ca 2007/01/11 Secure Multicast Using HIP