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

From: Stig Venaas <[email-masked]>
Date: Sat, 7 Mar 2020 16:48:42 -0800

Support

Stig

On Mon, Jan 27, 2020, 10:31 Greg Shepherd <[email-masked]> wrote:

> MBONED,
>
> We had support in the room in Singapore for adoption. Time to take it to
> the list. Please read and respond w/ or w/o support to this thread.
>
> https://tools.ietf.org/html/draft-jholland-mboned-ambi-04
>
> Thanks,
> Shep
> (Chairs)
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: William Atwood <[email-masked]>
Date: Sun, 8 Mar 2020 17:16:37 -0400

Support.

  Bill

On 2020-03-07 7:48 p.m., Stig Venaas wrote:
> Support
>
> Stig
>
>
> On Mon, Jan 27, 2020, 10:31 Greg Shepherd <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     MBONED,
>
>     We had support in the room in Singapore for adoption. Time to take
>     it to the list. Please read and respond w/ or w/o support to this
>     thread.
>
>     [email-masked] <mailto:[email-masked]>

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 9 Mar 2020 01:13:24 +0000

On Mon, Jan 27, 2020, 10:31 Greg Shepherd <mailto:[email-masked]> wrote:
MBONED, 

> We had support in the room in Singapore for adoption. Time to take it to the list. Please read and respond w/ or w/o support to this thread.
>

If the manifests, in AMBI's current incarnation, are unicast, then why bother with the multicast stream at all? Why not unicast the data in authenticated or encrypted packets, the same way as the manifests have to be unicast?

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.

Bert

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 9 Mar 2020 02:28:19 +0000

Hi Bert,

Thanks for taking a look and for asking questions!

>    If the manifests, in AMBI's current incarnation, are unicast, then why bother with the multicast stream at all? Why not unicast the data in authenticated or encrypted packets, the same way as th…

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.

We do also hope eventually to publish a way to send the manifests over multicast
with a one-way asymmetric signature scheme, but that's not as far along yet, and
we think we can get a big efficiency gain even with the simpler unicast manifest
stream.

I went over this a bit in Singapore, if you want a slightly longer explanation:
https://www.youtube.com/watch?v=ttGJyd5is2w&t=1h07m45s

I maybe should also add a paragraph or 2 to the draft if this isn't clear from the
text, thanks for raising it.

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

The problem with this is that the receivers do not trust each other, for instance
in a video broadcast scenario.

So if all the receivers share a secret, there's a problem if any of those receivers
are able to inject traffic into the data stream, and that's not as hard as one might
wish if you're using AMT for ingest, or if the network itself injects traffic for its
end users (evidently this has happened before in some flavors of ad-hijacking, but
could also be used for things like packets of death that could compromise receivers).

This is addressed in one of the references from the intro section of AMBI describing
the motivation, but maybe I should import the description of that issue for a better
in-line explanation if it isn't clear.  But this section of TESLA gives an explanation:
https://tools.ietf.org/html/rfc4082#section-1

Best regards,
Jake

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 9 Mar 2020 02:56:19 +0000

-----Original Message-----
From: Holland, Jake <[email-masked]> 

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.

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?

Bert

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 9 Mar 2020 03:51:34 +0000

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

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.

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

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

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 9 Mar 2020 17:17:48 +0000

Support adoption

On Jan 27, 2020, at 9:25 AM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

MBONED,

Thanks,
Shep
(Chairs)
_______________________________________________
MBONED mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mboned

---

From: William Zhang <[email-masked]>
Date: Mon, 9 Mar 2020 16:41:48 -0400

I support adoption of all three drafts.

William

On Mon, Mar 9, 2020 at 1:18 PM Mankamana Mishra (mankamis) <mankamis=
[email-masked]> wrote:

> Support adoption
>
> On Jan 27, 2020, at 9:25 AM, Greg Shepherd <[email-masked]> wrote:
>
> MBONED,
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 10 Mar 2020 15:52:26 -0700

Overwhelming adoption vote. Thanks to all responders.

Authors, please re-sub w/ WG name.

Be well,
Shep