Re: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...]

Hugh Holbrook <> Wed, 12 March 2003 20:21 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id PAA20605 for <>; Wed, 12 Mar 2003 15:21:21 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h2CKZRS10975 for; Wed, 12 Mar 2003 15:35:27 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2CKZRO10972 for <>; Wed, 12 Mar 2003 15:35:27 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA20550 for <>; Wed, 12 Mar 2003 15:20:49 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h2CKZ2O10952; Wed, 12 Mar 2003 15:35:02 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2CKYfO10925 for <>; Wed, 12 Mar 2003 15:34:41 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA20517 for <>; Wed, 12 Mar 2003 15:20:03 -0500 (EST)
Received: from ( []) by (8.12.6/8.12.6) with ESMTP id h2CKM5hs018554; Wed, 12 Mar 2003 12:22:11 -0800 (PST)
Received: by (Postfix, from userid 500) id 6AA9510B7A7; Wed, 12 Mar 2003 12:17:41 -0800 (PST)
From: Hugh Holbrook <>
To: Pekka Savola <>
Cc: Hugh Holbrook <>, Brian Haberman <>,
In-reply-to: <>
Subject: Re: Re: Re: [ssm] what to say about scoping for v6 [was ...last call...]
Message-Id: <>
Date: Wed, 12 Mar 2003 12:17:41 -0800
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET)
> From: Pekka Savola <>
> Cc: Brian Haberman <>, <>
> On Wed, 12 Mar 2003, Hugh Holbrook wrote:
> > > One should note that the use of IPv6 scoped addresses either in S or G may
> > > cause significant complexities, for example regarding mismatching scopes
> > > between S and G or regarding forwarding decisions for a scoped (S,G).  
> > > The implications of scoped addresses are described in other documents
> > 
> > Isn't the scoping behavior simply that the most restrictive (smallest)
> > scope applies.  A packet is forwarded neither across a source-scope
> > boundary nor across a destination-scope boundary.  Unless I'm missing
> > something, this actually sounds rather uncomplicated to me.  Is there
> > something that makes this tricky?
> At the moment, in practise (=implementation), everything related to
> scoping is *undefined*, it seems to me.
> How your SSM-enabled router will/would react now, or in 1-2 years is a 
> complete question mark.

Perhaps I'm not creative enough, but I can't imagine any
implementation of scoped addresses that would not apply scope limits
to both the source and destination.

> > Is there something about this that makes it a Security Considerations
> > issue?
> Yes, but only slightly: if people use e.g. site-local addresses as a
> security measure, and use SSM with like (<site-local>, global-scope-SSM)  
> -- for whatever reason, e.g. the use of the same application (and
> subsequent G) both site-locally and globally, the forwarding of such
> multicasts might *NOT* be limited to your site-local S scope.  This is an
> uncertainty as the implementation is unclear.

I don't dispute that implementations are not complete, but I can't see
how the IETF could endorse a scheme in which a join for a site-local
address S would allowed to be routed through a scoped boundary for S.
S refers to two totally diferent hosts on the two sides of the scope
boundary, so it's like sending the join to the wrong host.

In fact, I would be ok with putting in text saying that for SSM joins
and data, the scope boundaries MUST be applied to the source address
in addition to the destination address.

> On the hindsight, the text I proposed above seems better fit to some other 
> section, and something different might be more applicable to security 
> considerations, like:
>   Note that when forwarding or processing SSM, the scope of both S and G 
>   may have to be considered [SCOPED-ARCH]; in particular, if the unicast 
>   scope of S is smaller than respective multicast scope of G, the packets 
>   might end up forwarded outside of the scope of S.  Therefore, limited 

I would prefer not to say this because I think it is not likely to
ever be allowed.  I'd be happy saying just that "scopes should not be
used as a security mechanism..."  and leaving it at that.  I think
it's overkill to say that limited scope addresses must be avoided with
SSM, because I think they work fine as long as boundaries are applied
to the source as well.


>   scopes should be avoided and must not be used as a security mechanism.
> .. I wonder if that's any better ..
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
ssm mailing list