Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS)

From: Alissa Cooper <[email-masked]>
Date: Fri, 11 Sep 2015 09:57:43 -0700

Adding Paul to this thread as he will helping to resolve comments on this draft.

> On Mar 5, 2015, at 7:01 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Spencer,
> 
> I think I can help with the last part of your discuss after reading this to help reduce the list...
> 
> On Wed, Mar 4, 2015 at 11:38 PM, Spencer Dawkins <[email-masked] <mailto:[email-masked]>> wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-bfcpbis-rfc4582bis-13: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html <http://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:
> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ <http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/>
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> For the moment, I'm balloting a process Discuss, because I'm not seeing a
> response to Gorry Fairhurst's TSV-DIR review sent on March 2, at
> https://www.ietf.org/mail-archive/web/ietf/current/msg92156.html <https://www.ietf.org/mail-archive/web/ietf/current/msg92156.html>. Did I
> miss it?
> 
> During my review, I did not see a definition of "transaction failure
> window". I can guess what that means, but would love to know for sure.
> 
> I'm understanding that in RFC 4582, the version number (1) was a version
> number, but in this draft, version 1 means "reliable transport" and
> version 2 means "unreliable transport". Is that right? If so, how does an
> RFC 4582 TCP-only floor control server receive a message with a version
> field set to 2, which would have been sent over UDP?
> 
> I'm also wondering whether overloading the version number field as a
> transport reliability indicator would cause a problem in the future. If
> you end up with a mandatory extension that applies to both reliable and
> unreliable transport, does that mean you'd use two version numbers
> (possibly 2 for reliable and 3 for unreliable)?
> 
> Within Gorry's review, these are the points I thought were
> Discuss-worthy. It's probably best for you to reply to these in his
> e-mail, rather than try to juggle two sets of overlapping comments. I'm
> just pointing out what I think matters most. On the others, please do the
> right thing.
> 
> -
> 
> Gorry asked in Section 5:
> 
> What is the security model when TLS/DTLS is not used? - has the protocol
> protection from off-path attacks, and how is this provided?
> 
> I'm especially interested in this question when unreliable transport is
> used without DTLS. This is probably related to the question about
> randomizing Conference ID later in Gorry's review.
> 
> See section 7:
>    BFCP floor control servers
>    and clients (which include both floor participants and floor chairs)
>    MUST support TLS for transport over TCP [6] and MUST support DTLS [7]
>    for transport over UDP.  Any BFCP entity MAY support other security 
>        mechanisms. 
> 
> This covers MTI, we usually don't get into MTU.  Are you asking that the properties required for other secure transport alternatives be listed?  If someone doesn't want to turn on encryption and have that session established securely, they could have a really 'fun' conference session.
> 
> 
> -
> 
> Payload Length:
> - What happens when using a datagram format if the datagram length (e.g.
> UDP-Length) is less or more than the value specified within the BFCP?
> 
> -
> 
> Fragment Length:
> - What happens if the datagram length (e.g. UDP-Length) is less or more
> than the value specified within the BFCP?
> 
> I'd also like to see this covered to explicitly prevent fragmentation overlap attacks, so I'll add a discuss as I think it's important to have this stated.
> 
> Thanks,
> Kathleen 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 23 Sep 2015 06:26:32 +0000

Spencer,

Following up on this email (and building a growing to-do list)....

------ Original Message ------
From: "Spencer Dawkins" <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]
Sent: 3/4/2015 11:38:26 PM
Subject: [bfcpbis] Spencer Dawkins' Discuss on 
draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS)

>Please refer to 
>http://www.ietf.org/iesg/statement/discuss-criteria.html
>http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
>
>
>
>https://www.ietf.org/mail-archive/web/ietf/current/msg92156.html. Did I
>miss it?

I did not see a reply, either, so I just sent one.  Several good points 
in there, as you might see in my response.

>window". I can guess what that means, but would love to know for sure.

Agree, this would help to have that term.

>field set to 2, which would have been sent over UDP?
You understanding of "ver" is correct.  The error-handling text is there 
just for completeness. In theory, there should never be a ver==1 over 
UDP or ver==2 over TCP.

>(possibly 2 for reliable and 3 for unreliable)?

If a version 3 device sends messages over TCP, then the v1/v2 servers 
will reject it.  That would have to be dealt with at that time, such as 
falling back to v1 mode if the server is v1.

>just pointing out what I think matters most. On the others, please do 

He had a lot of good points.  I replied to each one, so I'll not repeat 
that here (as you suggest).

>than the value specified within the BFCP?
All of the above are in a reply to Gorry (and I CC'd you).

Paul