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

[Kathleen Moriarty <[e-mail]>]

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 <
[e-mail]> 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
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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. 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