Re: Tsvart last call review of draft-ietf-mboned-driad-amt-discovery-09

--===============7625657278399824351==
Content-Type: multipart/alternative; boundary="00000000000051a1da0598d3fa39"

--00000000000051a1da0598d3fa39
Content-Type: text/plain; charset="UTF-8"

>
> [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.
>
>
>

--00000000000051a1da0598d3fa39
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">[JH] I can add the text from Section 5.2.3.4.3 of RFC 74=
50 (referenced<br>
from the next paragraph), which contains a similar equation with that<br>
justification for the 120 second timer:<br>
<a href=3D"https://tools.ietf.org/html/rfc7450#section-5.2.3.4.3" rel=3D"no=
referrer" target=3D"_blank">https://tools.ietf.org/html/rfc7450#section-5.2=
..3.4.3</a><br>
&quot;<br>
=C2=A0 =C2=A0a RECOMMENDED maximum_timeout of 120 seconds (which is the<br>
=C2=A0 =C2=A0recommended minimum NAT mapping timeout described in [RFC4787]=
).<br>
&quot;<br>
<br>
Will that address this concern?<br></blockquote><div><br></div><div>[BA] Ye=
s.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Do you think the same text is necessary in both places? (Or<br>
necessary at all, given the reference to a very similar equation<br>
in the following paragraph?)<br>
<br>
I&#39;ve provisionally added it to both spots in my local copy, but<br>
please let me know if you think it should be different.[B<br></blockquote><=
div><br></div><div>[BA] Putting it in one place is sufficient.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[JH]=C2=A0 I =
agree that the text is a bit weak here, and that suggests it<br>
should be possible to improve, but I never was happy with any of the<br>
ideas I came up with--nothing I could find seemed both generic enough<br>
to be generally applicable and specific enough to be useful.<br>
<br>
If you think it&#39;s helpful, I can add something like &quot;The specifics=
<br>
of the health monitoring logic are out of scope for this document.&quot;<br=
></blockquote><div><br></div><div>[BA] This is an area where developing a s=
olid recommendation would require implementation and operational experience=
..=C2=A0 In the absence of that, it might be best to point out what is missi=
ng and leave it to future work.=C2=A0=C2=A0</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
(I also thought it might be best to just cut this section, but decided<br>
against that because I thought it better to acknowledge and encourage<br>
this where it&#39;s feasible.=C2=A0 Maybe that&#39;s a mistake?=C2=A0 My no=
t-very-firm<br>
judgement call was that leaving this in is better than nothing, but<br>
I&#39;ll take advice here.)<br></blockquote><div><br></div><div>[BA] The se=
ction is acknowledging a real problem so it&#39;s worth keeping, even if a =
recommended solution is not available at this time.=C2=A0</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">The issue is modific=
ation of the RRs.=C2=A0 (I assume an adversary who can<br>
observe the DNS request and poses a privacy threat is also likely<br>
positioned to observe the AMT traffic and its embedded subscriptions,<br>
which is already a worse privacy problem than the source-specific<br>
discovery request and is a pre-existing issue when using AMT, not added<br>
by this doc.)=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
<br>
The next paragraph in the same section (I thought) explained the threat<br>
model that this section was trying to address:<br>
&quot;=C2=A0 If an AMT gateway accepts a maliciously crafted AMTRELAY recor=
d, the<br>
=C2=A0 =C2=A0result could be a Denial of Service, or receivers processing<b=
r>
=C2=A0 =C2=A0multicast traffic from a source under the attacker&#39;s contr=
ol.&quot;<br>
<br>
Do you have a suggestion for improving on that explanation?=C2=A0 I&#39;m n=
ot<br>
sure where this fell short.=C2=A0 Do I need to spell out more about the<br>
possible consequences of accepting traffic from a source under an<br>
attacker&#39;s control?<br></blockquote><div><br></div><div>[BA] I raised t=
he question because the value of DoT or DoH wasn&#39;t clear to me in this =
context.=C2=A0 Based on the above, it might make sense to focus on DNSSEC a=
nd consider leaving out DoT or DoH.=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>
[JH]=C2=A0In particular: the DNS-SD service is not source-specific, and<br>
although it should be preferred where available for the reasons<br>
given in section 2.3.1, any network that can supply a valid relay<br>
via DNS-SD (one that can receive and forward multicast traffic<br>
from the given source) either has native multicast connectivity<br>
to the source (like perhaps you could do if the receive network was<br>
directly connected to the send network, rather than only reachable<br>
across the internet), or has an upstream AMT ingest point that<br>
relies on the AMTRELAY discovery (which today would be almost all<br>
networks that are not walled gardens, with the exception of i2).=C2=A0 I<br=
>
had thought this explanation was more or less covered by section 2.2.<br>
<br>
One day, I do hope the AMTRELAY record can be abandoned because<br>
there will be a native multicast backbone available everywhere.<br>
<br>
However, as a transition technology until that time, some mechanism<br>
for automatically connecting the multicast-enabled receiver islands<br>
to the multicast-enabled sender islands in a source-dependent way is<br>
necessary, which is what this document is trying to define, and which<br>
has previously been missing.<br>
<br>
I hope that clarifies things, and please let me know if you can<br>
suggest any place to add text that would have made this more clear on<br>
the first reading.<br>
<br>[BA] Thanks for the clarification.=C2=A0 Might be useful to add some of=
 the above explanation to the document.<br>
<br>
<br>
</blockquote></div></div>

--00000000000051a1da0598d3fa39--


--===============7625657278399824351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned

--===============7625657278399824351==--