[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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
