1 / 22

A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol

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 ‡. Contents. Introduction Motivation HIP Architecture Multicast Architectures Group Identification

zinna
Télécharger la présentation

A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Workshop on Peer-to-Peer MulticastingIEEE CCNC 2007 A Secure Multicast Model forPeer-to-Peer and Access NetworksUsing the Host Identity Protocol Zueyong Zhu† and J. William Atwood‡

  2. Contents • Introduction • Motivation • HIP Architecture • Multicast Architectures • Group Identification • System Operation • Validation • Conclusion Secure Multicast Using HIP

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

  4. 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 Secure Multicast Using HIP

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

  6. 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 Secure Multicast Using HIP

  7. No native multicast support • When there is no native multicast support, we must use overlay or p2p Secure Multicast Using HIP

  8. 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 Secure Multicast Using HIP

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

  10. 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 Secure Multicast Using HIP

  11. 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 Secure Multicast Using HIP

  12. Advantages • The security provided by HIP is just what we need • Use of a Multicast Agent improves control in DSLAN Secure Multicast Using HIP

  13. New Architecture • Two-layer architecture (or n-layer) • New interactions • No need for IGMP or PIM-SM • Absolute control of membership Secure Multicast Using HIP

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

  15. 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 Secure Multicast Using HIP

  16. 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 Secure Multicast Using HIP

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

  18. Constructing MulticastDistribution 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 Secure Multicast Using HIP

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

  20. 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 simpleencryption • Load not too great • Transfer is delayed, but not invalidated Secure Multicast Using HIP

  21. 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 Secure Multicast Using HIP

  22. 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 Secure Multicast Using HIP

More Related