[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