Skip to main content

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
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]