[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SAIDs and multicasting
Sorry that I haven't been able to comment sooner; unfortunately my employer
insisted that I get a product out the door first ;-). I've just been going
through the past several weeks of the mailing list discussions, and am starting
to read (or reread, as the case may be) some of the specs, so please bear with me.
W.R.T. the issue of multicast traffic and security associations, I've now seen
three possible "classes" of traffic for a given multicast group (e.g. where
the traffic shares the same address), where each class has a different delivery
scope. This is in the context of multicast traffic that can be originated
by end systems, not in the context of multicast traffic originated by
intermediate systems, e.g. route updates. In my opinion, this is a
problem of more than the "classification", as it were, of the types of
traffic between two individual systems.
a. Local network only. If a host wants to become a member of a multicast
group, a registration request is sent to the local multicast router, using
the destination address of the desired multicast group. This information
needs to be decrypted and retained by the local router. If the local
router can't see these packets, the host systems can't see their
multicast traffic. And, in the context of the protocol, the other hosts
on that local network also need to be able to see these packets, in order
for them to "listen before sending" to keep from bombarding the network
with duplicate membership requests. [The protocol only cares about the
existance of *someone* on the local network that wants the traffic, it
doesn't care about whom or how many systems want it.]
b. The group of "end systems". If a host wants to send traffic (e.g.
application data) to the multicast group, the data is sent using the
destination address of the desired multicast group. This information is
eventually sent to the end systems throughout the multicast tree. [This
traffic is commonly UDP traffic, but there are those implementors who
actually *care* that someone or someones are out there listening and who
choose to write something more robust (read proprietary) to sit on top
of the IP multicast delivery service.]
c. The intermediate network routers. In the case of resource reservation
for a multicast "session" from a particular source system, the equivalent
of a path setup message is sent from the source system throughout the
multicast tree. The intervening routers that handle resource reservation
must have the capability to intercept and read these flow descriptors (to
use an RSVP term).
As I work for a router vendor, the requirement to quickly distinguish
between which packets need to be intercepted by the router for decryption
(a and c above) and which need to be blindly forwarded (b above) is
important. The fewer bits one has to look at, the better.
I've been wrestling with how separate security associations could be
*identified* and set up for these diverse classes of traffic, short of
reserving SAIDs for certain types of traffic or forcing some sort
of "scope of control" on the SAIDs. Apart from distingishing between
types of traffic addressed to a single multicast address (which can be
provided implicitly by the use of different SAIDs), I don't think there
is a desire for everyone, *routers included*, to be a part of the same
security association for the application-specific traffic between the end
systems. It may also not be desirable for other end systems to be in the
same security association as the intermediate routers for the resource
reservation message distribution. [I say this while thinking about
"limiting exposure", but I'm also not fully sure how to truly prevent
excess exposure even if separate security associations were available.]
How would a dynamic assignment of SAIDs come together? To visit a topic
which has been mentioned in the past, this becomes an issue of "what party
is responsible for the security association?" in the case of a multicast
group. In the context of a router, multicast groups are dynamic and
ownerless. "sd" is something that allows *people* to reserve group slots,
but this is in the context of an application. If a router didn't have to
worry about security, it would have no need to figure out who "owned" a
group. Of course, all systems will have to go to some repository to obtain
certain certificate/key information, but the management of that
information in the context of a multicast group is important. [How would
we name such things in a central repository?]
Aside from that, the thought of having to decrypt and reencrypt these flow
descriptor packets (or make copies of the encrypted packets) on a per-hop
basis through a multicast tree gives me a headache ;-(.
For serious environments, resource reservation will have to be integrated
with multicasting. The Mbone may even need it before the next Stones'
concert ;-).
I'm doing some additional research on some related scoping issues, such as
the administrative scoping of multicast groups, so this list isn't
necessarily complete. [How does this scoping get identified and/or meshed
with the key/certificate server?] However, I wanted to get this out on the
table for discussion.
Comments and suggestions are welcome. - C
=================================================================
Cheryl Madson
Senior Engineer, Router Protocol Development
Bay Networks, Inc.
2 Federal St., Billerica, MA 01821
cmadson@baynetworks.com