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

Hi Jake!

On Fri, Dec 20, 2019 at 06:14:12PM +0000, Holland, Jake wrote:
> 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.

Seems reasonable; thanks for thinking it through all the way.

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

That sounds good and is not too verbose, so probably is worth including.
Thanks!

-Ben

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