--- 1/draft-ietf-mboned-driad-amt-discovery-09.txt 2019-12-12 12:13:14.792324789 -0800 +++ 2/draft-ietf-mboned-driad-amt-discovery-10.txt 2019-12-12 12:13:14.864326635 -0800 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) October 27, 2019 +Updates: 7450 (if approved) December 12, 2019 Intended status: Standards Track -Expires: April 29, 2020 +Expires: June 14, 2020 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-09 + draft-ietf-mboned-driad-amt-discovery-10 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource record named AMTRELAY when discovering AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 29, 2020. + This Internet-Draft will expire on June 14, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,37 +58,37 @@ 1.2.1. Relays and Gateways . . . . . . . . . . . . . . . . . 4 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Relay Discovery Operation . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Signaling and Discovery . . . . . . . . . . . . . . . . . 6 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 2.3.3. Connecting to Multiple Relays . . . . . . . . . . . . 12 2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 12 - 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 12 + 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 - 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 14 - 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 + 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 15 + 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 - 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 16 + 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 17 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 - 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 18 + 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 19 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 - 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 19 + 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 20 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 20 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 20 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 20 - 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 20 - 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 21 + 3.1.1. Internet Service Provider . . . . . . . . . . . . . . 21 + 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 22 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 23 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 23 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 24 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 25 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 25 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 25 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 26 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 26 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 26 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 27 @@ -97,22 +97,22 @@ 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 29 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 32 - Appendix A. Unknown RRType construction . . . . . . . . . . . . 33 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 + Appendix A. Unknown RRType construction . . . . . . . . . . . . 34 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address. AMT (Automatic Multicast Tunneling) is defined in [RFC7450], and provides a method to transport multicast traffic over a unicast tunnel, in order to traverse non-multicast-capable network segments. @@ -397,20 +397,28 @@ When the above conditions are met, the gateway has no path within its local network that can receive multicast traffic from the source IP of the (S,G). In this situation, the best way to find a relay that can forward the required traffic is to use information that comes from the operator of the sender. When the sender has configured an AMTRELAY RR, gateways can use the DRIAD mechanism defined in this document to discover the relay information provided by the sender. + Note that the DNS-SD service is not source-specific, so even though + several methods of finding a more local source of multicast traffic + connectivity are preferred where available to using a relay provided + by an AMTRELAY RR, a gateway further upstream would still be using + the AMTRELAY RR unless the upstream network has a peering or direct + connectivity that provides an alternative end-to-end multicast + transport path for the (S,G)'s traffic. + 2.3.2. Preference Ordering This section defines a preference ordering for relay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs algorithm to try candidate relays concurrently, but even gateways that do not implement a Happy Eyeballs algorithm SHOULD use this ordering, except as noted. When establishing an AMT tunnel to forward multicast data, it's very important for the discovery process to prioritize the network @@ -608,21 +615,21 @@ connection attempt as "generally when the TCP handshake completes". There is no normative definition of a connection in the AMT specification [RFC7450], and there is no TCP connection involved in an AMT tunnel. However, the concept of an AMT connection in the context of a Happy Eyeballs algorithm is a useful one, and so this section provides the following normative definition: - o An AMT connection is completed successfully when the gateway + o An AMT connection is established successfully when the gateway receives from a newly discovered relay a valid Membership Query message (Section 5.1.4 of [RFC7450]) that does not have the L flag set. See Section 2.5.5 of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. See Section 2.5.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source. To "cancel" this kind of AMT connection for the Happy Eyeballs @@ -737,21 +744,22 @@ received in a reasonable time, it's appropriate for the gateway to restart the discovery process. If the gateway restarts the discovery process multiple times consecutively for this reason, the timeout period SHOULD be adjusted to provide a random exponential back-off. The RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 4 seconds - and a RECOMMENDED maximum_timeout of 120 seconds. + and a RECOMMENDED maximum_timeout of 120 seconds (which is the + recommended minimum NAT mapping timeout described in [RFC4787]). Note that the recommended initial_timeout is larger than the initial timout recommended in the similar algorithm from Section 5.2.3.4.3 of [RFC7450]. This is to provide time for RPF Join propagation in the sending network. Although the timeout values may be administratively adjusted to support performance requirements, operators are advised to consider the possibility of join propagation delays between the sender and the relay when choosing an appropriate timeout value. Gateways restarting the discovery process because of an absence of @@ -907,25 +915,25 @@ As with the waiting process for the Relay Advertisement message from Section 5.2.3.4.3 of [RFC7450], the RECOMMENDED timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and a RECOMMENDED maximum_timeout of 120 seconds. 3. Example Deployments 3.1. Example Receiving Networks +3.1.1. Internet Service Provider -3.1.1. Tier 3 ISP - - One example of a receiving network is an ISP that offers multicast - ingest services to its subscribers, illustrated in Figure 3. + One example of a receiving network is an Internet Service Provider + (ISP) that offers multicast ingest services to its subscribers, + illustrated in Figure 3. In the example network below, subscribers can join (S,G)s with MLDv2 or IGMPv3 as described in [RFC4604], and the AMT gateway in this ISP can receive and forward multicast traffic from one of the example sending networks in Section 3.2 by discovering the appropriate AMT relays with a DNS lookup for the AMTRELAY RR with the reverse IP of the source in the (S,G). Internet ^ ^ Multicast-enabled @@ -1310,24 +1318,27 @@ established and secured. 6.2. Record-spoofing The AMTRELAY resource record contains information that SHOULD be communicated to the DNS client without being modified. The method used to ensure the result was unmodified is up to the client. There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to- - end DNSSEC validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel - to another secure source, a secure local channel on the host, DNS - over TLS [RFC7858] or HTTPS [RFC8484], or some other secure - mechanism. + end DNSSEC validation, or a secure connection to a trusted DNS server + that provides end-to-end safety, to prevent record-spoofing of the + response from the trusted server. The connection to the trusted + server can use any secure channel, such as with a TSIG [RFC2845] or + SIG(0) [RFC2931] channel, a secure local channel on the host, DNS + over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism + that provides authentication of the RR. If an AMT gateway accepts a maliciously crafted AMTRELAY record, the result could be a Denial of Service, or receivers processing multicast traffic from a source under the attacker's control. 6.3. Congestion Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks, as described in Section 4 of [RFC8085]. @@ -1343,21 +1354,23 @@ attack. 7. Acknowledgements This specification was inspired by the previous work of Doug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented in the MBONED working group at IETF 93. Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill - Atwood, Tim Chown, and Warren Kumari for their very helpful comments. + Atwood, Tim Chown, Warren Kumari, Dan Romanescu, Bernard Aboba, + Carlos Pignataro, and Niclas Comstedt for their very helpful reviews + and comments. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and @@ -1455,20 +1468,25 @@ July 2003, . [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, . + [RFC5110] Savola, P., "Overview of the Internet Multicast Routing Architecture", RFC 5110, DOI 10.17487/RFC5110, January 2008, . [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, . [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel