Subject: Re: How can we block Novell 5.0 SLP multicast using only one RP?

From: James Kempf <[email-masked]>
Date: Fri, 4 Jun 1999 09:02:07 -0700 (PDT)

>2. Use a SLP Directory Agent.  This basically replaces the multicast traffic 
with unicast traffic to the DA.  NEGATIVE: Workstations still see all the 
services, they just unicast the to DA instead of multicast.
>
>3. Use scopes.  If each organization had its own scope, it would ask for and 
receive only the services within its scope.  NEGATIVE: Ugh. If you don't need to 
use scopes for any other reason, then this is probably not a good reason to get 
into the complications that scopes can cause you.  You may end up having to 
configure each workstation and server with the scope to use, in which case it 
would be simpler to do #1.

Actually, these two solutions in tandem are *exactly* the way to solve the
problem. As I understand it, the problem seems to be that users are
seeing services they "shouldn't". This is precisely the problem for which scopes 
were designed. They were designed to provision services so that users
only see the services they need. Using the DHCP options (which I
believe Netware 5 supports) should avoid having to configure each
workstation and server with a scope (provided the organization uses
DHCP).

Similarly, if the network is large enough that multicasts are propagating
out of the immediate organization onto the backbone, as the original
email indicated, then it is probably time to deploy a DA in the organization.
If scopes are deployed with DAs, the DAs will only see the services
in those scopes.

Unfortunately, SLPv1 has a number of flaws in the way it handles scopes. 
If scopes and DAs are being deployed, then they should be deployed
consistently, i.e. no unscoped DAs. Otherwise, if there are any unscoped DAs, 
all unscoped services will show up in them. SLPv2 is much better at handling 
scopes.

		jak

---

From: [email-masked]
Date: Fri, 04 Jun 1999 20:01:12 +0200

> seeing services they "shouldn't".

Yes and no. If I simply wanted to stop users in organization A from
seeing SLP announcements from organizations B, C, etc (ie. outside A),
I can use a normal packet filter in organization A's border router, and
filter out 224.0.1.22/ 224.0.1.35 from the *incoming* traffic.

The problem is - I really don't want these announcements getting *out*
from organizations B, C, etc to the global Internet in the first place. 
And this is the hard problem (which cannot be solved by a normal packet
filter), because this traffic is *tunneled* from organizations B, C etc
to the Rendezvous Point (due to PIM-SM).

Steinar Haug, Nethelp consulting, [email-masked]