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

"Manfredi (US), Albert E" <> Mon, 09 March 2020 02:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6167F3A0EDF for <>; Sun, 8 Mar 2020 19:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hWa7ELUXHnwW for <>; Sun, 8 Mar 2020 19:56:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D8D3A0ED8 for <>; Sun, 8 Mar 2020 19:56:26 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0292uNVO019926; Sun, 8 Mar 2020 22:56:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1583722584; bh=3QFInPRvXLpY4/NgNCOWPrXHiW6G+pwPoSE8zbsuUw8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=KSL7TrsdqwLRpx17UnW3FyfhLl0gwLP3/eZpyMzr9TzSu4KEr7/Vo+JwvBO2a3vLJ WXReIhC0CMotbdErmjLKWOuCzBKNe13R6NVlEtwG2CGnuXyeyWeY1drM9tLuTe+3AK vj+6T5nbTvSvNUYwBD7vIcnHuCEy9dHmM5/wErynD8PO5wWAKBhZZfnzRw5uN/nxF4 P9zryIYXJHIjTGi+gbIW9kjTtm1EYFeOVUs5A0vU1cwASncjf2FA74gJPU+KWmOGOl UG7C9aYWUWKq5jEyouoFNLC1ywPH5CHCgwVX1YHqBa9s34UIlr8OzvtZmkNGRSVkef 6ibgPmVQmd4rA==
Received: from ( []) by (8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0292uLE6019052 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 8 Mar 2020 22:56:21 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1913.5; Sun, 8 Mar 2020 19:56:20 -0700
Received: from ([fe80::a96c:5d85:1337:4323]) by ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1913.005; Sun, 8 Mar 2020 19:56:20 -0700
From: "Manfredi (US), Albert E" <>
To: "Holland, Jake" <>, "" <>
Thread-Topic: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04
Thread-Index: AQHV9Zaky/Sj+UOtYU2epv20XG6sMKg/baDggACRVoD//4vsoA==
Date: Mon, 9 Mar 2020 02:56:19 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: E5FDFB452F3CF638C562E1D413B1C3FBC8D0599A7A3E73B120D9C13E67A39B672000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2020 02:56:39 -0000

-----Original Message-----
From: Holland, Jake <> 

> For scale.  If you're sending full-sized (~1500-byte) multicast packets, the
authenticated manifest stream is only 1-3% of the data stream, so even with
unicast manifests you get a substantial benefit.

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:

2.1.  Overview

   In order to authenticate a data packet, AMBI receivers need to hold
   these three pieces of information at the same time:

   o  the data packet; and

   o  an authenticated manifest containing the packet digest for the
      data packet; and

   o  a digest profile defining the transformation from the data packet
      to its packet digest.

   The manifests are delivered as a stream of manifests over an
   authenticated data channel.  Manifest contents MUST be authenticated
   before they can be used to authenticate data packets.

   The manifest stream is composed of an ordered sequence of manifests
   that each contain an ordered sequence of packet digests,
   corresponding to the original packets as sent from their origin, in
   the same order.

2.2.  Buffering and Validation Windows

   ... While holding a data packet, if the corresponding packet digest for
   that packet arrives in the manifest stream and can be authenticated,
   the data packet is authenticated.

>> Conversely, for authenticated or encrypted multicast traffic, is it not simpler to use a symmetric key stream cipher, with wide enough packet sequence numbers to permit the new secret key to be sent to all multicast group members, out of band, at a relatively low rate? If you can show that the sequence number never repeats, with a given secret key, you're done. Let's say, update the secret key daily, using any low data rate key exchange protocol.
> 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?