Subject: Re: draft-ietf-v6ops-cpe-simple-security-12.txt feedback

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jul 2010 09:40:29 +0200

I'm copying the IESG, as this document is currently under review in the IESG. Having been through, literally, years of conversation and multiple last calls, I'm a little concerned that this request to reconsider and redraft the recommendations of the specification is coming so late.

We have had this in review for the past few years, and I for one have also commented that the only multicast models that we actually have algorithms to implement are link-local (broadcast on a directly-attached LAN) and routed IP multicast; this is the reason that the concept of multi-subnet broadcast was removed from RFC 1716 in the process of editing into RFC 1812. Organization-local addressing has inexplicably survived in the IPv6 Addressing Architecture, although the lack of running code re its routing has been pointed out on numerous occasions. The argument in the discussion was that since 6man is deluded into believing that a form of multicast besides link-local and routed exists and is workable, it should be dealt with.

In my opinion, not as working group chair but as an individual who knows a little about such things, 6man should either be asked to define the term ("organization-local multicast is a form of routed multicast in which administrative boundaries are observed") and demonstrate algorithms and running code that systemically imposes such boundaries. Note that RFC 2365 defines administratively scoped multicast for IPv4, but does not touch on IPv6 and provides no algorithms to deal with the obvious "security consideration" of a systemic boundary to such routing.

On Jul 28, 2010, at 9:23 AM, Toerless Eckert wrote:

> I would strongly suggest to change the requirement in REC-2 of
> subject draft to say that the default SHOULD be site-local scope
> instead of organizational-local scope.
> 
> The reason for this is that the largest scope that we specify in this draft
> will influence designers of ip multicast applications that use ASM multicast.
> The worst of such often written applications are using ASM multicast for
> discovery. When these applications are then deployed in other environments
> such as enterprises, they will send out IP multicast packets that will
> go across the whole organization, which in the case of an enterprise could
> be worldwide.
> 
> On the other hand, use of ASM to do this type of discovery mechanisms
> in applications, while not preferred by multicast architecture, is 
> perfectly valid for simple applications meant to run in a residential home.
> 
> So the best compromise seems to be to recommend the smallest scope we
> feel is large enough for a residential (or small business) site, and
> that would be site-local scope.
> 
> [ Now if it was for me, i would add the requirement that the scope must not
> be larger than site-local scope to be within the bounds of the drafts
> recommendations].
> 
> I have not followed the draft in detail in before, so if there where any
> arguments to recommend organizational scope, it would be nice if those
> could be repeated.
> 
> I have Cc'ed mboned, because my concern is one of multicast operations,
> and i am not aware that these considerations where brought up in front of
> mboned in before.
> 
> Thanks
>    Toerless

http://www.ipinc.net/IPv4.GIF

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Jul 2010 00:40:45 -0700

> go across the whole organization, which in the case of an enterprise could

I don't see the concern.  If an enterprise expects their discovery protocol to be routed over the global scope multicast routing domain, then they should use global scope multicast addresses to be sure that IPv6 CPE simple-security will forward it.  Otherwise, the fact that CPE routers enforce organizational scope multicast boundary means that CPE routers will block those flows from extending into the service provider routing domain and potentially into networks owned by other subscribers.  If we reduce the scope boundary to site-local, then organizational scope discovery protocols will be blocked by the organizational boundary somewhere north of the subscriber gateway.  This doesn't strike me as a desirable outcome.  Why do you disagree?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Jul 2010 14:31:15 +0100

Hi,

I agree that 3.1 REC-2 should say site-local scope is the default for the context of this draft (CPE devices in homes and small offices).   The provider would most likely use organisation-local to scope multicast within its whole network.

In our campus site-local multicast is constrained by configured router boundaries within departments and organisation-local scope multicast is constrained within our campus.   But that's a very different, larger scenario.

The terminology is different for unicast where if we used 'site local' unicast ULAs we would use one /48 ULA for our whole campus.    As of yet we have not felt a need to multi-address (any part of) our campus with ULAs.

Tim

On 28 Jul 2010, at 08:51, Toerless Eckert wrote:

> For once, the dfraft in question does not differentiate between
> unicast site-local and multicast site-local addresses, and i do not
> even know if there are unicast orginaizational-local addresses.
> 
> I am only referring to scoped IPv6 multicast group addresses as
> defined in RFC4291 section 2.7. IPv6 site-local IP multicast addresses
> are just a smaller scope than IPv6 Organizational-Local scope. There
> is otherwise no semantic difference between them.
> 
> Routed IP multicast works and can be recommended and should be included,
> i did not contest that. I contested that we do recommend the correct scope
> size in this draft. Organizational-Local is too large, and i think i explained
> the risks.
> 
> Thanks
>    Toerless
> 
> On Wed, Jul 28, 2010 at 09:40:29AM +0200, Fred Baker wrote:
> ---
> Toerless Eckert, [email-masked]
> Cisco NSSTG Systems & Technology Architecture
> "The strategy is what you do, not what you write" - Wesley Clark
> "Vision without ressources is hallucination" - James L. Jones
> 
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned