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

Thanks Ben!

2 more responses for the hopefully final rev:

On 2019-12-19, 18:47, "Benjamin Kaduk" <[email protected]> wrote:
> The potential edit (not quite a suggestion) was to note that when we're
> using a relay-discovery procedure that involves "try one, and fall over to
> another one if it doesn't work", an attacker can disrupt one (or more)
> attempts early in the procedure to try to force a particular relay to be
> used.  (That might be with the ultimate goal to intercept traffic, to alter
> traffic, to gain the ability to selectively drop traffic, or otherwise, but
> it's not terribly interesting for this point.)  Furthermore, the particular
> procedure that we've chosen reduces the ability of an attacker to do so,
> since we try the relays that are "closer" (and thus harder to attack)
> first.

This is an interesting point, but I'm reluctant to claim that this
improves the security in practice, so I'm thinking I'll leave it out.

The reason being that although we take a close relay first (with DNS-SD,
for instance), and although that relay might be hard for an off-path
attacker to disrupt, it's likely that upstream of the DNS-SD connection
there's another gateway using DRIAD to connect to a sender-advertised
relay (the main other option being native multicast connectivity to the
sender, which is uncommon on today's internet).

So I think the "find a close relay first" approach likely doesn't do
enough to warrant a mention as a useful mitigation to this issue, because
an attacker who can disrupt a connection and force retrying to his target
could still disrupt another connection further upstream that's still a
part of the path.  Ultimately all the traffic from a sender would usually
come from relays known to the sender, except where there's native multicast
connectivity all the way to a "close" gateway (or to the receiver), which
in practice today is mostly just walled garden scenarios that already
limit the reachability for this kind of attack.

>> Yes, but this is generic to AMT and is mentioned in the 2nd paragraph of
>> Section 6.2 of RFC 7450.  I guess it's a fair point that it's not clear
>> the warning there is entirely adequate--should I try to write a section
>> about this on the grounds that I'm updating 7450 and making it more
>> widely deployable?
>
> I don't insist on it, so maybe give it a quick go and see if it looks good.

I'll add a paragraph to the bottom of "6.1 Use of AMT" section:

   Note that AMT does not itself provide any integrity protection on
   Multicast Data packets (Section 5.1.6 of [RFC7450]), so absent
   protections like those mentioned above, even an off-path attacker who
   discovers the gateway IP, the relay IP, and the relay source port for
   an active AMT connection can inject multicast data packets for a
   joined (S,G) into the data stream if he can get data packets
   delivered to the gateway IP that spoof the relay as the source.


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