Subject: [rtcweb] JSEP nit: Size of <sess-id> in the o= line

From: Harald Alvestrand <[email-masked]>
Date: Sat, 3 Nov 2018 09:38:45 +0100

JSEP -24 currently says:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the initial value MUST be less than (2**62)-1, as
      required by [RFC3264 <https://tools.ietf.org/html/rfc3264>].  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the two highest
      bits being set to zero and the remaining 62 bits being
      cryptographically random.

There are two problems here:

- RFC 3264 actually doesn't place that restriction on the sess-id,
that's the restriction on the version field.

- Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1

Quote from RFC 3264:

   The offer (and answer) MUST be a valid SDP message, as defined by RFC <https://tools.ietf.org/html/rfc2327>
   2327 <https://tools.ietf.org/html/rfc2327> [1 <https://tools.ietf.org/html/rfc3264#ref-1>], with one exception.  RFC 2327 <https://tools.ietf.org/html/rfc2327> mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

So what's easiest to change, deployed code or JSEP?

This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855

-- 
Surveillance is pervasive. Go Dark.

---

From: Justin Uberti <[email-masked]>
Date: Sat, 3 Nov 2018 10:17:27 -0700

Agreed. Suggested new text:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the value MUST be less than (2**63)-1, to prevent
      negatives.  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the highest
      bit set to zero and the remaining 63 bits being
      cryptographically random.

On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand <[email-masked]>
wrote:

> - RFC 3264 actually doesn't place that restriction on the sess-id, that's
> the restriction on the version field.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 4 Nov 2018 00:04:06 +0100

> Agreed. Suggested new text:

Suggested addition: "As stated in RFC 3264, ...." - these are not new
requirements, they're repeating old requirements.
>       cryptographically random.

Suggested addition:

  The sess-version MUST be less than (2**62) - 1, to avoid overflow when
incrementing.

>
> On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     JSEP -24 currently says:
>
>     This note is also filed as
>     https://github.com/rtcweb-wg/jsep/issues/855
>
>     -- 
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Sat, 3 Nov 2018 23:50:41 -0700

SGTM