Re: [MSEC] QUIC multicast

[Behcet Sarikaya <[e-mail]>]

On Tue, Jun 28, 2022 at 12:37 PM Holland, Jake <[e-mail]> wrote:

> Hi Behcet,
>
>
>
> I’d encourage you to read sections 1 and 4 of the draft, which try to
> cover this in some detail.
>
>
>
> The summary answer is that there’s always a unicast connection as an
> anchor, but the server can ask the client to additionally join multicast
> channels that carry QUIC packets that can be decoded by the client using
> information that was passed to the client over the unicast connection.
>
>
>
> Those packets have a channel id instead of a connection id, as well as
> secrets that are generated and distributed differently than the unicast
> secrets (with the in-depth examination of the security consequences of this
> covered in our earlier draft-krose-multicast-security doc), but the
> handling is otherwise very similar to handling for QUIC multipath packets.
>
>
>


It sounds like a lot of stretch  to me, multipath is basically for
mobility, here you don't have the same thing.

Behcet

> HTH.
>
>
>
> -Jake
>
>
>
> *From: *Behcet Sarikaya <[e-mail]>
> *Reply-To: *"[e-mail]" <[e-mail]>
> *Date: *Tue,2022-06-28 at 8:53 AM
> *To: *"Holland, Jake" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [MSEC] QUIC multicast
>
>
>
>
>
>
>
> On Mon, Jun 27, 2022 at 10:48 AM Holland, Jake <jholland=
> [e-mail]> wrote:
>
> Hi msec,
>
> One of the actionable pieces of feedback[1] from the secdispatch
> presentation of draft-krose-multicast-security at IETF 112 was
> that we needed a concrete protocol proposal in order to evaluate
> the security considerations, so we went ahead and made a
> concrete proposal for multicast QUIC:
> https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-jholland-quic-multicast/__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lv2dGuCBA$>
> https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast
> <https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/draft-jholland-quic-multicast__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lsEw-3FOg$>
>
> We think this proposal meets the security goals given in
> draft-krose-multicast-security (plus the one that Ekr raised that
> we haven't added text for about web content needing to be associated
> with a url), but if you can see any sense in which this draft falls
> short or is unclear on how those security properties are achieved,
> we'd love to get that feedback (and suggestions on fixing it if you
> have any).
>
> I haven't sent this to quic yet, but will do so before long
> unless anyone in msec can point out a critical flaw.  I'm planning
> to ask for a short slot in quic to present at 114.  My main question
> will be about what wg members would want to see addressed before
> we ask for adoption (not planning to ask for adoption this time yet),
> plus soliciting general feedback.
>
>
>
> Before sending to quic, will you please let me know how multicast will
> work with a connection oriented  transport protocol which Quic largely is?
>
>
>
> Behcet
>
> -Jake
>
> PS: several members of the W3C Multicast Community Group have
> been working on an implementation and we'll have a table at the
> hackathon, so if you'd like to be involved with that, please let
> me know.
>
> [1] notes from the secdispatch feedback:
> https://mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lsbbSpK7w$>
>
>
> _______________________________________________
> MSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/msec
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/msec__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4luYDboKgw$>
>
>