Re: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04

"Holland, Jake" <jholland@akamai.com> Mon, 09 March 2020 03:51 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9BD3A0FEC for <mboned@ietfa.amsl.com>; Sun, 8 Mar 2020 20:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 m5KSjCBWYWww for <mboned@ietfa.amsl.com>; Sun, 8 Mar 2020 20:51:39 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A53A3A0FEA for <mboned@ietf.org>; Sun, 8 Mar 2020 20:51:38 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0293iO1u005498; Mon, 9 Mar 2020 03:51:36 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=USpOYFJM2ZNYg/jrIxsKRP8FLyjgYmbhYiqHb9IJwXo=; b=oqrH5pYMuF5cYRtPpHpcgS8OyAiKfqPzolUvFMhFW5aLWE/9loKSr0TuQj6/52vuEelb uTehsdOJBuwgjn9/ACc0CtmwvJwYNBU69fnIX1ZgQCx1DSmUhokztKJxZkh7hhXpUJqa 3TLyXlnruc5lJDnEF7JHH+yrgRT0ETHnNa6PaM+CQtNJa8Xhs7u4WFH5UGWQ2eek1kxq lus2o55XI8oHiIHmL//ciKqycIIDe7PgKFXdAUvHePDL69ASFkH69ErjShivJDWGWZBT rDAk7nUXnVjojvQr20SbyZQbQ2ki/W+fUhiERGUAEXs2FKrXJN0T7E669BtgBm0ZR2yi Tg==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ym4wee778-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Mar 2020 03:51:36 +0000
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 0293nCaZ006948; Sun, 8 Mar 2020 20:51:35 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint5.akamai.com with ESMTP id 2ymafbh7hb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 08 Mar 2020 20:51:35 -0700
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 8 Mar 2020 23:51:34 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.006; Sun, 8 Mar 2020 23:51:34 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, "mboned@ietf.org" <mboned@ietf.org>
Thread-Topic: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04
Thread-Index: AQHV9ONfxdoQUPcKvkCP2NLAxrn/mqg/dvuAgABCKAD//5+VAIAAfSyA//+aFoA=
Date: Mon, 9 Mar 2020 03:51:34 +0000
Message-ID: <4C9F515D-5481-455D-8D0E-45963294590F@akamai.com>
References: <CABFReBqK8d=wYwDWzs64yFk_dB5U=tCOK90Tu3BffFAaxNf4OA@mail.gmail.com> <CAHANBtLDjzDbP=z-jjXEcJnY00dOLGV7_FC3_oQwDRa+QVYNUw@mail.gmail.com> <ad61bee9-ff3f-0ee3-ac28-11c9507e13d6@concordia.ca> <c1e2f1036a114153b981a676aafa788b@boeing.com> <F86DCB72-A098-4B6F-985A-A725D5B85F39@akamai.com> <6ba79ebab96145b78223f6d200e6c118@boeing.com>
In-Reply-To: <6ba79ebab96145b78223f6d200e6c118@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.112.140]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1805B8EAFD92FA449395060180C9ECDA@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-08_09:2020-03-06, 2020-03-08 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2003090025
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-08_09:2020-03-06, 2020-03-08 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003090025
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/CG9FLjPwuno3MtvYvgNcD5p69I4>
Subject: Re: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2020 03:51:41 -0000

On 3/8/20, 7:56 PM, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> wrote:
>    Thanks for the quick reply, Jake. Hmm. I get the packet size, but I thought that a manifest packet has to be sent for each multicast data packet? Is that wrong? That's the crux of my questioning. To me, the packets per unit time could become more of a scaling problem than packet size. This is what led me to believe that there is one manifest packet per data packet, although I admit, it's not 100% clear if this is the intention:

No, each data packet has to have a corresponding authenticated hash, but the hashes
can be delivered many per packet.  I'd usually expect to fit up to 90 or so 16-byte
hashes into each packet of the manifest stream.

It sounds like I should explain that point better if it's easily missed.  I'll look
for a good way to clarify that in the text.


    >> The problem with this is that the receivers do not trust each other, for instance
    in a video broadcast scenario.
    
>    Good answer! My own solution, even in AMT, if this problem that receivers don't trust each other exists, is to filter every received multicast for the correct source IP address. It does make AMT more like SSM, however the filter is simple enough to implement, when security becomes a concern. I would think this approach is much more lightweight and direct, no?

I think this is probably OK in some walled-garden situations with enough control of the
network, but in general the source IP address can be spoofed very easily, so we think we
need something more.

The threat model I'm thinking of here is:

1. Receiver joins (S1,G1)

2. AMT Gateway, with source IP/Port A1:P1 connects to AMT relay with A2:2268, propagates
the join, starts forwarding traffic.
(Now any AMT with source A2:2268, dest A1:P1, containing a multicast packet from S1->G1
will be forwarded in the Gateway's network and received by subscribed receivers)

3. Attacker can easily discover S1,G1 (maybe he owns a legitimate receiver), and can
also likely discover the viable options for A2, so he only needs to discover A1 and
P1, send it UDP traffic with source address spoofed as if it was from A2, and he can
inject packets that did not originate from the sender into the S1->G1 stream.

Certainly for an on-path attacker forwarding the AMT (or for that matter the multicast
packets), such an attack is trivial, and Section 3 of BCP 72 clearly describes this as an
important threat model.

But even off-path attackers can often send a packet with a spoofed source address, so an
off-path attacker has a slightly harder job since he can't watch the AMT connection, but
the possible A2*A1*P1 space can easily be small enough to scan effectively, and an attacker
in control of a legitimate receiver would be able to know when he found it by watching for
his probe to be received at the receiver.

To the extent BCP 38 and BCP 84 are ubiquitously deployed, it might not be possible for
every attacker from any end system to achieve the off-path attack, but we find that it's
not safe to rely on these entirely, so we think we need to provide some cryptographic
authentication, not just IP-checking.

(Nothing in the AMT Data-type packet prevents this kind of injection with AMT Data packets
in an established tunnel with an active join--the only crypto is during the handshake to
ensure 2-way connectivity.)

I hope that's helpful, and I think I probably should have explained this better in the
draft.  If this explanation makes sense, I'll try to turn it into a reasonable section
to add into the draft, and thanks!

Best regards,
Jake