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

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2010 11:31:32 -0700

On Jul 28, 2010, at 01:00, Toerless Eckert wrote:
> 
> Not quite sure what you mean. I would like application meant to be written
> for home/SMB networks to be written to use at most site-local IPv6 multicast
> group address scopes.

That's not in the ambit of the draft.

The draft recommends a DEFAULT multicast scope boundary of organization-local because we think it will be very rare for a subscriber and their service provider to be separate sites within the *same* organization, and moreover, we do not think that the DEFAULT should be set so that subscribers are all expected to be within the same organization unless they actively take steps to separate themselves by reconfiguring the multicast scope boundary.

Setting the DEFAULT multicast scope boundary to site-local, instead of organization-local, would be profoundly wrong-headed.  I would object vigorously to making the change to the draft you propose.

> When such an application is then put into an
> enterprise network it is most likely to work comparably because it will
> be constrained to a site of the enterprise, like an office, which although
> usually larger in size than todays home networks, will still be sufficiently
> small in size to make ASM application fairly well workable.

I get that you're worried about application developers who are unsure what multicast scope to use, and who might see this document and mistakenly think, "Hey! I better use organization-local scope so I get the widest distribution possible in home networks without extending beyond residential gateway."  But those application developers are A) mistaken, B) not our problem, and C) unsolvable.

Any developer who uses organization-local multicast scope when they really mean to use site-local, or vice-versa, is just plain wrong.  If a routed internetwork at a residential subscriber contains site-local multicast scope boundaries, then we must assume the subscriber put them there for a reason.  We also have to expect that developers who are careless about choosing the right multicast scope will be corrected by other mechanisms than the functions of IPv6 CPE Simple Security.

> I am not sure where the expectation was raised that application for
> home networks/SMB should default to Organizational-Local scope.

I don't know where you acquired that expectation either.  It's certainly not in the draft.

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2010 11:49:10 -0700

On Jul 28, 2010, at 06:31, Tim Chown wrote:

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

See my previous message on this topic for my response to that proposal.

> The provider would most likely use organisation-local to scope multicast within its whole network.

As well they should do so for their private use, c.f. RFC 2365.

Setting the DEFAULT multicast scope boundary at site-local would extend service provider private multicast beyond demarcations into their subscriber networks.  For that reason, service providers will certainly expect to use organization-local zone boundary edge routers for the same reason we recommend that residential gateways be organization-local zone boundary routers.

The first-mile link is an organizational zone boundary.  I don't understand why this is a point of such confusion.  Or do we really not like the idea that subscribers are separate organizations from their service providers?  "We are the Internet company.  All your base are belong to us!"

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Aug 2010 20:58:27 +0200

> Setting the DEFAULT multicast scope boundary to site-local, instead of organization-local, would be profoundly wrong-headed.  I would object vigorously to making the change to the draft you propose.

Dumb question, chair hat off...

In the absence of a deployed multicast routing protocol, I would be surprised at the use use of anything beyond link-local multicast. We don't have an algorithm that will correctly route a multicast in a wider scope (eg, deliver exactly once barring random loss), and we don't have an algorithm besides route filtering in a routing protocol that will contain a multi-subnet multicast within any specific boundary.

As a result, in a SMB/SOHO/Residential environment and for that matter any environment, I would expect multicasts to be *link-local* in scope apart from configuration - at minimum configuration of a multicast routing protocol and appropriate route filters.

Why are site-local or organization-local even on the table?

---

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2010 13:20:03 -0700

> Why are site-local or organization-local even on the table?

An excellent question. In light of the absence, which you note, of any kind of multicast routing to/from residential networks, it seems to me that service provider edge routers are-- in actual practice-- global multicast zone boundaries today. But that need not always be the case. Call me a dreamer, but I'm not willing to stand up and recommend that we brick up the residential side of the first-mile multicast link just yet.

I'm really not sure why people seem to think that subscribers ought to be lumped into the same organizational zone as their service provider. I must need to be educated about operational considerations again.

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Aug 2010 10:19:11 +0930

On Fri, 6 Aug 2010 13:20:03 -0700

> An excellent question. In light of the absence, which you note, of any kind of multicast routing to/from residential networks, it seems to me that service provider edge routers are-- in actual prac…

There's quite a lot of IPTV interest in the .au market at the moment,
and one of the branded service wholesale IPTV providers to ISPs is
using IPv4 multicast to deliver it. The provider is originating the
multicast traffic outside the ISP networks, so in an IPv6 context I
think the scope for that traffic would need to be global. To avoid
using a global scope for that, it probably wouldn't be hard to
re-originate the content at the IPv6 layer within the ISP's network,
changing it's scope at the same time. However for that to work I think
that would mean that scope for the traffic would be organization local,
with the organisation including residential subscribers networks.

Related to this topic, the TR-124_Issue-2.pdf document from the BBF,
via Fred's ftp server, says -

"LAN.MLD.ROUTED. The device MUST default to not sending MLD messages for
scope of 0 through 8."

---

From: Fred Baker <[email-masked]>
Date: Sat, 7 Aug 2010 05:32:55 +0200

On Aug 7, 2010, at 2:49 AM, Mark Smith wrote:

> via Fred's ftp server

which btw is temporary - things I post there disappear about a month later. Folks, please feel free to use the IETF Liaison site...

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

---

From: Fred Baker <[email-masked]>
Date: Sat, 7 Aug 2010 06:06:20 +0200

On Aug 7, 2010, at 2:49 AM, Mark Smith wrote:

> think the scope for that traffic would need to be global.

OK, Mark, what are you arguing here?

I *think* you are arguing that the router SHOULD be configurable by some means (manual? UPnP? what?) to accept a multicast from the ISP and repeat it on the (a?) local LAN, or more generally, that a CPE router SHOULD be configurable to forward an identified class of multicast traffic between subnets to which it is attached. Is that correct? If so, I'll suggest we think about that recommendation for the CPE Router discussion that we just initiated.

With respect to security, which is the subject of this draft, how would you recommend identifying the class of traffic? Are you suggesting that a simple home firewall should prevent the home from being ddos'd using unicast but should be default be ddos-able using multicast? Where does this discussion lead us?

---

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2010 21:12:51 -0700

On Aug 6, 2010, at 17:49, Mark Smith wrote:
> 
> To avoid using a global scope for that, it probably wouldn't be hard to re-originate the content at the IPv6 layer within the ISP's network, changing it's scope at the same time.

I fail to understand why this should be viewed as necessary.  If service providers feel the need to re-originate content at a local interface address, they can certainly do so without changing the multicast addressing scope.  They could easily just retransmit with a distinguished global scope address in the RFC 3305 range corresponding to a route filter at their transit borders.

Nothing requires service providers to advertise every global scope multicast route from their network interior and subscribers all the way out to the public default free zone.  In fact, I'd be shocked and surprised if they did.

That said, I'm sorta guessing that more interest in reserving some value of SCOP > 8 for subscriber aggregation purposes will happen when more interest in multicast routing arises among service providers, but I'm not sure MZAP [RFC 2776] is well-specified for operation across AS boundaries.

(Meanwhile, there is RFC 2908, which makes my head hurt.)

> "LAN.MLD.ROUTED. The device MUST default to not sending MLD messages for scope of 0 through 8."

This says gateways do not join multicast groups on their LAN interfaces unless SCOP > 8, but it says nothing about forwarding behavior.  Otherwise, this isn't that different from what our draft says.

Our draft says that multicast-capable residential gateways should default to acting as an organization-local zone boundary, i.e. they are multicast routers that only *forward* multicast with SCOP > 8.  They can still join multicast narrower-scope groups on the LAN, but they do not forward them into the service provider network.  Likewise, they can join narrower-scope groups on their WAN interface, but they do not forward them into the subscriber LAN.

That's because it's the forwarding behavior we care about.

---

From: Mark Smith <[email-masked]>
Date: Sun, 8 Aug 2010 19:30:40 +0930

Hi Fred,

On Sat, 7 Aug 2010 06:06:20 +0200

> I *think* you are arguing that the router SHOULD be configurable by some means (manual? UPnP? what?) to accept a multicast from the ISP and repeat it on the (a?) local LAN, or more generally, that…

Yes. I would assume that the multicast functionality would be achieved
by having the CPE act as an MLD proxy.

> With respect to security, which is the subject of this draft, how would you recommend identifying the class of traffic? Are you suggesting that a simple home firewall should prevent the home from being ddos'd using unicast but should be default be ddos-able using multicast?

No. 

Firstly I think the upstream network's multicast forwarding capability
provides a level of protection. If the upstream ISP network doesn't
support multicast forwarding, then the CPE would only receive multicast
traffic on it's WAN interface from on-link peers. If the CPE is acting
as an MLD proxy, then that multicast traffic would only be forwarded
onto the LAN ports if there were subscriptions for groups towards which
this malicious multicast traffic were being sent to. So current threat
from malicious multicast traffic is quite low level. Even if the
upstream ISPs network is multicast enabled, the Internet isn't, so the
threat isn't a global one.

Secondly, when the ISPs network is configured to multicast route, for
multicast traffic inbound towards the home LAN, it would seem to me
that MLD / MLD proxy would in effect serve as a "multicast firewall
configuration" protocol. Traffic for groups that are subscribed to,
regardless of their scope, could be permitted to be forwarded by the
CPE from the WAN to appropriate LAN interfaces. Any other inbound
multicast traffic not be forwarded.

I can't really think of a use for outbound multicast i.e. the
unique multicast source is attached to the home LAN. However, with IPv6
restoring or attempting to restore the peer-to-peer communications
nature of the Internet, the are probably some use cases. They're
probably worth trying to avoid constraining if doing so doesn't reduce
security unacceptably.

In the context of this draft, I think CPE multicast security is possibly
is not simple enough to just use multicast address scopes as security
discriminators in determining if the traffic should be forwarded or
not. It might be better to say in this draft something like, "all
multicast traffic is not to be forwarded by the CPE, unless appropriate
multicast traffic security mechanisms have been implemented. Such
multicast security mechanisms are out of scope for this memo." (or
addressed in a multicast security RFC that I'm not aware of.)

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Sun, 8 Aug 2010 16:05:36 -0700

On Aug 8, 2010, at 3:00 AM, Mark Smith wrote:

> It might be better to say in this draft something like, "all

Again, I'm wrestling with the distinction between the security draft and the CPE Router draft. Absent the configuration of some form of multicast routing, I would be surprised by the router forwarding anything at all. Configuration of routing protocols or mechanisms, and routing behaviors on or off by default, sounds more like the subject of the CPE Router draft to me. I should think that the security draft is about filters - "presuming that a standard router would choose to forward the datagram, is there any other policy that would prevent it?" A standard router doesn't do a thing with MLD unless it is configured to do so.

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Aug 2010 07:32:50 +0930

Hi Fred,

On Sun, 8 Aug 2010 16:05:36 -0700

> Again, I'm wrestling with the distinction between the security draft and the CPE Router draft. Absent the configuration of some form of multicast routing, I would be surprised by the router forward…

I suppose that might mean there are three levels/layers of problem,
with parts of the layers covered by the two drafts (and possibly
are to be covered by other drafts)

- what are the capabilities of the CPE (unicast routing is the
  baseline, capable of routing multicast is optional)

- what capabilities are enabled by default

- what are appropriate security measures for those capabilities, with
  whether they're enabled by default being an influence on what is
  appropriate.

I suppose my comments have been a bit influenced by some of the IPv6 CPE
I've been working with. They have multicast capabilities, and options
relating to IGMP or MLD snooping. Since they're low end residential
CPE at a low price point, inherently I think I've started to accept
that their capabilities are the baseline IPv6 CPE functionality that
will be common.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Aug 2010 15:07:36 -0700

> that their capabilities are the baseline IPv6 CPE functionality that

And you may be right. That doesn't make "turn on MLD" a security recommendation...