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

[Hugh Holbrook <[e-mail]>]

> > > So I'm trying to convert this discussion about scoping to concrete
> > > text.  Here's what the doc currently says about v6 scoped addresses.
> > > 
> > >   For IPv6, administratively scoped SSM addresses are created by choosing
> > >   an appropriate scope identifier for the SSM destination address.  Normal
> > >   IPv6 multicast scope boundaries are applied to traffic sent to an SSM
> > >   destination address.
> > > 
> > > I note that this paragraph is confusing because it says you can make a
> > > "scoped SSM addresses" when what it should say is "scoped SSM channel
> > > addresses".  Here is proposed text to incorporate what I think Pekka
> > > is suggesting.
> > > 
> > >   For IPv6, administratively scoped SSM channel addresses are created
> > >   by choosing an appropriate scope identifier for the SSM destination
> > >   address.  Normal IPv6 multicast scope boundaries are applied to
> > >   traffic sent to an SSM destination address, including any relevant
> > >   boundaries applied to both the source and destination address.
> > > 
> > > Question 1: Do you accept the above text?  I'm not sure I captured the
> > > issue, so I'd appreciate a better alternative if you see one.
> > 
> > I am ok with it, but I didn't raise the issue either.  So, I would
> > like Pekka's assessment before we declare victory. :)
> 
> I can live with it, with the inclusion of the reference.

Done.  I massaged the English of the last sentence to make it a bit
more direct, without changing the wording.  The text now reads

For IPv6, administratively scoped SSM channel addresses are created by
choosing an appropriate scope identifier for the SSM destination
address.  Normal IPv6 multicast scope boundaries [SCOPINGV6] are
applied to traffic sent to an SSM destination address.  Boundaries are
applied to both the source and destination address.

...

[SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address Architecture",
Work in Progress.

> However, I'd like a statement in the security considerations, perhaps 
> along the lines of:
> 
> 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
> [REF:SCOPED-ARCH]

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?

Is there something about this that makes it a Security Considerations
issue?

> > > Question 2: If not, is there an appropriate reference for "Normal IPv6
> > > multicast scope boundaries," or is it preferable to intentionally
> > > leave the document without a reference?
> > 
> > I don't see a problem with having an informative reference for the
> > scoped addr arch doc.
> 
> I think an informational reference is necessary. (Actually, it should be 
> "almost" normative, but we don't want to have SSM arch get stuck due to 
> scoped addrarch, so..)

Ok.   I'm fine with referring to that document, as above.

> > > Question 3: Should we add text to clarify the "embedded address" text
> > > in RFC3306.  I can think of three options:
> > > 
> > > Either prohibit it:
> > > 
> > >   For IPv6, senders MUST ensure that the scope of a channel
> > >   destination address does not exceed the scope of the channel source
> > >   address.
> > > 
> > > Or allow it:
> > > 
> > >   For IPv6, the scope of a channel destination address MAY exceed the
> > >   scope of the channel source address.  Normal forwarding rules for
> > >   scoped traffic apply to a packet sent to such a channel.  Normal
> > >   multicast scoping rules apply for any routing protocol messages
> > >   (e.g., "joins") referring to such a channel.
> > > 
> > > Or say nothing:
> > > 
> > > I am inclined to do the latter, and I think this is what both of you
> > > are saying.  Am I right?
> > 
> > I agree, the latter works for me.  
> 
> I'm ok with leaving the text out.  It is up to RFC3306bis and 
> clarification of it in scoped addrarch.

Ok.  Agreed on that.

> > Should we add a reference to RFC
> > 3484 as a note on how the address selection could occur?
> 
> I'm ok with it but don't see where it would fit nicely.

Ok.  The resolution is to not say anything about address selection
rules for SSM.

Thanks.

> -- 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ssm
_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm