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

From: Hugh Holbrook <[email-masked]>
Date: Sun, 2 Mar 2003 02:03:37 -0800 (PST)

Hi, folks.  

I've just submitted draft-ietf-ssm-arch-02.txt to the internet draft
repository.  Until it shows up, you can retrieve it from

    http://sith.maoz.com/SSM/draft-ietf-ssm-arch-02.txt

There were enough changes to the draft that I'd like to do one more
working group last call.  I've included below the list of changes from
my last mail.  The only other change was that I changed a SHOULD (for
ignoring non-source-specific requests) in section 8 to a MUST, to be
consistent with Section 5.2.

I would particularly appreciate any comments on the Security
Considerations section, as this has seen the least review.

This last call expires March 24th.

-Hugh
--------------------------------

- [pavlin] Added text: OS API should return an error for a (*,G)
  request on an SSM address.

- [pavlin] Added a note about limitations of SSM.  (1) Any
  multi-source aspect apps must be implemented in the application
  layer.  (2) SSM does not support network-layer resource discovery.

- [pekka/brian] Added clarification about the SSM address range
        FF3x::/32 is reserved for SSM
           P=1 and T=1 and plen=0 is required.
        Thus, FF3x::/96 is the actual range today because 
           network prefix field must be zero
        But we leave open the possibility of putting something else in the
           network prefix field.

- [pavlin] Changed erroneous FF2x:: to FF3x::

- [pekka] New text on administrative scoping to describe admin-scoping
  in v6 and to clarify that there is none for IPv4.

- [pekka] New text on source routing: A router SHOULD NOT allow
  source-routing to an SSM addr; MAY have a config option to allow it

- [me/bweis/mbaugher] 
  Add security considerations text describing the IPSec/SSM issue.

- Minor things:

  - [pavlin] Use consistent capitalization on v6 addresses
  - [me] Use consistent capitalization of Source-Specific
  - [pavlin] id-nits
    - Removed references from abstract and shortened it
    - Modified address ranges
    - Added IPR notice and Copyright Statement.
  - [brad] Changed author mailing address

_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET)

> Considerations section, as this has seen the least review.

I've reviewed the draft.  It looks mainly good, but unless I 
misunderstand, there are still a few issues.

One particularly big issue is how to deal with IPv6's non-globally scoped 
addresses (sigh!).  You asked for sec cons review, so here's some.. :-)

substantial
-----------

Security Considerations

==> should one mention again the fact that IPv4 admin scoping is to be done
differently for SSM if it is requested?

==> (also a part of the main doc, but..) one thing I'd maybe like to see is
how SSM is treated with non-global IPv6 addresses.  Perhaps it has to say
something like that the scoping must also be done based on the rules for
unicast addresses of S.  In particular, (S,G) = (fe80::1%eth0, ff3e::1) is
clearly invalid outside of the link-local zone where it originated.  Another
potential issue is whether the unicast scope must at least equal that of the
multicast address.  There are also some other unicast scoping issues to
consider, but they might make the those are rather complex and maybe not
worth the effort.

...

Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses
with prefix FF3x:: are reserved for services with wide applicability

==> the prefix length is FF3x::/32, I think, must state here!

Addresses in the
range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
addresses, per [IPV6-UBM].  The treatment of a packet sent to such an
invalid address is undefined -- a router or host MAY choose to drop such
a packet.

==> the above seem to be clearly wrong -- I see *nothing* in IPV6-UBM that 
says so!?

An incoming datagram destined to an SSM address MUST be delivered by the
IP module to all sockets that have indicated (via Subscribe) a desire to
receive data that matches the datagram's source address, destination
address, and arriving interface.  It MUST NOT be delivered to other
sockets.

==> is arriving interface checked for ASM?  I'm not sure -- if not, I don't
see why it should be done for SSM.

editorial:
----------

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].

==> I believe this should be at the end of Introduction, but not sure..?

designated as source-specific multicast (SSM) destination addresses and
are reserved for use by source-specific applications and protocols.  For
IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
Source-Specific Multicast use.  It defines an extension to the Internet

==> source-specific multicast vs Source-Specific Multicast -- pick one for
consistancy

Using the terminology of [IPv6-UBM], this means that P=1, T=1, and
plen=0 for any SSM address.

==> "means that x=y for any address", is ok but could be a bit better,
maybe:

Using the terminology of [IPv6-UBM], all SSM addresses must have P=1, T=1, and
plen=0.

within the FF3x::/96 range, but a system should treat all of FF3x::/32
as an SSM address, to allow for compatibility with possible future uses

==> s/an SSM address/SSM addresses/

referred to as a "channel."  In contrast to the ASM model of RFC 1112,

==> s/."/"./ ?

  Identifier:           G                   S,G
  Receiver Operations:  join, leave         subscribe, unsubscribe

==> s/subscribe/Subscribe/, s/unsubscribe/Unsubscribe/

host IP module sends an unsubscription request for that channel out
interface I.

==> s/interface/the interface/, or "on interface".

address range for IPv4).  For IPv6, the randomization should apply to
the lower 32 bits of the address.

==> s/lower/lowest/ ?

subscriber would be delivered to another's IP module, which would then
have to reject the datagram.

==> perhaps s/reject/discard/ would be slightly better?

specify the required  modifications to those protocols to support SSM.

==> s/required  /required / (extra space)

7.  Security Considerations

==> add a 1-2 line summary of the subsections here.

To reduce the damage from such an attack, a router MAY have
configuration options to limit the following items:

==> s/limit/limit, for example,/ ?  the list is not meant to be exclusive,
and it's a MAY after all..

risks unduly burdening the network infrastructure by deliver (S,G)

==> s/deliver/delivering/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 6 Mar 2003 09:38:11 -0800 (PST)

Thanks for your comments, Pekka.  My responses inline.

> Date: Thu, 6 Mar 2003 12:31:55 +0200 (EET)
> From: Pekka Savola <[email-masked]>
> Cc: [email-masked]
> 

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.

> clearly invalid outside of the link-local zone where it originated.

So, today the document says this "Normal IPv6 multicast scope
boundaries are applied to traffic sent to an SSM destination address."

I thought this was sufficient -- as I understand it, a router isn't
allowed to forward an SSM packet across a scope boundary of either the
source or the destination address.  I think this is exactly how scoped
unicast works (and how ASM works), so do we really need any special
rules for SSM?

> Another

I thought about this and looked at the IPv6 default address selection
document (draft-ietf-ipv6-default-addr-select-09.txt) for guidance
when I last revved the document.

My rationale for *not* saying that the unicast scope must be as large
as the multicast scope is that this restriction does not appear to be
required (as far as I can tell) for IPv6 unicast or IPv6 ASM, and I
didn't see a reason for SSM to be special in this regard.  On a host
with multiple addresses, I suppose we could say that the source
address selection rules of draft-ietf-ipv6-default-addr-select-09
probably SHOULD be followed when picking the SSM source, but again, I don't
really think this is an SSM-specific issue.

But I'm open to ideas.

> ==> the above seem to be clearly wrong -- I see *nothing* in IPV6-UBM that 

Ok, so you're right about this not being stated in IPv6-UBM.  It is
actually the combination of [IPV6-UBM] and [IPV6-MALLOC] that together
imply that these are invalid SSM addresses.  The problem is that
IPV6-MALLOC says that the 0x00000001 to 0x3fffffff must have P=0 and
T=0, but IPv6-UBM says that all SSM addresses must set P=1 and T=1.
This is the rationale for calling these invalid addresses.

So perhaps this needs to be clarified in the document, then.

> see why it should be done for SSM.

I think it is -- it's part of the service interface specified in
IGMPv3:

Here's a quote from RFC3376, section 2, under the "interface" bullet.

   ... a system's IP service interface must support the following operation:

      IPMulticastListen ( socket, interface, multicast-address,
                          filter-mode, source-list )

   where:

   ...

   o "interface" is a local identifier of the network interface on which
     reception of the specified multicast address is to be enabled or...
     If reception of the same multicast address is desired on more than one
     interface, IPMulticastListen is invoked separately for each desired
     interface.

I think it's pretty clear from the last sentence that reception is
specific to the interface on which it is requested.  A scenario where
this might matter is the one in which a host has two interfaces
pointing into two private networks, both using site-local addresses
with potentially overlapping SSM channels.

> editorial:

I will look at the editorial comments and respond in a separate email.
They all look helpful.

Thanks again, Pekka.

-Hugh

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 16:32:13 +0200 (EET)

Hi, sorry for delay,

(Brian: sorry for the intrusion, note an issue about IPv6 Scoped Address
Architecture below.)

> (obviously not this exact text.)  If you have some specific ideas for

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.

> unicast works (and how ASM works), so do we really need any special

Perhaps Brian Haberman, as a co-author of scoped address architecture, can 
comment on this.

You're right that this is not really SSM-specific except in one fashion:  
sources indicate interest in (S,G) channels, not just G.  So, what if on a
web page someone publishes a channel with (fe80::1, ff3e::1) -- or the
same for site-local addresses?  This is one area which does seem 
SSM-specific. 
 
> really think this is an SSM-specific issue.

The problem as above seems to be that the source address for a channel 
needs to be published in some fashion.  Publication of non-unique (S,G) 
may be a problem.  Of course, one could argue that this is not so much 
different from publisting an admin-scoped ASM G..

I'm not sure what to think of this issue -- so other comments would be 
useful.
 
> So perhaps this needs to be clarified in the document, then.

It seems to me that this would imply that no such reserved range exists 
for SSM?

This seems like an issue that we must be very careful of, so that no one 
could say this document is trying to usurp either Proposed Standard.

Brian as an author for both can probably clarify at least on the intent.
 
> with potentially overlapping SSM channels.

Agree, no changes etc. needed.

HTH, thanks.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 08 Mar 2003 15:36:21 -0500

> same for site-local addresses?  This is one area which does seem 

Actually it is not SSM specific.  Someone could publish an FTP link
on a webpage that specifies FE80::5 as the target.  If you reach the
webpage using a global address, there is nothing that can be done
about it.

Also consider that the rules in RFC 3306 state that the scope of
the multicast address cannot exceed the scope of the unicast prefix
from which it derives.  Even though it is not specifically stated
for SSM, it applies.  So, an SSM channel cannot have a group address
that exceeds the scope of the unicast address.

> I'm not sure what to think of this issue -- so other comments would be 

As stated above RFC 3306 does have restrictions on what the scope
of the group address can be.

> Brian as an author for both can probably clarify at least on the intent.

Not sure I quite understand the issue.  The SSM range is to be
allocated out of FF3x::/96, however 3306 reserves the entire /32
for use later on with bigger group ID values.

Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with
permanently allocated IPv6 multicast addresses.  This is for
consistency with permanent IPv4 multicast addresses.  That
means that T=0 in the flags field.  I would expect that SSM
applications would allocate group IDs out of the 0x80000000 to
0xFFFFFFFF range for SSM channels.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Mar 2003 22:54:37 +0200 (EET)

> webpage using a global address, there is nothing that can be done

This is slightly different: the addrarch document is relatively clear on 
how the routers should handle such an address.

Is the SSM document clear on how (fe80::1, ff3e::1) is handled?  I'm not 
sure.

> that exceeds the scope of the unicast address.

More specifically it states:

   The scope of the unicast-prefix based multicast address MUST NOT
   exceed the scope of the unicast prefix embedded in the multicast
   address.

note: "embedded in the multicast address".  But as you should note here, 
an address (particularly _SSM_, which is really not derived from the 
unicast prefix) does not.

So, I think this is *not* clear.

> of the group address can be.

As above, I'm not sure how this applies to RFC3306 addresses which do not 
depend on the prefix, ie. SSM.

> for use later on with bigger group ID values.

Yes.
 
> 0xFFFFFFFF range for SSM channels.

But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue 
that the reservation does not hold.

IMO, reserving 0x8... to 0xf for apps would be a bad decision.  SSM is
_source_ specific.  It makes very much sense for apps/users to use as
simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like 
FF3X::8000:0001, FF3X::8000:0002, etc.

There doesn't seem to be need for this kind of address reservation is
necessary for SSM; if, for some particular reason, reservation is
necessary, it would seem to be better done at the end of the address
space.

---

From: Brian Haberman <[email-masked]>
Date: Sun, 09 Mar 2003 20:32:10 -0500

> Is the SSM document clear on how (fe80::1, ff3e::1) is handled?  I'm not 

See below.

> unicast prefix) does not.

The intent was that the scope of the SSM group address would
not exceed the scope of the SSM source address.  The scoped addr
arch forwarding rules *WILL* prevent a scoped address from leaking
out of the administrative zone.

The overall issue though is not SSM-specific.  That is, the
scoped addr arch is responsible for determining the forwarding
issues around scoped addresses.  I don't see a need for putting
any type of scoped address issues in the SSM doc.

>>>I'm not sure what to think of this issue -- so other comments would be 

As stated above, I don't see a reason to deal with scoped addresses
in the SSM arch doc.

> depend on the prefix, ie. SSM.

I consider the source address of an SSM group to be equivalent to
the unicast prefix used in an RFC 3306 generated address.

> that the reservation does not hold.

Not sure what you mean here.  3307 is very explicit in what IANA
is reserving for group IDs.

> FF3X::8000:0001, FF3X::8000:0002, etc.

But there is a bigger issue.  One of the goals of 3307 is to help
prevent collisions at the layer-2 mapping of group addresses.  By
having separate 32-bit ranges for the group IDs, it is possible to
minimize the number of collisions that occur at the MAC layer.

> necessary, it would seem to be better done at the end of the address

But, the end of the address range collides with existing assignments
already delegated in RFC 2375.  That is why 3307 uses the low end of
the range for permanent group IDs.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2003 09:27:55 +0200 (EET)

On Sun, 9 Mar 2003, Brian Haberman wrote:
> The overall issue though is not SSM-specific.  

Yes and no: in ASM, the DR only checks that G is ok; not it must check 
that both S and G are ok.

> That is, the
...
> As stated above, I don't see a reason to deal with scoped addresses

I understand this argument and I agree with it, mostly: at this point, we
may end up doing some nasty things (in ipv6 w.g.) with scoped address
architecture anyway, so trying to specify everything in detail in the 
specs before we know we have to do it seems premature.

So, I can support putting considerations like these in the scoped address 
architecture document, but IMO, there *must* be a brief mention of the 
issues and a pointer in e.g. Security Considerations section.

> the unicast prefix used in an RFC 3306 generated address.

One could consider so, but as was noted earlier, I didn't see it that way, 
and many others probably won't either -- unless clarified.

More work for scoped addrarch, I suppose.

> is reserving for group IDs.

3307 says:

4.1  Permanent IPv6 Multicast Addresses

   Permanent multicast addresses, like those defined in [RFC 2375], are
   allocated by IANA.  These addresses will be assigned with group ID's,
   in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.

   Multicast addresses assigned by IANA MUST have the T bit set to 0 and
   the P bit set to 0.

==> the last sentence does not hold for SSM; the IANA considerations 
section itself is quite explicit.

> minimize the number of collisions that occur at the MAC layer.

Ok, I can accept that, I think.

> the range for permanent group IDs.

Ok; so, if a user manually configures an SSM address to be used, he must
use ones from the dynamic range?  (even though the dynamicity is
arguable.)

---

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Mar 2003 08:01:49 -0500

> that both S and G are ok.

Actually, the DR has to check both S and G to ensure that it does
not send a PIM Join across a scope zone boundary regardless of it
being ASM or SSM.  There was some text in the original PIM for v6
draft a long time ago.

> specs before we know we have to do it seems premature.

Agreed. :)

> issues and a pointer in e.g. Security Considerations section.

I don't see a problem with doing that.  The security section can mention
the issue and say that it is out of scope for this doc and is being
addressed elsewhere.

> More work for scoped addrarch, I suppose.

Long-term it should be fixed in a revision of 3306.  Near-term we
could add text to this doc in section 4.3 clarifying the allocation
issue on scopes.

> section itself is quite explicit.

SSM addresses are not restricted to the completely dynamic addresses.
An SSM app could request a permanent group ID as defined in section
4.2.

> use ones from the dynamic range?  (even though the dynamicity is

As noted above, the user could request a permanent group ID for the
application.

Brian

---

From: Hugh Holbrook <[email-masked]>
Date: Mon, 10 Mar 2003 22:49:38 -0800 (PST)

> Date: Sat, 8 Mar 2003 16:32:13 +0200 (EET)
> Cc: [email-masked], <[email-masked]>
>

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

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Mon, 10 Mar 2003 23:30:08 -0800 (PST)

[ ... Snipping just the thread on scoping for ssm ]

My comments inline...

> Date: Mon, 10 Mar 2003 08:01:49 -0500
> From: Brian Haberman <[email-masked]>
> Cc: Hugh Holbrook <[email-masked]>, [email-masked]
> 
> Pekka Savola wrote:

A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt?

> the issue and say that it is out of scope for this doc and is being

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.

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?

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?

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 11 Mar 2003 00:02:14 -0800 (PST)

[snipping just the thread on allocating permanent ipv6 addresses]

Thanks for your input, Pekka and Brian.

Exactly -- the idea is that an application that requires, for some
reason, that the same channel destination address be used on all hosts
providing that channel would be allocated from 0x40000000-0x7fffffff.
Any other channel destination addresses, regardless of lifetime, must
come from the 0x80000000-0xffffffff space.

Section 4.3 states that a host OS SHOULD provide an interface to
allocate a random address, and that this information must be stored in
a database that persists across reboots.  The idea is that this is the
mechanism that an application or user uses to allocate an SSM address.

I think this is probably already clear, but I want to underscore the
importance of using random allocation for SSM addresses.  It is not a
good idea (and is in fact specifically disallowed in section 4.3) for
a host, host application, or host OS, to deterministically pick
FF3x::1 or FF3x::2, or *any* fixed value as the channel destination
address on all hosts for some application -- because of the link-layer
collision issue.

So to summarize on the text changes, the only textual change I
currently think is warranted is to clarify in 4.3 and in the IANA
Considerations section the use of the 4000:0000 to 7fff:ffff

In 4.3, change this:

  The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT
  send datagrams with destination address of 232.0.0.0.  The address range
  232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA.  The
  IPv6 SSM address range FF3x::/32 is reserved for IANA allocation.

to correctly call out the 0x4000000-7fffffff range.

  The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT
  send datagrams with destination address of 232.0.0.0.  The address range
  232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA.  SSM
  destination addresses in the range FF3x::4000:0000 through
  FF3x::7FFF:FFFF are similarly reserved for IANA allocation.

I'm not sure where the FF3x::/32 came from, but I think it is a
vestige of an earlier revision that was less clear on the /96 vs /32 
distinction.

And a similar fix IANA Considerations.

  Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6
  addresses with prefix FF3x:: are reserved for services with wide
  applicability that either require or would strongly benefit if all
  hosts used a well-known SSM destination address for that service.

to read

  Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6
  addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are
  reserved for services with wide applicability that either require or
  would strongly benefit if all hosts used a well-known SSM
  destination address for that service.

Any objections to these changes?

-Hugh

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Mar 2003 08:00:13 -0500

> address on all hosts for some application -- because of the link-layer

Seems reasonable to me.

> vestige of an earlier revision that was less clear on the /96 vs /32 

I agree.  RFC 3306 reserves the entire /32 so that group IDs can
grow beyond the lower 32 bits of the group address.  RFC 3307 then
states that allocations must be done out of the /96 (for the time
being).

> Any objections to these changes?

I don't have any objections.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Mar 2003 07:48:48 -0500

> Considerations section, barring any objects.

Looks fine to me.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Mar 2003 09:08:01 -0500

> A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt?

That would be the beast.  RFC 3484 references it when discussing
the issue of scope within the source address selection policy.  It
can be an informative reference here.

> 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. :)

> leave the document without a reference?

I don't see a problem with having an informative reference for the
scoped addr arch doc.

> I am inclined to do the latter, and I think this is what both of you

I agree, the latter works for me.  Should we add a reference to RFC
3484 as a note on how the address selection could occur?

Brian

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 11 Mar 2003 23:19:09 -0800 (PST)

Cool, thanks.   I've made both of these changes to my working copy.
-Hugh

> Date: Tue, 11 Mar 2003 08:00:13 -0500
> Cc: Pekka Savola <[email-masked]>, [email-masked]
> 
> Hugh Holbrook wrote:

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 12:42:11 +0200 (EET)

> can be an informative reference here.

Agree.

> like Pekka's assessment before we declare victory. :)

I can live with it, with the inclusion of the reference.

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]

> I don't see a problem with having an informative reference for the

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..)

> 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.

> Should we add a reference to RFC

I'm ok with it but don't see where it would fit nicely.

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 12 Mar 2003 10:08:04 -0800 (PST)

> 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.

> 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?

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

> "almost" normative, but we don't want to have SSM arch get stuck due to 

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

> clarification of it in scoped addrarch.

Ok.  Agreed on that.

> 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.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 12 Mar 2003 13:44:52 -0500

> something that makes this tricky?

Not that I am aware of.

> Is there something about this that makes it a Security Considerations

I don't see a huge need for it.  Especially since it affects all
forwarding of scoped addresses, not just multicast.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET)

> 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.
 
> Is there something about this that makes it a Security Considerations

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.

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 
  scopes should be avoided and must not be used as a security mechanism.

.. I wonder if that's any better ..

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 12 Mar 2003 21:12:45 +0100 (MET)

>   scopes should be avoided and must not be used as a security mechanism.

Although I didn't completely follow every mail of this subject, for
me, it is simple that;

       an end-node should not request any (S,G) join whose unicast
       address scope and multicast address scope are not same. If the
       kernel receives such request, it should discard it. Likewise,
       if a router receives such join request, it should also discard
       it.

Why isn't it reasonable?
--
Hitoshi Asaeda

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 12 Mar 2003 12:17:41 -0800 (PST)

> Date: Wed, 12 Mar 2003 21:41:27 +0200 (EET)
> Cc: Brian Haberman <[email-masked]>, <[email-masked]>
> 

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.

> 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.

>   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.

-Hugh

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 22:28:33 +0200 (EET)

>        if a router receives such join request, it should also discard

What corresponds to organization-local multicast scope?

(seriously, one of the points in this doc was trying to avoid normative 
language on unicast scoping issues, and leave it to the scoped address 
architecture.)

---

From: Brian Haberman <[email-masked]>
Date: Wed, 12 Mar 2003 15:52:32 -0500

> to both the source and destination.

Neither can I.  In fact, that is one of the items in the scoped
addressing architecture that everyone agrees on.  Both S & G have
to be checked when a scoped boundary is encountered.

> boundary, so it's like sending the join to the wrong host.

I agree that would be dangerous.  The situation is a little muddled
though, in that the PIM protocol would have to do checking of S &
G within the PIM Join/Prune messages.  Of course, the actual
routing protocols will have to do the same too.  So, it seems that
the scenario is already covered and is much larger than SSM.

> in addition to the destination address.

That is what the scoped addressing architecture already says.
Do we need to repeat it?

> SSM, because I think they work fine as long as boundaries are applied

I agree with Hugh on this point.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 23:23:26 +0200 (EET)

> > to both the source and destination.

Different unicast and multicast codepaths? Or..

> to be checked when a scoped boundary is encountered.

.. not *implementing* scoped address architecture at all while supporting 
SSM?

I certainly don't want to require scoped addrarch for SSM implementation;  
moreover, I don't want to give users the expectation that using e.g.  
(fec0::1, ff3e::1) would just somehow magically get discarded somewhere
near the manually configured site border by SSM routers.

I see a lot of cases.  Most IPv6 routers today, as far as I've looked,
forward site-local source addresses quite nicely anywhere I want..
 
> That is what the scoped addressing architecture already says.

I'd like a mention of why it is a problem better, and leaving the actual 
behaviour undefined or TBD in scoped addrarch.

> > ever be allowed.  

I agree here: it's not likely be allowed, but the *security 
considerations* part of it is that it *does* happen when/if scoped 
addrarch hasn't been implemented in the designated routers etc. -- this 
was a balance between specification status and operational reality.

> > I'd be happy saying just that "scopes should not be
> > used as a security mechanism..."  and leaving it at that.  

If a variation of that where it's explicit that it applies to the source 
address is added, that's ~ok.

> > I think

(For what it's worth, I was referring to unicast S scoped *only*, if it 
makes any difference.)

The point is that I'm having some doubts whether boundaries *are* actually
applied to the source..

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 12 Mar 2003 15:01:30 -0800 (PST)

Thanks again for your comments, Pekka.

It sounds like you're primarily concerned with the scenario where
some router either does not implement scoping as per [SCOPED-ARCH],
or only implements part of it (either for unicast or for dest addrs).

I see how such an implementation can violate scoped boundaries, but
I'm having a hard time coming up with any text that is not a tautology.  I
keep getting writing non-informative sentences like "if source address scoping
is not implemented on domain border routers, then source address
scopes will not be enforced for SSM traffic."  Here's the best I've
been able to come up with so far.  Does this capture you're concerns.

  Neither source nor destination address scoping should not be used as
  a security measure.  In some (many?) currently-deployed IPv6 routers (that 
  do not conform to [SCOPED-ARCH]), scope boundaries are not applied
  to the source address.  Such a router may incorrectly forward an 
  SSM channel (S,G) through a scope boundary for S.

(Of course this is less likely to happen than one might think at first
because, when forwarding a join, a router typically does a destination
lookup on S to figure out the next hop....)

This is slightly less tautological, I guess.  I'd welcome improvements
or any alternative text, though.

-Hugh
----------------------------------------------------------------

> Date: Wed, 12 Mar 2003 23:23:26 +0200 (EET)
> Cc: [email-masked], <[email-masked]>
> 

I guess I don't consider this "an implementation of scoped addressing."

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2003 20:57:13 +0200 (EET)

> or any alternative text, though.

This is OK by me, but I might propose a slight modification, s/are not 
applied/are not always applied/ (ie. it's typical to filter out 
link-locals because they're "easy" but it's not an all or nothing issue).