[MBONED] Benjamin Kaduk's No Objection on draft-ietf-mboned-driad-amt-discovery-11: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 19 December 2019 05:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mboned@ietf.org
Delivered-To: mboned@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24490120018; Wed, 18 Dec 2019 21:57:45 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mboned-driad-amt-discovery@ietf.org, Tim Chown <tim.chown@jisc.ac.uk>, mboned-chairs@ietf.org, tim.chown@jisc.ac.uk, mboned@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157673506508.4859.18252907968152390250.idtracker@ietfa.amsl.com>
Date: Wed, 18 Dec 2019 21:57:45 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/ybGH13KMFCukKtY5WIxwupYNUJg>
Subject: [MBONED] Benjamin Kaduk's No Objection on draft-ietf-mboned-driad-amt-discovery-11: (with COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 05:57:45 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mboned-driad-amt-discovery-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this well-written document!  My comment are all pretty
minor (and many of them are more of a "side note" than actionable
comments, anyway...).

Section 1

   This document updates Section 5.2.3.4 of [RFC7450] by adding a new
   extension to the relay discovery procedure.

I know that there is not a universal usage of "updates", but note that
in other protocols with similar scenarios (multiple possible discovery
methods), the core protocol document is not always in an "Updated by"
relationship with the new discovery methods.  (That said, there seem to
be plenty of other ways in which this document updates RFC 7540, so this
particular instsance isn't a big deal.)

Section 1.2.2

   |     L flag | The "Limit" flag described in Section 5.1.1.4 of     |
   |            | [RFC7450]                                            |

nit: s/5.1.1.4/5.1.4.4/

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

nit: this is not quite the prescribed form from RFC 8174.

Section 2.2

Perhaps it's worth a brief note that the UDP unicast tunnel is over IPv6
even though the multicast traffic being conveyed is native IPv4 in both
multicast networks?

Section 2.3.2

      A related motivating example in the sending-side network is
      provided by considering a sender that needs to instruct the
      gateways on how to select between connecting to Figure 6 or
      Figure 7 (from Section 3.2), in order to manage load and failover
      scenarios in a manner that operates well with the sender's
      provisioning strategy for horizontal scaling of AMT relays.

I don't think I understand what "connecting to Figure 6" means.

   Among relay addresses that have an equivalent preference as described
   above, a Happy Eyeballs algorithm for AMT SHOULD use use the
   Destination Address Selection defined in Section 6 of [RFC6724].

   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway SHOULD make a non-deterministic choice

side note: I think that the way RFC 6724 is written (as a series of
comparison rules), it doesn't have an "are equivalent preference"
option, just a "leave the order unchanged" one.  But that's probably a
useless pedantic distinction and I can't see an actionable change that
would result from it.

Section 2.7

   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
   retry logic to determine the timeouts between retries.

The first part of this seems to be a duplication of Section 2.4.2, but
the latter part (and following paragraph/sentences) diverges.  There's
probably some room for consolidation and/or harmonization of procedures
here.

Section 4.2.4

(Presumably we ignore entires with unrecognized 'type'; I forget whether
this is standard DNS usage or we should mention it explicitly, though.)

Section 5

Is there any guidance to give to the Designated Experts in addition to
the default rules from RFC 8126?

Section 6

I like that the relay-discovery precedence rules minimize the
opportunity for an attacker to disrupt discovery and try to force a
different relay to be used (whether to afford an opportunity to tamper
with the traffic going to a target recipient or other reasons).  Since
we are updating the generic AMT relay discovery procedure, we could
reasonably mention that (and the generic risks with discovery procedures
that involve attempting to contact a relay and failing over if a timely
response does not appear); RFC 7450's Section 6.2 provides only a
minimal mention.  That said, most of the security considerations
relevant here seem to be ones that apply to stock AMT, and are tolerably
covered in RFC 7450.  I'm a little surprised that Happy Eyeballs doesn't
cover this sort of disruption in its security considerations; I was
going to suggest referencing that as well.

We briefly mention active/active failover in Section 2.3.3, and such a
scheme poses some risk of (additional) traffic duplication around a
failover event, but (1) that can happen with UDP anyway, so it will
already be handled, and (2) it's a pretty tenuous hook to say that we
need to talk about the security considerations of such a situation.

Also on the borderline of worth mentioning, an attacker might attempt to
force a gateway to repeatedly go through the relay discovery process; I
don't think this process is sufficiently resource-intensive that it
would be a usable DoS attack, though, so there's not really much there
other than the generic "disruption" that is already covered in 7450.

Section 6.2

Even though not all of the listed mechanisms are currently specified for
recursive-to-authoritative queries, I think it's fine to list them here,
as they are expected to become defined in the future and would make
sense as options, when available.

   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.

I don't think that it's really "authentication" that we're providing for
the RR itself; what we want is more of "source authentication" for the
provenance of the RR (and integrity protection for its contents).

   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.

Even for an honest AMTRELAY record, isn't there a chance that the
multicast traffic's contents could also be modified or injected by the
attacker?

Section 8.2

Arguably RFC 8499 would be normative, since we defer to its definition
of FQDN, but I am not really very concerned about it.

Appendix A

     $ ./translate.py amtrelays.example.com
     24
     09616d7472656c617973076578616d706c6503636f6d
   <CODE ENDS>

   The length and the hex string for the domain name
   "amtrelays.example.com" are the outputs of this program, yielding a
   length of 22 and the above hex string.

I'm having a hard time parsing this in a consistent way where the
yielded length is 22 and the literal command output is 24.