[MBONED] draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution

["TARAPORE, PERCY S" <[e-mail]>]

Hi All,

We received comments from Hitoshi & Jake about this BCP during this Last Call - see attached emails. We have made many changes based on these comments. - see attached draft. Some of these changes impact previously agreed upon text and hence we want concurrence from all parties before we finalize the changes and upload the next revision. All changes in the draft are accompanied by Comments on the side indicating the source of the suggested change.

So here is a brief summary of our proposed changes.


1.     Hitoshi Comment 1: On Page 3, we have changed the RFC references as requested.

2.     Hitoshi Comment 2: On page 4, the reference to "draft-acq" is removed and the phrase "receiver's router" is changed to "receiver's upstream router". However these changes impact previously agreed upon text from Mikael Abrahamsson and Tim Chown. Mikael and Tim, can you please confirm whether these changes are OK with you? If not, could you all work out acceptable text that we can include? Thanks.

3.     Hitoshi Comment 3: This comment deals with the term "manifest file" which is mentioned in several places in the draft. We have decided to delete this term altogether. We have made several changes indicating that the main point here is the delivery of the appropriate information in the form of metadata that provides the End User with the "S, G" information at a minimum. See our changes on Pages 5, 16, 18, 19 & 20. Please let us know if these changes adequately resolve this comment.

4.     Jake Comment 1: On Page 4, Jake requested an additional reference inclusion for RFC4607 that answers the question "Why Not ASM". However per previous Last Call comment resolution, we have removed all mention of ASM in the preceding paragraph. To add a reference here that now answers the question "Why Not ASM" is therefore a little ambiguous? Hence we are hesitant to do this. However if you can provide appropriate text that deals with this either at the impacted sentence on Page 4 or elsewhere, we would be happy to discuss further.

5.     Jake Comment 2: This is about the manifest file. See the resolution per Hitoshi Comment 3.

6.     Jake Comment 3: On Pages 26 and 27 we have added text to state that the authentication is done at the application layer independent of AD-2.

7.     Jake Comment 4: Per interaction with Lenny, Jake has withdrawn this concern. However we have added the sentence proposed by Jake - see page 15.

Please let us know if these changes adequately address your concerns.

Thanks in advance

Percy & Bob

--- Begin Message ---

Hi,

> On 16 Aug 2016, at 09:25, Hitoshi Asaeda <[e-mail]> wrote:
>
> 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.)

Fair comment.

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

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.

> 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 wishes,
Tim

> Best,
> --
> Hitoshi Asaeda
>
>
>
>
>> 2016/08/12 7:13, Greg Shepherd <[e-mail]> wrote:
>>
>> 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
>> _______________________________________________
>> MBONED mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mboned
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned

--- End Message ---

--- Begin Message ---

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

On 8/16/16, 2:47 PM, "Leonard Giuliano" <[e-mail]> wrote:

>
>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 <[e-mail]>
>| Reply-To: "[e-mail]" <[e-mail]>
>| Date: Thursday, August 11, 2016 at 3:13 PM
>| To: "[e-mail]" <[e-mail]>
>| 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
>|

_______________________________________________
MBONED mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned

--- End Message ---

--- Begin Message ---

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 <[e-mail]> wrote:
>
> 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
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned

--- End Message ---