--- 1/draft-ietf-mboned-driad-amt-discovery-08.txt 2019-10-27 20:13:11.252508685 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-09.txt 2019-10-27 20:13:11.320510413 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) June 14, 2019 +Updates: 7450 (if approved) October 27, 2019 Intended status: Standards Track -Expires: December 16, 2019 +Expires: April 29, 2020 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-08 + draft-ietf-mboned-driad-amt-discovery-09 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,93 +26,93 @@ 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 December 16, 2019. + This Internet-Draft will expire on April 29, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 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. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Optimal Relay Selection . . . . . . . . . . . . . . . . . 8 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 - 2.3.2. Connection Definition . . . . . . . . . . . . . . . . 9 - 2.4. Optimal Relay Selection . . . . . . . . . . . . . . . . . 9 - 2.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 9 - 2.4.2. Preference Ordering . . . . . . . . . . . . . . . . . 10 - 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 - 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 - 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14 - 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15 - 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 - 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17 - 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 - 2.5.7. Independent Discovery Per Traffic Source . . . . . . 18 - 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18 - 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18 - 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19 - 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 - 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 - 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 - 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22 - 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22 - 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23 - 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24 - 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24 - 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24 - 4.2.1. RData Format - Precedence . . . . . . . . . . . . . . 25 - 4.2.2. RData Format - Discovery Optional (D-bit) . . . . . . 25 - 4.2.3. RData Format - Type . . . . . . . . . . . . . . . . . 25 - 4.2.4. RData Format - Relay . . . . . . . . . . . . . . . . 26 - 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 26 - 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 26 - 4.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . 27 - - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 6.1. Use of AMT . . . . . . . . . . . . . . . . . . . . . . . 28 - 6.2. Record-spoofing . . . . . . . . . . . . . . . . . . . . . 28 - 6.3. Congestion . . . . . . . . . . . . . . . . . . . . . . . 29 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 - 8.2. Informative References . . . . . . . . . . . . . . . . . 31 - Appendix A. Unknown RRType construction . . . . . . . . . . . . 32 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 + 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.2. Algorithm Guidelines . . . . . . . . . . . . . . . . 13 + 2.4.3. Connection Definition . . . . . . . . . . . . . . . . 14 + 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 14 + 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 14 + 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 15 + 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 16 + 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 16 + 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 18 + 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 18 + 2.5.7. Independent Discovery Per Traffic Source . . . . . . 19 + 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 19 + 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.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 + 4.3. AMTRELAY Record Presentation Format . . . . . . . . . . . 27 + 4.3.1. Representation of AMTRELAY RRs . . . . . . . . . . . 27 + 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 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. @@ -239,21 +239,21 @@ index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as described in Section 2.5 of [RFC3596]). This mechanism should be treated as an extension of the AMT relay discovery procedure described in Section 5.2.3.4 of [RFC7450]. A gateway that supports this method of AMT relay discovery SHOULD use this method whenever it's performing the relay discovery procedure, and the source IP addresses for desired (S,G)s are known to the gateway, and conditions match the requirements outlined in - Section 2.4. + Section 2.3. Some detailed example use cases are provided in Section 3, and other applicable example topologies appear in Section 3.3 of [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 2.2. Signaling and Discovery This section describes a typical example of the end-to-end process for signaling a receiver's join of an SSM channel that relies on an AMTRELAY RR. @@ -318,22 +318,22 @@ contains the domain name "15.100.51.198.in-addr.arpa.", which is the reverse lookup domain name for his sender. The zone file contains an AMTRELAY RR with the Relay's IP address. (See Section 4.3 for details about the AMTRELAY RR format and semantics.) The sequence of events depicted in Figure 2 is as follows: 1. The end user starts the app, which issues a join to the (S,G): (198.51.100.15, 232.252.0.2). - 2. The join propagates with RPF through the multicast-enabled - network with PIM [RFC7761] or another multicast routing + 2. The join propagates with RPF through the receiver's multicast- + enabled network with PIM [RFC7761] or another multicast routing mechanism, until the AMT gateway receives a signal to join the (S,G). 3. The AMT gateway performs a reverse DNS lookup for the AMTRELAY RRType, by sending an AMTRELAY RRType query for the FQDN "15.100.51.198.in-addr.arpa.", using the reverse IP domain name for the sender's source IP address (the S from the (S,G)), as described in Section 3.5 of [RFC1035]. The DNS resolver for the AMT gateway uses ordinary DNS recursive @@ -343,62 +343,24 @@ 4. The AMT gateway performs AMT handshakes with the AMT relay as described in Section 4 of [RFC7450], then forwards a Membership report to the relay indicating subscription to the (S,G). 5. The relay propagates the join through its network toward the sender, then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as native multicast through its downstream network to the end user. -2.3. Happy Eyeballs +2.3. Optimal Relay Selection 2.3.1. Overview - Often, multiple choices of relay will exist for a gateway using DRIAD - for relay discovery. It is RECOMMENDED that DRIAD-capable gateways - implement a Happy Eyeballs [RFC8305] algorithm to support connecting - to multiple relays in parallel. - - The parallel discovery logic of a Happy Eyeballs algorithm serves to - reduce join latency for the initial join of an SSM channel. This - section and Section 2.4.2 taken together provide guidance on use of a - Happy Eyeballs algorithm for the case of establishing AMT - connections. - -2.3.2. Connection Definition - - Section 5 of [RFC8305] non-normatively describes success at a - 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 - 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. - -2.4. Optimal Relay Selection - -2.4.1. Overview - The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway to discover a relay that is known to the sender. However, it is NOT necessarily a good way to discover the best relay for that gateway to use, because the RR will only provide information about relays known to the source. If there is an upstream relay in a network that is topologically closer to the gateway and able to receive and forward multicast traffic from the sender, that relay is better for the gateway to use, @@ -435,26 +397,27 @@ 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. -2.4.2. Preference Ordering +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, but even gateways that do not implement a - Happy Eyeballs algorithm SHOULD use this ordering, except as noted. + 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 topology considerations ahead of address selection considerations, in order to gain the packet replication benefits from using multicast instead of unicast tunneling in the multicast-capable portions of the network path. The intent of the advice and requirements in this section is to describe how a gateway should make use of the concurrency provided by @@ -551,33 +514,130 @@ Section 2.5.5. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection, and are also not part of the superseding considerations described above. The discovery and connection process for the relay addresses in the above described ordering MAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5 of [RFC8305] for successively launched concurrent connection attempts. -2.4.3. Connecting to Multiple Relays +2.3.3. Connecting to Multiple Relays In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic, in order to support an active/active failover model. A gateway SHOULD NOT be configured to do so without guaranteeing that adequate bandwidth is available. A gateway configured to do this SHOULD still use the same preference - ordering logic from Section 2.4.2 for each connection. (Note that + ordering logic from Section 2.3.2 for each connection. (Note that this ordering allows for overriding by explicit administrative configuration where required.) +2.4. Happy Eyeballs + +2.4.1. Overview + + Often, multiple choices of relay will exist for a gateway using DRIAD + for relay discovery. Happy Eyeballs [RFC8305] provides a widely + deployed and generalizable strategy for probing multiple possible + connections in parallel, therefore it is RECOMMENDED that DRIAD- + capable gateways implement a Happy Eyeballs algorithm to support fast + discovery of the most preferred available relay, by probing multiple + relays concurrently. + + The parallel discovery logic of a Happy Eyeballs algorithm serves to + reduce join latency for the initial join of an SSM channel. This + section and the preference ordering of relays defined in + Section 2.3.2 taken together provide guidance on use of a Happy + Eyeballs algorithm for the case of establishing AMT connections. + + Note that according to the definition in Section 2.4.3 of this + document, establishing the connection occurs before sending a + membership report. As described in Section 5 of [RFC8085], only one + of the successful connections will be used, and the others are all + canceled or ignored. In the context of an AMT connection, this means + the gateway will send the membership reports that subscribe to + traffic only for the chosen connection, after the Happy Eyeballs + algorithm resolves. + +2.4.2. Algorithm Guidelines + + During the "Initiation of asynchronous DNS queries" phase described + in Section 3 of [RFC8305]), a gateway attempts to resolve the domain + names listed in Section 2.3. This consists of resolving the SRV + queries for DNS-SD domains for the AMT service, as well as the + AMTRELAY query for the reverse IP domain defined in this document. + + Each of the SRV and AMTRELAY responses might contain one or more IP + addresses, (as with type 1 or type 2 AMTRELAY responses, or when the + SRV Additional Data section of the SRV response contains the address + records for the target, as urged by [RFC2782]), or they might contain + only domain names (as with type 3 responses from Section 4.2.3, or an + SRV response without an additional data section). + + When present, IP addresses in the initial response provide resolved + destination address candidates for the "Sorting of resolved + destination addresses" phase described in Section 4 of [RFC8085]), + whereas domain names without IP addresses in the initial response + result in another set of queries for AAAA and A records, whose + responses provide the candidate resolved destination addresses. + + Since the SRV or AMTRELAY responses don't have a bound on the count + of queries that might be generated aside from the bounds imposed by + the DNS resolver, it's important for the gateway to provide a rate + limit on the DNS queries. The DNS query functionality is expected to + follow ordinary standards and best practices for DNS clients. A + gateway MAY use an existing DNS client implementation that does so, + and MAY rely on that client's rate limiting logic to avoid issuing + excessive queries. Otherwise, a gateway MUST provide a rate limit + for the DNS queries, and its default settings MUST NOT permit more + than 10 queries for any 100-millisecond period (though this MAY be + overridable by administrative configuration). + + As the resolved IP addresses arrive, the Happy Eyeballs algorithm + sorts them according to the requirements and recommendations given in + Section 2.3.2, and attempts connections with the corresponding relays + under the algorithm restrictions and guidelines given in [RFC8085] + for the "Establishment of one connection, which cancels all other + attempts" phase. + +2.4.3. Connection Definition + + Section 5 of [RFC8305] non-normatively describes success at a + 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 + 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 + algorithm, a gateway that has not sent a membership report with a + subscription would simply stop sending AMT packets for that + connection. A gateway only sends a membership report to a connection + it has chosen as the most preferred available connection. + 2.5. Guidelines for Restarting Discovery 2.5.1. Overview It's expected that gateways deployed in different environments will use a variety of heuristics to decide when it's appropriate to restart the relay discovery process, in order to meet different performance goals (for example, to fulfill different kinds of service level agreements). @@ -748,21 +807,21 @@ 2.5.5. Relay Loaded or Shutting Down The L flag (see Section 5.1.4.4 of [RFC7450]) is the preferred mechanism for a relay to signal overloading or a graceful shutdown to gateways. A gateway that supports handling of the L flag should generally restart the discovery process when it processes a Membership Query packet with the L flag set. If an L flag is received while a concurrent Happy Eyeballs discovery process is under way for multiple - candidate relays (Section 2.3), the relay sending the L flag SHOULD + candidate relays (Section 2.4), the relay sending the L flag SHOULD NOT be considered for the relay selection. It is also RECOMMENDED that gateways avoid choosing a relay that has recently sent an L flag, with approximately a 10-minute hold-down. Gateways SHOULD treat this hold-down timer in the same way as the hold-down in Section 2.5.4.1, so that the relay is removed from consideration for short-term subsequent rounds of discovery. 2.5.6. Relay Discovery Messages vs. Restarting Discovery @@ -1283,22 +1342,22 @@ that don't follow UDP congestion control principles, or deliberate 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, and Bill - Atwood for their very helpful comments. + Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill + Atwood, Tim Chown, and Warren Kumari for their very helpful 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 @@ -1307,20 +1366,25 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + DOI 10.17487/RFC2782, February 2000, + . + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, .