Lecture 6

advertisement
Lecture 6
• Bandwidth allocation in multirate multicast
is significantly more complicated than the
unicast network.
• There can be several bandwidth allocation
objectives.
– Fair Allocation
– Utility Maximization
Transmission of Layered
Multicast
• Receiver Driven Layered Multicast (RLM)
• S. Mccanne, V. Jacobson and M.
Vetterli,``Receiver Driven Layered
Multicast,’’ Proceedings of ACM
SIGCOMM 1996, October 1996
RLM
• Every layer is transmitted as a separate multicast
group.
• Receivers join and leave groups depending on the
bandwidth contention.
• Ideally all receivers would like to receive all
layers for good quality of reception.
• However, bandwidth limitations do not allow
receivers to subscribe to all layers.
• So receivers should subscribe to the maximum
number of layers that do not congest the network.
Initially, all receivers subscribe to the lowest layer.
Receivers conduct join experiments time to time.
If a receiver does not experience significant packet loss
for some time, it joins a layer on an ``experimental’’
basis.
If the join experiment causes congestion in the network,
it leaves the layer.
Otherwise, the receiver retains the layer.
If at any time, a receiver experiences congestion, it drops the highest
layer is subscribes to.
Congestion may be because of decrease in link capacity, or other
receivers conducting join experiments.
Receivers learn from the outcomes of other join and leave
experiments (shared learning)
If another receiver fails in an add layer experiment, then
the inference is that the network is congested, and
receivers do not conduct add layer experiments for some
time.
Burden of choosing the right level of subscription is
left to the receivers
So the source is not burdened with handling the
subscription levels for all receivers.
Hence, RLM is scalable.
Defects in RLM
The protocol is not scalable because every receiver needs to
know the outcome of experiments of all other receivers.
Hence, every receiver needs to maintain and process a lot of
information.
Also, a receiver should not drop the highest layer whenever
it is congested.
1
2
This is because some other receiver sharing its path, may
already be subscribing to a higher layer, and this higher
layer is causing the congestion. So, leaving a lower layer
may not help.
Layered Video Multicast with
Retransmissions (LVMR)
``Layered Video Multicast with Retransmissions (LVMR):
Evaluation of Hierarchical Rate Control,’’ X. li, S. Paul, M.
Ammar, INFOCOM 1998
There is scope of retransmission of lost packets
Receivers do not keep track of the outcome of join
experiments of other receivers, but there are other
nodes responsible for storing the information.
Every receiver takes permission from these
responsible nodes before conducting any join
experiments.
These responsible nodes also issue leave notices for
particular layers to receivers in their area.
R7
R8
R1
R2
R3
R4 R5 R6
A node (n1) is in charge of R1, R2, R3
A node (n2) is in charge of R4, R5, R6
A node (n3) is in charge of R7, R8
A node n4 is in charge of n1 and n2, etc.
R1, or R2 or R3 takes join experiment permission from
node n1.
If R1 is using 4 layers, then n1 can give permission to R2 to
conduct experiment of joining the 3rd layer.
If the max. layer under a nodes jurisdiction is k, then it can
give permission to any node for trying to join layers 1,…k,
otherwise it passes the request to a higher node.
A node gives permission to only one experiment
under its jurisdiction at a time, else the outcomes of
the experiments will be confused.
Layer Drop Events
Whenever a receiver experiences congestion, it reports its
highest layer number to the node in charge.
The node broadcasts the layer number to all nodes under
its charge.
All nodes receiving such congestion information leaves
their highest layer, if the highest layer is greater or equal
to the reported layer number.
If the congestion is the outcome of a join experiment to the
highest layer for the receivers under its charge, then send
the congestion info to nodes higher in the hierarchy as well.
If the congestion info reaching from a lower node is
reagarding the highest layer currently in the domain of a
higher node, it broadcasts the info to the receivers under
its control for shared learning, and sends the information
further up-wards.
Other Alternatives For Network
Heterogeneity
• S. Cheung, M. Ammar, X. Li, ``On the use of
Destination Set Grouping to Improve Fairness in
Multicast Video Distribution’’, INFOCOM 1996
• Group receivers, with ``similar receivers’’ in the
same groups
• Transmit different streams at different rates for
different groups
• Tradeoff between Bandwidth Inefficiency and
stream granularity
Fairness Problems
Does not discuss the splitting of bandwidth between
different sessions.
A session which joins later is at a disadvantage,
because the entire bandwidth is grabbed by the
other sessions.
Any join experiment will lead to congestion for the
session.
A solution is to have different dropping thresholds
for different layers, i.e., a receiver having a higher
number of layers drops its highest layer more easily
than one with lower number of layers in the event of
congestion
Multisession layered video for rate controlled Multicast
X. li, S. Paul, M. Ammar
Reliable Multicast
Packets may be dropped in the links and
buffers due to congestion or link errors
Need retransmissions in the event of errors.
TCP gives reliability to IP
Normally, real time traffic like audio, video are
loss tolerant, but delay sensitive and do not require
any retransmission
But data traffic can tolerate delay, but not loss and
needs retransmissions
Reliable unicast protocols require the receiver to
ACK a successful transmission and NACK an
erroneous packet, if an error is detected. If there
is no ACK, or there is a NACK then the packet is
retransmitted.
Similarly, every receiver can send
acknowledgements in multicast, and the source
can retransmit missed packets.
However, this overwhelms the source if there are
many receivers, and also the source need not
retransmit the packet to all receivers, but only to
those who misses the packet.
So there is a serious scalability problem.
Reliable Multicast Protocols
Scalable Reliable Multicast, S. Floyd, V. Jacobson,S.
Mccanne, C. Liu, L. Zhang, Sigcomm 95
Whenever a receiver misses a packet, it sets up a
random timer.
The random timer is related to the distance between
the source and the receiver (the random number is
normally lower for receivers close to the source).
A receiver multicasts a repair request whenever the timer
expires.
A receiver suppresses the request if it hears a request from
another receiver.
Normally, a receiver closer to the source sends the
repair request before any other receiver.
The source needs to handle only a few repair
requests, even if many receivers miss the packet.
Whenever a receiver hears a repair request, and has
the data packet, it sets up another random timer.
It multicasts the data packet when the timer expires.
Any other receiver hearing the data packet retransmission
suppresses its timer.
Again only a few receivers multicast the same packet.
Cry baby problem
Suppose there is a receiver with an error prone link
(wireless link).
All receivers are somehow involved in sending a
data packet to this receiver every time there is an
error (needs to set up timers etc.).
This is inefficient overall.
Reliable Multicast Transfer
Protocol (RMTP)
S. Paul, K. Sabnani, J. Lin, S. Bhattacharya, JSAC
April 1997
This protocol follows a hierarchical approach.
There is a designated receiver, DR for each zone.
The DR sends ACK/NACK to the source
depending on the packets it receives from the
source.
Whenever a receiver misses a packet, it sends a request to its
local DR.
If the DR has the packet, it sends it to the receiver, else
it sends it to the receiver when it gets the packet
retransmitted by the source.
Again the source handles much fewer ACKs/NACKs
We can have a hierarchy of DRs, lower DRs reporting
to higher DRs etc., to reduce the load on the source.
Local DRs handle crying babies, if any.
Network Security (Unicast)
• Privacy of communication
– Communication is encrypted by a mutually agreed key
between two parties
– Y = f(X, Key) (encrypting) X = g(Y, Key)(decrypting)
• Y = X (xor) Key, X = (X (xor) Key) (xor) Key, X = Y (xor)
Key
– Key is crucial to secrecy
– Rekeying done at intervals or at session termination
– During rekeying, message must be exchanged between
two nodes.
• Authentication
– Need to prove identity
Authentication
• Public Key signature (RSA)
– A user has a public key and a private key.
– Everyone else knows the public key (published in a
directory
– Only the user knows the private key
– Sender sends Y, where Y = f(X, private key), where X
is the message along with X
– Receiver does Z = g(Y, public key). If f and g are
rightly chosen, Z = Y, and this means the sender has
used his private key, which is known only to the sender.
– This is like a signature.
Message Authenticaton Codes
• However, public and private key operations are time
consuming.
• Using Message Authentication Codes (MAC) is another
option
• A MAC is a function which takes a secret key k, a message
M and returns a value MAC(k, M). Sender sends the MAC
value along with the message.
• If sender and receiver both know the secret key, then the
receiver can repeat the MAC computation, and be sure of
the senders identity.
• MAC computations are faster.
Multicast Security
• Multicast Security: A taxonomy and Some Efficient
Constructions, R. Canetti, J. Garray, G. Itkis, D.
Mcciancio, M. Naor, B. Pinkas, INFOCOM 1999
• A mutually agreed key is used to encrypt and decrypt all
messages in a multicast session.
• It is important that only members of the multicast group
are able to decipher the messages communicated for the
group.
• When a receiver leaves a group, then the common session
key must be changed.
– Else the receiver will follow the messages without
being part of the group.
Also, when a member joins newly, then the session may
want to use new keys so that the new member can no
decrypt the information exchanged while he was not a part
of the group.
In this case, the new key may be encrypted with the
old key for the existing group, the old key discarded,
and the new key send to the new member via a secure
unicast communication.
Any problems with this approach?
Member Revocation
Member leaving a group
The new key must be secretly communicated
otherwise non-members will decrypt the messages for
the intended group.
The secret communication should not be encrypted with the
old key, because then the departing receiver will get hold of
the new key.
A simple solution is to share a separate secret key between
the source and every destination and
send the new secret key encrypted with the separate keys
for all the existing receivers
However, the problem with this approach is
every time a receiver leaves, we need to carry out
n encryption decryptions, where n is the number
of existing receivers,
And the source needs to know total n keys
So the approach is not scalable.
It is possible to have a key distribution scheme
which needs O(log n) encryption decryption
schemes every time a receiver leaves.
D. Wallner, E. Harder and R. Agee, ``Key
Management for Multicast: Issues and
Architectures’’, draft-wallner-key-arch-00.txt
N0
K0
K00
K000
a
N01
N00
N000
N001
K001
K0000
b
K0001
N010
K010
b
K0010
c
d e
K0011 K0100 K0101
Node Ni gets key Ki
A receiver gets all the keys in its path.
Receiver a gets Keys K0, K00 K000 K0000
The session messages are encrypted by key K0.
K01
N011
K011
f
K0110
g
K0111
N0
K0
K00
K000
a
N01
N00
N000
N001
K001
K0000
b
K0001
N010
K010
b
K0010
c
d e
K0011 K0100 K0101
How many keys are in the system?
What is the depth of the tree?
When a receiver leaves, all keys in its path are replaced
If Receiver g leaves Keys K0, K01 K011 are replaced.
K01
N011
K011
f
K0110
g
K0111
N0
K0
K00
K000
a
N01
N00
N000
N001
K001
K0000
b
K0001
K01
N010
K010
b
K0010
c
d e
K0011 K0100 K0101
N011
K011
f
K0110
g
K0111
Replacement of Key K011 is encrypted by K0110 and either
multicasted or just communicated to f
Replacement of Key K01 is encrypted by new K011 and old
K010 and multicasted to entire group or selectively to d, e, f
Replacement of Key K0 is encrypted by new K01
and old K00 and multicasted to entire group.
There are log n keys in the path.
Each key is encrypted with at most two keys.
Hence O(log n) encryption decryptions are
required.
We still need to store n keys.
Can we get away with storing just O(2log n) keys?
Key Management for Secure Internet Multicast using
Boolean Function Minimization Techniques, I. Chang,
R. Engel, D. Kandlur, D. Penderakis, D. Saha
The system has 2log n keys.
Have a binary id for each receiver.
So the binary ids have log n bits. System has 1 key
corresponding to each possible value of a bit. Key x represents 0
value of a bit, and x represents 1 value of a bit.
Keys representing complementary bits need not be complements
of each other.
If the id of a receiver is 000, then it gets keys x0’ x1 , x2.
A receiver with id 001 gets keys x0’ x1 , x2.
In addition every member has a session key for
encrypting/decrypting the message.
When a receiver leaves, a new session key is sent
encrypted with the keys which represent the
complement of the id of the leaving receiver.
The departing receiver does not have any of the keys,
But any other receiver have at least one of the keys.
For example, if 000 departs, then the session key is
encrypted with x0, x1 , x2. Let the encryption of
new key with key Ki be Mi , then M0 M1 M2 are
transmitted.
The keys held by the departing receiver must also be
changed.
For example, keys x0’ x1 , x2 must be changed.
New Key Kn = f(new session key, old key Kn)
Rekeying encryption/decryption has O(log n)
complexity as before.
There are O(log n) keys in the system.
This method is particularly efficient for
simultaneous revocation of multiple receivers
Typically, rekeying is not done every time a receiver
departs, but at intervals. In regular intervals, quite a few
receivers may depart.
A simple solution is to multicast the new key with all
keys corresponding to each member.
For example, let 000 and 111 depart.
Six encrypted versions are sent, one corresponding to each
existing member.
The version corresponding to 001 is successively encrypted
by x0’ x1 , x2.
Each version can be decrypted by the targetted member
only, and no version can be decrypted by expelled
members.
However there is a lower complexity scheme.
The ids of each member can be represented by a boolean
function, (001 is x0x1x2).
Keys should be used such that the function for each
remaining member evaluates to 1, and that for each
departing member is 0.
The minimum number of encryptions required
for that can be found by a boolean function
minimization.
Karnaugh map techniques can be used.
However, this scheme is not collusion
resistant.
Receivers can group to fool the system.
Message Authentication
Suppose there is just one key used by all members
in the system to authenticate themselves.
Clearly, the receiver can not tell which member in the
group is the source. It knows whether a message is
sent by a group member or not by checking the MAC
value, but does not know which member sends it.
A simple solution is that each member has its own key,
and computes MAC with its individual key. A receiver
can compute MACs with all keys of group members.
Only the one computed with the correct senders key
matches the MAC.
Again, there is the usual scalability problem, as each
member needs to maintain n keys.
The paper by Canetti et al (INFOCOM 2000) suggests a
scheme where one needs to store only k keys if there are
at most k corrupt users.
It is assumed that k corrupt users try to put together
their keys to get the key of any one sender, and then use
it to generate the MAC so as to fool the receivers.
Each user is given a set of random keys.
The sender has all keys.
The composition of the keys are such that all the keys
of a user is not a subset of the keys of any group of k
users, with very high probability.
A sender adds MACs computed by every key.
A receiver checks the MAC with each of its keys.
It rejects the message unless all MACs match.
Since its keys are not subset of those of the colluding
users, colluding users will not be able to fool the
receiver (with very high probability). Why?
We need O(k/q) keys overall,
k is the number of corrupt users
q is the tolerable collusion success probability.
Download