Re: [MMUSIC] 10 BUNDLE questions

Justin Uberti <juberti@google.com> Mon, 18 March 2013 03:20 UTC

Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3521F8C7D for <mmusic@ietfa.amsl.com>; Sun, 17 Mar 2013 20:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.975
X-Spam-Level:
X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhm2KL3t+amu for <mmusic@ietfa.amsl.com>; Sun, 17 Mar 2013 20:20:16 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id A1E4A21F8C77 for <mmusic@ietf.org>; Sun, 17 Mar 2013 20:20:14 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id o13so1402692qaj.1 for <mmusic@ietf.org>; Sun, 17 Mar 2013 20:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EYW7o8bgsZa9jbhTGz4ZkiqE6CX3CPSiOKYpFCCpsFk=; b=YgadBk46FZI06DEfALr66ahovbMgCX67TNRlwy4AZcSZ0DA1T7csY+PAQwV4+l81pp Zzb92iQ04Z2EXFM/VjvJuFOPAG5klBl0xF+VjPcTlOQ6ILwuci1qcnq0ZknUSOS6Fb04 CO6jRVd8SnW3oaKUKtNXCN9cgv3Pdfh/6hBMJcz7fKYDWTQMNMzDuedZXUakDWZ84mVO SUue8cDmPJjLJrjUvKFS++7c/gJjUv4AZeRaO/rMh4oDCOGwTch7H7NWIDAwm8KGYQn+ n6S5DnwnRI/Xf1lrHgvFjQ9cpZ1ckSnHb6zgo+EVWYhN/MWx53MGB9ZRumLSOMRz5Pyo e+4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=EYW7o8bgsZa9jbhTGz4ZkiqE6CX3CPSiOKYpFCCpsFk=; b=oZzUZJXmHhqWwiWoWs1CRfK9aC5mFqAehHacTdI4JaTlwoUkRXGMxKMgp7Xa/7vZmb C0Fc0IQ24t8MZ3dRaOo3h/RADBgyxp2kXao/8lwvPh5RZ64sTQMhI+pWMAcMYtkeqf1H kmnETo3AoU9q3yMZxKaJTmGS/E768fnYNirPFSzBFD8YYuGDGM3u9967iSRMPcpzW/Da /NZKgmEqGALIDwlcsDUSLICWjAUCZjJlF1jCW81bEu/ScGziS+4Q7DX+ydwiWPqY+vqH QiJx67Pi+pxFuiiR+Uhx/4fock+Sy4p2Sz5+GcjD/gH5vIDBWjW4hbj+bymi2J75VVxz aGTg==
X-Received: by 10.224.42.66 with SMTP id r2mr17693296qae.36.1363576812962; Sun, 17 Mar 2013 20:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.138.3 with HTTP; Sun, 17 Mar 2013 20:19:49 -0700 (PDT)
In-Reply-To: <5145786F.8060507@alvestrand.no>
References: <CAOJ7v-0tr6_HAPwOnLD_De-LkNCsj1EfLhZL=G_B=k5tz9Hkwg@mail.gmail.com> <5145786F.8060507@alvestrand.no>
From: Justin Uberti <juberti@google.com>
Date: Sun, 17 Mar 2013 20:19:49 -0700
Message-ID: <CAOJ7v-0X2KbAgQpf0wN7wq0=eumAA300tn2TVWHPwmMrcJq8uw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=20cf3074b63e8f9b3904d82a77c8
X-Gm-Message-State: ALoCoQlsMTR2zjSnCNjih7xK4hHNnmeWFS7/HfiSKX/3Z6Szgrr706cDXaha473mNIkKSV5WdTazthaeFfzPUblzu2OyH1HbiUyCvJtW3K/RMMZ05nqYNjqNFn3Q3wbnRkmG8B8T7w1eZd1fYlO80EagQxgbhHZcgBF2QNxBwF0OPndm1yihZMjJYx3/dh5qVzinI8xNIxAh
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2013 03:20:17 -0000

On Sun, Mar 17, 2013 at 1:01 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 03/15/2013 09:51 PM, Justin Uberti wrote:
>
> The list below is a set of questions (some marked as OPEN ISSUE already)
> regarding the new BUNDLE proposal. If you agree with my suggested answers,
> I'm willing to contribute text accordingly.
>
>    1. Can you create a BUNDLE with a single m= line? (assuming yes)
>    2. Can you create multiple BUNDLEs? (assuming yes)
>    3. When creating an initial offer, how should we deal with the case
>    where a "null" port is to be used with trickle ICE (since 6.1:1 indicates
>    the ports MUST be different)
>
>   Tangential, sort of - when creating an initial offer, when would one
> need to use a null port?
> We're creating the offer, if we don't want the m-line, we can omit it
> altogether.
> (This was one of the things that simplified the problem when Christer,
> Cullen and I were discussing this version).
>

If you are hiding your source address when doing trickle, some non-zero
port # needs to be put into the offer. The current thinking was to use port
9 for this, but this would mean all m= lines would share port 9, although
their ICE info would be different.

This is a corner case, but I think we should specify the behavior exactly.

>
>
>
>    1. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>    use same c=, add rtcp-mux, same a=fingerprint)
>    2. From 6.1, list 2 - is condition 6 right? Why would we use different
>    SDES keys for a single RTP session?
>
>   Having the same SDES keys for two RTP sessions runs the risk of a
> two-time pad attack, I think (needs some other things to be the same too,
> but I don't think there's a guard against that anywhere). So this is a
> fatal flaw if the negotiation results in non-BUNDLE.
>

I was referring to 6.1, list 2, which indicates the behavior to be used
when we know we are BUNDLEing (i.e. one RTP session). List 2 says to use
different SDES keys in this case.

>
> The lists could be better formatted - only 1, 3 and 4 are different
> between the lists, I think it's good to keep the differences between
> "before BUNDLE" and "after BUNDLE" minimal, but one should call out the
> differences.
>
>
>
>    1. If you start with a m= line with one SDES config (e.g. 32-bit MAC),
>    and then BUNDLE with another SDES line with a different (non overlapping)
>    SDES config (e.g. 80-bit MAC), what happens? (assume fail)
>
>   I assume so too. This should be noted.
>
>
>    1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>    the offer, what happens? (assume fail)
>
>   I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>

According to 9.2, the only restriction is the answer mids must be a subset
of the offer, so we would have to specify an exact match directly. But I
think we do want to impose this restriction, or else we can't BUNDLE a new
m-line until we know the other side wants to BUNDLE it as well.

>
>
>    1. If you add a m= line to an existing BUNDLE, can the recipient
>    reject that BUNDLEing (assume no)
>    2. If m= lines are rejected, should their mids show up in the BUNDLE
>    answer? (assume yes?)
>
> Turns out 5888 spells out the behavior here, namely the mids do not
appear.

>
>     1. If not, how does remote side indicate BUNDLE support if it rejects
>       the m= lines that are BUNDLEd?
>
> 5888 also says an empty a=group:BUNDLE line is permissible, so this is a
non-issue.

>
>     1. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>    that were previously BUNDLEd (assume no)
>
>
> Syntactically, it's easy (omit the mid from the a=group:bundle line);
> semantically, I think it hurts my mind to think about what should happen in
> the RTP session(s) and when, so let's just outlaw it.
>

SGTM

>
>
>
> _______________________________________________
> mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>