Re: Re: Re: [ssm] another last call for draft-ietf-ssm-arch

> Date: Sat, 8 Mar 2003 16:32:13 +0200 (EET)
> From: Pekka Savola <pekkas@netcore.fi>
> Cc: ssm@ietf.org, <bkhabs@nc.rr.com>
>
> > > ==> should one mention again the fact that IPv4 admin scoping is to be done
> > > differently for SSM if it is requested?
> > 
> > Sure, we could more or less repeat the text from 4.3 again in the
> > Security Considerations, although part of why I didn't mention it
> > there is that the Security Considerations section of RFC 2365 (The
> > admin-scoping RFC) is very clear that they administrative scoping
> > should not be used as a security measure.  (Although I think in
> > practice people use it that way often enough.)  So I'm having a hard
> > time figuring out what the message should be on this point.
> > 
> >   Perhaps something to the effect of:
> > 
> >   Admin-Scoping is not a security measure, but in
> >   case you are using it as one anyway, remember that SSM doesn't 
> >   have an admin-scoped range.
> > 
> > (obviously not this exact text.)  If you have some specific ideas for
> > text, that would help.
> 
> Yeah, it is used too much as a rough security mechanism, so I think some
> text is would be good.  What you say above looks quite good, perhaps like:
> 
> Administrative scoping should not relied upon as a security measure
> [ADMIN-SCOPE]; however, in many cases it is at least a part of security
> solutions.  It should be noted that no administrative scoping exists for
> IPv4 source-specific multicast.  An alternative approach is to configure
> manual access-lists to create such scoping if necessary.

This text looks pretty good to me.  I will add it to the Security
Considerations section, barring any objects.

-Hugh
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm

Re: Re: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24