RFC relevance of multicast

As per Relevance of the word multicast, we have this rfc below:

Network Working Group A.
Request for Comments: 1949 University College
Category: Experimental May 1996

Scalable Multicast Key

Status of this

This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

The benefits of multicasting are becoming ever-more apparent, and
use much more widespread. This is evident from the growth of
MBONE [1]. Providing security services for multicast, such as
integrity, authentication, and confidentiality, is
problematic since it requires securely distributing a group (session
key to each of a group's receivers. Traditionally, the
distribution function has been assigned to a central network entity
or Key Distribution Centre (KDC), but this method does not scale
wide-area multicasting, where group members may be widely-
across the internetwork, and a wide-area group may be
populated

Even more problematic is the scalable distribution of sender-
keys. Sender-specific keys are required if data traffic is to
authenticated on a per-sender basis

This memo provides a scalable solution to the multicast
distribution problem

NOTE: this proposal requires some simple support mechanisms, which
it is recommended here, be integrated into version 3 of IGMP.
support is described in Appendix B

1.

Growing concern about the integrity of Internet communication [13]
(routing information and data traffic) has led to the development
an Internet Security Architecture, proposed by the IPSEC
group of the IETF [2]. The proposed security mechanisms
implemented at the network layer - the layer of the protocol stack
which networking resources are best protected [3].

Ballardie Experimental [Page 1]

RFC 1949 Scalable Multicast Key Distribution May 1996

Unlike many network layer protocols, the Core Based Tree (CBT
multicast protocol [4] makes explicit provision for security; it
its own protocol header, unlike existing IP multicast
[10,11], and other recently proposed schemes [12].

In this document we describe how the CBT multicast protocol
provide for the secure joining of a CBT group tree, and how this
process can provide a scalable solution to the multicast
distribution problem. These security services are an integral
of the CBT protocol [4]. Their use is optional, and is dependent
each individual group's requirements for security. Furthermore,
use of the CBT multicast protocol for multicast key distribution
not preclude the use of other multicast protocols for the
multicast communication itself, that is, CBT need only be the
with which to distribute keys

Secure joining implies the provision for authentication, integrity
and optionally, confidentiality, of CBT join messages. The scheme
describe provides for the authentication of tree nodes (routers)
receivers (end-systems) as part of the tree joining process.
distribution (optional) is an integral part of secure joining

Network layer multicast protocols, such as DVMRP [7] and M-OSPF [9],
do not have their own protocol header(s), and so cannot provision
security in themselves; they must rely on whatever security
provided by IP itself. Multicast key distribution is not addressed
any significant degree by the new IP security architecture [2].

The CBT security architecture is independent of any
cryptotechniques, although many security services, such
authentication, are easier if public-key cryptotechniques
employed

What follows is an overview of the CBT multicasting. The
of our proposal in section 6.1 assumes the reader is
familiar with the CBT protocol. Details of the CBT architecture
protocol can be found in [7] and [4], respectively

2. Overview of BCT

CBT is a new architecture for local and wide-area IP multicasting
being unique in its utilization of just one shared delivery tree
group, as opposed to the source-based delivery tree approach
existing IP multicast schemes, such as DVMRP and MOSPF

A shared multicast delivery tree is built around several so-
core routers. A group receiver's local multicast router is
to explicitly join the corresponding delivery tree after receiving

Ballardie Experimental [Page 2]

RFC 1949 Scalable Multicast Key Distribution May 1996

IGMP [8] group membership report over a directly connected interface
A CBT join message is targeted at one of the group's core routers
The resulting acknowledgement traverses the reverse-path of the join
resulting in the creation of a tree branch. Routers along
branches are called non-core routers for the group, and there
a parent-child relationship between adjacent routers along a
of the same tree (group).

3. How the CBT Architecture Complements

The CBT architecture requires "leaf" routers to explicitly join a
tree. Hence, CBT is not data driven; the ack associated with a
"fixes" tree state in the routers that make up the tree. This so
called "hard state" remains until the tree re-configures,
example, due to receivers leaving the group, or because an
failure has occurred. The CBT protocol incorporates
enabling a CBT tree to repair itself in the event of the latter

As far as the establishment of an authenticated
distribution tree is concerned, DVMRP, M-OSPF, and PIM, are at
disadvan- tage; the nature of their "soft state" means a
tree only exists as long as there is data flow. Also,
implementing a multicast protocol that builds its delivery tree
on a reverse-path check (like DVMRP and PIM dense mode) cannot
sure of the previous-hop router, but only the interface a
packet arrived on

These problems do not occur in the CBT architecture. CBT's hard
approach means that all routers that make up a delivery tree know
their on-tree neighbours are; these neighbours can be
as part of delivery tree set-up. As part of secure tree set-up
neighbours could exchange a secret packet handle for inclusion in
CBT header of data packets exchanged between those neighbours
allowing for the simple and efficient hop-by-hop authentication
data packets (on-tree).

The presence of tree focal points (i.e. cores) provides CBT
with natural authorization points (from a security viewpoint) --
formation of a CBT tree requires a core to acknowledge at least
join in order for a tree branch to be formed. Thereafter
authorization and key distribution capability can be passed on
joining nodes that are authenticated

In terms of security, CBT's hard state approach offers
additional advantages: once a multicast tree is established,
state maintained in the routers that make up the tree does not
out or change necessarily to reflect underlying unicast topology
The security implications of this are that nodes need not be

Ballardie Experimental [Page 3]

RFC 1949 Scalable Multicast Key Distribution May 1996

to repeated authentication subsequent to a period of inactivity,
tree nodes do not need to re-authenticate themselves as a result
an underlying unicast topology change, unless of course, an
(node) failure has occurred

Hard-state protocol mechanisms are often thought of as being
fault tolerant than soft-state schemes, but there are pros and
to both approaches; we see here that security is one of the pros

4. The Multicast Key Distribution

We believe that multicast key distribution needs to be combined
group access control. Without group access control, there is no
in employing multicast key distribution, since, if there are no
restrictions, then it should not matter to whom multicast
is divulged

There are different ways of addressing group access control.
group access control we describe requires identifying one
member (we suggest in [14] that this should be the group initiator
who has the ability to create, modify and delete all or part of
group access control list. The enforcement of group access
may be done by a network entity external to the group, or by a
member

The essential problem of distributing a session (or group) key to
group of multicast receivers lies in the fact that some central
management entity, such as a key distribution centre (KDC) (A
Distribution Centre (KDC) is a network entity, usually residing at
well-known address. It is a third party entity whose
it to generate and distribute symmetric key(s) to peers, or
receivers in the case of multicast, wishing to engage in a "secure
communication. It must therefore be able to identify and
authenticate requestors of symmetric keys.), must authenticate
of a group's receivers, as well as securely distribute a session
to each of them. This involves encrypting the relevant message
times, once with each secret key shared between the KDC
corresponding receiver (or alternatively, with the public key of
receiver), before multicasting it to the group. (Alternatively,
KDC could send an encrypted message to each of the
individually, but this does not scale either.) Potentially, n may
very large. Encrypting the group key with the secret key (of
secret-public key pair) of the KDC is not an option, since the
key would be accessible to anyone holding the KDC's public key,
public keys are either well-known or readily available. In short
existing multicast key distribution methods do not scale

Ballardie Experimental [Page 4]

RFC 1949 Scalable Multicast Key Distribution May 1996

The scaling problem of secure multicast key distribution
compounded for the case where sender-specific keys need to
distributed to a group. This is required for sender-
authentication of data traffic. It is not possible to achieve per
sender authentication, given only a group session key

Recently a proposal has emerged, called the Group Key
Protocol (GKMP) [15]. This was designed for military networks,
the authors have demonstrated how the architecture could be
to a network like the Internet, running receiver-oriented
applications

GKMP goes a considerable way to addressing the problems of
key distribution: it does not rely on a centralised KDC, but
places the burden of key management on a group member(s). This is
approach adopted by the CBT solution, but our solution can take
distributed approach further, which makes our scheme that much
scalable. Furthermore, our scheme is relatively simple

The CBT model for multicast key distribution is unique in that it
integrated into the CBT multicast protocol itself. It offers
simple, low-cost, scalable solution to multicast key distribution.
describe the CBT multicast key distribution approach below

5. Multicast Security

The IP security architecture [2] introduces the concept of "
Associations" (SAs), which must be negotiated in advance during
key management phase, using a protocol such as Photuris [20],
ISAKMP [21]. A Security Association is normally one-way, so if two
way communication is to take place (e.g. a typical TCP connection),
then two Security Associations need to be negotiated. During
negotiation phase, the destination system normally assigns a
Parameter Index to the association, which is used, together with
destination address (or, for the sender, the sender's user-id)
index into a Security Association table, maintained by
communicating parties. This table enables those parties to index
correct security parameters pertinent to an association.
security association parameters include authentication algorithm
algorithm mode, cryptographic keys, key lifetime, sensitivity level
etc

The establishment of Security Associations (SA) for
communication does not scale using protocols like Photuris,
ISAKMP. This is why it is often assumed that a multicast group
be part of a single Security Association, and hence share a
SPI. It is assumed that one entity (or a pair of entities)
the SPI "by some means" (which may be an SA negotiation protocol

Ballardie Experimental [Page 5]

RFC 1949 Scalable Multicast Key Distribution May 1996

like [20] and [21]), which is then simply multicast, together
the SA parameters, to the group for subsequent use. However,
precludes multicast receivers from performing sender-specific
authentication; all a receiver can be sure of is that the sender
part of the multicast Security Association

We advocate that the primary core, either alone, or in
with the group initiator, establish the security parameters to
used in the group communication. These are distributed as part of
secure join process. Thereafter, individual senders can
their own key and security parameters to the group. In the case
the latter, there are two cases to consider

+ the sender is already a group member. In this case, the
can decide upon/generate its own security parameters, and multi
cast them to the group using the current group session key

+ the sender is not a group member. In this case, before
sender begins sending, it must first negotiate the
parameters with the primary core, using a protocol such as Pho
turis [20] or ISAKMP [21]. Once completed, the primary
multicasts (securely) the new sender's session key and
parameters to the group

Given that we assume the use of asymmetric
throughout, this scheme provides a scalable solution to
origin authentication

Sender-specific keys are also discussed in section 8.

6. The CBT Multicast Key Distribution

The security architecture we propose allows not only for the
joining of a CBT multicast tree, but also provides a solution to
multicast key distribution problem [16]. Multicast key
is an optional, but integral, part of the secure tree
process; if a group session key is not required, its distribution
be omitted

The use of CBT for scalable multicast key distribution does
preclude the use of other multicast protocols for the
multicast communication. CBT could be used solely for multicast
distribution -- any multicast protocol could be used for the
multicast communication itself

The model that we propose does not rely on the presence of
centralised KDC -- indeed, the KDC we propose need not be
to key distribution. We are proposing that each group have its

Ballardie Experimental [Page 6]

RFC 1949 Scalable Multicast Key Distribution May 1996

group key distribution centre (GKDC), and that the functions
provides should be able to be "passed on" to other nodes as they
the tree. Hence, our scheme involves truly distributed
distribution capability, and is therefore scalable. It does
require dedicated KDCs. We are proposing that a CBT primary
initially take on the role of a GKDC

6.1 Operational

When a CBT group is created, it is the group initiator'
responsibility to create a multicast group access control list (ACL
[14]. It is recommended that this list is a digitally
"document", the same as (or along the lines of) an X.509
[9], such that it can be authenticated. The group
subsequently unicasts the ACL to the primary core for the group.
communication is not part of the CBT protocol. The ACL's
signature ensures that it cannot be modified in transit
detection. If the group membership itself is sensitive information
the ACL can be additionally encrypted with the public key of
primary core before being sent. The ACL can be an "inclusion"
or an "exclusion" list, depending on whether group
includes relatively few, or excludes relatively few

The ACL described above consists of group membership (inclusion
exclusion) information, which can be at the granularity of hosts
users. How these granularities are specified is outside the scope
this document. Additionally, it may be desirable to restrict
distribution capability to certain "trusted" nodes (routers) in
network, such that only those trusted nodes will be given
distribution capability should they become part of a CBT
tree. For this case, an additional ACL is required
"trusted" network nodes

The primary core creates a session key subsequent to receiving
authenticating the message containing the access control list.
primary core also creates a key encrypting key (KEK) which is
for re-keying the group just prior to an old key exceeding its life
time. This re-keying strategy means that an active key is
likely to become compromised during its lifetime

The ACL(s), group key, and KEK are distributed to secondary cores
they become part of the distribution tree

Any tree node with this information can authenticate a
member, and hence, secure tree joining and multicast session
distribution are truly distributed across already authenticated
nodes

Ballardie Experimental [Page 7]

RFC 1949 Scalable Multicast Key Distribution May 1996

6.2 Integrated Join Authentication and Multicast Key

For simplicity, in our example we assume the presence of
internetwork-wide asymmetric key management scheme, such as
proposed in [17]. However, we are not precluding the use
symmetric cryptographic techniques -- all of the security services
are proposing, i.e. integrity, authentication, and confidentiality
can all be achieved using symmetric cryptography, albeit a
expense, e.g. negotiation with a third party to establish
secret keys. For these reasons, we assume that a public (asymmetric
key management scheme is globally available, for example, through
Domain Name System (DNS) [17] or World Wide Web [18].

NOTE: given the presence of asymmetric keys, we can assume
signatures provide integrity and origin authentication
combined

The terminology we use here is described in Appendix A. We
define some additional terms here

+ grpKey: group key used for encrypting group data traffic

+ ACL: group access control list

+ KEK: key encrypting key, used for re-keying a group with a
group key

+ SAparams: Security Association parameters, including SPI

+ group access package (grpAP): sent from an already verified
node to a joining node

[token_sender, [ACL]^SK_core, {[grpKey, KEK
SAparams]^SK_core}^PK_origin-host
{[grpKey, KEK, SAparams]^SK_core}^PK_next-hop]^SK_

NOTE: SK_core is the secret key of the PRIMARY core

As we have already stated, the elected primary core of a CBT
takes on the initial role of GKDC. In our example, we assume that
group access control list has already been securely communicated
the primary core. Also, it is assumed the primary core has
participated in a Security Association estabishment protocol [20,21],
and thus, holds a group key, a key-encrypting key, and an SPI

NOTE, there is a minor modification required to the CBT
[4], which is as follows: when a secondary core receives a join
instead of sending an ack followed by a re-join to the primary

Ballardie Experimental [Page 8]

RFC 1949 Scalable Multicast Key Distribution May 1996

the secondary forwards the join to the primary; the ack
from the primary (or intermediate on-tree router) back to the
origin. All routers (or only specific routers) become GKDCs
they receive the ack

We now demonstrate, by means of an example, how CBT routers join
tree securely, and become GKDCs. For clarity, in the example, it
assumed all routers are authorised to become GKDCs, i.e. there is
trusted-router ACL

In the diagram below, only one core (the primary) is shown.
process of a secondary joining the primary follows exactly what
describe here

In the diagram, host h wishes to join multicast group G. Its
multicast router (router A) has not yet joined the CBT tree for
group G

b b b-----
\ | |
\ | |
b---b b------
/ \ / KEY....
/ \/
b C C = Core (Initial Group Key Dist'n Centre
/ \ A, B, b = non-core
/ \
/ \ ======= LAN where host h is
B b------
\
\ NOTE: Only one core is shown, but
host h A a CBT tree is likely to comprise several
o |
=====================

Figure 1: Example of Multicast Key Distribution using

A branch is created as part of the CBT secure tree joining process
as follows

+ Immediately subsequent to a multicast application starting up
host h, host h immediately sends an IGMP group
report, addressed to the group. This report is not
(see Appendix B), like other IGMP report types, and it
includes the reporting host's token, which is digitally

h --> DR (A): [[token_h]^SK_h, IGMP group membership report

Ballardie Experimental [Page 9]

RFC 1949 Scalable Multicast Key Distribution May 1996

(A host's token differs in two respects compared with
defined in [9]. To refresh, a token assists a recipient in
verification process, and typically contains: recipient'
unique identity, a timestamp, and a pseudo-random number.
token is also usually digitally signed by its originator
Firstly, A host's token does not contain the
recipient's identity, since this token may need to
several CBT routers before reaching a GKDC. A host does
actually know which router, i.e. GKDC, will
acknowledge the join that it invoked. Secondly, the host'
token is digitally signed -- this is usual for a token
However, tokens generated by routers need not be
digitally signed because the JOIN-REQUESTs and JOIN-ACKs
carry them are themselves digitally signed.)

+ In response to receiving the IGMP report, the local
router (router A) authenticates the host's enclosed token.
successful, router A formulates a CBT join-request, whose
is core C (the primary core). Router A includes its own token
the join, as well as the signed token received from host h.
join is digitally signed by router A

NOTE 1: router A, like all CBT routers, is configured with
unicast addresses of a prioritized list of cores, for
group sets, so that joins can be targeted accordingly

NOTE 2: the host token is authenticated at most twice, once
the host's local CBT router, and once by a GKDC. If the
router is already a GKDC, then authentication only happens once
If the local router is not already a GKDC, a failed authentica
tion check removes the overhead of generating and sending a
join-request

Router A unicasts the join to the best next-hop router on
path to core C (router B).

A --> B: [[token_A], [token_h]^SK_h, JOIN-REQUEST]^SK_

+ B authenticates A's join-request. If successful, B repeats
previous step, but now the join is sent from B to C (the pri
mary, and target), and the join includes B's token. Host h'
token is copied to this new join

B --> C: [[token_B], [token_h]^SK_h, JOIN-REQUEST]^SK_

+ C authenticates B's join. As the tree's primary
point (and GKDC), C also authenticates host h, which
the join process. For this to be successful, host h must

Ballardie Experimental [Page 10]

RFC 1949 Scalable Multicast Key Distribution May 1996

included in the GKDC's access control list for the group. If
is not in the corresponding access control list,
is redundant, and a join-nack is returned from C to B,
eventually reaches host h's local DR, A

Assuming successful authentication of B and h, C forms a
access package (grpAP), encapsulates it in a join-ack, and digi
tally signs the complete message. C's token, host h's
token, a signed ACL, and two (group key, KEK) pairs are
in the group access package; one for the originating host,
one for the next-hop CBT router to which the join-ack is des
tined. Each key pair is digitally signed by the issuer, i.e.
primary core for the group. The host key pair is encrypted
the public key of the originating host, so as to be only deci
pherable by the originating host, and the other key pair
encrypted using the public key of the next-hop router to
the ack is destined -- in this case, B. Host h's token is
by the router connected to the subnet where h resides so as
be able to identify the new member

C --> B: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_

+ B authenticates the join-ack from C. B extracts its
key pair from the group access package, decrypts it, authenti
cates the primary core, and stores the key pair in
form, using a local key. B also verifies the digital
included with the access control list. It subsequently
the ACL in an appropriate table. The originating host key
remains enciphered

The other copy of router B's key pair is taken and
using its secret key, and immediately enciphered with the
key of next-hop to which a join-ack must be passed, i.e.
A. A group access package is formulated by B for A. It
B's token, the group ACL (which is digitally signed by the pri
mary core), a (group key, KEK) pair encrypted using the
key of A, and the originating host's key pair,
encrypted. The group access package is encapsulated in a join
ack, the complete message is digitally signed by B, then for
warded to A

B --> A: [[token^h]^SK_h, grpAP, JOIN-ACK]^SK_

+ A authenticates the join-ack received from B. A copy of
encrypted key pair that is for itself is extracted from
group access package and deciphered, and the key issuer (
core) is authenticated. If successful, the enciphered key
is stored by A. The digital signature of the included

Ballardie Experimental [Page 11]

RFC 1949 Scalable Multicast Key Distribution May 1996

control list is also verified, and stored in an
table. The key pair encrypted for host h is extracted from
group access package, and is forwarded directly to host h,
is identified from the presence of its signed token.
receipt, host h decrypts the key pair for subsequent use,
stores the SA parameters in its SA table

A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h

Going back to the initial step of the tree-joining procedure, if
DR for the group being joined by host h were already established
part of the corresponding tree, it would already be a GKDC. It
therefore be able to directly pass the group key and KEK to host
after receiving an IGMP group membership report from h

A --> h: [[token^h]^SK_h, {grpKey, KEK, SAparams}^PK_h

If paths, or nodes fail, a new route to a core is gleaned as
from the underlying unicast routing table, and the re-joining
(see [4]) occurs in the same secure fashion

7. A Question of

The security architecture we have described, involving multicast
distribution, assumes that all routers on a delivery tree are
and do not misbehave. A pertinent question is: is it reasonable
assume that network routers do not misbehave and are
protected from malicious attacks

Many would argue that this is not a reasonable assumption,
therefore the level of security should be increased to discount
threat of misbehaving routers. As we described above,
periodically decrypt key pairs in order to verify them, and/or re
encrypt them to pass them on to joining neighbour routers

In view of the above, we suggest that if more stringent security
required, the model we presented earlier should be slightly
to accommodate this requirement. However, depending on the
requirement and perceived threat, the model we presented may
acceptable

We recommend the following change to the model already
above, to provide a higher level of security

All join-requests must be authenticated by a core router, i.e. a
arriving at an on-tree router must be forwarded upstream to a core
the join is identified as being a "secure" join (as indicated by
presence of a signed host token).

Ballardie Experimental [Page 12]

RFC 1949 Scalable Multicast Key Distribution May 1996

The implication of this is that key distribution capability
with the core routers and is not distributed to non-core
whose joins have been authenticated. Whilst this makes our
somewhat less distributed than it was before, the concept of
distribution being delegated to the responsibility of
groups remains. Our scheme therefore retains its attractiveness
centralized schemes

8. The Multicast Distribution of Sender-Specific

Section 5, in part, discussed the scalable distribution of sender
specific keys and sender-specific security parameters to a
group, for both member-senders, and non-member senders. If
cryptotechniques are employed, this allows for sender-specific
authentication

For member-senders, the following message is multicast to the group
encrypted using the current group session key, prior to the
sender transmitting data

{[sender_key, senderSAparams]^SK_sender}^group_

Non-member senders must first negotiate (e.g. using Photuris
ISAKMP) with the primary core, to establish the security
parameters, and the session key, for the sender. The sender,
course, is subject to access control at the primary. Thereafter,
primary multicasts the sender-specific session key, together
sender's security parameters to the group, using the group's
session key. Receivers are thus able to perform
authentication

Photuris or
1. sender <----------------------> primary

2. {[sender_key, senderSAparams]^SK_primary}^group_

For numerous reasons, it may be desirable to exclude certain
members from all or part of a group's communication. We cannot
any solution to providing this capability, other than requiring
keys to be distributed via the establishment of a newly-formed
(CBT tree).

Ballardie Experimental [Page 13]

RFC 1949 Scalable Multicast Key Distribution May 1996

9.

This memo has offered a scalable solution to the multicast
distribution problem. Our solution is based on the CBT
and protocol, but this should not preclude the use of other
protocols for secure multicast communication subsequent to
distribution. Furthermore, virtually all of the functionality
in our solution is in-built in the secure version of the
protocol, making multicast key distribution an optional, but
part, of the CBT protocol

Ballardie Experimental [Page 14]

RFC 1949 Scalable Multicast Key Distribution May 1996

Appendix

The following terminology is used throughout this document

+ PK_A indicates the public key of entity A

+ SK_A indicates the secret key of entity A. The secret key can
used by a sender to digitally sign a digest of the message
which is computed using a strong, one-way hash function, such
MD5 [19].

+ Unencrypted messages will appear enclosed within square brack
ets, e.g. [X, Y, Z]. If a message is digitally signed, a super
script will appear outside the right hand bracket,
the message signer. Encrypted messages appear enclosed
curly braces, with a superscript on the top right hand side out
side the closing curly brace indicating the encryption key, e.g
{X, Y, Z}^{PK_A}.

+ a token is information sent as part of a strong
exchange, which aids a receiver in the message verification pro
cess. It consists of a timestamp, t (to demonstrate
freshness), a random, non-repeating number, r (to
message originality), and the unique name of the
recipient (to demonstrate that the message is indeed
for the recipient). A digital signature is appended to
token by the sender (which allows the recipient to
the sender). The token is as follows

[t_A, r_A, B]^{SK_A} -- token sent from A to B

+ A --> B: -- denotes a message sent from A to B

Appendix

The group access controls described in this document require a
simple support mechanisms, which, we recommend, be integrated
version 3 of IGMP. This would be a logical inclusion to IGMP,
that version 3 is expected to accommodate a variety of
requirements, including security. Furthermore, this would remove
need for the integration of a separate support protocol in hosts

To refresh, IGMP [8] is a query/response multicast support
that operates between a multicast router and attached hosts

Whenever an multicast application starts on a host, that
generates a small number of IGMP group membership reports in
succession (to overcome potential loss). Thereafter, a host

Ballardie Experimental [Page 15]

RFC 1949 Scalable Multicast Key Distribution May 1996

issues a report in response to an IGMP query (issued by the
multicast router), but only if the host has not received a report
the same group (issued by some other host on the same subnet)
the host's IGMP random response timer expires. Hence, IGMP
incorporates a report "suppression" mechanism to help avoid "
storms" on a subnet, and generally conserve bandwidth

We propose that IGMP accommodate "secure joins" - IGMP reports
indicate the presence of a digitally signed host (or user) token
These report types must not be suppressible, as is typically the
with IGMP reports; it must be possible for each host to
report its group presence to the local router, since a GKDC bases
group access control decision on this information

This functionality should not adversely affect
compatibility with earlier versions of IGMP that may be present
the same subnet; the new reports will simply be ignored by older
versions, which thus continue to operate normally

Security

Security issues are discussed throughout this memo

Author's

Tony Ballardie
Department of Computer Science
University College London
Gower Street
London, WC1E 6BT
ENGLAND, U.K

Phone: ++44 (0)71 419 3462
EMail: A.Ballardie@cs.ucl.ac.

[1] MBONE, The Multicast BackbONE; M. Macedonia and D. Brutzman
available from http://www.cs.ucl.ac.uk/mice/mbone_review.html

[2] R. Atkinson. Security Architecture for the Internet Protocol;
1825, SRI Network Information Center, August 1995.

[3] D. Estrin and G. Tsudik. An End-to-End Argument for Network Layer
Inter-Domain Access Controls; Journal of Internetworking & Experience
Vol 2, 71-85, 1991.

Ballardie Experimental [Page 16]

RFC 1949 Scalable Multicast Key Distribution May 1996

[4] A. Ballardie, S. Reeve, N. Jain. Core Based Tree (CBT) Multicast -
Protocol Specification; Work in Progress, 1996. Available from
ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-spec-XX.txt

[5] R. Atkinson. IP Authentication Header; RFC 1826, SRI
Information Center, August 1995.

[6] R. Atkinson. IP Encapsulating Security Payload; RFC 1827, SRI Net
work Information Center, August 1995.

[7] A. Ballardie. Core Based Tree (CBT) Multicast Architecture;
in progress, 1996. Available from
ftp://cs.ucl.ac.uk/darpa/IDMR/draft-ietf-idmr-cbt-arch-XX.

[8] W. Fenner. Internet Group Management Protocol, version 2 (IGMPv2),
Work in progress, 1996.

[9] CCITT Data Communication Networks Directory (Blue Book). Recommen
dation X.509, Authentication Framework

[10] T. Pusateri. Distance-Vector Multicast Routing Protocol (DVMRP
version 3. Working draft, February 1996.

[11] J. Moy. Multicast Extensions to OSPF; RFC 1584, SRI
Information Center, March 1994.

[12] D. Estrin et al. Protocol Independent Multicast, protocol specif
ication; Work in progress, January 1996.

[13] R. Braden, D. Clark, S. Crocker and C. Huitema. Security in
Internet Architecture. RFC 1636, June 1994.

[14] A. Ballardie and J. Crowcroft. Multicast-Specific
Threats and Counter-Measures. In ISOC Symposium on Network and Distri
buted System Security, February 1995.

[15] H. Harney, C. Muckenhirn, and T. Rivers. Group Key
Protocol (GKMP) Architecture. Working draft, 1994.

[16] N. Haller and R. Atkinson. RFC 1704, On Internet Authentication
SRI Network Information Center, October 1994.

[17] C. Kaufman and D. Eastlake. DNS Security Protocol Extensions
Working draft, January 1996.

[18] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, A
Secret. The World Wide Web. Communications of the ACM, 37(8):76-82,
August 1994.

Ballardie Experimental [Page 17]

RFC 1949 Scalable Multicast Key Distribution May 1996

[19] R. Rivest. RFC 1321, The MD-5 Message Digest Algorithm, SRI Net
work Information Center, 1992.

[20] P. Karn, W. Simpson. The Photuris Session Key Management Proto
col; Working draft, January 1996.

[21] D. Maughan, M. Schertler. Internet Security Association and
Management Protocol; Working draft, November 1995.

Ballardie Experimental [Page 18]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX