Middleware-Konzepte. Multicast. Dr. Gero Mühl

Transcription

1 Middleware-Konzepte Multicast Dr. Gero Mühl Kommunikations- und Betriebssysteme Fakultät für Elektrotechnik und Informatik Technische Universität Berlin

2 Agenda > Introduction > IPv4 Multicast > Reliability > Ordering > Probabilistic Multicast > Security Middleware-Konzepte Gero Mühl 2

3 Introduction Middleware-Konzepte Gero Mühl 3

4 Multicast > Enables one-to-many (1-to-n) as well as many-to-many (n-to-m) communication > Also known as group communication > Group consists of a set of processes > Message published by a member should be received by all members > Unicast protocols cannot simply be transferred to multicast > Sender cannot keep state for unknown number of receivers Middleware-Konzepte Gero Mühl 4

5 Message Addressing Modes > Unicast > Message is addressed to one receiver > Broadcast > Message is addressed to all potential receivers > E.g., all hosts on a local network > Multicast > Message is addressed to a specific group of receivers > E.g., all file servers > Anycast > Message is delivered to one out of a group of receivers > E.g., to the nearest server Middleware-Konzepte Gero Mühl 5

6 Multicast Applications > Audio and video multicast > File distribution (e.g., software updates) > Information Dissemination > Stock quotes > Usenet news > Cache updates > Shared whiteboards > > Fault-tolerant computing > Distributed databases > Group queries > Multi-player on-line games Middleware-Konzepte Gero Mühl 6

7 Benefits of Multicast > Saves bandwidth when sending a message to a large number of recipients > Without multicast, messages are sent over the same link multiple time (see example below) Middleware-Konzepte Gero Mühl 7

8 Implementing Multicast > Hardware-supported multicast > Ethernet multicast > IP Multicast > Application-level multicast > On top of 1-to-1 communication (e.g., TCP or UDP) > Overlay network of application-level multicast routers Messages are sent multiple times over the links connecting the routers to the backbone Middleware-Konzepte Gero Mühl 8

9 IP Multicast Middleware-Konzepte Gero Mühl 9

10 IPv4 Multicast > IP multicast addresses (class D) range from to to Bits > Exploits Ethernet multicast > Ethernet MAC multicast addresses range from E through e7F.FFFF 23 Bits available > IP multicast addresses are mapped to Ethernet MAC addresses > Lower 23 Bits are mapped, 5 Bits are dropped 32 IP multicast groups have the same MAC address Ambiguity > Group membership handled by network interface card (NIC) Middleware-Konzepte Gero Mühl 10

11 IPv4 Multicast (contd.) > No limitation on the number and location of senders and receivers > Also non-members can post messages to a group > Hosts can be members of several groups simultaneously > Hosts can join and leave groups at any time > Requires multicast-enabled routers Middleware-Konzepte Gero Mühl 11

12 Multicast Routing > IGMP (Internet Group Management Protocol) > DVMRP (Distance Vector Multicast Routing Protocol) > PIM (Protocol Independent Multicast) > BGMP (Border Gateway Multicast Protocol) BGMP PIM IGMP DVMRP Tunnel Middleware-Konzepte Gero Mühl 12

13 Reliability Middleware-Konzepte Gero Mühl 13

14 Reliability Properties > Unreliable multicast (e.g., IP-Multicast) > Messages may get lost, corrupted, or duplicated > Implementation is cheap > Reliable multicast > Every receiver eventually gets every message (What about faults?) > Achieving reliability is costly! > Requires some sort of feedback from receivers > Requires state at the sender Middleware-Konzepte Gero Mühl 14

15 Implementing Reliability > A sequence number is used for each sender s messages > Strategies > Positive acknowledgements (ACKs) vs. negative acknowledgements (NACKs) > Nonhierarchical vs. hierarchical feedback strategies Middleware-Konzepte Gero Mühl 15

16 Positive Acknowledgements (ACKs) > Received messages are acknowledged > either with separate messages or piggybacked > Unique message ids would be sufficient here > If a timeout occurs, the message is resent > Either point-to-point or multicasted again > Message is buffered until all receivers have acknowledged The number of receivers must be known to the sender > Additional Problem: Timeout is very difficult to choose! Adaptive solution necessary Middleware-Konzepte Gero Mühl 16

17 Negative Acknowledgements (NACKs) > Receiver > detects missing messages using sender-based sequence numbers > requests retransmission of missed messages > Assumes that group members regularly send messages > Otherwise, e.g., heartbeats must be used > Since sender does not know when all receivers have received a message, messages must be buffered at the sender indefinitely long (or message latency must be bounded) Middleware-Konzepte Gero Mühl 17

18 Nonhierarchical Feedback > Naïve approach results in ACK/NACK implosion > One possible solution: Feedback suppression > NACKs are multicasted to the group with some random delay > If sender receives NACK, the message is retransmitted > If another member receives NACK, it suppresses its own NACK > NACK repeated after timeout because of possibly lost NACK > Used by Scalable Reliable Multicast (SRM); see Floyd et al. > Problem: Members are bothered with useless messages Middleware-Konzepte Gero Mühl 18

19 Hierarchical Feedback > Group members are organized into a tree > The sender is originated as the root > Each subgroup appoints a local coordinator > Coordinator > Has its own history buffer > Handles ACKs and NACKs in its own group > Sends ACK/NACK to its parent if it received/missed a message > Deletes message from its history if messages was acknowledged by all local members and its children > Main problem is the tree construction Middleware-Konzepte Gero Mühl 19

20 Ordering Middleware-Konzepte Gero Mühl 20

21 Message Ordering Properties > Restrict the order in which messages can be delivered > Distinguish between message receipt and delivery > Received messages must possibly be hold back until they can be delivered ordering properties introduce delay > Enforcing ordering is costly! > Overlapping vs. non-overlapping groups Middleware-Konzepte Gero Mühl 21

22 Example: Database Replicas > Set of database replicas which should be kept consistent Updates must be executed in the same order at every replica! Total order of updates necessary! DB1 DB2 DB3 DB4 Middleware-Konzepte Gero Mühl 22

23 Example: Bulletin Board > Every user has its own copy of the bulletin board > Users post (i.e., multicast) messages to board > For every topic, a separate multicast group is used > Ordering requirements > Messages of the same sender should appear in the order in which they were published > Replies to messages should appear after the message to which they refer Causal ordering necessary Middleware-Konzepte Gero Mühl 23

24 Message Ordering Properties (contd.) > Arbitrary > Messages can be delivered in any order > FIFO > Messages from the same sender must be delivered to every group member in the order in which they were sent > Causal > Message delivery is causally ordered > Total > Messages are delivered to every group member in the same order > Reliable total multicast is often called atomic multicast Middleware-Konzepte Gero Mühl 24

25 FIFO Message Ordering > Messages from the same sender are delivered to every group member in the order in which they were sent send deliver P P P Middleware-Konzepte Gero Mühl 25

26 Implementing FIFO Order: Sequence Numbers > Sequence number for each sender > Message tagged with sender id and sender sequence number > Receiver delivers only the next expected message from a specific sender > Note that this strategy requires reliability! > Potential unreliable alternative > Receiver delivers a received message if the message s sequence number is larger than the one of the message delivered before > Otherwise the message is dropped Middleware-Konzepte Gero Mühl 26

27 Causal Message Ordering > If a message m causally precedes a message m, m is delivered before m > Implies FIFO ordering P 1 P 2 P 3 Middleware-Konzepte Gero Mühl 27

28 Implementing Causal Order: Vector Clocks > Can be implemented with vector clocks > Each process P n maintains its own vector timestamp V n > Upon initialization, all entries of all timestamps are set to 0 > If a message is delivered to P n sent by P m, V n [m] := V n [m] + 1 > If a message is multicasted by a process P n, V n [n] := V n [n] +1 and V n is piggybacked on the message > A message sent by P m is only delivered to P n if for the message s timestamp T the following holds: T[m] = V n [m] + 1 T[k] V n [k] ( k m) next expected message from P m no message missing from any P k > Vector size grows linearly in the number of group members Middleware-Konzepte Gero Mühl 28

29 Middleware-Konzepte Gero Mühl 29 Implementing Causal Order (contd.) P 1 P 2 P receipt

30 Total Message Order > Messages are delivered to every member in the same order P 1 P 2 P 3 Middleware-Konzepte Gero Mühl 30

31 Implementing Total Order: Extended Timestamp > If message latency and clock differences are bound, extended timestamps can be used > If a message is sent, it is tagged with a timestamp SentTime:UniqueSenderId > Order received messages in a queue according to their timestamp > Deliver first message in queue if no message with smaller timestamp can arrive anymore > Problems > Large delay introduced because worst case must be considered > Are the assumption realistic, e.g. in the Internet? Middleware-Konzepte Gero Mühl 31

32 Implementing Total Order: Sequencer > Each message is sent to a elected process called sequencer using unicast communication > The sequencer assigns the next available sequence number to a message it receives and multicast it with its proper id > Problem: Sequencer > Single point of failure > Potential bottleneck > Variant: Multicast messages are multicasted to the group and sequencer multicasts order messages Middleware-Konzepte Gero Mühl 32

33 Relation among Message Ordering Properties FIFO Total Partial Orders FIFO Total Causal implies Total Orders Causal Total Middleware-Konzepte Gero Mühl 33

34 Group vs. Global Ordering Properties > Ordering can be valid with respect to a single group or globally (i.e., across all, potentially overlapping groups) > Example below > Global FIFO violated, Group-based FIFO satisfied P 1 Group 1 Group 2 P 2 Middleware-Konzepte Gero Mühl 34

35 Application-specific Ordering > Often causal or total order are either to weak or to strong > Application order lets the application specify the order of messages > For example, messages may be ordered according to the order in which receive statements occur in the program > A specification is used to describe the ordering among messages > E.g., message m 1 should be delivered before message m 2 Middleware-Konzepte Gero Mühl 35

36 Probabilistic Multicast Middleware-Konzepte Gero Mühl 36

37 Probabilistic Multicast > Also known as gossiping or rumor spreading > Based on epidemic algorithms > Existing mathematical theory of epidemics > Algorithms are randomized instead of deterministic > Randomized algorithms are often much simpler > But only probabilistic reliability guaranties can be given > However, failure probability can be made arbitrarily small > Basic idea: Periodically each member contacts some randomly chosen other members and forwards messages to them > Members must have some knowledge about the group Middleware-Konzepte Gero Mühl 37

38 Probabilistic Multicast (contd.) > Wrt. an individual message, group members can be in one of three sequential states > Susceptible > Message has not yet been received > Infective > Message has been received > Member is spreading the message > Removed > Message has been received > Member is no longer spreading the message Susceptible Infective Removed Middleware-Konzepte Gero Mühl 38

39 Good Epidemics > Minimize the following numbers > Average Delay > Expected delay after which a member gets a message > Inactive Delay > Time after which the system becomes inactive (i.e., no member is infective anymore) > Residue > Proportion of members that do not receive the message > Network traffic > The overall number of messages used to spread the message > Tradeoff between some of these numbers exists Middleware-Konzepte Gero Mühl 39

40 Simple vs. Complex Epidemics > Simple epidemics > Member are either susceptible or infective Eventually all members are infected if at least one member is infected initially > Complex epidemics > Infected members eventually enter the removed state Not all members may be infected Middleware-Konzepte Gero Mühl 40

41 Push vs. Pull > Push > Infectious messages are sent to other members > Pull > Infectious messages are requested from other members > Push-Pull (aka. anti-entropy) > When communicating, members exchange infectious messages in both directions Middleware-Konzepte Gero Mühl 41

42 Blind vs. Feedback > Blind > Receiving member does not tell whether he was susceptible > Requires no feedback from receiving members > Feedback > Receiving member tells whether he was susceptible > This can influence whether the contacting node stays infective or becomes removed > Requires feedback from receiving members Middleware-Konzepte Gero Mühl 42

43 Coin vs. Counter > Coin > After contacting another member, a member enters the removed state with probability 1 / k, k [1, [ > Time a member is in infective state has exponential distribution (see next slide) memory-less distribution > More precisely, it is a geometrical distribution because time is discrete > Variant with feedback also possible; then, only unnecessary contacts are considered > Counter > Member enters removed state after contacting k members > Either blind or with feedback > With feedback only the unnecessary contacts are counted > Counting requires extra state at the sender Middleware-Konzepte Gero Mühl 43

44 Duration of an Infection of a Member (Coin) Fraction of infectious members t Middleware-Konzepte Gero Mühl 44

45 Spatial vs. Uniform Distributions > Uniform distributions > Do not consider network topology > Pick members randomly > Results in high network traffic > Messages spread fast O(n) messages per round > Spatial distributions > Consider network topology > Tend to choose nearby members > Reduce network traffic > But, too much localism increases the time to spread message O(n) group members Middleware-Konzepte Gero Mühl 45

46 Preventing Reinfection > Without special care, information might circulate forever in the system! > Nodes are continually reinfected in this case > Death certificates stored by the nodes can prevent reinfection deterministically > Hash key of data is sufficient > Stored until information is guaranteed to have left the system > But how to determine this period of time? > An alternative is an expiration time for every information > Information is deleted a certain period of time after it appeared for the first time in the system Middleware-Konzepte Gero Mühl 46

47 Mathematical Theory of Epidemics > s fraction of susceptible members > i fraction of infectious members > r fraction of removed members s + i + r =1 > 1 / k probability that an infectious member becomes removed after contacting a non-susceptible member ( push coin with feedback strategy ) Middleware-Konzepte Gero Mühl 47

48 Mathematical Theory of Epidemics (contd.) > Based on differential equations (mass balance equations) > Describe state transitions; sum of equations is zero > Susceptibles are infected according to the product s i > Aim: Determining k wrt. s ds dt di dt dr dt = si = + si 1 = (1 k 1 (1 k s) i divide di k +1 = 1 + ds k ks Middleware-Konzepte Gero Mühl 48 loss due to coin with feedback s) i integrate k i ( s) = s + ln s + k k c

49 Mathematical Theory of Epidemics (contd.) k i ( s) = s + ln s + k k c n 1 i( ) = n 1 n 1 n = k + 1 k n 1 n + 1 k ln n 1 n + c Initial condition: Only 1 infected member, n-1 member susceptible n 1 n 1 n For large n: 1, 0 c k +1 k = i( s) = (1 s) + ln s k k k Middleware-Konzepte Gero Mühl 49

50 Mathematical Theory of Epidemics (contd.) i( s) = 0 Terminal condition: No infectious members s = e ( k+ 1)(1 s) log s k k ln s = s ,55 3,65 5,91-4 8,21 Middleware-Konzepte Gero Mühl 50

51 Mathematical Theory of Epidemics (contd.) k e-07 1e-06 1e-05 1e s Middleware-Konzepte Gero Mühl 51

52 Mathematical Theory of Epidemics II > Here, we consider a simple epidemic r = 0 di = dt si s =1 i di dt = i 2 i solve it () 1 = 1 + C e t 1 i( 0) = C = n 1 n Initial condition: Only 1 infected member 1 i = 1 + ( n 1) e t At the end (t ) all members are infected Middleware-Konzepte Gero Mühl 52

53 i Mathematical Theory of Epidemics II (contd.) n=1000 t Middleware-Konzepte Gero Mühl 53

54 Numerical Solution and Simulation > More complicated differential equations cannot be solved analytically > Often only a qualitative analysis can be made > E.g., whether there will be an epidemic or not > Alternatives > Numerical solution of the differential equations > Simulations Middleware-Konzepte Gero Mühl 54

55 Implementation Example > Every member keeps a list of recently received messages > Periodically these messages are exchanged with other members > Eventually each message is deleted from the list > Members must know some other members! > Bimodal multicast uses two phases (see [1]) > Phase 1: Best effort multicast is used to distribute messages > Phase 2: Group members periodically resent messages they have received Middleware-Konzepte Gero Mühl 55

56 Multicast Security Middleware-Konzepte Gero Mühl 56

57 Agenda > Multicast Security Introduction > Multicast Security Requirements > Logical Key Hierarchies (LKHs) > Re-encryption Trees Middleware-Konzepte Gero Mühl 57

58 Multicast Security > Security much more difficult than in unicast settings > Application Scenarios > News feeds (stock quotes etc.) > Audio streaming > Pay TV (especially pay-per-view) > Main Problems > Authentication (of the provider) > Confidentiality (of the content) > Scalability (in number of group members) > Multicast routing information must also be secured > Bogus routing messages may modify or disrupt routing Middleware-Konzepte Gero Mühl 58

59 Authentication > Provider must prevent other entities from generating or changing content on its behalf > Digital signatures can be used to secure messages > Rely on asymmetric encryption technique > Provider signs hash value of the message with its private key > Receiver verifies integrity and authenticity of the message with the provider s public key Middleware-Konzepte Gero Mühl 59

60 Confidentiality > Content should only be accessible to members for the duration of their membership > Backward secrecy > New member should not be able to discover old content > Forward secrecy > Former member should not be able to discover new content Encryption must be adapted each time a member is added or removed (or little time after; e.g., at end of the day) Middleware-Konzepte Gero Mühl 60

61 Algorithmic Requirements > Processing Scalability > Algorithm should scale to a large number of group members > Membership Robustness > Members should be able to access the content as soon as it is received Middleware-Konzepte Gero Mühl 61

62 Naïve Approach > Global key used for content encryption > Every time member set changes, new global key is sent to all current members using secure unicast channel > Requires n messages Not scalable Middleware-Konzepte Gero Mühl 62

63 The Logical Key Hierarchy (LKH) > Each client receives a key set according to its path in a tree > The traffic is encrypted with the root key k 1, also known as the traffic encryption key (TEK) > The other keys are called key encryption keys (KEKs) > TEK is invalidated every time a member is added or removed TEK k 1 k 2 k 3 k 4 k 5 k 6 k 7 C 1 C 2 C 3 C 4 Middleware-Konzepte Gero Mühl 63

64 Removing a Member > All keys on the path to the removed member are invalidated and replaced by new random keys k 1 encrypted with > The new keys are then multicasted to the group in a key update message k 2 k 3 > k 2 encrypted with k 4 > k 1 encrypted with k 2 k 4 k 6 k 7 > k 1 encrypted with k 3 C 1 C 3 C 4 2* log 2 n -1 encrypted keys are {k 1,k 2,k 4 } {k 1,k 3,k 6 } {k 1,k 3,k 7 } multicasted updated key sets Middleware-Konzepte Gero Mühl 64

65 Adding a Member > All keys on path to new member are invalidated > New keys are distributed the same way > The key corresponding to the new member is sent to him using a secure unicast channel Middleware-Konzepte Gero Mühl 65

66 LKH Summary > Traffic is encrypted with a single key that is updated using a binary key tree > No intermediaries necessary > Optimizations can be used to decrease update complexity > Adding new member with a single unicast message possible by calculating new key from old ones using one way functions > Cost of removing member can also be halved with one way functions > If client misses key update message, it might loose synchronization > Hints and parity messages can moderate this problem Middleware-Konzepte Gero Mühl 66

67 Re-encryption Trees > Group is hierarchically divided into subgroups > Top-level group contains Group Security Center (GSC) > Subgroups are connected by Group Security Intermediaries (GSI) which also manage the respective subgroup > Traffic is re-encrypted by every GSI > Naïve algorithm or LKH can be used within a subgroup for updates GSI G 2 GSC GSI G 1 GSI G 3 GSI G 4 G 5 Middleware-Konzepte Gero Mühl 67

68 Re-encryption Trees (contd.) > Divide large multicast group into small enough subgroups > Adding and removing a member only affects members in the same subgroup > Impact of attacks is limited to the scope of the respective subgroup > Disadvantage: Intermediaries must be trusted! Middleware-Konzepte Gero Mühl 68

69 Bibliography 1. Kenneth P. Birman, Mark Hayden, Oznur Ozkasap, Zhen Xiao, Mihai Budiu, and Yaron Minsky. Bimodal Multicast. ACM Transactions on Computer Systems, 17(2):41--88, May G. Singh and S. Badarpura. Application Ordering in Group Communication. In International Conference on Distributed Computing Systems Workshop, pages , F. Bauer and C. Castillo-Chávez. Mathematical Models in Population Biology and Epidemiology. Number 40 in Texts in Applied Mathematics. Springer, pp George Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems: Concepts and Design. Addison-Wesley, pp Alan Demers, Dan Greene, Carl Hauser, Wes Irish, and John Larson. Epidemic Algorithms for Replicated Database Maintenance. In Proceedings of the sixth annual ACM Symposium on Principles of distributed computing, pages ACM Press, S. Floyd, V. Jacobson, C. Liu, S. McCanne, and L. Zhang. A Reliable Multicast Framework for Light-Weight Sessions and Application Level Framing. In IEEE/ACM Transactions on Networking, pages , December 1997 Middleware-Konzepte Gero Mühl 69

70 Bibliography (contd.) 7. L. Lamport. Time, Clocks, and the Ordering of Events in a Distributed Environment. Communications of the ACM, 21: , July S. Mittra. Iolus: A Framework for Scalable Secure Multicasting. In Proceedings of the ACM SIGCOMM'97, pages , Refik Molva and Alain Pannetrat. Network Security in the Multicast Framework. In E. Gregori, G. Anastasi, and S. Basagni, editors, NETWORKING 2002 Tutorials, volume 2497 of LNCS, pages , Pisa, Italy, Springer- Verlag 10. Andrew S. Tanenbaum and Marten van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall, pp and pp G. Tel. Introduction to Distributed Algorithms. Cambridge University Press, pp C. K. Wong, M. Gouda, and S. S. Lam. Secure Group Communications Using Key Graphs. IEEE/ACM Transactions on Networking, 8(1):16--30, February Middleware-Konzepte Gero Mühl 70