Re: [Tsv-art] [MBONED] Tsvart last call review of draft-ietf-mboned-driad-amt-discovery-09

Bernard Aboba <bernard.aboba@gmail.com> Tue, 03 December 2019 22:11 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E143120044; Tue, 3 Dec 2019 14:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljQiFV21Czek; Tue, 3 Dec 2019 14:11:31 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63BC12003F; Tue, 3 Dec 2019 14:11:30 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id a13so5609316ljm.10; Tue, 03 Dec 2019 14:11:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F7gjYegnYYqoSUXu/TIYz0C0Yar+ayWlq/d5dyECNB0=; b=QrGt/5YmhnN8IhzloCBBn2+OJQDtdmD7LuvuKN8fR4gaGal30tctwgaZt7vK92Im3H uvJE9auGRFHP3ft6tSPEtWuIgMfim9ya981LHPApwFF3CfXNRmwphZ+nGvrknwSfPLHd KQ7DnnPrG6TkGxKjh/0CPjrp+/UEZYQslyKBqLV+UqVRQIIxySL2+Vuic2H9z7b7gazE 2u+DkczdcWegK0N5rLFY5XG0idYi2ZtrfI4T9OJqFpZMe0XLKorRFGKOcoIYq4T3Rm/h ThBVDQt4YSmqfZc4EyJ4FfTloofSEaNPqISpVj7naOM5RbNrNTmK14LMwdudsg6LdcSJ e6Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F7gjYegnYYqoSUXu/TIYz0C0Yar+ayWlq/d5dyECNB0=; b=FrReEvURgBxo48RroysJlFFoCsZc/YeRC9CoCVDRF6SPMaLcJXyNuzGP9tQ3bnl44u iMmd84VXH28cQK4NTUAA1K/2fNghFrEoyyzCYVPtVwal8jkc/StjIwUSF3m2OhvN3u1U EWAscgah31hZ07oIfemfYZntkuzRtqUPNlSoxO2IZrSGurzdvbwjoIprtCgSS8ukWvbb ikX5IgDIp3l5n6MBI3gjBTJYQOmMJkHuSmMSi6d3zXRHYl6/3mqd3k/qQ5FOkc5Qa9kz cCUB2cm1Wu6c0tyVe9OLiSe2IOYVX+C8ras+QGNnxXuFUh/hP+CbhBYtAJZ0ZCSjlri+ ijsQ==
X-Gm-Message-State: APjAAAVYtT/wiHpxc6hcL6OS8AT8oT0UWDzNRVCnMTPC8vlZ7L2ZWX9m 9Ar5bFXneDH7FP8c5XZAIif7LAbQlND4yMgg7rA=
X-Google-Smtp-Source: APXvYqzSbrG+ZHtfpUe2R3Jw+RI2ooz/gNdFqICh4vmq6OHpeO+IkY5/4WWcsY9iJWlvnmb+rNlLeKqvQhjfvMHCg7U=
X-Received: by 2002:a2e:7005:: with SMTP id l5mr3940931ljc.230.1575411088720; Tue, 03 Dec 2019 14:11:28 -0800 (PST)
MIME-Version: 1.0
References: <157516457060.14457.16384103008148553530@ietfa.amsl.com> <6ECF7074-0579-448B-BB6A-DEDD3B414C22@akamai.com>
In-Reply-To: <6ECF7074-0579-448B-BB6A-DEDD3B414C22@akamai.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 03 Dec 2019 14:11:17 -0800
Message-ID: <CAOW+2dtsojmMRuz_OMb8EnKy8-6XxVg6u3sBndDYcqY11XiKNQ@mail.gmail.com>
To: "Holland, Jake" <jholland@akamai.com>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-mboned-driad-amt-discovery.all@ietf.org" <draft-ietf-mboned-driad-amt-discovery.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051a1da0598d3fa39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Jgt0QSPRmz6mBWE4InP7gRkTTYE>
Subject: Re: [Tsv-art] [MBONED] Tsvart last call review of draft-ietf-mboned-driad-amt-discovery-09
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2019 22:11:33 -0000

>
> [JH] I can add the text from Section 5.2.3.4.3 of RFC 7450 (referenced
> from the next paragraph), which contains a similar equation with that
> justification for the 120 second timer:
> https://tools.ietf.org/html/rfc7450#section-5.2.3.4.3
> "
>    a RECOMMENDED maximum_timeout of 120 seconds (which is the
>    recommended minimum NAT mapping timeout described in [RFC4787]).
> "
>
> Will that address this concern?
>

[BA] Yes.

>
> Do you think the same text is necessary in both places? (Or
> necessary at all, given the reference to a very similar equation
> in the following paragraph?)
>
> I've provisionally added it to both spots in my local copy, but
> please let me know if you think it should be different.[B
>

[BA] Putting it in one place is sufficient.


> [JH]  I agree that the text is a bit weak here, and that suggests it
> should be possible to improve, but I never was happy with any of the
> ideas I came up with--nothing I could find seemed both generic enough
> to be generally applicable and specific enough to be useful.
>
> If you think it's helpful, I can add something like "The specifics
> of the health monitoring logic are out of scope for this document."
>

[BA] This is an area where developing a solid recommendation would require
implementation and operational experience.  In the absence of that, it
might be best to point out what is missing and leave it to future work.


> (I also thought it might be best to just cut this section, but decided
> against that because I thought it better to acknowledge and encourage
> this where it's feasible.  Maybe that's a mistake?  My not-very-firm
> judgement call was that leaving this in is better than nothing, but
> I'll take advice here.)
>

[BA] The section is acknowledging a real problem so it's worth keeping,
even if a recommended solution is not available at this time.


> The issue is modification of the RRs.  (I assume an adversary who can
> observe the DNS request and poses a privacy threat is also likely
> positioned to observe the AMT traffic and its embedded subscriptions,
> which is already a worse privacy problem than the source-specific
> discovery request and is a pre-existing issue when using AMT, not added
> by this doc.)


> The next paragraph in the same section (I thought) explained the threat
> model that this section was trying to address:
> "  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."
>
> Do you have a suggestion for improving on that explanation?  I'm not
> sure where this fell short.  Do I need to spell out more about the
> possible consequences of accepting traffic from a source under an
> attacker's control?
>

[BA] I raised the question because the value of DoT or DoH wasn't clear to
me in this context.  Based on the above, it might make sense to focus on
DNSSEC and consider leaving out DoT or DoH.

>
> [JH] In particular: the DNS-SD service is not source-specific, and
> although it should be preferred where available for the reasons
> given in section 2.3.1, any network that can supply a valid relay
> via DNS-SD (one that can receive and forward multicast traffic
> from the given source) either has native multicast connectivity
> to the source (like perhaps you could do if the receive network was
> directly connected to the send network, rather than only reachable
> across the internet), or has an upstream AMT ingest point that
> relies on the AMTRELAY discovery (which today would be almost all
> networks that are not walled gardens, with the exception of i2).  I
> had thought this explanation was more or less covered by section 2.2.
>
> One day, I do hope the AMTRELAY record can be abandoned because
> there will be a native multicast backbone available everywhere.
>
> However, as a transition technology until that time, some mechanism
> for automatically connecting the multicast-enabled receiver islands
> to the multicast-enabled sender islands in a source-dependent way is
> necessary, which is what this document is trying to define, and which
> has previously been missing.
>
> I hope that clarifies things, and please let me know if you can
> suggest any place to add text that would have made this more clear on
> the first reading.
>
> [BA] Thanks for the clarification.  Might be useful to add some of the
> above explanation to the document.
>
>
>