Use of Multicast Across Inter-Domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8313.
|
|
---|---|---|---|
Authors | Percy Tarapore , Robert Sayko , Greg Shepherd , Toerless Eckert , Ramki Krishnan | ||
Last updated | 2016-03-21 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
TSVART Telechat review
(of
-11)
by Yoshifumi Nishida
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 8313 (Best Current Practice) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-mboned-interdomain-peering-bcp-02
#x27;s to facilitate information sharing related to diagnostic troubleshooting. o A default resolution period may be considered to resolve open issues. Alternately, mutually acceptable resolution periods Tarapore, et al Expires July 20, 2016 [Page 24] IETF I-D Use of Multicast Across Inter-Domain Peering Points Jan 2015 could be established depending on the severity of the identified trouble. 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. Additionally: o Encryption - Peering point links may be encrypted per agreement if dedicated for multicast delivery. o Security Breach Mitigation Plan - In the event of a security breach, the two AD's are expected to have a mitigation plan for shutting down the peering point and directing multicast traffic over alternated peering points. It is also expected that appropriate information will be shared for the purpose of securing the identified breach. DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source provider and/or AD-1. AD-1 needs to work out the appropriate agreements with the source provider. Network has no DRM responsibilities, but might have authentication and authorization obligations. These though are consistent with normal operations of a CDN to insure end user reliability, security and network security. 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] style filtering could be deployed by both AD's to ensure that only legitimately sourced multicast content is exchanged between them. 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). Tarapore, et al Expires July 20, 2016 [Page 25] IETF I-D Use of Multicast Across Inter-Domain Peering Points Jan 2015 7. IANA Considerations 8. Conclusions This Best Current Practice document provides detailed Use Case scenarios for the transmission of applications via multicast across peering points between two Administrative Domains. A detailed set of guidelines supporting the delivery is provided for all Use Cases. For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is recommended that proper procedures are implemented such that the various AMT Gateways (at the End User devices and the AMT nodes in AD-2) are able to find the correct AMT Relay in other AMT nodes as appropriate. Section 4.3 provides an overview of one method that finds the optimal Relay-Gateway combination via the use of an Anycast IP address for AMT Relays. 9. References 9.1. Normative References [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- ietf-mboned-auto-multicast-13, April 2012, Work in progress [RFC4604] H. Holbrook, et al, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, August 2006 [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, August 2006 [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", RFC 3618, October 2003 Tarapore, et al Expires July 20, 2016 [Page 26] IETF I-D Use of Multicast Across Inter-Domain Peering Points Jan 2015 [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP: 38, May 2000 9.2. Informative References [INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a Multi-Party Federation Environment", ATIS Standard A-0200010, December 2012 [MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D draft-ietf-mboned-mdh-04.txt, May 2000 [Traceroute] http://traceroute.org/#source%20code 10. Acknowledgments Tarapore, et al Expires July 20, 2016 [Page 27] IETF I-D Use of Multicast Across Inter-Domain Peering Points Jan 2015 Authors' Addresses Percy S. Tarapore AT&T Phone: 1-732-420-4172 Email: tarapore@att.com Robert Sayko AT&T Phone: 1-732-420-3292 Email: rs1983@att.com Greg Shepherd Cisco Phone: Email: shep@cisco.com Toerless Eckert Cisco Phone: Email: eckert@cisco.com Ram Krishnan Brocade Phone: Email: ramk@brocade.com Tarapore, et al Expires July 20, 2016 [Page 28]