Subject: [AVTCORE] Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 17:34:03 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-avtcore-rfc5285-bis-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Why are you allowing this extension to be "normal" in BUNDLE?
If you're bundling, you should be modern enough to handle
mixed, no? Why not make life simple?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   There are two variants of the extension: one-byte and two-byte
   headers.  Since it is expected that (a) the number of extensions in
   any given RTP session is small and (b) the extensions themselves are
   small, the one-byte header form is preferred and MUST be supported by
   all receivers.  A stream MUST contain only one-byte or two-byte

"or only two-byte" would be clearer.

   headers unless it is known that all recipients support mixing, either
   by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
   of-band knowledge.  Each RTP packet with an RTP header extension
   following this specification will indicate if it contains one or two
   byte header extensions through the use of the "defined by profile"
   field.  Extension element types that dp not match the header

do not match

   extension format, i.e. one- or two-byte, MUST NOT be used in that RTP
   packet.  Transmitters SHOULD NOT use the two-byte form when all
   extensions are small enough for the one-byte header form.
   Transmitters that intend to send the two-byte form SHOULD negotiate
   the use of IDs above 14 if they want to let the Receivers know that
   they intend to use two-byte form, for example if the RTP header
   extension is longer than 16 bytes.  A transmitter may be aware that
   an intermediary may add RTP header extensions in this case, the
   transmitter SHOULD use two-byte form.

I think you want '; in this case...." if this means what I think it
means.

   assignment of different IDs.  Any RTP header extension that do not

does not

   match this assumption MUST explicitly provide rules for what are

   cipher.  It can be noted that the default SRTP ciphers (AES CM 128
   bits with HMAC-SHA1) are relative weak and more modern ciphers are
   stronger and should be considered.

What's weak about AES-CTR-HMAC? I recognize that this was in the
secdir review, but I'm not sure what claim you are making here.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Jun 2017 15:57:40 +0000

Hi Eric,

As Shepherd I have some questions and comments below regarding the discuss.

So Normal allows individual negotiation on a per m= line. This was
discussed in the WG see the thread starting with this message:
https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk

I was arguing for Identical to make things simple and consistent,
however both David Singer and Roni Even disagreed, so I let it go as
soon as what was specified could work. 

Or the above a question of considering mandating allowed mixed support
if one offers BUNDLE?

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Jun 2017 05:08:22 +0000

Hi,
Inline 
Roni

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: יום ג 20 יוני 2017 03:34
> To: The IESG
> Cc: [email-masked]; Magnus Westerlund; avtcore-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12: (with
> DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> If you're bundling, you should be modern enough to handle mixed, no? Why
> not make life simple?
[Roni Even] I saw that Magnus responded to this one
[Roni Even] OK
>    field.  Extension element types that dp not match the header
[Roni Even] OK
> I think you want '; in this case...." if this means what I think it means.
[Roni Even] OK
>    assignment of different IDs.  Any RTP header extension that do not
[Roni Even] OK
> What's weak about AES-CTR-HMAC? I recognize that this was in the secdir
> review, but I'm not sure what claim you are making here.
[Roni Even] The default ciphers were defined in RFC5285, this document is a bis draft so we did not want to change the default ciphers for backward interoperability. 
I discussed the issue of ciphers with Magnus when responding to the secdir review. In general we claimed that this is not the document in which we change ciphers discussed in RFC3711 (SRTP) and RFC 6904 (header extensions encryption).
So this text is just a note . If you can suggest some other text to clarify this note I will be happy to use it.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Jun 2017 06:09:46 -0700

On Tue, Jun 20, 2017 at 10:08 PM, Roni Even <[email-masked]> wrote:

> email

Yes. I think this is the wrong decision, but I agree it's a WG decision.
I'll clear
my discuss.

> [Roni Even] The default ciphers were defined in RFC5285, this document is
> a bis draft so we did not want to change the default ciphers for backward
> interoperability.
> I discussed the issue of ciphers with Magnus when responding to the secdir
> review. In general we claimed that this is not the document in which we
> change ciphers discussed in RFC3711 (SRTP) and RFC 6904 (header extensions
> encryption).
> So this text is just a note . If you can suggest some other text to
> clarify this note I will be happy to use it.
>

I would just remove the note.

-Ekr

---

From: "Roni Even" <[email-masked]>
Date: Wed, 21 Jun 2017 16:51:36 +0300

Hi, 

I have no problem to remove the note, I also see no value there. It is there because of the secdir review

Roni

From: avt [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, June 21, 2017 4:10 PM
To: Roni Even
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12: (with DISCUSS and COMMENT)

Hi,
Inline
Roni

Yes. I think this is the wrong decision, but I agree it's a WG decision. I'll clear

my discuss.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Thu, 22 Jun 2017 11:32:30 +0000

inline

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
[Roni Even] It is not a question about handing mixing if you bundle but if there is a use case where you do not want to mix for one of the m-lines. This is the discussion since even if you use normal you can still do identical (for example by having the allow mixing at the session level) but not the opposite.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Jun 2017 05:53:54 -0700

Yes, I understand that, but why would you not want to mix? I assume merely
because your implementation can't handle it, right? Is there some other
reason?

-Ekr

On Thu, Jun 22, 2017 at 4:32 AM, Roni Even <[email-masked]> wrote:

> [Roni Even] It is not a question about handing mixing if you bundle but if
> there is a use case where you do not want to mix for one of the m-lines.
> This is the discussion since even if you use normal you can still do
> identical (for example by having the allow mixing at the session level) but
> not the opposite.
>
>
>

---

From: Roni Even <[email-masked]>
Date: Thu, 22 Jun 2017 13:15:31 +0000

Want to use only one byte header extensions for the audio for routing audio on low bandwidth link. Anyhow many of the RTP header extensions will be different between the audio and video
Roni

From: Eric Rescorla [mailto:[email-masked]]
Sent: יום ה 22 יוני 2017 15:54
To: Roni Even
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12: (with DISCUSS and COMMENT)

Yes, I understand that, but why would you not want to mix? I assume merely because your implementation can't handle it, right? Is there some other reason?

-Ekr

On Thu, Jun 22, 2017 at 4:32 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
inline

> From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; Magnus Westerlund; avtcore-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Jun 2017 06:20:59 -0700

On Thu, Jun 22, 2017 at 6:15 AM, Roni Even <[email-masked]> wrote:

> Want to use only one byte header extensions for the audio for routing
> audio on low bandwidth link.
>

But mixed mode allows this.

> Anyhow many of the RTP header extensions will be different between the
> audio and video
>

I don't see how this is relevant.

-Ekr

> Roni
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* יום ה 22 יוני 2017 15:54
> *To:* Roni Even
> *Cc:* The IESG; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-avtcore-rfc5285-bis-12:
> (with DISCUSS and COMMENT)
>
>
>