Subject: [magma] WG Last Call: draft-ietf-magma-igmp-proxy-01.txt

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Feb 2003 12:36:41 -0500

All,
      This is the start of the MAGMA work group last call on
draft-ietf-magma-igmp-proxy-01.txt, "IGMP/MLD-based Multicast
Forwarding" as a Proposed Standard.  The last call period will
end on Feb. 24, 2003.  Substantive comments should be made to
the mailing list and editorial comments sent to the authors.

Regards,
Brian & Bill

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Feb 2003 23:25:03 +0200 (EET)

> the mailing list and editorial comments sent to the authors.

A few comments:

Substantial:

5. Security Considerations

==> it might make sense to note that by definition, when proxying 
joins/reports, the ability of the real PIM routers to verify the 
joins/reports may get difficult if not impossible.  I'm not sure if this 
is a problem today, but consider some e.g. multicast content delivery 
options where the router would verify at least some authorization (IMO, 
this kind of solution is probably broken, but the point stands)

==> the abstract and the introduction are wisely generic about the 
applicability, but later sections go on, describing "routers" acting as 
MLD/IGMP forwarders.  Is this semantically O.K.?  Replace with "IGMP/MLD 
proxying device" or something (sigh..)?  A lot of switches perform 
proxying...

==> I think the must-be-querier-numbering rule should be explained in more 
detail in a separate section, subsection or whatever.  E.g. which kind of 
scenarios this applies to, etc. -- this could really be an applicability 
problem so it must be very clearly spelled out, IMO!  There's already some 
good text there, perhaps add a bit more but more importantly, make it more 
prominent in the spec.

==> is it possible (or sufficiently simple) to specify a mechanism to 
detect "upstream loop" -- and possibly disable proxying then?  This kind 
of potential flooding-DoS-loop should be listed in security 
considerations!

More or less editorial:

Internet Engineering Task Force               Bill Fenner, AT&T Research
INTERNET-DRAFT                              Haixiang He, Nortel Networks

==> the first line on left should list the magma working group as this is 
a w.g. document.

Abstract
[...]

   This document is a product of the MAGMA working group within the
   Internet Engineering Task Force.  Comments are solicited and should
   be addressed to the working group's mailing list at [email-masked]
   and/or the authors.

==> this should be moved out of the abstract, perhaps in introduction if 
really necessary (I would vote for removing it completely)

2. Definitions

==> one could perhaps define that by the term "group", one also refers to
"channel" in the case of SSM? -- at least in some places (substituting
everywhere might not look nice)

   IGMP/MLD used is explicitly configured and default to the highest

==> s/default/defaults/

References

==> split the references to normative/informative; in particular, remember 
that this cannot be published before all normative references have been 
published.

-- 
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: Pekka Savola <[email-masked]>
Date: Sat, 22 Feb 2003 23:25:03 +0200 (EET)

A few comments:

Substantial:

More or less editorial:

Abstract
[...]

2. Definitions

==> s/default/defaults/

References

---

From: Haixiang He <[email-masked]>
Date: Mon, 24 Feb 2003 00:24:11 -0500

Hi

Thanks for your comments. See below for some inline answers.

> this kind of solution is probably broken, but the point stands)

I personally disagree with you. I don't think BY DEFINITION, a Proxy makes its
upstream PIM router harder to verify the joins/reports. Using IGMP host
portion on the upstream link is as good/as bad as using PIM on the upstream
link in terms of verifying joins/reports.

IMHO, you are discussing a bigger problem: access control and it is really
outside the scope of this draft. I have been focusing on solving IGMP access
control: authentication and authorization and I am glad that you have similar
concern especially for PIM.

> proxying device" or something (sigh..)?  A lot of switches perform

During the development of this draft, we had a discussion on using the term
"router". Bill Fenner mentioned that by definition a router is a device that
forwards traffic on IP layer. I think it is semantically OK since a Proxy
forwards traffic on IP layer.

> good text there, perhaps add a bit more but more importantly, make it more

Good point. We will make it clearer.

> of potential flooding-DoS-loop should be listed in security

I personally don't think that it is simple to add the "upstream loop"
detection mechanism. I don't understand how you start a "flooding-DoS-loop"
attack. Can you explain it?

> ==> the first line on left should list the magma working group as this is

I will make the change.

> really necessary (I would vote for removing it completely)

Actually I really like this style that Bill uses in his drafts.

In http://www.ietf.org/ietf/1id-guidelines.txt, we have "It is strongly
recommended  that the draft include a notice (with email address) of where
comments should be sent."

IMHO, having a notice in the Abstract is a good practice since Abstract is
used in the draft or RFC index.

> everywhere might not look nice)

This draft is not SSM specific. To make it clear, how about I mention "channel
in SSM" when "group" is first used in the draft?

>    IGMP/MLD used is explicitly configured and default to the highest

Thanks for the catch.

> that this cannot be published before all normative references have been

I already had a version that follows the ID-NITs. I am waiting for the last
call comments and will submit the new version before the deadline.

Best Regards,

Haixiang

---

From: Haixiang He <[email-masked]>
Date: Mon, 24 Feb 2003 00:24:11 -0500

Hi

I will make the change.

Thanks for the catch.

Best Regards,

Haixiang

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Feb 2003 09:08:48 +0200 (EET)

> link in terms of verifying joins/reports.

That's right -- but only if you compare it to the situation where the 
alternative is a PIM router.  The alternative could be "no router at all", 
too. (Consider an ethernet switch.)
 
> concern especially for PIM.

Well, I don't think the issue should be discussed in detail, but I'd like 
to have it mentioned (as one potential issue) somewhere.
 
> forwards traffic on IP layer.

Is an ethernet switch a router?  I don't think you have to be a router 
(you can forward traffic below IP layer too!) for this mechanism to be 
applicable to you, I think?

> attack. Can you explain it?

You describe a situation where multicast packets would be looped in a 
subnet.  If install your proxying devices in such a fashion, you will have 
a loop which leads to a denial of (multicast) service.  An issue with 
configuration could lead to a lot of problems, so it seems to me should be 
listed.

Of course, you don't trigger this "DoS" from locally or remotely, so it is 
not "an attack" as such.

> comments should be sent."

Well, that's not really the practise (as almost all drafts have a w.g.  
name embedded in the name in some fashion, which gives the hint for
followups), but I don't argue that.

> used in the draft or RFC index.

Well, in my eyes, abstract is meant to be _Abstract_.  That particular 
information is not relevant unless you read the draft, and in that case, 
the notice could (and IMO should) be somewhere else.

> in SSM" when "group" is first used in the draft?

I'm not sure if I can envision the change.  Anything that clarifies that 
"group" also applies to "channels" in SSM is good for me.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Feb 2003 09:08:48 +0200 (EET)

---

From: Haixiang He <[email-masked]>
Date: Wed, 26 Feb 2003 11:20:08 -0500

Sorry for the late reply.

> too. (Consider an ethernet switch.)

I personally don't think it is fair to compare a multicast routing function with non
multicast routing function.

> to have it mentioned (as one potential issue) somewhere.

If the access control needs to be addressed, IMHO it should be addressed in the
IGMP/MLD. IGMP/MLD proxy depends on the downstream IGMP/MLD subscriptions.

> Is an ethernet switch a router?

If an ethernet switch has PIM and forward traffic based on IP address, do you call
it a switch or router?

>  I don't think you have to be a router

The title of this draft has: IGMP/MLD-based multicast forwarding. The traffic
forwarding bases on IGMP/MLD subscriptions.

> Of course, you don't trigger this "DoS" from locally or remotely, so it is

OK. I will repeat the configuration concern in the security consideration.

Haixiang

---

From: Haixiang He <[email-masked]>
Date: Wed, 26 Feb 2003 11:20:08 -0500

Haixiang

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Feb 2003 22:42:46 +0200 (EET)

On Wed, 26 Feb 2003, Haixiang He wrote:
> I personally don't think it is fair to compare a multicast routing
> function with non multicast routing function.

IMO, I feel this is very fair, even required.  That is one usage case of
IGMP proxying as far as I see it.

> IGMP/MLD. IGMP/MLD proxy depends on the downstream IGMP/MLD subscriptions.

IGMP/MLD proxy changes the assumptions of IGMP/MLD.  The assumption of 
IGMP/MLD is that the reports are directly received by the designated 
router.  This is no longer the case.

> If an ethernet switch has PIM and forward traffic based on IP address, do you call

I'd call such a router.

But that's not what I was talking about, of course.  A honest-to-god,
Layer 2 ethernet switch, forwarding traffic by MAC address, implementing
IGMP/MLD proxying (and possibly IGMP/MLD snooping).  These seem to be
quite common around here, at least.  Actually, we have a bunch of *Nortel*
switches doing this.
 
> forwarding bases on IGMP/MLD subscriptions.

The title does not take a stance on how the forwarding occurs: at IP layer
or at L2.  You can still forward the multicast frames below IP layer, and 
use the mechanisms specified in this memo as an extra guidance.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Feb 2003 22:42:46 +0200 (EET)

I'd call such a router.

---

From: Haixiang He <[email-masked]>
Date: Wed, 26 Feb 2003 17:01:30 -0500

> router.  This is no longer the case.

I don't understand how proxy changes the assumptions. IMO, the reports are directly
received by routers that perform IGMP/MLD Proxying  instead of PIM or DVMRP.

Where do you think a PIM router should enforce the access control for IGMP joins, in PIM
or in IGMP?

> quite common around here, at least.  Actually, we have a bunch of *Nortel*

Let's try it again. If an ethernet switch has only one upstream link and performs PIM on
that link,  it has many downstream links and performs IGMP router part on downstream
links,  and it forwards traffic by MAC address, do you call it a router or a switch?

---

From: Haixiang He <[email-masked]>
Date: Wed, 26 Feb 2003 17:01:30 -0500

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 09:21:08 +0200 (EET)

On Wed, 26 Feb 2003, Haixiang He wrote:
> I don't understand how proxy changes the assumptions. 

See below.

> IMO, the reports are directly

This is true.  

But I'm sure that you agree that "routers performing IGMP/MLD proxying"
and "routers performing PIM or DVMRP" are two different sets of devices?

Previously, *all* devices participating in the multicast forwarding 
process (whether at IP layer or below) had access to directly received 
reports.

Now, this is no longer the case "routers performing PIM or DVMRP" do no 
longer get these unaggregated, direct reports ig there are "routers 
performing IGMP/MLD proxying" in between.

This is a change.

I don't say it's necessarily a critical or even major change, but a change 
nevertheless, and should be spelled out.

> Where do you think a PIM router should enforce the access control for
> IGMP joins, in PIM or in IGMP?

IGMP joins generate PIM joins; for validating that originating PIM join is 
valid, IGMP join must also be validated.

I don't know where to enforce the access control, I haven't formed an
opinion -- so I think we should not close the door on *either*, at least
without documenting we're doing so!

> links,  and it forwards traffic by MAC address, do you call it a router or a switch?

I don't know, perhaps an "intelligent switch having PIM router
functionality".  I haven't come across many of these, and it wasn't my
point.

If an ethernet switch has only one upstream link and performs IGMP
proxying (IGMP host part) on that link, it has many downstream links and
performs IGMP router part on downstream links, and it forwards traffic by
MAC address, do you call it a router or a switch?

That's my question, and I believe you'd say "switch", which was the point.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 09:21:08 +0200 (EET)

See below.

This is true.  

This is a change.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Feb 2003 07:46:14 -0500

Pekka & Haixiang,
      Let me try and bring these issues to a close...

Pekka Savola wrote:
 >>>>>> IMHO, you are discussing a bigger problem: access control
 >>>>>> and it is really outside the scope of this draft. I have
 >>>>>> been focusing on solving IGMP access control:
 >>>>>> authentication and authorization and I am glad that you
 >>>>>> have similar concern especially for PIM.
 >>>>>
 >>>>> Well, I don't think the issue should be discussed in detail,
 >>>>> but I'd like to have it mentioned (as one potential issue)
 >>>>> somewhere.
 >>>>
 >>>> If the access control needs to be addressed, IMHO it should be
 >>>> addressed in the IGMP/MLD. IGMP/MLD proxy depends on the
 >>>> downstream IGMP/MLD subscriptions.
 >>>
 >>> IGMP/MLD proxy changes the assumptions of IGMP/MLD.  The
 >>> assumption of IGMP/MLD is that the reports are directly received
 >>> by the designated router.  This is no longer the case.
 >>
 >> IMO, the reports are directly received by routers that perform
 >> IGMP/MLD Proxying  instead of PIM or DVMRP.
 >
 >
 > This is true.
 >
 >
 > But I'm sure that you agree that "routers performing IGMP/MLD
 > proxying" and "routers performing PIM or DVMRP" are two different
 > sets of devices?

Yes.  These are two different types of devices.  However, they
are both making forwarding decisions based on L3 information.
That is the only way that the proxy knows to aggregate the
IGMP/MLD information in order to send it upstream.

 > process (whether at IP layer or below) had access to directly
 > received reports.
 >
 > Now, this is no longer the case "routers performing PIM or DVMRP" do
 > no longer get these unaggregated, direct reports ig there are
 > "routers performing IGMP/MLD proxying" in between.
 >
 > This is a change.
 >
 > I don't say it's necessarily a critical or even major change, but a
 > change nevertheless, and should be spelled out.
 >

The operator who deploys a proxy will be aware that the upstream
multicast router WILL NOT get the unaggregated IGMP/MLD messages.
Given that the operator knows this, I would assume that if some
type of IGMP/MLD access authorization is used all the devices behind
the proxy will be given the same level of access/authorization.

The other option that exists here is for vendors of such proxy
devices to offer access/authorization capability within the
proxy itself.

So, from the specification point of view, I would suggest that
we add text to the Security Considerations section that points
this out.  Nominally, it is a short paragraph that states that
the information being presented to the upstream router has been
aggregated from possibly multiple receivers.

 >
 >> Where do you think a PIM router should enforce the access control
 >> for IGMP joins, in PIM or in IGMP?
 >
 >
 > IGMP joins generate PIM joins; for validating that originating PIM
 > join is valid, IGMP join must also be validated.
 >
 >  opinion -- so I think we should not close the door on *either*, at
 > least without documenting we're doing so!
 >

As I stated above, the level of validation will be the same for
all devices behind the proxy or the proxy can offer validation
services as well.

 >
 >>>> If an ethernet switch has PIM and forward traffic based on IP
 >>>> address, do you call it a switch or router?
 >>>
 >>> I'd call such a router.
 >>>
 >>> But that's not what I was talking about, of course.  A
 >>> honest-to-god, Layer 2 ethernet switch, forwarding traffic by MAC
 >>> address, implementing IGMP/MLD proxying (and possibly IGMP/MLD
 >>> snooping).  These seem to be quite common around here, at least.
 >>> Actually, we have a bunch of *Nortel* switches doing this.
 >>
 >> Let's try it again. If an ethernet switch has only one upstream
 >> link and performs PIM on that link,  it has many downstream links
 >> and performs IGMP router part on downstream links,  and it forwards
 >> traffic by MAC address, do you call it a router or a switch?
 >
 >
 > functionality".  I haven't come across many of these, and it wasn't
 > my point.
 >
 > proxying (IGMP host part) on that link, it has many downstream links
 > and performs IGMP router part on downstream links, and it forwards
 > traffic by MAC address, do you call it a router or a switch?
 >

In my opinion, the device could any of the above.  The key is not
only the multicast forwarding aspect,  but also the forwarding of
unicast as well as how the device learns the forwarding state.

For clarity, I would support changing the term "router" in the
spec to be "proxy device".  That is a nice generic term that
reflects what the device is doing without prejudicing anyone's
opinion of what the device COULD be.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Feb 2003 07:46:14 -0500

Pekka & Haixiang,

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 14:52:40 +0200 (EET)

>       Let me try and bring these issues to a close...

These sound very good to me.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 14:52:40 +0200 (EET)

---

From: Haixiang He <[email-masked]>
Date: Thu, 27 Feb 2003 09:45:13 -0500

Brian,

Thanks. One comment inline.

> devices to offer access/authorization capability within the

I personally really think if we want to do access/authorization for IGMP
joins, we have to do it during the IGMP process. This is because that
current IGMP does not track individual receiver in a network. So per
interface IGMP subscription already has some level of aggregation (e.g.,
individual receiver information is lost).

I will put a section as you suggested. I still believe there is no
difference between Proxy router or PIM router in this context if the Proxy
is treated a multicast router by a provider.

---

From: Haixiang He <[email-masked]>
Date: Thu, 27 Feb 2003 09:45:13 -0500

Brian,