Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

From: Greg Shepherd <[email-masked]>
Date: Thu, 11 Aug 2016 15:13:20 -0700

WG,

The latest rev reflects input from the group.
Please read and respond.

https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/

Two week timer ends Aug 25th.

Thanks,
Chairs

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 11 Aug 2016 22:23:05 +0000

Approve

Percy

Sent from my iPhone

On Aug 11, 2016, at 6:13 PM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

WG,

Thanks,
Chairs
_______________________________________________
MBONED mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mboned

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Mon, 15 Aug 2016 13:31:39 +0000

I vote to accept!!

Robert Sayko
Principal Member of Tech Staff
AT&T Labs
732-420-3292
[email-masked]<mailto:[email-masked]>

From: MBONED [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, August 11, 2016 6:13 PM
To: [email-masked]
Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

WG,

Thanks,
Chairs

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 15 Aug 2016 17:28:05 +0000

This looks good to me too. Thanks.

Bert

From: MBONED [mailto:[email-masked]] On Behalf Of SAYKO, ROBERT J
Sent: Monday, August 15, 2016 09:32
To: [email-masked]; [email-masked]
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

I vote to accept!!

Robert Sayko

From: MBONED [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, August 11, 2016 6:13 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

WG,

Thanks,
Chairs

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 16 Aug 2016 17:25:25 +0900

Hi,

I’ve read this draft and have a few questions and comments.

1. For the following sentence in Introduction;
   "It is understood that several protocols are available for this
   purpose including PIM-SM, Protocol Independent Multicast -
   Source Specific Multicast (PIM-SSM) [RFC4607], Internet Group
   Management Protocol (IGMP) [RFC4604], Multicast Listener
   Discovery (MLD) [RFC4604]."
Regarding IGMP's and MLD's references, although there are errata in RFC3376 and 3810, IMO, RFC3376 and 3810 are the RFCs for IGMPv3 and MLDv2, respectively. Do you think using RFC4604 for IGMP/MLD references is correct?
In addition, for PIM-SM's reference, RFC7761 should be used. For PIM-SSM, I don't know whether using RFC4607 is suitable or not. (I would use RFC7761 for PIM-SSM as well, though.)

2. For the following sentence in Introduction;
    "Under this condition, PIM-SSM use is beneficial for the reasons
    stated in [draft-acq], e.g., it allows the receiver's router
    to directly send a JOIN message to the source without the need
    of invoking an intermediate Rendezvous Point (RP)."
Is it necessary to refer [draft-acq] here as the normative reference for this sentence? Above explanation is straightforward (if you refer PIM-SSM’s RFC); therefore you can just say; "PIM-SSM use is beneficial as it allows ..."
BTW, "receiver’s router" should be "receiver's upstream router".

3. Regarding "manifest file";
In this document, "manifest file" is used without its detail definition.
In section 4.2.1, there is a description, "typically known as the manifest file" and in section 4.2.3 it is briefly explained, but I cannot understand how it is created and distributed to whom.
Section 4.3.1 says "this file must be provided to the EU regarding multicast URL - and unicast fallback if applicable."
Is manifest file commonly used in IP multicast community recently and no explanation or reference needed? (And what is multicast URL?)

Best,
--
Hitoshi Asaeda

> 2016/08/12 7:13, Greg Shepherd <[email-masked]> wrote:
> 
> WG,
> 
> [email-masked]

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 16 Aug 2016 21:32:50 +0000

Hello,

Sorry for chiming in late. I have only recently joined the mboned mailing list and begun trying to make sure I understand everything I need to in order to contribute meaningfully to the discussion, so please forgive me and point me to the right references if there’s something essential I seem to have missed.

I reviewed some of the earlier mailing list discussion from the archive, and I have some remaining comments and questions that I think are relevant to this draft.

1. In the introduction where SSM-only is recommended (with “Hence, in the case of inter-domain peering, it is recommended to use only SSM protocols”), it may be useful to include a reference to https://tools.ietf.org/html/rfc4609#section-4.2, which recommends that inter-domain ASM (and MSDP) be retired on security grounds to avoid attacks.

I noticed in the email thread reviewing version 03 a request for a reference that was answered by pointing to RFC 4607, but I’d suggest that the recommendation from RFC 4609 addresses the question of “why not ASM?” more directly.

2. I am confused by the requirement that AD-2 would build a manifest, in section 4.3.1 (Provisioning Guidelines):

AD-2 must build manifest and provision capability to provide the file to the EU.

This seems to require that in addition to the need for AS and the EU to coordinate with each other using an application layer that can communicate successfully to deliver some content, AD-2 also must communicate with EU with formats that both parties understand at the application layer, rather than just providing transport for the multicast data.

The other 8 uses of the term “manifest” in the draft seem only to expect that the EU can obtain a manifest (usually just meaning “knowledge of the existence of a particular S,G”) via some means, not that AD-2 must build or understand it.

So I wanted to clarify: Is it intentional that AD-2 needs to participate at the application layer in the communications between AS and EU by building the manifest?

If so, should this BCP suggest any specific formats?  I ask because this seems a surprising expectation for use case 3.4, e.g., where AD-2 seems to have no other direct communication with EU/G, and which would have no such requirement if AD-2 were passing other UDP unicast packets that were not multicast data wrapped in AMT.

3. I am confused by the paragraph about token authentication in section 6 (security considerations):

   If there are problems related to failure of token authentication
   when end-users are supported by AD-2, then some means of validating
   proper working of the token authentication process (e.g., back-end
   servers querying the multicast application source provider's token
   authentication server are communicating properly) should be
   considered. Details will have to be worked out during implementation
   (e.g., test tokens or trace token exchange process).

I didn’t see token authentication mentioned elsewhere in the document, and I didn’t see a reference saying why there might be token authentication involved that the AD’s would know about.

Maybe I’m misunderstanding, but from context it looks to me like it’s suggesting there would be some association between the authentication of an end user and the multicast traffic transferred from AD-1 to AD-2, and that that association would be based on token authentication?

(I saw such an association mentioned in the discussion of “accounts” in section 4.3.2, but that talks about AD-2 providing accounts to AD-1, and I think this talks about a token authentication server owned by the multicast application source provider, so I don’t think it’s the same?)

4. My last comment is about another security consideration about a DoS attack I’ve been calling “overjoining”.

The attack involves an attacker gaining control (possibly remotely) of at least 1 EU machine and using his control of the machine to join enough high-volume channels to overflow the bandwidth allocated to multicast traffic into AD-2, thus forcing the bandwidth cap to drop packets, and resulting in a DoS against all other clients receiving any multicast via AD-2.

I understand that there are some parts of the draft which speak to this issue, but I couldn’t see how they could prevent the problem. The sections I noticed included these 3:

a. Section 3.1 (Native Multicast):

     b. If the peering point between AD-1 and AD-2 is a controlled network
        environment, then bandwidth can be allocated accordingly by the
        two domains to permit the transit of non-rate adaptive multicast
        traffic. If this is not the case, then it is recommended that the
        multicast traffic should support rate-adaption.

b. Section 4.1 (Network Interconnection Transport and Security Guidelines):

     o Bandwidth Allocation - If shared with other services, then there

        needs to be a determination of the share of bandwidth reserved

        for multicast delivery.

c. Section 6 (Security Considerations):

   From a security perspective, normal security procedures are expected

   to be followed by each AD to facilitate multicast delivery to

   registered and authenticated end users.

...

   AD-1 and AD-2 should have mechanisms in place to ensure proper

   accounting for the volume of bytes delivered through the peering

   point and separately the number of bytes delivered to EUs. For

   example, [BCP38<https://tools.ietf.org/html/draft-ietf-mboned-interdomain-peering-bcp-04#ref-BCP38>] style filtering could be deployed by both AD's to

   ensure that only legitimately sourced multicast content is exchanged

   between them.

At first glance it seems that passage (a) above, recommending either a controlled network environment or use of only rate-adaptive multicast protocols, should solve this problem.

However, even if the sending side is using a rate-adaptive protocol such as FLUTE (https://tools.ietf.org/html/rfc6726), a rogue client can use IGMP to join the channels in a way that does not conform to the congestion control scheme available in FLUTE, which requires (non-malicious) clients to leave or avoid joining too many channels based on a congestion signal.

Likewise, passage (c) recommends filtering to ensure only legitimately sourced multicast content is exchanged, but https://tools.ietf.org/html/bcp38 only refers to ensuring that traffic is properly sourced, and provides no mechanism for ensuring that all receivers are legitimate.

Although section 6 calls for “normal security procedures” to facilitate delivery to registered and authenticated end users, preventing a rogue client from joining inappropriately high-bandwidth (S,G)’s at the IGMPv3/MLDv2 layer does not seem possible without some unspecified protocol extension, unless I’m missing something?

So as far as I can tell, as long as anywhere in the world, the aggregate bandwidth of all channels that are sending at a steady rate anywhere on a multicast backbone reachable via AD-1 exceeds the bandwidth allocated to multicast between AD-1 and AD-2, this vulnerability will be present. (Coupled with the assumption from section 4.3.1, “Native multicast functionality is assumed to be available across many ISP backbones, peering and access networks.”, or alternately if the aggregate bandwidth of all channels in AD-1 exceeds the allocated multicast bandwidth by more than a small portion.)

I haven’t yet understood a way to avoid this problem without making a new standard, so I’m hoping someone on this list can point me to an explanation I’ve missed.

I’m not sure whether this last point about overjoining should be in this document or written up separately, but I was considering trying to write this up under a name like “problems-with-interdomain-multicast”, and I realized when I saw this draft’s title that it might be a worthwhile topic to include, since one could argue it’s fundamentally a problem with interdomain multicast.

Again, apologies for my lateness in joining this conversation and for the length of the comments.

Cheers,
Jake

From: Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Thursday, August 11, 2016 at 3:13 PM
To: "[email-masked]" <[email-masked]>
Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

WG,

https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp_&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=PlnXUaiv5YHYV7-p_iO1SFYtWgEnD9G-ApfZAExBlHQ&s=KboWDGvQ6TaizsqcYm3SwqBJLMa5ND3SjgQ5ZMzI21U&e=>

Thanks,
Chairs

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 16 Aug 2016 14:47:56 -0700

Jake- regarding #4, I would say this is a UDP problem moreso than a 
multicast problem.  That is, a rogue host could do the same thing to 
overaccess too much UDP unicast content as well.

-Lenny

On Tue, 16 Aug 2016, Holland, Jake wrote:

| Hello,
| 
| Sorry for chiming in late. I have only recently joined the mboned mailing list and begun trying to make sure I understand everything I need to in order to contribute meaningfully to the discussion, so please forgive me and point me to the right references if there’s something essential I seem to have missed.
| 
| I reviewed some of the earlier mailing list discussion from the archive, and I have some remaining comments and questions that I think are relevant to this draft.
| 
| 
| 1. In the introduction where SSM-only is recommended (with “Hence, in the case of inter-domain peering, it is recommended to use only SSM protocols”), it may be useful to include a reference to https://tools.ietf.org/html/rfc4609#section-4.2, which recommends that inter-domain ASM (and MSDP) be retired on security grounds to avoid attacks.
| 
| I noticed in the email thread reviewing version 03 a request for a reference that was answered by pointing to RFC 4607, but I’d suggest that the recommendation from RFC 4609 addresses the question of “why not ASM?” more directly.
| 
| 
| 2. I am confused by the requirement that AD-2 would build a manifest, in section 4.3.1 (Provisioning Guidelines):
| 
| 
| AD-2 must build manifest and provision capability to provide the file to the EU.
| 
| This seems to require that in addition to the need for AS and the EU to coordinate with each other using an application layer that can communicate successfully to deliver some content, AD-2 also must communicate with EU with formats that both parties understand at the application layer, rather than just providing transport for the multicast data.
| 
| The other 8 uses of the term “manifest” in the draft seem only to expect that the EU can obtain a manifest (usually just meaning “knowledge of the existence of a particular S,G”) via some means, not that AD-2 must build or understand it.
| 
| So I wanted to clarify: Is it intentional that AD-2 needs to participate at the application layer in the communications between AS and EU by building the manifest?
| 
| If so, should this BCP suggest any specific formats?  I ask because this seems a surprising expectation for use case 3.4, e.g., where AD-2 seems to have no other direct communication with EU/G, and which would have no such requirement if AD-2 were passing other UDP unicast packets that were not multicast data wrapped in AMT.
| 
| 
| 3. I am confused by the paragraph about token authentication in section 6 (security considerations):
| 
|    If there are problems related to failure of token authentication
|    when end-users are supported by AD-2, then some means of validating
|    proper working of the token authentication process (e.g., back-end
|    servers querying the multicast application source provider's token
|    authentication server are communicating properly) should be
|    considered. Details will have to be worked out during implementation
|    (e.g., test tokens or trace token exchange process).
| 
| I didn’t see token authentication mentioned elsewhere in the document, and I didn’t see a reference saying why there might be token authentication involved that the AD’s would know about.
| 
| Maybe I’m misunderstanding, but from context it looks to me like it’s suggesting there would be some association between the authentication of an end user and the multicast traffic transferred from AD-1 to AD-2, and that that association would be based on token authentication?
| 
| (I saw such an association mentioned in the discussion of “accounts” in section 4.3.2, but that talks about AD-2 providing accounts to AD-1, and I think this talks about a token authentication server owned by the multicast application source provider, so I don’t think it’s the same?)
| 
| 
| 4. My last comment is about another security consideration about a DoS attack I’ve been calling “overjoining”.
| 
| The attack involves an attacker gaining control (possibly remotely) of at least 1 EU machine and using his control of the machine to join enough high-volume channels to overflow the bandwidth allocated to multicast traffic into AD-2, thus forcing the bandwidth cap to drop packets, and resulting in a DoS against all other clients receiving any multicast via AD-2.
| 
| I understand that there are some parts of the draft which speak to this issue, but I couldn’t see how they could prevent the problem. The sections I noticed included these 3:
| 
| a. Section 3.1 (Native Multicast):
| 
|      b. If the peering point between AD-1 and AD-2 is a controlled network
|         environment, then bandwidth can be allocated accordingly by the
|         two domains to permit the transit of non-rate adaptive multicast
|         traffic. If this is not the case, then it is recommended that the
|         multicast traffic should support rate-adaption.
| 
| b. Section 4.1 (Network Interconnection Transport and Security Guidelines):
| 
| 
|      o Bandwidth Allocation - If shared with other services, then there
| 
|         needs to be a determination of the share of bandwidth reserved
| 
|         for multicast delivery.
| 
| c. Section 6 (Security Considerations):
| 
| 
|    From a security perspective, normal security procedures are expected
| 
|    to be followed by each AD to facilitate multicast delivery to
| 
|    registered and authenticated end users.
| 
| ...
| 
| 
| 
|    AD-1 and AD-2 should have mechanisms in place to ensure proper
| 
|    accounting for the volume of bytes delivered through the peering
| 
|    point and separately the number of bytes delivered to EUs. For
| 
|    example, [BCP38<https://tools.ietf.org/html/draft-ietf-mboned-interdomain-peering-bcp-04#ref-BCP38>] style filtering could be deployed by both AD's to
| 
|    ensure that only legitimately sourced multicast content is exchanged
| 
|    between them.
| 
| 
| At first glance it seems that passage (a) above, recommending either a controlled network environment or use of only rate-adaptive multicast protocols, should solve this problem.
| 
| However, even if the sending side is using a rate-adaptive protocol such as FLUTE (https://tools.ietf.org/html/rfc6726), a rogue client can use IGMP to join the channels in a way that does not conform to the congestion control scheme available in FLUTE, which requires (non-malicious) clients to leave or avoid joining too many channels based on a congestion signal.
| 
| Likewise, passage (c) recommends filtering to ensure only legitimately sourced multicast content is exchanged, but https://tools.ietf.org/html/bcp38 only refers to ensuring that traffic is properly sourced, and provides no mechanism for ensuring that all receivers are legitimate.
| 
| Although section 6 calls for “normal security procedures” to facilitate delivery to registered and authenticated end users, preventing a rogue client from joining inappropriately high-bandwidth (S,G)’s at the IGMPv3/MLDv2 layer does not seem possible without some unspecified protocol extension, unless I’m missing something?
| 
| So as far as I can tell, as long as anywhere in the world, the aggregate bandwidth of all channels that are sending at a steady rate anywhere on a multicast backbone reachable via AD-1 exceeds the bandwidth allocated to multicast between AD-1 and AD-2, this vulnerability will be present. (Coupled with the assumption from section 4.3.1, “Native multicast functionality is assumed to be available across many ISP backbones, peering and access networks.”, or alternately if the aggregate bandwidth of all channels in AD-1 exceeds the allocated multicast bandwidth by more than a small portion.)
| 
| I haven’t yet understood a way to avoid this problem without making a new standard, so I’m hoping someone on this list can point me to an explanation I’ve missed.
| 
| 
| I’m not sure whether this last point about overjoining should be in this document or written up separately, but I was considering trying to write this up under a name like “problems-with-interdomain-multicast”, and I realized when I saw this draft’s title that it might be a worthwhile topic to include, since one could argue it’s fundamentally a problem with interdomain multicast.
| 
| 
| Again, apologies for my lateness in joining this conversation and for the length of the comments.
| 
| 
| Cheers,
| Jake
| 
| 
| 
| From: Greg Shepherd <[email-masked]>
| Reply-To: "[email-masked]" <[email-masked]>
| Date: Thursday, August 11, 2016 at 3:13 PM
| To: "[email-masked]" <[email-masked]>
| Subject: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp
| 
| WG,
| 
| The latest rev reflects input from the group.
| Please read and respond.
| 
| https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp_&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=PlnXUaiv5YHYV7-p_iO1SFYtWgEnD9G-ApfZAExBlHQ&s=KboWDGvQ6TaizsqcYm3SwqBJLMa5ND3SjgQ5ZMzI21U&e=>
| 
| Two week timer ends Aug 25th.
| 
| Thanks,
| Chairs
|

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 17 Aug 2016 17:58:15 +0000

Hi Lenny,

I mostly agree that over-sending is a UDP problem, except that unicast UDP can point to BCP 145/RFC 5405. It’s probably possible in principle for an operator to detect and suppress senders that don’t follow BCP 145 in unicast (or maybe even not following BCP 41/RFC2914, in terms of failure to respond to AQM behaviors from RFC 7141).

In unicast, doing so would be a reasonably effective defense against DoS against the other receivers sharing the same network. In contrast, multicast has problems that are not readily addressed by pointing to BCP 41 (or the inapplicable BCP 145, since it’s specific to unicast).

That said, I’ll withdraw that point as an objection to this draft, because if there are no current known best practices to address the issue for multicast beyond “set a bandwidth cap”, then it seems reasonable not to include them. I was just hoping someone might know an existing solution that could be recommended.

But equally, it might be nice to see a nod to BCP 41 in section  4.1 in the Bandwidth Allocation section. Something along the lines of “When determining the appropriate bandwidth allocation, parties should consider that design of a multicast transport protocol suitable for live video streaming which is consistent with Congestion Control Principles [BCP 41], especially in the presence of potentially malicious receivers, is still an open research problem.”

Cheers,
Jake

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 17 Aug 2016 11:14:45 -0700

Jake,
Inline:

On Wed, Aug 17, 2016 at 10:58 AM, Holland, Jake <[email-masked]> wrote:

> Hi Lenny,
>
> I mostly agree that over-sending is a UDP problem, except that unicast UDP
> can point to BCP 145/RFC 5405.

5405bis draft includes recommendations for multicast. It should obsolete
rfc5405

Greg

> It’s probably possible in principle for an operator to detect and suppress
> senders that don’t follow BCP 145 in unicast (or maybe even not following
> BCP 41/RFC2914, in terms of failure to respond to AQM behaviors from RFC
> 7141).
>
> In unicast, doing so would be a reasonably effective defense against DoS
> against the other receivers sharing the same network. In contrast,
> multicast has problems that are not readily addressed by pointing to BCP 41
> (or the inapplicable BCP 145, since it’s specific to unicast).
>
>
> That said, I’ll withdraw that point as an objection to this draft, because
> if there are no current known best practices to address the issue for
> multicast beyond “set a bandwidth cap”, then it seems reasonable not to
> include them. I was just hoping someone might know an existing solution
> that could be recommended.
>
> But equally, it might be nice to see a nod to BCP 41 in section  4.1 in
> the Bandwidth Allocation section. Something along the lines of “When
> determining the appropriate bandwidth allocation, parties should consider
> that design of a multicast transport protocol suitable for live video
> streaming which is consistent with Congestion Control Principles [BCP 41],
> especially in the presence of potentially malicious receivers, is still an
> open research problem.”
>
> Cheers,
> Jake
>
> >| Sorry for chiming in late. I have only recently joined the mboned
> mailing list and begun trying to make sure I understand everything I need
> to in order to contribute meaningfully to the discussion, so please forgive
> me and point me to the right references if there’s something essential I
> seem to have missed.
> >|
> >| I reviewed some of the earlier mailing list discussion from the
> archive, and I have some remaining comments and questions that I think are
> relevant to this draft.
> >|
> >|
> >| 1. In the introduction where SSM-only is recommended (with “Hence, in
> the case of inter-domain peering, it is recommended to use only SSM
> protocols”), it may be useful to include a reference to
> https://tools.ietf.org/html/rfc4609#section-4.2, which recommends that
> inter-domain ASM (and MSDP) be retired on security grounds to avoid attacks.
> >|
> >| I noticed in the email thread reviewing version 03 a request for a
> reference that was answered by pointing to RFC 4607, but I’d suggest that
> the recommendation from RFC 4609 addresses the question of “why not ASM?”
> more directly.
> >|
> >|
> >| 2. I am confused by the requirement that AD-2 would build a manifest,
> in section 4.3.1 (Provisioning Guidelines):
> >|
> >|
> >| This seems to require that in addition to the need for AS and the EU to
> coordinate with each other using an application layer that can communicate
> successfully to deliver some content, AD-2 also must communicate with EU
> with formats that both parties understand at the application layer, rather
> than just providing transport for the multicast data.
> >|
> >| The other 8 uses of the term “manifest” in the draft seem only to
> expect that the EU can obtain a manifest (usually just meaning “knowledge
> of the existence of a particular S,G”) via some means, not that AD-2 must
> build or understand it.
> >|
> >| So I wanted to clarify: Is it intentional that AD-2 needs to
> participate at the application layer in the communications between AS and
> EU by building the manifest?
> >|
> >| If so, should this BCP suggest any specific formats?  I ask because
> this seems a surprising expectation for use case 3.4, e.g., where AD-2
> seems to have no other direct communication with EU/G, and which would have
> no such requirement if AD-2 were passing other UDP unicast packets that
> were not multicast data wrapped in AMT.
> >|
> >|
> >| I didn’t see token authentication mentioned elsewhere in the document,
> and I didn’t see a reference saying why there might be token authentication
> involved that the AD’s would know about.
> >|
> >| Maybe I’m misunderstanding, but from context it looks to me like it’s
> suggesting there would be some association between the authentication of an
> end user and the multicast traffic transferred from AD-1 to AD-2, and that
> that association would be based on token authentication?
> >|
> >| (I saw such an association mentioned in the discussion of “accounts” in
> section 4.3.2, but that talks about AD-2 providing accounts to AD-1, and I
> think this talks about a token authentication server owned by the multicast
> application source provider, so I don’t think it’s the same?)
> >|
> >|
> >| The attack involves an attacker gaining control (possibly remotely) of
> at least 1 EU machine and using his control of the machine to join enough
> high-volume channels to overflow the bandwidth allocated to multicast
> traffic into AD-2, thus forcing the bandwidth cap to drop packets, and
> resulting in a DoS against all other clients receiving any multicast via
> AD-2.
> >|
> >| I understand that there are some parts of the draft which speak to this
> issue, but I couldn’t see how they could prevent the problem. The sections
> I noticed included these 3:
> >|
> >|    example, [BCP38<https://tools.ietf.org/
> html/draft-ietf-mboned-interdomain-peering-bcp-04#ref-BCP38>] style
> filtering could be deployed by both AD's to
> >|
> >| At first glance it seems that passage (a) above, recommending either a
> controlled network environment or use of only rate-adaptive multicast
> protocols, should solve this problem.
> >|
> >| However, even if the sending side is using a rate-adaptive protocol
> such as FLUTE (https://tools.ietf.org/html/rfc6726), a rogue client can
> use IGMP to join the channels in a way that does not conform to the
> congestion control scheme available in FLUTE, which requires
> (non-malicious) clients to leave or avoid joining too many channels based
> on a congestion signal.
> >|
> >| Likewise, passage (c) recommends filtering to ensure only legitimately
> sourced multicast content is exchanged, but https://tools.ietf.org/html/bc
> p38 only refers to ensuring that traffic is properly sourced, and
> provides no mechanism for ensuring that all receivers are legitimate.
> >|
> >| Although section 6 calls for “normal security procedures” to facilitate
> delivery to registered and authenticated end users, preventing a rogue
> client from joining inappropriately high-bandwidth (S,G)’s at the
> IGMPv3/MLDv2 layer does not seem possible without some unspecified protocol
> extension, unless I’m missing something?
> >|
> >| So as far as I can tell, as long as anywhere in the world, the
> aggregate bandwidth of all channels that are sending at a steady rate
> anywhere on a multicast backbone reachable via AD-1 exceeds the bandwidth
> allocated to multicast between AD-1 and AD-2, this vulnerability will be
> present. (Coupled with the assumption from section 4.3.1, “Native multicast
> functionality is assumed to be available across many ISP backbones, peering
> and access networks.”, or alternately if the aggregate bandwidth of all
> channels in AD-1 exceeds the allocated multicast bandwidth by more than a
> small portion.)
> >|
> >| I haven’t yet understood a way to avoid this problem without making a
> new standard, so I’m hoping someone on this list can point me to an
> explanation I’ve missed.
> >|
> >|
> >| I’m not sure whether this last point about overjoining should be in
> this document or written up separately, but I was considering trying to
> write this up under a name like “problems-with-interdomain-multicast”,
> and I realized when I saw this draft’s title that it might be a worthwhile
> topic to include, since one could argue it’s fundamentally a problem with
> interdomain multicast.
> >|
> >|
> >| https://datatracker.ietf.org/doc/draft-ietf-mboned-interdoma
> in-peering-bcp/<https://urldefense.proofpoint.com/v2/
> url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-
> 2Dmboned-2Dinterdomain-2Dpeering-2Dbcp_&d=DQMFaQ&c=96
> ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnE
> lT1Ook&m=PlnXUaiv5YHYV7-p_iO1SFYtWgEnD9G-ApfZAExBlHQ&s=KboWD
> GvQ6TaizsqcYm3SwqBJLMa5ND3SjgQ5ZMzI21U&e=>
> >|

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Aug 2016 14:07:36 +0000

Hi,

> On 16 Aug 2016, at 09:25, Hitoshi Asaeda <[email-masked]> wrote:
> 
> Hi,
> 

Fair comment.

> BTW, "receiver’s router" should be "receiver's upstream router”.

We had a discussion at the Berlin WG meeting around draft-acg-mboned-multicast-models-00, and what it should include and say. There was some good feedback, and I think as a result the draft will progress to at least another iteration to see if there’s interest in adoption.

There are sections in RFC7761 that can be highlighted as SSM benefits, e.g. 4.8 and 6.1.2.

At present there isn’t a single document where the rationale for favouring SSM is recommended, and I think the steer in Berlin was to focus on that, and trim down the “fat” on general models. I’ll listen back to the recording to check.

> Is manifest file commonly used in IP multicast community recently and no explanation or reference needed? (And what is multicast URL?)

Best wishes,
Tim

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 25 Aug 2016 14:24:10 +0000

Tim, Hitoshi, Jake,

We have been drafting revisions to the BCP based on comments received so far in this Last Call from Hitoshi & Jake. We will first send out our proposed revisions based on these comments to the email list to see if the revisions address the comments. In particular, the point raised here in Tim's response is critical to some of Hitoshi's & Jake's comments: If we make changes based on these comments, then some of the text that was agreed upon from the previous Last Call (in response to Mikael Abrahamsson & Tim Chown's comments) will be changed. Hence we will seek concurrence from all parties before we finalize the changes in the Draft and upload.

We will be sending out a revised version very shortly.

Thanks to all

Percy & Bob

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Thursday, August 25, 2016 10:08 AM
To: Hitoshi Asaeda <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp

Hi,

Fair comment.

Best wishes,
Tim