--- 1/draft-ietf-mboned-driad-amt-discovery-05.txt 2019-05-06 12:13:13.815427677 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-06.txt 2019-05-06 12:13:13.895429696 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) April 25, 2019 +Updates: 7450 (if approved) May 06, 2019 Intended status: Standards Track -Expires: October 27, 2019 +Expires: November 7, 2019 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-05 + draft-ietf-mboned-driad-amt-discovery-06 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 October 27, 2019. + This Internet-Draft will expire on November 7, 2019. 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 @@ -535,23 +535,23 @@ Among relay addresses that still have an equivalent preference after the above orderings, a gateway MUST make a non-deterministic choice for relay preference ordering, in order to support load balancing by DNS configurations that provide many relay options. The gateway MAY introduce a bias in the non-deterministic choice according to information obtained out of band or from a historical record about network topology, timing information, or the response to a probing mechanism, that indicates some expected benefits from selecting some relays in preference to others. Details about the - structure and collection of this information is out of scope for this - document, but a gateway in possession of such information MAY use it - to prefer topologically closer relays. + structure and collection of this information are out of scope for + this document, but a gateway in possession of such information MAY + use it to prefer topologically closer relays. Note also that certain relay addresses may be excluded from consideration by the hold-down timers described in Section 2.5.4.1 or 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 @@ -1240,24 +1240,26 @@ 6. Security Considerations 6.1. Use of AMT This document defines a mechanism that enables a more widespread and automated use of AMT, even without access to a multicast backbone. Operators of networks and applications that include a DRIAD-capable AMT gateway are advised to carefully consider the security considerations in Section 6 of [RFC7450]. - AMT gateway operators also are encouraged to implement the - opportunistic use of IPSec [RFC4301] when IPSECKEY records [RFC4025] - are available to secure traffic from AMT relays, or when a trust - relationship with the AMT relays can be otherwise secured. + AMT gateway operators also are encouraged to take appropriate steps + to ensure the integrity of the data received via AMT, for example by + the opportunistic use of IPSec [RFC4301] to secure traffic received + from AMT relays, when IPSECKEY records [RFC4025] are available or + when a trust relationship with the AMT relays can be otherwise + 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